39 ms·

OCaml 4.03 will, “if all goes well”, support multicore

185 points by wting 11y ago

SniperOwl 11y ago
If Jane Street Capital has it their way, multicore support "will definitely go well".
- diginux 11y ago
  Are you from JSC by chance? Is this from an authoritative source, or an just an observation of likeliness? Would love if they indeed do push hard for this.
- tomjen3 11y ago
  It sounds like such a company might also have the capital to pay people to make it work. It is pretty stupid for a language not to have multicore support in 2015. Javascript has it (in its own, somewhat broken way).
  - rubiquity 11y ago
    > Javascript has it (in its own, somewhat broken way). No it doesn't. Also OCaml is from a pre-multicore era. Even Erlang wasn't multicore from the start, SMP was added in 2005.
    - tomjen3 11y ago
      Webworkers And I don't really care if it is from an other era - C has threads (as a library but still).
      - rubiquity 11y ago
        > Webworkers JavaScript Webworkers can't interact with the page at all, they can only send messages around. This implementation detail leads me to believe the browser is probably doing little more than instantiating another JavaScript interpreter and handling IPC/synchronization for you. This is a far cry from true parallelism. Further illustrating that JavaScript doesn't have parallelism is that Node.js isn't parallel and in fact encourages its users to use process forking instead. > And I don't really care if it is from an other era - C has threads (as a library but still). OCaml has threads. It just doesn't have parallel threads (yet). Threads existed before CPU parallelism so of course C and a bunch of other pre-CPU parallelism languages have them. The difference is C doesn't have a GIL whereas OCaml does/did.
DonPellegrino 11y ago
More information is available in my original post in r/ocaml: https://www.reddit.com/r/ocaml/comments/36ninh/403_scheduled_for_the_end_of_the_year_if_all_goes/ https://www.reddit.com/r/ocaml/comments/36ninh/403_scheduled... in the repost in r/programming: https://www.reddit.com/r/programming/comments/36ppx0/ocaml_403_will_if_all_goes_well_support_multicore/ https://www.reddit.com/r/programming/comments/36ppx0/ocaml_4...
- DonPellegrino 11y ago
  For those asking "How the hell does OCaml not support multicore in 2015????", this is my reply, crossposted from /r/ocaml: You can make OS level threads, but they can't be both running at the same time due to the GIL (Global Interpreter Lock). Then why are they even there you might ask? Because it allows you to do a blocking call on a thread and to keep executing other stuff in the main thread. Other languages that have a GIL (and the same restriction) are Javascript (including Node.js), Ruby and Python. Now, IN PRACTICE, things are a bit different. You're never gonna make your own thread to block on things. You're gonna use Lwt to manage all your concurrency so you can do tons of blocking stuff at the same time and combine the tasks nicely without ending up in a Node.js-style "callback hell". But still, even with tons of concurrency, you don't have parallelism. It's all you need for 98% of your programs, but if you then need to do heavy number-crunching it won't be enough. This is the exact same situation that happens in Node.js, Python, etc, except that OCaml is massively faster than those languages, so even some CPU-bound work is acceptable because OCaml is really performant. Currently, there's 2 options if you wanna do CPU-bound work: you can use ctypes to call C code easily (from Lwt_preemptive) and then release the lock from within C with caml_release_runtime_system(), so your C code will be truly parallel (and running in the thread pool automatically managed by Lwt_preemptive), and you can call caml_acquire_runtime_system() before returning the result back to OCaml to get the lock back and merge back with the normal code. The second option is to do an oldschool fork() and communicate with message-passing. Or have a master that manages workers and communicates with ZMQ, HTTP, TCP, IPC, etc. Or use a library that does it all for you like parmap, Async Parallel, etc etc. What this "multicore support" means is that you'll be able to have threads in the same process that run in parallel because the GIL is going away. In practice it'll probably be implemented directly into Lwt so you'll be able to do something with Lwt_preemptive and just tell it to run some function in a separate thread and then use >>= to handle its result. It's gonna be simpler than both options I described above. Again, more technical information is available in my r/ocaml post
