On Sunday 20 December 2009 14:27:00 Dario Teixeira wrote: > Hi, > > > It's too bad that INRIA is not interested in fixing this bug. No > > matter what people say I consider this a bug. Two cores is standard by > > now, I'm used to 8, next year 32 and so on. OCaml will only become > > more and more irrelevant. I hate to see that happening. > > This is a perennial topic in this list. Without meaning to dwell too > long on old arguments, I simply ask you to consider the following: > > - Do you really think a concurrent GC with shared memory will scale neatly > to those 32 cores? > > - Will memory access remain homogeneous for all cores as soon as we get > into the dozens of cores?
The following web page describes a commercial machine sold by Azul Systems that has up to 16 54-core CPUs (=864 cores) and 768 GB of memory in a flat SMP configuration: http://www.azulsystems.com/products/compute_appliance.htm As you can see, a GC with shared memory can already scale across dozens of cores and memory access is no more heterogeneous than it was 20 years ago. Also, note that homogeneous memory access is a red herring in this context because it does not undermine the utility of a shared heap on a multicore. > - Have you considered that many Ocaml users prefer a GC that offers maximum > single core performance, OCaml's GC is nowhere near offering maximum single core performance. Its uniform data representation renders OCaml many times slower than its competitors for many tasks. For example, filling a 10M float->float hash table is over 18x slower with OCaml than with F#. FFT with a complex number type is 5.5x slower with OCaml than F#. Fibonacci with floats is 3.3x slower with OCaml than my own HLVM project (!). > because their application is parallelised via multiple processes > communicating via message passing? A circular argument based upon the self-selected group of remaining OCaml users. Today's OCaml users use OCaml despite its shortcomings. If you want to see the impact of OCaml's multicore unfriendliness, consider why the OCaml community has haemorrhaged 50% of its users in only 2 years. > In this context, your "bug" is actually a "feature". I'm not even sure you can substantiate that in the very specific context of distributed parallel theorem provers because other languages are so much more efficient at handling common abstractions like parametric polymorphism. Got any benchmarks? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?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
