6 ms·

It's interesting to read Xavier's annual statement on why there will never be multi core support in OCaml: http://mirror.ocamlcore.org/caml.inria.fr/pub/ml-arch

• AceJohnny2 11y ago
  When was the latest iteration of post from? The page displays date as NaN... Edit: I think I found it [1] That iteration was from 2002. I'd be curious to see if his opinion has evolved in 12 years. Also, interesting to see game developer Chris Hecker [2] in that thread. [1] http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/threads.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/threa... search for "Why systhreads?" and "Xavier Leroy". Also, damn their website's broken. Better link, I wish GMane had better Googlejuice: http://thread.gmane.org/gmane.comp.lang.caml.general/16381/focus=16396 http://thread.gmane.org/gmane.comp.lang.caml.general/16381/f... [2] http://en.wikipedia.org/wiki/Chris_Hecker http://en.wikipedia.org/wiki/Chris_Hecker
  • gnuvince 11y ago
    Around 2001 I think?
  • rwmj 11y ago
    2002
• istvan__ 11y ago
  I think he was saying it is unlikely. "In summary: there is no SMP support in OCaml, and it is very very unlikely that there will ever be. If you're into parallelism, better investigate message-passing interfaces."
• trentnelson 11y ago
  > To make things worse, non-blocking I/O is done completely differently > under Unix and under Win32. I'm not even sure Win32 provides enough > support for async I/O to write a real user-level scheduler. sigh, VMS got the link between processes, threads, I/O and waitable events (specifically, the link between tying the completion of future I/O to subsequent computation) right from day one. And by virtue of Cutler, therefore, so did NT, and thus, Windows. UNIX did not. The core concept of separating the work (computation to be done after an event occurs) from the worker[1] (the thread that performs the work) is absent; the manifestation of that is the lack of good, completion-oriented asynchronous I/O primitives. Instead of being able to say to the kernel "here, do this, then let me know when you're done"[2] and moving on to the next piece of work in the queue, you have to do the elaborate non-blocking multiplex dance for socket I/O, palm file I/O off onto a separate set of threads that can block (or do AIO) and generally manage all threading and concurrency primitives yourself. It took me ten years of UNIX systems programming to suddenly grasp the elegance of the VMS/NT/Windows approach a few years ago. It provides you with everything you need to optimally exploit all your cores for work that is both heavily compute bound and I/O bound. It has been fascinating to see the difference in performance between Linux and Windows in practice with PyParallel when Windows kernel primitives are exploited properly: https://speakerdeck.com/trent/pyparallel-pycon-2015-language-summit?slide=5 https://speakerdeck.com/trent/pyparallel-pycon-2015-language.... And more recently, with 10Gbe hardware at home: Linux lwan (the top performer on Techempower Framework Benchmark): [trent@zebra/ttypts/1(~s/wrk)%] time ./wrk --timeout 120 --latency -c 256 -t 12 -d 30 http://10.0.0.2:8080/plaintext Running 30s test @ http://10.0.0.2:8080/plaintext 12 threads and 256 connections Thread Stats Avg Stdev Max +/- Stdev Latency 5.34ms 7.46ms 197.13ms 82.40% Req/Sec 14.41k 364.49 18.82k 76.61% Latency Distribution 50% 398.00us 75% 9.01ms 90% 17.50ms 99% 28.03ms 5178617 requests in 30.10s, 0.93GB read Requests/sec: 172048.49 Transfer/sec: 31.67MB Windows PyParallel: [trent@zebra/ttypts/1(~s/wrk)%] time ./wrk --timeout 120 --latency -c 256 -t 12 -d 30 http://10.0.0.2:8080/plaintext Running 30s test @ http://10.0.0.2:8080/plaintext 12 threads and 256 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.52ms 9.38ms 492.43ms 99.33% Req/Sec 18.37k 1.01k 22.75k 73.50% Latency Distribution 50% 1.09ms 75% 1.28ms 90% 1.56ms 99% 5.18ms 6598900 requests in 30.10s, 1.03GB read Requests/sec: 219236.69 Transfer/sec: 34.92MB ./wrk --timeout 120 --latency -c 256 -t 12 -d 30 106.30s user 138.87s system 814% cpu 30.114 total [1]: https://speakerdeck.com/trent/parallelism-and-concurrency-with-python?slide=27 https://speakerdeck.com/trent/parallelism-and-concurrency-wi... [2]: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=52 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...
  • gtk40 11y ago
    Would you mind explaining what the link between NT and VMS is?
    • cmrdporcupine 11y ago
      Dave Cutler was a lead engineer on both.
    • trentnelson 11y ago
      The principle architect of VMS was David Cutler, purportedly the best engineer at Digital at the time (80s), and best OS designer in the industry. Digital dropped the ball in the late 80s with regards to management of Cutler and his team, canceling his PRISM project and leaving him and his team disgruntled. Elsewhere in Seattle, a chap named Bill Gates was flush with billions of cash and knew that the shelf life of DOS was limited; if Microsoft were to succeed, they needed a new, robust, reliable and high-performance OS that they could "bet the company on". Gates got word that Cutler was disgruntled at Digital, and a mutual party set up a meeting. Cutler was dismissive of Microsoft's technology stack at the time (DOS and some office apps) -- he was a hardcore OS engineer, and DOS was a toy. Gates persisted, ensuring Cutler that he would have the opportunity to build the next generation of OS from the ground up and essentially unlimited resources at his disposal to do it. Cutler eventually agreed, and the NT kernel project was born. http://www.amazon.com/Show-Stopper-Breakneck-Generation-Microsoft/dp/0029356717/ref=sr_1_12?ie=UTF8&qid=1432232814&sr=8-12&keywords=show+stopper http://www.amazon.com/Show-Stopper-Breakneck-Generation-Micr... http://windowsitpro.com/windows-client/windows-nt-and-vms-rest-story http://windowsitpro.com/windows-client/windows-nt-and-vms-re...
      • CountSessine 11y ago
        I actually just read Show Stopper recently. The author is very non-technical and can't really explain the engineering details behind what he's writing about, but if you know something about basic OS design and concepts, that's ok. And the human stories - the stories behind the developers working on the project - are fascinating. Reading the book and learning the story behind NT's development, it's just amazing that such a good OS came out of that process - they released years after their initial projections and were rushed the whole time. But of course the really good parts of NT - the kernel, the object manager, the pager, async IO, the threading model - were things Cutler and his cohorts had been working on for years, first with VMS, then with PRISM, and then finally in NT. They had YEARS to ruminate about those things before they ever arrived at Microsoft. The bits of NT that aren't so well-regarded - the registry, NTFS, the graphical shell, csrss.exe and the 'microkernel' design - were completely new and developed in much less time and with less practical experience behind them than they really deserved.
• plorkyeran 11y ago
  > Of course, all this SMP support stuff slows down the runtime system even if there is only one processor, which is the case for almost all our users... > What about hyperthreading? Well, I believe it's the last convulsive movement of SMP's corpse :-) Oh how things have changed. This was written before it was clear just how much of a disaster the P4 was, so it was a pretty reasonable position at the time.
  • rodgerd 11y ago
    He was hardly the only one thinking that way - I remember Gabe Newell being scathing about multicore/multiprocessing when the PS3 and Xbox 360 were released. All a fad, waste of time.
• bitmadness 11y ago
  That was back in 2002! I don't think he'd take the same stance now...