j_baker 11y ago
Does OCaml not already support multicore? Is concurrency green thread based? Even at that, there's nothing stopping a user from starting multiple processes....
- bad_user 11y ago
  Starting multiple processes sucks though, you know, for the kind of use cases for which OCaml should be well suited for. This is because OS processes are more expensive than threads and communication and synchronization between such processes gets very expensive.
  - istvan__ 11y ago
    on this argument you could state that Erlang's processes the way to go because OS threads are way more expensive. If I have a problem that I can easily make parallel than I could just start up N OCaml processes and send each process a chunk of work and this would not be much more inefficient than the thread based implementation. On the top of that, I don't like to create a tonn of threads in any application, I much rather have a fixed number of threads and using channels to send them work than dynamically (on demand) creating threads or processes.
    - bad_user 11y ago
      Erlang's processes are actually better than threads for many use cases, yes. But the thing is that with 1:1 multi-threading you can build many abstractions on top and for example on top of the JVM frameworks using Erlang's model like Akka [1] and Quasar [2] are very popular. Either way, you can't compare Erlang with platforms whose notion of parallelism involves POSIX's fork, but lo and behold, I'm comparing it with Java because I can. MOST problems are not easily parallelizable and you'll end up with concurrency. Concurrency means synchronizing and sending messages between processes. For example sending messages between processes means opening a socket of some sort, serializing the data you want to send and deserializing it on the consumer's side. That's extremely inneficient and there's no way you can end up with a pipeline of tens of millions of messages per second, but with 1:1 multi-threading you can [3]. Erlang can't cope with this load btw. One other thing I like about working with threads is the user-friendliness. Yes, skipping over the perils of multi-threading which you can sort of avoid by using better libraries, you can easily do things like number crunching using "parallel collections", combine actors with reactive streams and futures, or fake asynchronous I/O by blocking threads. People nowadays tend to underestimate the utility of blocking threads, but it's pretty cool having an interface like `def fetchData: Future[Result]` that could be implemented on top of Netty (asynchronous I/O) or with JBDC (blocking I/O), only suffer a very small penalty and your process to still be able to reach 80% of CPU utilization. So I think OCaml getting multi-threading support is a pretty big deal. [1] http://akka.io/ http://akka.io/ [2] https://github.com/puniverse/quasar https://github.com/puniverse/quasar [3] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/
feld 11y ago
Seems like a major feature to put in a point release... I don't understand why some projects have such bizarre versioning methodology.
- LeonidasXIV 11y ago
  This is not really a point release. OCaml versions a little different, a version number has three parts: Super-Major.Major.Patch. Super-Major releases are incredibly rare, the last one was the bump to 4, which was done since the language now supports GADTs (while staying compatible with OCaml 3.x). I don't even know what caused the bump from 2.x to 3.00. Then the Major part is a normal release in which many features may be added. The format is always two digits, of which the first may as well be a 0. The Patch part is just for fixes, stuff that was broken and overlooked when the release was done. So OCaml 4.03.0 is basically 4.3.0 in a Python-esque versioning scheme (remember how many changes were done between Python 2.2.0 and 2.7.0?).
  - feld 11y ago
    Thanks for clearing that up
nextos 11y ago
I'm considering OCaml for a new project where C++ would be the typical choice. Think algorithms handling massive amounts of data, and some numerics. I have some experience with ML, Haskell & Lisp. OCaml is appealing because it is quite efficient and predictable. Does it have the bit of laziness Clojure has that makes functional programming easy with large data?
- shriphani 11y ago
  Function application in OCaml is eager. However, implementing laziness is trivially accomplished.
  - raphaelss 11y ago
    It already comes with support for lazy evaluation. http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec216 http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec216
    - sgeisenh 11y ago
      Just about every eagerly evaluated functional language supports laziness through thunks. This is just syntactic sugar.
- gmfawcett 11y ago
  Yes, there is support for laziness (see "streams"). A couple things to keep in mind: floating point values in Ocaml are boxed (floats are actually pointers to float data on the heap), and integers are one bit shorter than native types (31 or 63 bits) due to the way that Ocaml values are tagged internally. The native compiler generates good, predictable, but fairly simple code: few optimizations are applied (although there is active work underway, in the "flambda" project, that will significantly change this). Also, there is of course a garbage collector, though it is quite efficient in most cases. These factors may or may not be a performance issue in your own project.
  - DonPellegrino 11y ago
dorfsmay 11y ago
I took a really hard look at OCaml a year ago, as I was running into performance issues with python. Lack of multicore support made me give up on it. Now that Rust is around and supporting multicore, that's probably where I'll be investing my time. I'd love to hear feedback from people who have used both Rust and OCaml.
- e_d_g_a_r 11y ago
  What were you doing that you needed multicore?
  - dorfsmay 11y ago
    Pivoting hundreds of millions json entries and upload the results to an object store. I ended up using a combination of python threads and processes, which was more work I wanted to do, and still relatively slow.
    - chubot 11y ago
      Why not C or C++? OCaml and Rust aren't going to interface with Python nearly as well. Also, it's trivial to write multithreaded extensions in C or C++ (at least for data processing). You just have to make sure to release the GIL. IMO the trick is to just use the Python C API, and not use any wrappers like SWIG or ctypes. The Python C API is a little odd but it is fairly explicit. Also, it's better to write plain functions rather than classes, but for data processing that is natural anyway. If you need a class, do that part in Python. Writing "one way" extension functions (that don't call back into Python) is quite easy and can give you a huge performance boost. I think people get hung up on Python extensions because they are using TWO unfamiliar languages -- the wrapper language, and C/C++. But if you are just using one additional language, it's not hard to figure out.
      - pcwalton 11y ago
        Why won't Rust interface with a C API?
timruffles 11y ago
Great! This, plus the lack of libraries, put me off. Will take a new look!
- LeonidasXIV 11y ago
  You'll be delighted to hear that OPAM curently features >800 libraries, too.
- kristianp 11y ago
  Any libraries in particular?
almosthaskeller 11y ago
Looked into a static FP language recently. Was torn between OCaml and Haskell. Leaned more toward Haskell than OCaml. Mainly because OCaml feels like it was hacked together, with a lot of very strange and inconsistent syntax and poorly thought out semantics. That said, I haven't chosen either yet, because Haskell has its own share of oddities that I'm still not comfortable with. But at least it feels more pure and consistent and well thought out in its syntax and semantics.
- e_d_g_a_r 11y ago
  What do you mean hacked together? It looks like most any other ML for the most part. And what poorly thought out semantics?
- jallmann 11y ago
  ML actually has a formally specified semantics. Haskell does not.
  - brians 11y ago
    OCaml doesn't either.
    - jallmann 11y ago
      Sure, for a subset of the language. But the point is, a hand-wavy complaint about PL semantics (which can be precisely defined) doesn't make sense when comparing languages in this context.
  - codygman 11y ago
    Do you mean: http://sml-family.org/sml97-defn.pdf http://sml-family.org/sml97-defn.pdf
    - jallmann 11y ago
      That's the one for Standard ML, yes. There are others for SML, some using proof assistants [1]. Other (S)ML extensions have formal semantics as well, and OCaml itself is partially specified [2]. [1] https://github.com/CakeML/cakeml https://github.com/CakeML/cakeml [2] http://www.cl.cam.ac.uk/~so294/ocaml http://www.cl.cam.ac.uk/~so294/ocaml
tangled 11y ago
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-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html http://mirror.ocamlcore.org/caml.inria.fr/pub/ml-archives/ca...
- 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-...
avsm 11y ago
If you'd like to see the approach we're taking at OCaml Labs in order to build multicore, read KC's blog post here: http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico... The core idea is incredibly exciting (to us, anyway). Rather than baking in a specific multicore scheduler, we're allowing pluggable schedulers written in OCaml. They use algebraic effects to allow an independent scheduler to compose concurrency among OCaml threads. This will ensure that the OCaml runtime remains lean, and even allow applications to define their own strategies for concurrent scheduling.
tempodox 11y ago
Yupeee!

