Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Efficiency of let/and
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-09-27 (13:06)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] Re: Ant: Efficiency of let/and

On Tue, 27 Sep 2005, skaller wrote:

> On Mon, 2005-09-26 at 11:30 -0500, Brian Hurt wrote:
>> I'm not even sure how much extra efficiency is there to be had.  Obviously
>> it'd be hard "thread" calls to complex functions,
> Why? Hyperthreading allows two completely independent processes
> to execute on a hyperthread enabled P4 .. the hardware can already
> do it .. even better with dual core.

Creating a new kernel-level process/thread (required to get code executing 
on a different processor or pseudo-processor) is generally expensive.  You 
don't want to do it except for very large functions.  And then, once you 
do have the second thread of execution, you now have all the fun of 
multithreaded code- race conditions and deadlocks and livelocks, oh my.

I have contemplated writting a purely-functional (no imperitive) language 
that does micro-threads ala cilk- but it's more work than I really want to 
put in to that project.

> There is no lack of small scale low level parallelism in
> modern computing systems, just a lack of software that knows
> how to take advantage of it.

The benefit may be there, theoretically, but practical considerations may 
make it not worth the effort to go after the benefit.

> There are plenty of places in an average program where one
> can determine parallel execution would be ok, so it is really
> a lack of capability in the software.
> I personally don't think of this as real parallelism,
> that's something you get on a machine with K's or M's
> of processing units .. eg the human eye.

Heh.  We've hit the point where we have so many transistors on a chip we 
literally don't know what to do with them all- we have no idea how to 
spend the transistors to provide more than very small incremental 
performance improvements to single-threaded execution.  Which is why the 
sudden interest in parallelism (Symmetric Mult-Threading aka 
Hyperthreading, multi-core chips, etc.).  The problem is that the theory 
on how to write race condition/deadlock/livelock -free code isn't there, 
to my knowledge (someone please prove me wrong).