On Friday 11 July 2008 14:01:45 Gerd Stolpmann wrote:
> In the past, it was very important for hardware vendors that existing
> software runs quicker on new CPU generations. This is no longer true for
> multicore. So unless there is a software revolution that makes it simple
> to exploit multicore, we won't see 1024-cores for the masses.

That revolution happened several years ago when everyone migrated to the JVM 
and CLR and their concurrent GCs made it easy to exploit multicores.

Ironically, given the hype surrounding functional programming for parallelism, 
all open source FPLs were left behind. On Linux, even the future prospects 
are bleak: no tail calls on the JVM, prohibitively difficult to implement an 
efficient concurrent GC yourself and Mono is going nowhere.

> Well, there is a another option for the chip industry. Instead of
> keeping the die at some size and packing more and more cores on it, they
> can also sell smaller chips for less. Basically, this alternate path
> already exists (e.g. Intel's Atom). Of course, this makes this industry
> more boring, and they would turn into more normal industrial component
> suppliers.

Other factors are certainly playing an increasingly important role. ARM cores 
are now outselling Intel and AMD thanks to an exploding embedded market. ARM 
CPUs found their way into ultramobiles and are now moving up into laptops. 
Microsoft are supporting ARM-based Windows and .NET.

However, even ARM recently went multicore and their GHz quadcore Cortex-A8 
with integrated nVidia graphics is going into mobile phones. By the end of 
this year, OCaml will not even be able to tap the power of my mobile phone...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Reply via email to