[plt-scheme] Number crunching -> Matthias, Eli

On Fri, Jul 3, 2009 at 8:15 AM, Anthony Cowley <acowley at gmail.com> wrote:

>
> > For example, a runtime that could take advantage of
> > multicore machines would benefit many more people that optimising
> > floating point calculations. I love performance as much as the next
> > guy -- my hard disk is littered with little compilers and so on -- but
> > it really isn't that important in the grand scheme of things.
>
> This is another area where I think many FP advocates tend to be a bit
> too glib. Being able to claim near linear performance scaling on
> today's 2-8 core machines is great, but to do so at the expense of
> 10-100x slower performance compared to, let's say C, is a really tough
> sales pitch! Many functional languages are dealing with that today;
> Clojure is a particularly interesting case because it has Java as a
> ready point of comparison, and Java is not exactly incapable of
> reasonably expressing concurrent programs. I think Haskell makes a
> very strong case for itself by most definitely *not* ignoring
> single-threaded speed. If a functional language is within striking
> distance of C's performance, then I think it's fine to say that easier
> parallelism negates that difference. But if you're giving up orders of
> magnitude up front, then gains down the road have too much distance to
> make up.
>

Hmm... are you sure people are claiming concurrency scaling will beat
sequential speedup?  Maybe really fast FP such as ocaml or clean are making
these claims, but I have not heard of it here.

IMHO multicore is not meant to be "faster" - it's meant to do more things.
Ruby and javascript have proven that for many things you don't need speed.
And if you truly need speed, C might not even be fast enough and you'll need
assembly.  But many apps need multi-threads, especially things like server
apps.  In such instances, multicore is very important.

IMO this is a matter of priority and where best to stake down.  As Noel
said, there aren't too many Matthew Flatts around, and my vote (if this is
up for vote) would be to put the effort behind multicore than to improve
sequential speed, since C already dominated that arena with many excellent
reusable libs and can be binded (although not trivial), and multicore is
where the world is going to be.  Let's skate to where the puck will be.

(and multicore is needed when you want to use FFI without blocking all other
scheme threads).

Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090703/90cc9632/attachment.html>