185 points by wting 11y ago

SniperOwl 11y ago

If Jane Street Capital has it their way, multicore support "will definitely go well".

diginux 11y ago
Are you from JSC by chance? Is this from an authoritative source, or an just an observation of likeliness? Would love if they indeed do push hard for this.
tomjen3 11y ago
It sounds like such a company might also have the capital to pay people to make it work. It is pretty stupid for a language not to have multicore support in 2015. Javascript has it (in its own, somewhat broken way).
- rubiquity 11y ago
  > Javascript has it (in its own, somewhat broken way). No it doesn't. Also OCaml is from a pre-multicore era. Even Erlang wasn't multicore from the start, SMP was added in 2005.
  - tomjen3 11y ago
    Webworkers And I don't really care if it is from an other era - C has threads (as a library but still).
    - rubiquity 11y ago
      > Webworkers JavaScript Webworkers can't interact with the page at all, they can only send messages around. This implementation detail leads me to believe the browser is probably doing little more than instantiating another JavaScript interpreter and handling IPC/synchronization for you. This is a far cry from true parallelism. Further illustrating that JavaScript doesn't have parallelism is that Node.js isn't parallel and in fact encourages its users to use process forking instead. > And I don't really care if it is from an other era - C has threads (as a library but still). OCaml has threads. It just doesn't have parallel threads (yet). Threads existed before CPU parallelism so of course C and a bunch of other pre-CPU parallelism languages have them. The difference is C doesn't have a GIL whereas OCaml does/did.

DonPellegrino 11y ago

More information is available in my original post in r/ocaml: https://www.reddit.com/r/ocaml/comments/36ninh/403_scheduled_for_the_end_of_the_year_if_all_goes/ https://www.reddit.com/r/ocaml/comments/36ninh/403_scheduled... in the repost in r/programming: https://www.reddit.com/r/programming/comments/36ppx0/ocaml_403_will_if_all_goes_well_support_multicore/ https://www.reddit.com/r/programming/comments/36ppx0/ocaml_4...

DonPellegrino 11y ago
For those asking "How the hell does OCaml not support multicore in 2015????", this is my reply, crossposted from /r/ocaml: You can make OS level threads, but they can't be both running at the same time due to the GIL (Global Interpreter Lock). Then why are they even there you might ask? Because it allows you to do a blocking call on a thread and to keep executing other stuff in the main thread. Other languages that have a GIL (and the same restriction) are Javascript (including Node.js), Ruby and Python. Now, IN PRACTICE, things are a bit different. You're never gonna make your own thread to block on things. You're gonna use Lwt to manage all your concurrency so you can do tons of blocking stuff at the same time and combine the tasks nicely without ending up in a Node.js-style "callback hell". But still, even with tons of concurrency, you don't have parallelism. It's all you need for 98% of your programs, but if you then need to do heavy number-crunching it won't be enough. This is the exact same situation that happens in Node.js, Python, etc, except that OCaml is massively faster than those languages, so even some CPU-bound work is acceptable because OCaml is really performant. Currently, there's 2 options if you wanna do CPU-bound work: you can use ctypes to call C code easily (from Lwt_preemptive) and then release the lock from within C with caml_release_runtime_system(), so your C code will be truly parallel (and running in the thread pool automatically managed by Lwt_preemptive), and you can call caml_acquire_runtime_system() before returning the result back to OCaml to get the lock back and merge back with the normal code. The second option is to do an oldschool fork() and communicate with message-passing. Or have a master that manages workers and communicates with ZMQ, HTTP, TCP, IPC, etc. Or use a library that does it all for you like parmap, Async Parallel, etc etc. What this "multicore support" means is that you'll be able to have threads in the same process that run in parallel because the GIL is going away. In practice it'll probably be implemented directly into Lwt so you'll be able to do something with Lwt_preemptive and just tell it to run some function in a separate thread and then use >>= to handle its result. It's gonna be simpler than both options I described above. Again, more technical information is available in my r/ocaml post

