Re: [Caml-list] Why systhreads?

[Chris Hecker <checker@d6.com>]

>If you want your application to parallelize well, the winning design 
>pattern seems to be message passing between distributed memory processes.

I was going to let it drop after the "lecture" (which should be put in a 
faq or something), but come on, this is a silly generalization.  I have 
colleagues who have gotten very large speedups from hyperthreading on 
commercial applications, not demos.  The point is, it's "free" for Intel to 
put it in, and your app is waiting on cache misses and pipeline stalls 
anyway, so you might as well do something with those cycles.  Now you can 
get extra work done during those times in C, but you won't be able to in 
caml, and that's a bummer.  It's not a showstopper, since you can always 
call out to C, but it is yet another thing in the list of features that 
aren't natively exploitable in caml.  Of course there's a cost to enabling 
this in caml, and it may be that there's no good way to do it or that it's 
not worth it cost/benefit-wise, but saying "you don't want to do it anyway" 
is just apologist.

Xavier saying 1.5x is not worth it is really strange to me; most 
performance sensitive programmers I know would kill their mother to get 
1.5x.  I wonder what factor would be worth it for Xavier?

I think the overriding point here is that in the past SMP has not taken off 
on the desktop, so it wasn't worth worrying about for end-user 
applications.  That will no longer be true, simply because it was so cheap 
for Intel to add HT.  From now on, almost all chips they ship will be 
"logically" SMP (barring some unforseen thing where HT isn't used at all 
and becomes expensive to keep in the chip...I assume this is what Xavier 
meant by "last gasp", but I doubt it based on Intel's historic behavior 
with other CPU features).  For commercial application developers, that 
changes the landscape a bit.

It's very similar to MMX and SSE.  Neither technology revolutionized to 
world (like the hype suggested), but once all viable end user machines have 
it, it becomes cost effective to use.  HT is even easier, because unlike 
MMX and SSE, it involves no compiler changes (for C compilers) and is 
backwards compatible.

I am not a big fan of threading; in fact, I think it's almost always a 
cost/benefit lose (except when used to simulate async io) for my kinds of 
applications (games).  However, HT changes the cost/benefit equation.  How 
much remains to be seen, of course.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners