From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA08819; Mon, 25 Nov 2002 23:22:05 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA08807 for ; Mon, 25 Nov 2002 23:21:35 +0100 (MET) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id gAPMLY125428 for ; Mon, 25 Nov 2002 23:21:34 +0100 (MET) Received: (qmail 7667 invoked from network); 25 Nov 2002 22:21:33 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay1.pair.com with SMTP; 25 Nov 2002 22:21:33 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20021125134858.037b4ef8@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Nov 2002 14:20:11 -0800 To: james woodyatt , Blair Zajac From: Chris Hecker Subject: Re: [Caml-list] Why systhreads? Cc: The Trade In-Reply-To: References: <3DE2736D.F4FCC064@orcaware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >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