j_baker 11y ago

Does OCaml not already support multicore? Is concurrency green thread based? Even at that, there's nothing stopping a user from starting multiple processes....

bad_user 11y ago
Starting multiple processes sucks though, you know, for the kind of use cases for which OCaml should be well suited for. This is because OS processes are more expensive than threads and communication and synchronization between such processes gets very expensive.
- istvan__ 11y ago
  on this argument you could state that Erlang's processes the way to go because OS threads are way more expensive. If I have a problem that I can easily make parallel than I could just start up N OCaml processes and send each process a chunk of work and this would not be much more inefficient than the thread based implementation. On the top of that, I don't like to create a tonn of threads in any application, I much rather have a fixed number of threads and using channels to send them work than dynamically (on demand) creating threads or processes.
  - bad_user 11y ago
    Erlang's processes are actually better than threads for many use cases, yes. But the thing is that with 1:1 multi-threading you can build many abstractions on top and for example on top of the JVM frameworks using Erlang's model like Akka [1] and Quasar [2] are very popular. Either way, you can't compare Erlang with platforms whose notion of parallelism involves POSIX's fork, but lo and behold, I'm comparing it with Java because I can. MOST problems are not easily parallelizable and you'll end up with concurrency. Concurrency means synchronizing and sending messages between processes. For example sending messages between processes means opening a socket of some sort, serializing the data you want to send and deserializing it on the consumer's side. That's extremely inneficient and there's no way you can end up with a pipeline of tens of millions of messages per second, but with 1:1 multi-threading you can [3]. Erlang can't cope with this load btw. One other thing I like about working with threads is the user-friendliness. Yes, skipping over the perils of multi-threading which you can sort of avoid by using better libraries, you can easily do things like number crunching using "parallel collections", combine actors with reactive streams and futures, or fake asynchronous I/O by blocking threads. People nowadays tend to underestimate the utility of blocking threads, but it's pretty cool having an interface like `def fetchData: Future[Result]` that could be implemented on top of Netty (asynchronous I/O) or with JBDC (blocking I/O), only suffer a very small penalty and your process to still be able to reach 80% of CPU utilization. So I think OCaml getting multi-threading support is a pretty big deal. [1] http://akka.io/ http://akka.io/ [2] https://github.com/puniverse/quasar https://github.com/puniverse/quasar [3] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/

feld 11y ago

Seems like a major feature to put in a point release... I don't understand why some projects have such bizarre versioning methodology.

LeonidasXIV 11y ago
This is not really a point release. OCaml versions a little different, a version number has three parts: Super-Major.Major.Patch. Super-Major releases are incredibly rare, the last one was the bump to 4, which was done since the language now supports GADTs (while staying compatible with OCaml 3.x). I don't even know what caused the bump from 2.x to 3.00. Then the Major part is a normal release in which many features may be added. The format is always two digits, of which the first may as well be a 0. The Patch part is just for fixes, stuff that was broken and overlooked when the release was done. So OCaml 4.03.0 is basically 4.3.0 in a Python-esque versioning scheme (remember how many changes were done between Python 2.2.0 and 2.7.0?).
- feld 11y ago
  Thanks for clearing that up

nextos 11y ago

I'm considering OCaml for a new project where C++ would be the typical choice. Think algorithms handling massive amounts of data, and some numerics. I have some experience with ML, Haskell & Lisp. OCaml is appealing because it is quite efficient and predictable. Does it have the bit of laziness Clojure has that makes functional programming easy with large data?

shriphani 11y ago
Function application in OCaml is eager. However, implementing laziness is trivially accomplished.
- raphaelss 11y ago
  It already comes with support for lazy evaluation. http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec216 http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec216
  - sgeisenh 11y ago
    Just about every eagerly evaluated functional language supports laziness through thunks. This is just syntactic sugar.
