<div class="gmail_quote">On Fri, Jul 3, 2009 at 8:15 AM, Anthony Cowley <<a href="mailto:acowley@gmail.com">acowley@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">> 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. </div>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. </blockquote><div> 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 </div></div>