gmfawcett 11y ago
Yes, there is support for laziness (see "streams"). A couple things to keep in mind: floating point values in Ocaml are boxed (floats are actually pointers to float data on the heap), and integers are one bit shorter than native types (31 or 63 bits) due to the way that Ocaml values are tagged internally. The native compiler generates good, predictable, but fairly simple code: few optimizations are applied (although there is active work underway, in the "flambda" project, that will significantly change this). Also, there is of course a garbage collector, though it is quite efficient in most cases. These factors may or may not be a performance issue in your own project.
- DonPellegrino 11y ago

dorfsmay 11y ago

I took a really hard look at OCaml a year ago, as I was running into performance issues with python. Lack of multicore support made me give up on it. Now that Rust is around and supporting multicore, that's probably where I'll be investing my time. I'd love to hear feedback from people who have used both Rust and OCaml.

e_d_g_a_r 11y ago
What were you doing that you needed multicore?
- dorfsmay 11y ago
  Pivoting hundreds of millions json entries and upload the results to an object store. I ended up using a combination of python threads and processes, which was more work I wanted to do, and still relatively slow.
  - chubot 11y ago
    Why not C or C++? OCaml and Rust aren't going to interface with Python nearly as well. Also, it's trivial to write multithreaded extensions in C or C++ (at least for data processing). You just have to make sure to release the GIL. IMO the trick is to just use the Python C API, and not use any wrappers like SWIG or ctypes. The Python C API is a little odd but it is fairly explicit. Also, it's better to write plain functions rather than classes, but for data processing that is natural anyway. If you need a class, do that part in Python. Writing "one way" extension functions (that don't call back into Python) is quite easy and can give you a huge performance boost. I think people get hung up on Python extensions because they are using TWO unfamiliar languages -- the wrapper language, and C/C++. But if you are just using one additional language, it's not hard to figure out.
    - pcwalton 11y ago
      Why won't Rust interface with a C API?

timruffles 11y ago

Great! This, plus the lack of libraries, put me off. Will take a new look!

LeonidasXIV 11y ago
You'll be delighted to hear that OPAM curently features >800 libraries, too.
kristianp 11y ago
Any libraries in particular?

almosthaskeller 11y ago

Looked into a static FP language recently. Was torn between OCaml and Haskell. Leaned more toward Haskell than OCaml. Mainly because OCaml feels like it was hacked together, with a lot of very strange and inconsistent syntax and poorly thought out semantics. That said, I haven't chosen either yet, because Haskell has its own share of oddities that I'm still not comfortable with. But at least it feels more pure and consistent and well thought out in its syntax and semantics.

e_d_g_a_r 11y ago
What do you mean hacked together? It looks like most any other ML for the most part. And what poorly thought out semantics?
jallmann 11y ago
ML actually has a formally specified semantics. Haskell does not.
- brians 11y ago
  OCaml doesn't either.
  - jallmann 11y ago
    Sure, for a subset of the language. But the point is, a hand-wavy complaint about PL semantics (which can be precisely defined) doesn't make sense when comparing languages in this context.
- codygman 11y ago
  Do you mean: http://sml-family.org/sml97-defn.pdf http://sml-family.org/sml97-defn.pdf
  - jallmann 11y ago
    That's the one for Standard ML, yes. There are others for SML, some using proof assistants [1]. Other (S)ML extensions have formal semantics as well, and OCaml itself is partially specified [2]. [1] https://github.com/CakeML/cakeml https://github.com/CakeML/cakeml [2] http://www.cl.cam.ac.uk/~so294/ocaml http://www.cl.cam.ac.uk/~so294/ocaml

tangled 11y ago

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-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html http://mirror.ocamlcore.org/caml.inria.fr/pub/ml-archives/ca...

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-...

avsm 11y ago

If you'd like to see the approach we're taking at OCaml Labs in order to build multicore, read KC's blog post here: http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico... The core idea is incredibly exciting (to us, anyway). Rather than baking in a specific multicore scheduler, we're allowing pluggable schedulers written in OCaml. They use algebraic effects to allow an independent scheduler to compose concurrency among OCaml threads. This will ensure that the OCaml runtime remains lean, and even allow applications to define their own strategies for concurrent scheduling.

tempodox 11y ago

Yupeee!