[HN Gopher] OCaml 5.0 Multicore is out
___________________________________________________________________
OCaml 5.0 Multicore is out
Author : sadiq
Score : 432 points
Date : 2022-12-16 12:21 UTC (1 days ago)
(HTM) web link (discuss.ocaml.org)
(TXT) w3m dump (discuss.ocaml.org)
| systems wrote:
| Still no native windows build To install on windows, I guess your
| best bet is via WSL (Windows Subsystem for Linux)
|
| I now run mainly on windows and this is an issue for me to try
| OCaml
| Tomte wrote:
| Do I misremember? I thought that was a goal for 5.0.
| octachron wrote:
| Not for 5.0, the aim of 5.0 was to focus on getting multicore
| support out of the door. Thus only mingw64 is supported for
| Windows. Support for MSVC will come with later versions. At
| the same time, improving opam ecosystem support for Windows
| is one of the major goal of opam 2.2 . Thus hopefully the
| support for native Windows will improve in the future (next
| year?).
| Tomte wrote:
| Thank you, that's good.
| runevault wrote:
| I saw some kind of other installer that might come with either
| MSYS2 or Cygwin I forget which, but it also said that installer
| takes 2 hours to run. They seem to strongly recommend WSL over
| it based on how I read things.
| dra27 wrote:
| opam 2.2's release cycle has fallen a bit behind the compiler's
| (actually because of the Windows support). It's an experimental
| branch, but this works with opam-repository-mingw to get a
| vanilla mingw-w64 build of OCaml 5.0.0:
|
| opam switch create 5.0
| --repos=dra27=git+https://github.com/dra27/opam-
| repository#windows-compilers --packages=ocaml.5.0.0,ocaml-
| option-mingw
| no_wizard wrote:
| Jane Street must be so happy today! I think this opens up a whole
| new host of fast applications on ocaml.
|
| I wonder how this will affect ReScript
| KMag wrote:
| Presumably, in cases where performance really matters, they're
| using single-threaded processes pinned to cores and shared
| memory ring buffers to communicate across processes. It ends up
| looking not that much different from a high performance C++
| project, except for the lack of full address space sharing.
|
| Modern MMUs don't require full TLB flushes when switching
| address spaces, and physically tagged cache lines allow the
| ring buffers to be shared in cache even if they're mapped at
| different virtual addresses in the different processes. Also,
| you're guaranteed to not have false sharing, and there's zero
| contention for locks within malloc/free.
|
| I don't mean to suggest there are no advantages to full address
| space sharing, but they're both fewer and less than one would
| initially assume.
| melony wrote:
| What's the current status of Esy? https://github.com/esy/esy
|
| Any plans to backport its design back to Opam?
| Alifatisk wrote:
| What an amazing ending of 2022!
|
| Just Hotwire Strada left.
| [deleted]
| runevault wrote:
| Been dabbling in f# lately, but this has me wanting to give OCaml
| a try for comparison, very interested in the new effects stuff.
| rigoleto wrote:
| I wish OCaml had something like F#'s lightweight syntax:
| https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
| bitbckt wrote:
| It's been tried
| https://people.csail.mit.edu/mikelin/ocaml+twt/
| KMag wrote:
| Note that The Whitespace Thing actually preceded F#. (Mike
| and I were in the same fraternity, I remember talking to
| him about TWT, and we haven't talked much since our college
| days, which pre-date F#.)
|
| IIRC, Mike was also doing a bunch of stuff with a Jabber
| client in OCaml around that time.
| yawaramin wrote:
| OCaml syntax is whitespace-insensitive. You don't need to
| worry about indentation, copy-pasting code snippets, etc. I
| think that makes for a better experience especially for
| beginners when the parser is more forgiving.
| robot9000 wrote:
| This so-called lightweight syntax gives me anxiety just
| scrolling through these examples.
| runevault wrote:
| I'd never seen the verbose syntax for f#, I thought you had
| to write it the whitespace dependent way. Huh.
| hawk_ wrote:
| Lightweight syntax is a pain to use for blind people. Glad
| OCaml hasn't fallen for that fad.
| naasking wrote:
| Do blind people use special code editors? If so, they
| should probably have a whitespace sensitive mode to make
| this easier.
| cies wrote:
| ReasonML or ReScript not your cup of tea? They are different
| syntactical front-ends for OCaml.
| devmunchies wrote:
| Yes, I started in OCaml but switched to F# for the last 3 years
| and will likely move back to OCaml when effects are mature
| (when lwt and async are snuffed out).
|
| Being able to use C# libs is very nice but also it sucks that I
| don't have true null safety.
|
| Who knows, maybe F# is always more performant than OCaml and it
| doesn't make sense to switch back.
| LAC-Tech wrote:
| F# is .NET, so you can have pretty fine grained control over
| memory layout, right? Spans, packed structs, 8/16/32/64 bit
| signed/unsigned ints, etc.
|
| That stuff all gets a bit screwy in Ocaml, an int has 31 bits
| of information but is 32 bits in size, a record with two int
| 64s ends up being twice you expect, etc.
| yawaramin wrote:
| > when effects are mature (when lwt and async are snuffed
| out).
|
| That's actually on the way right now. The main concurrency
| library which is designed for OCaml 5, eio, internally uses
| effects but doesn't require its users to be exposed to them.
| Users write code in direct style and don't need to care about
| internal implementation with effects.
| keepquestioning wrote:
| Does it support Apple Silicon Macs?
| phplovesong wrote:
| Yes.
| didip wrote:
| OCaml syntax is a little hard to read for plebian like me.
|
| What is the use cases for OCaml?
| defrost wrote:
| One famous example (from 1997) is to lay out the rules for
| generating Fast Fourier code (for any input range, not just
| powers of two) and have correct efficient C code generated.
|
| [1] https://www.fftw.org/
|
| [2] https://en.wikipedia.org/wiki/FFTW
| jasperry wrote:
| One of the top use cases for OCaml is to build interpreters and
| compilers for new languages. Its syntax and type system makes
| it very natural to navigate tree-structured data, such as ASTs.
| It has a great parser generator library, Menhir, as well as an
| up-to-date LLVM API. The first version of Rust was written in
| OCaml.
| logicchains wrote:
| I remember around a decade ago when I first got into programming,
| I was super excited that OCaml would soon get multicore,
| regularly checking the progress. Although it took a lot longer
| than I imagined it would, nevertheless it feels amazing to see it
| finally here, almost like a dream when you've waited so long for
| something and you can't believe it's finally happening.
| InitEnabler wrote:
| What OSS is out there that uses OCaml?
| ziotom78 wrote:
| FFTW is written in C, but it used a FFT compiler written in
| OCaml to generate snippets of C code. [1]
|
| [1] https://www.fftw.org/fftw3_doc/Generating-your-own-
| code.html
| giraffe_lady wrote:
| A lot of projects also _started_ on ocaml and then later moved
| off of it once they had succeeded by showing the concept works
| and got some momentum going. People like it for exploratory
| compiler dev, then switch off it when their language can self
| host. IIRC both rust and elm started like this, certainly
| others as well.
| Skinney wrote:
| nitpick: Elm was and is written in Haskell.
| giraffe_lady wrote:
| Oh you're right. Now that I think about it elm is more
| stylistically similar to haskell too. Last time I used elm
| I had never played with haskell so I probably just assumed
| it was related to ocaml which I did know.
| phplovesong wrote:
| Yup. Rust was originally written in OCaml
|
| https://github.com/rust-
| lang/rust/tree/ef75860a0a72f79f97216...
| edwintorok wrote:
| The XAPI toolstack is written in OCaml:
| https://xenproject.org/developers/teams/xen-api/
|
| I've recently completed bugfixing/testing on 4.14.1+no-naked-
| pointers, and 5.0 compatibility is not far behind (we're
| usually 1 or 2 compiler versions behind latest, e.g. current
| production releases are built using 4.13.1)
|
| Disclaimer: I work on the XAPI project as part of my job, the
| project itself is >15 years old at this point.
| abathologist wrote:
| here are a few
|
| - https://github.com/coq/coq
|
| - https://github.com/mirage/mirage
|
| - https://github.com/returntocorp/semgrep
|
| - https://github.com/bcpierce00/unison
|
| See https://v2.ocaml.org/learn/companies.html for some more
| leads, as lots of those companies maintain useful OSS software.
| yawaramin wrote:
| One that I've found pretty helpful is comby: https://comby.dev/
|
| It's a code-syntax aware large-scale search-and-replace tool.
| E.g., comby -matcher .scala -review
| 'foo(:[x], :[y])' 'foo(:[x])'
|
| This will search in the current directory tree for all files
| that contain the code pattern 'foo(x, y)' and replace it with
| 'foo(x)', using Scala syntax rules. It's super convenient for
| doing large-scale codemods. E.g.
| https://github.com/tinymce/rescript-webapi/pull/40
| actionfromafar wrote:
| The Haxe language: https://haxe.org/
|
| https://frama-c.com/
|
| https://fbinfer.com/
|
| https://mirage.io/
|
| https://coq.inria.fr/
|
| https://github.com/ygrek/mldonkey (Stale project but large
| codebase.)
|
| https://akabe.github.io/ocaml-jupyter/
|
| https://reasonml.github.io/
|
| https://github.com/moby/vpnkit (Used by Docker)
| dunham wrote:
| Also https://flow.org/
| grumpyprole wrote:
| One that I use is the unison sync tool
| badrabbit wrote:
| I started learning ocaml and i stopped when I heard about the
| lack of multicore support (felt like it wasn't ready for general
| purpose use) this is an awesome developemt. From all the
| functional lanuages I've sampled so far Ocaml is the most
| intuitive. Hoping to finally get into it in 2023.
|
| Great work Ocaml devs!
| hnra wrote:
| Did you compare it to F#? I'll probably try to learn an ML
| language next year and without doing much research F# looks
| really nice since it gets all the .Net benefits.
| ecshafer wrote:
| I like F# and I think its a great language. But I also think
| it will always be second class for Microsoft.
| reverseblade2 wrote:
| I'd say significant portion of F# users are using Fable to
| generate Javascript. F# can compile to Rust and Python as
| well. https://github.com/ncave/fable-raytracer
| badrabbit wrote:
| I haven't tried F# because I am already having to work with
| powershell and C# and that whole .net/visualstudio ecosystem.
| The last thing I will look at on my personal time is a
| language in that ecosystem but since you recommended it I
| will have a look.
| belmont_sup wrote:
| Since we have a Unity product, I'm moving us to an F#
| backend! I actually quite like it since we're building a
| typical web api for a game.
|
| You don't have to deal with the typical need to determine
| what packages to use as you would in ocaml. I have aspnet
| and co. I'm okay with OOP leaking here and there when I get
| most of what I need already: an ML tool with an huge
| ecosystem.
| mbac32768 wrote:
| F# is nicer than the alternatives if you need to be (or want
| to be) on the Microsoft ecosystem but there are some things I
| miss when I use it from OCaml, like modules and functors. It
| also doesn't support named arguments, which are a fairly
| trivial thing that drastically cuts down the bugspace and
| increase usability for me.
|
| I also don't _think_ F# is as fast as OCaml?
|
| Fairly relevant piece of culture on why a company switched
| from OCaml to F# https://blog.darklang.com/new-backend-
| fsharp/
| jjtheblunt wrote:
| https://learn.microsoft.com/en-us/dotnet/fsharp/language-
| ref...
|
| might be now in there.
| int_19h wrote:
| I would expect F# to be faster than OCaml, given that it
| doesn't box floats, and is backed by a JIT that proactively
| does monomorphization of generics.
| naasking wrote:
| I doubt very much that F#/.NET is faster than OCaml. The
| latter is very fast, and the CLR's runtime generics have
| runtime costs.
| int_19h wrote:
| Can you give examples of the latter? I know from personal
| experience (of looking at disassembly of JIT output)
| that, when CLR generics are instantiated with structs, it
| is perfectly capable of full monomorphization with
| inlining of stuff similar to C++ <algorithm>.
| naasking wrote:
| Yes, structs are generally very good because they are
| mostly monomorphized. I haven't tested lately if structs
| of the same size but different types will fully
| monomorphize or if they share code and so require a small
| dispatch table. There was a CLR release awhile back where
| they discussed sharing code in this way to reduce code
| bloat.
|
| There are still a few pitfalls. Off the top of my head,
| accessing generic static fields, ie. static class Foo<T>
| { public readonly static T Member }. Mainly for non-
| struct members, this typically requires a hashtable-like
| lookup to resolve the offset for the.
|
| Also, generic interface dispatch can't be monomorphized,
| ie. interface IFoo<T> { void Method<T>(T value); }, so
| this too costs more than a regular virtual call because
| it too requires a hashtable-like lookup to resolve the
| generic overload to invoke.
| phillipcarter wrote:
| It's faster in some ways and slower in others. But in
| general this is "very fast" vs. "very fast". You won't
| find yourself wanting in web service performance in
| either language, for example.
| vkazanov wrote:
| Amazing! An incredible amount of effort! This was holding back
| ocaml almost for as long as I remember - and now it's just gone.
|
| Congratulations to the team!
|
| What are the next plans for the project? Spread newly available
| features..?
| sadiq wrote:
| There's definitely some work to build atop the new
| functionality available in 5.0 and make sure there's plenty of
| good learning material.
|
| In terms of the compiler and runtime development, the OCaml and
| ML Workshops at ICFP in October have videos that cover some of
| the experimental work happening: https://watch.ocaml.org/video-
| channels/ocaml2022/videos and
| https://www.youtube.com/playlist?list=PLyrlk8Xaylp7f8T7L5SFF...
|
| There's also a compiler development newsletter that's posted on
| the discuss at regular intervals which details some of the
| other work happening: https://discuss.ocaml.org/t/ocaml-
| compiler-development-newsl...
| sadiq wrote:
| There are a few OCaml contributors lurking and happy to answer
| questions if you have them.
| tomp wrote:
| How does "bounding races in space and time" impact the
| generated machine code? Do you have some interesting examples
| of how it's different from the code C++ or JVM JIT would
| generate? What's the performance impact? Thanks!
| kcsrk wrote:
| See examples in the second section and the results in the
| paper: https://kcsrk.info/papers/pldi18-memory.pdf
| tomp wrote:
| Do you mean section 2 of the paper? It only contains C-like
| pseudo-code, no machine code.
|
| The results section of the paper only compare the
| performance of Multicore OCaml with plain OCaml, not OCaml
| vs C++ / Java.
| jon_smark wrote:
| Are the plans for typed algebraic effects solidifying, or are
| they still nebulous? Concretely, are you willing to take a
| guess as to when we are expected to see OCaml 6? ;-)
| kcsrk wrote:
| Rather than a full effect system, we're very likely to have
| lexically scoped "checked" effects with the help of modal
| types. I briefly talked about it at the end of my ICFP
| keynote: https://icfp22.sigplan.org/details/icfp-2022-papers/
| 48/Retro...
|
| There are other cool stuff that is being worked on, which I
| am very excited about: https://discuss.ocaml.org/t/jane-
| street-compiler-development.... Hopefully, we will see many
| of these make it into OCaml 6.
| jon_smark wrote:
| Thanks for the reply. I hope that the array and list
| comprehensions land soon in upstream; it's a useful and
| hopefully not-too-controversial feature.
|
| I'm more ambivalent regarding the local allocations and the
| unboxed types. I totally understand why they'd be useful
| when you are trying to squeeze every last drop of
| performance, but they do require a not-so-trivial
| complexification of the language.
| kcsrk wrote:
| The local types are less invasive than the full support
| for typed effects. In particular, they are opt-in and
| associated complexity is pay-as-you-go. In my initial
| experiments, they seemed pretty nice to program with.
| octachron wrote:
| The type system for algebraic effects is still in the
| research and design phase at this point.
|
| Right now, I am not even taking a guess of what will be the
| defining new major features of OCaml 6 (effect system +
| modular implicits maybe? Maybe not?).
| jon_smark wrote:
| Thanks for the reply. I'm hoping that modular macros land
| soon. I'm very ambivalent about the PPX mechanism, and I
| hope that modular macros reduces the need of PPX.
| pdimitar wrote:
| As an Elixir (which steps on Erlang) and Rust dev I'm curious
| if you think OCaml 5.0 / Eio will give the Erlang's BEAM VM and
| Rust's tokio a run for their money in the parallel runtime
| space.
|
| I'm super curious about OCaml, picked it up and left it several
| times in the last 3 years. Now that multicore is here I'll
| absolutely be picking it up again and try to use it for
| parallel scripting and for some of my work. Great job!
| sadiq wrote:
| We certainly hope so. You may find Thomas Leonard's talk from
| last year's workshop interesting: https://watch.ocaml.org/vid
| eos/watch/74ece0a8-380f-4e2a-bef5...
|
| The paper we wrote on retrofitting effect handlers:
| https://arxiv.org/abs/2104.00250 also has some http
| benchmarks
| mbac32768 wrote:
| People who aren't PL theorists understand the multicore benefits
| even if the retrofitting paper might be over their heads. On the
| other hand, the bounding data races in time and space
| paper/presentation is also a fairly significant change that I
| don't think the average dev has an easy to understand
| relationship with.
|
| Anil covers it in a bit more plain English in this Signals and
| Threads episode. Here's a bit of the transcript, starting at
| about 50 minutes in: https://signalsandthreads.com/what-is-an-
| operating-system/
|
| > Ron: Do you have a pithy example of a pitfall in multicore Java
| that doesn't exist in multicore OCaml?
|
| > Anil: There's something called a data race. And when you have a
| data race, this means that two threads of parallel execution are
| accessing the same memory at the same time. At this point, the
| program has to decide what the semantics are. In C++, for
| example, when you have a data race, it results in undefined
| behavior for the rest of the program, the program can do
| anything. Conventionally, daemons could fly out of your nose is
| an example of just what the compiler can do.
|
| > In Java, you can have data races that are bounded in time so
| the fact that you change a value can mean later on in execution,
| because of the workings of the JVM, you can then have some kind
| of undefined behavior. It's very hard to debug because it is
| happening temporally across executions of multiple threads.
|
| > In OCaml, we guarantee that the program is consistent and
| sequentially consistent between data races. It's hard to explain
| any more without showing you fragments of code. But conceptually,
| if there's a data race in OCaml code, it will not spread in
| either space or time. In C++, if there's a data race, it'll
| spread to the rest of the codebase. In Java, if there's a data
| race, it'll spread through potentially multiple executions of
| that bit of code in the future.
|
| > In OCaml, none of those things happen. The data race happens,
| some consequence exists in that particular part of the code but
| it doesn't spread through the program. So if you're debugging it,
| you can spot your data race because it happens in a very
| constrained part of the application and that modularity is
| obviously essential for any kind of semantic reasoning about the
| program because you can't be looking in your logging library for
| undefined behavior when you're working on a trading strategy or
| something else. It's got to be in your face, at the point.
|
| (and so on)
| jojohohanon wrote:
| This reminds of the worse is better debate.
|
| Specifically how the "better" crowd spent a lot of time trying
| to solve PCLSRing while the "worse" crowd just said: meh, throw
| an error and let the program figure it out.
|
| Previously
|
| https://news.ycombinator.com/item?id=20225555
| KMag wrote:
| Honestly, the best of both worlds would have been to have the
| simple kernel implementation and put the boilerplate recovery
| code in the system libraries. For instance, libc's write()
| should handle interruption resumption, and libc should also
| provide a write_interruptable() (okay, appropriately
| shortened for the symbol limits in early linkers) to expose
| the raw system call in the uncommon case that the programmer
| wants to manually handle interruptions.
| rq1 wrote:
| Aren't these problems better resolved by linear types and
| alike?
|
| Successful implementations were made in several languages now.
| tomp wrote:
| Can you name a single successful implementation that can e.g.
| implement modern concurrent lock-free data structures without
| using `unsafe`?
| ghostwriter wrote:
| ATS has it [1], you can safely implement lock-free queues
| and ring buffers in it.
|
| [1] https://ats-
| lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML...
| dan-robertson wrote:
| I guess you still want well-defined semantics even if most
| users use some modes-based or other high-level api. Eg normal
| rust code gets to be 'data race free' but low level
| implementations of eg Arc could be racy if they were
| incorrect. But maybe the OCaml thing is more than just doing
| a good job of specifying semantics and there is some overhead
| in generated code because of it. I confess I haven't looked
| into the details.
| poulpy123 wrote:
| any easy way to try it on windows (not wsl) ?
| dra27 wrote:
| It's from an experimental branch, so not very easy, but this
| works with opam-repository-mingw to get a vanilla mingw-w64
| build of OCaml 5.0.0:
|
| opam switch create 5.0
| --repos=dra27=git+https://github.com/dra27/opam-
| repository#windows-compilers --packages=ocaml.5.0.0,ocaml-
| option-mingw
| poulpy123 wrote:
| Thanks I will have a look
| lilactown wrote:
| Is there a guide on how to use the new constructs? The link to
| the 5.0 docs was broken on the site, and after manually fixing
| the URL all I found was some type annotations in the `Effects`
| module.
| resoluteteeth wrote:
| IIRC, while they added the underlying language support for
| effects to this version to get the multicore support working,
| the standard library support for effects isn't really ready
| yet, so you may want to hold off another year or so.
|
| I think eventually it will hopefully turn into something like
| what languages like purescript have which would be really cool.
|
| (I've only used ocaml a tiny bit and use f# a lot more but I
| keep periodically checking the status of this because it's
| something that would make ocaml a lot more interesting to me.)
| c-cube wrote:
| The Effects module is kind of low level right now, as it
| understand it. You should like at Eio for a library that gives
| you nice fibers and non blocking IOs on top of effects! It's a
| neat library.
| cies wrote:
| > like at Eio
|
| Look at Eio here: https://github.com/ocaml-multicore/eio
| edwintorok wrote:
| Make sure to check out the new chapter on parallelism too that
| is linked from the release notes:
| https://v2.ocaml.org/releases/5.0/manual/parallelism.html
| anentropic wrote:
| https://github.com/kayceesrk/ocaml5-tutorial
| octachron wrote:
| The link to the Effect section of the manual at
| https://v2.ocaml.org/releases/5.0/manual/effects.html works for
| me and should contain an higher level description of what are
| effect handlers. Which link was broken for you?
| lilactown wrote:
| The "Manual" link on this page https://ocaml.org/releases is
| broken
| octachron wrote:
| This is fixed now, thanks!
| lilactown wrote:
| I also didn't think to look in the "language extensions"
| section of the manual, instead going to the API docs and
| clicking on the "Effect" module.
|
| This looks much more interesting, on a skim. Thanks!
| maattdd wrote:
| Amazing work from the team! I wonder if this is actually the
| first mainstream language which has managed to remove its "global
| lock" without breaking changes ?
| gadmm wrote:
| To clear up any misconception, out of the box OCaml will behave
| like OCaml 4 with a single domain and a "domain lock". Programs
| currently using multiple threads for concurrency will remain
| single-core for the time being, as they will need to opt-in to
| parallelism features. In this sense, adding parallelism to
| OCaml does not break existing programs, but they still might
| have to be audited for thread-safety depending on how they want
| to use parallelism. There is no magic.
| sadiq wrote:
| Just to add to the sibling comment. To maintain backwards
| compatibility, OCaml 5 has both threads and domains.
|
| Threads belong to a domain and only one thread can hold the
| runtime lock for the domain. This is the same behaviour as in
| OCaml 4.
|
| With OCaml 5 you can have as many domains as you want though
| (we recommend no more than you have cores though).
| edwintorok wrote:
| This backwards compatibility decision to separate threads
| from domains has been very useful and allows to gradually
| "port" existing code to 5.0: first just fixup C bindings to
| avoid naked pointers, and then code can safely run on OCaml 5
| just as before.
|
| And once a program (and all its dependencies) have removed
| dependence on global state they can opt-in to multicore by
| spawning additional domains.
| UncleOxidant wrote:
| $ opam update $ opam switch create 5.0.0
| --repositories=default $ eval $(opam env) $ ocaml
| OCaml version 5.0.0 Enter #help;; for help.
| rg111 wrote:
| What is the most fun and best source to learn OCaml for a
| programmer?
|
| I know this one [0] so far. Also the famous Coursera PL course
| covers ML.
|
| [0]: https://cs3110.github.io/textbook/cover.html
| laylomo2 wrote:
| Congrats! Super excited to start playing around with the effects
| system.
| [deleted]
| eatonphil wrote:
| If you want to see an example of it:
| https://v2.ocaml.org/releases/5.0/manual/parallelism.html.
| nih0 wrote:
| this was being talked about when i was still in high school and
| last year i did my masters
| octachron wrote:
| The road to multicore OCaml was indeed longer and harder than
| expected. At the end of the day, the constraint of trying to
| preserve the behavior of almost all existing programs ended up
| driving a majority of design choices. Typically, this required
| at least one major rewrite of the multicore runtime along the
| way.
| rg111 wrote:
| What is the most fun and best source to learn OCaml for a
| programmer?
|
| I know this one [0] so far. Also the famous Coursera PL course
| [1] covers ML.
|
| [0]: https://cs3110.github.io/textbook/cover.html
|
| [1]: https://coursera.org/learn/programming-languages
| nequo wrote:
| Check out Real World OCaml too:
|
| https://dev.realworldocaml.org/
| melling wrote:
| OCaml has a reputation for being fast.
|
| https://sixthhappiness.github.io/articles/python-scheme-and-...
|
| Does anyone have any multicore benchmarks that illustrate
| performance increases in 5.0?
| samuell wrote:
| Great, so, can someone send me a PR with an OCaml
| implementation of "my"/our GC-content benchmark (a simple
| string proccessing benchmark counting the fraction of G:s and
| C:s in DNA sequences, compared to all the A:s, C:s, G:s and
| T:s)?
|
| https://github.com/samuell/gccontent-benchmark
|
| :D
| kcsrk wrote:
| Here are some parallel benchmarks from the Sandmark continuous
| benchmarking service:
| https://sandmark.tarides.com/?app=Parallel+Benchmarks¶ll...
| [deleted]
| acaloiar wrote:
| Meta: I believe the title should be "OCaml 5 is out!", as it
| appears on the OCaml site.
|
| At first glance, I understood the title "OCaml 5.0 Multicore is
| out" to mean "Multicore is no longer part of OCaml 5.0".
| jon_smark wrote:
| Congratulations and a big thank you to the OCaml team! I hope
| that multicore support finally ticks all the requirement boxes
| that had prevented many from taking a serious look at OCaml. The
| language certainly deserves it: it hits that sweet spot between
| expressiveness, performance, and pragmatism like no other.
| pjmlp wrote:
| Great news! Kudos to everyone that helped make this happen.
| tempodox wrote:
| Christmas came slightly early this year.
| octachron wrote:
| The Christmas presents will be all the issues and bugs that
| will be discovered between now and Christmas eve in the shiny
| new multicore runtime.
| aylmao wrote:
| No way, it's finally out! This is fantastic news.
| pjmlp wrote:
| Great news! Kudos to everyone that helped make this happen.
| ghostwriter wrote:
| Multicore is there, STM instead of mutable imperative logic in
| all the libraries developed for the past two decades: not so much
| though.
| kcsrk wrote:
| Still early days, but I had done some exploratory work in the
| past on Reagents, a composable lock-free library [1]. Now that
| OCaml 5 is released, we're reviving this work.
|
| It's semantics is weaker than STM -- unlike STM, it doesn't
| provide serializability but Reagents can compile down to multi-
| word compare and swap operations, which can be implemented with
| the help of hardware transactions (when present) or efficient
| software implementations of it [2]. Hence, Reagent programs
| should be faster than STM.
|
| [1] https://github.com/ocaml-multicore/reagents [2]
| https://arxiv.org/pdf/2008.02527.pdf
| c-cube wrote:
| I haven't heard anyone talk about STM for OCaml, funny. People
| talk about, or work on, lightweight fibers, lockfree data
| structures, io_uring, etc. but not STM. Is it falling out of
| fashion? Even in clojure I hear that few people actually use
| it.
| grumpyprole wrote:
| It works great in Haskell. The problem is that it really
| needs typed effects, hopefully OCaml will get typed algebraic
| effects at some point.
| leoh wrote:
| Anyone know if OCaml was used at FTX, btw? Given that it's big at
| Jane Street, where SBF worked.
| mc10 wrote:
| Probably not, given that their public sample code[1] has C++,
| Go, and Python.
|
| [1]: https://github.com/ftexchange/ftx
| mbac32768 wrote:
| They did not. They were a Python and React shop, with efforts
| underway to rewrite in Rust.
| leoh wrote:
| Python for trading, yikes
|
| Would love to see that codebase
|
| Then again, Stripe has been wildly successful with Ruby
|
| Albeit they've had type checking with sorbet for years
| 2wrist wrote:
| Oh congratulations! Well done to all involved!
| mnming wrote:
| Is it still possible to use Reason as frontend for Ocaml 5?
|
| I felt an ergonomic and modern syntax is the only missing piece
| in Ocaml.
| grumpyprole wrote:
| There's nothing "modern" about the C-style curly brace and
| semi-colon syntax in Reason. In fact, the rise of Python and
| it's lightweight syntax means that C-style languages are
| starting to look dated.
| sqlserver2008 wrote:
| Indentation-sensitive syntax is totally obsolete in a world
| with autoformatters. In addition, with this kind of syntax
| you also lose the ability to have your code autoformatted in
| certain situations. Here's a trivial example to illustrate
| the point: def example(): x = 5
| print("Hello world")
|
| What's the mistake here? Depending on whether the print is
| part of the function, it should either be indented or have a
| newline before it. The point is you (and any formatting tool)
| can't know what the horizontal alignment of this code should
| be just by examining the vertical line order. You can only
| determine this by knowing (or reanalyzing) the semantics of
| the code. During a refactor where you're moving around lots
| of code, this can be a significant PITA. However, in the JS
| example, function example() {
| let x = 5 console.log("Hello world") }
|
| it's unambiguous what the mistake is because you can
| determine the correct formatting entirely from the line
| order, without having to know anything about the code's
| semantics.
| grumpyprole wrote:
| This is a really good point, but one still doesn't need
| curly braces and semis. Despite having a lightweight
| syntax, OCaml isn't indentation sensitive, so doesn't
| suffer from this. The Ocamlformat tool also works really
| well.
| sqlserver2008 wrote:
| > OCaml isn't indentation sensitive, so doesn't suffer
| from this
|
| True, I was just making the point that the lightweight
| syntax of indentation-sensitive languages like Python can
| be problematic. I don't know how OCaml is able to achieve
| this style of syntax without the use of significant
| indentation, but it is impressive.
| anentropic wrote:
| Strong disagree from me
|
| Adding spurious curly braces to make OCaml look more like JS is
| not 'ergonomic and modern' syntax, it's a step backwards if
| anything (though I can appreciate there is some sense to that
| in context of a compile-to-JS language for frontend dev)
| nequo wrote:
| Signals and Threads had an interview with Anil Madhavapeddy last
| year:
|
| https://signalsandthreads.com/what-is-an-operating-system/
|
| He talked about the work to put a multicore-ready memory model[1]
| and GC[2] under OCaml.
|
| [1] https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf
|
| [2] https://arxiv.org/abs/2004.11663
| forkbomb123 wrote:
| Just FYI the talk about multicore starts at 44:22
| inbx0 wrote:
| Offtopic, but Signals and Threads is my absolute favourite
| programming podcast, maybe even favourite podcast overall. They
| go into interesting topics deeply, instead of the way too
| common "interviewer read the summary of the wikipedia page
| about the subject and is now interviewing someone who actually
| read the entire page."
|
| Hoping they'll get more content out soon.
| mirekrusin wrote:
| Yaron Minsky is such a charismatic speaker, watched all his
| recordings you can find on internet more times that I'd like
| to admit, s&t is great.
| nielsole wrote:
| They are doing a really good job at employer branding. They
| make the requirements/constraints of the finance industry
| sound interesting. A field that cares about correctness,
| ordering and accurate clocks.
| dimitropoulos wrote:
| thanks for mentioning this! I've been looking for a new one
| that's good. Even if they're behind schedule, it looks like
| I've got some catching up to do to keep me busy in the
| meantime.
| sadiq wrote:
| One thing to point out to anyone listening to that episode is
| that at the time the plan was to only upstream the multicore GC
| for 5.0 and then follow up with effects. Instead they both went
| in to 5.0.
|
| (Was a very enjoyable episode though!)
| Decabytes wrote:
| I'm curious about what design decisions lead to OCaml not having
| Multi-threading when version 1.0 came out. Majorly impressive
| work getting something as complex as that added on afterwards.
| Kudos to everyone involved!
| dljsjr wrote:
| Caml 1.0 was released in '85 and OCaml (the O is for Object
| Orientation) was 1996. Multithreading wasn't a high priority
| for anybody back then. The JVM didn't even have threads until
| 1997 and those threads were green threads, OS threads came to
| Java later.
| pasc1878 wrote:
| However this is all Unix and academia based. If you wrote
| code for Windows and OS/2 in the commercial world you were
| using threads sine '89 and thus did not want to use the
| languages that did not use threads e.g. python, OCaml
| int_19h wrote:
| It would be pretty difficult to write threaded code for
| Windows in 1989, since it didn't support threads until
| WinNT 3.1 (1993).
|
| But even in late 90s it was still common for desktop Win9x
| apps to use the main window message loop for async
| processing (Win32 API itself heavily encouraged it at the
| time - e.g. that's how OS timers work) in lieu of threads.
| cmrdporcupine wrote:
| In the late 80s and early 90s we wrote things with threads
| but they were primarily a kind of convenience to get
| multitasking behaviour and not any kind of performance
| boost.
|
| Multicore / multiprocessor systems were not a mainstream
| thing in consumer hardware until the 21st century.
| Mikeb85 wrote:
| > I'm curious about what design decisions lead to OCaml not
| having Multi-threading when version 1.0 came out
|
| You do know that C (edit - didn't have multithreading in the
| language spec until C11, right?)
|
| It was common on languages of that era. Also Ocaml has had
| libraries for multithreading for many years, just like C has
| POSIX threads and things...
| c-cube wrote:
| I thought C11 had threads and atomic and concurrency
| primitives?
| Mikeb85 wrote:
| Ah yeah my bad. Still like 30+ years after it's creation
| though. And the vast majority of C software out there
| doesn't use C11 anyway.
| toolslive wrote:
| Halleluja! I think they were at it for more than a decade.
| ecshafer wrote:
| OCaml is one of those languages that is a real joy to use and
| makes me wonder why its not used more often. I feel like if I
| jump into a Lisp or ML language, I am so productive and can write
| some really complicated software with relative ease. But they are
| relatively rare in industry, and I have never really crossed the
| t on why, despite various reasonings about it.
|
| This is a great achievement for OCaml, but does anyone have an
| explanation on why it was so difficult to implement for them?
| c-cube wrote:
| It's just very hard to write a solid concurrent GC. There are
| not many in existence today. Here the challenge was doubled by
| the obligation to preserve the single core performance of
| existing programs, with the very fast allocation path on the
| minor heap. It's always harder to add these features to an
| existing language that already has significant programs written
| in it.
| amelius wrote:
| Would it be possible to take this work and turn it into a
| more general GC library that language implementers can use
| beside LLVM?
| c-cube wrote:
| If your language matches ocaml's runtime semantics, then
| sure. It means uniform representation, 63bits integers,
| etc. but can be quite useful if your language is ML-ish.
| epolanski wrote:
| I think John Carmack made a good point on this topic which I
| did not think of before.
|
| He stated that albeit he spent years working with Lisps (CL and
| Racket mostly) or Haskell he stated that jumping on projects in
| those languages instantly requires you pay the price of having
| to learn the abstractions and DSLs that the users wrote for the
| project before being able to understand anything.
|
| He compared it with C or Go, where he realized that it was
| easier to him to read kernel code without any context, because
| there is no abstraction price to pay. What you see is what
| there is to understand.
|
| He basically says that those languages (MLs, Lisps) are great
| for personal projects or very small teams but they don't scale
| well, this also reflects on open source where many will build
| their libraries and programs, but very few get into
| collaborating in those communities.
| Hermitian909 wrote:
| I agree with Carmack's analysis of Lisp but don't think it
| really applies to OCaml, which I've used professionally.
|
| IMO, OCaml is significantly easier to ramp up on than
| Haskell. The object model and the fact that the language
| allows you to ramp up on imperative code let you write
| working code and the language is feature rich enough you're
| not generally writing a DSL. Granted, I think it is still
| harder to ramp up programmers than in JS, Python, Java, or
| Go.
|
| I think OCaml's biggest problem has been one of timing and
| value proposition. The language matured to some level of
| production readiness in the mid 2000s at which point
| multicore started to become important.
|
| If you wanted extreme performance, OCaml increasingly
| couldn't compete with C++ or Java. Most shops don't the
| robustness the superior type system could provide and the
| other downsides of an unpopular language always loomed large
| when adoption was being considered.
|
| I still think OCaml or something OCaml-like might become
| popular with time, but it will require the kind of
| improvements the multicore project is hinting at providing
| and more.
| anentropic wrote:
| I don't know what JC said exactly but I would guess that some
| of the issues of scaling Lisps (dynamic typing, DSL hell)
| don't really apply to OCaml
| nightfly wrote:
| I'm certainly no expert, but isn't (linux) kernel C full of
| pre-processor macros that muddy reading the code?
| jojohohanon wrote:
| I think golang is designed intentionally to make it easy to
| read unfamiliar code.
|
| To paraphrase: The idea being that a well designed library
| api gets you 90% of the benefits of a richer language's
| features, but without exactly that penalty that Carmac calls
| out.
| gleenn wrote:
| Doesn't that kinda presume that everyone should just "write
| a well-designed library"? If it's that much easier to just
| use a richer language shouldn't we just do that?
| bmitc wrote:
| Those don't apply as heavily to F# and OCaml as heavily
| though. F# and OCaml are much more practical than Haskell and
| much more strict than Lisp/Scheme/Racket, and so they sit in
| a very nice sweet spot of programming language design. The
| MLs, despite their influence on other languages, are the most
| overlooked and underused languages.
|
| In F#, even for some DSLs, there's not much funny business at
| all. You have types and functions. I'm not as familiar with
| OCaml, but in F#, the only really confusing thing along the
| lines of DSLs or macros are computation expressions. But for
| the most part, you don't need them aside from the built-in
| `async` one.
| 59nadir wrote:
| > F# and OCaml are much more practical than Haskell
|
| For industrial applications in most deployment environments
| Haskell is a much more practical language than OCaml, due
| to having many more modern runtime features (green threads,
| STM, etc., that for many years have made the lack of
| multicore support in OCaml seem embarrassing). It's not
| really that that gap has been caught up to now either,
| OCaml is still many years behind Haskell in basic runtime
| features.
|
| F# obviously has a practically useful and featureful
| runtime, but has a scheduler that makes it easy to get
| thread exhaustion, whereas Haskell has a preemptive one
| that will make that a non-issue.
|
| I find that the "practical language" argument is usually
| used by people who have never used either OCaml or Haskell
| for solving real world problems. In practice OCaml is a
| did-not-finish versus the comparatively (to most other
| languages, notably losing to the BEAM languages) excellent
| finishing time of Haskell.
| WastingMyTime89 wrote:
| I have used both. Ocaml is a joy. I would rather swallow
| shards of glass than work with Haskell again.
|
| The language is a mess. The compiler is slow. Performance
| is poor. The community is insufferable.
|
| I think that what is meant by practical.
| bmitc wrote:
| I was mainly addressing Carmack's points on the "culture"
| of these languages, but F# is definitely more practical
| overall than Haskell, in my opinion. Eager by default
| with optional lazy evaluation, mutability, OOP,
| functional, pragmatic and huge standard library, easy
| FFI, CLI tooling, easy to use async and concurrency, and
| a strong VM that basically runs anywhere and is easy to
| install all go a long way. I am less familiar with the
| particulars of OCaml because I have never needed to reach
| for it over F#, and yes, the longstanding multicore
| support deficiency was not great.
|
| Also, to elaborate on my reply to Carmack, I think he is
| grossly underestimating the prevalence of esoteric
| implementations and DSLs in C, C++, and their ilk.
|
| And yes, Elixir and Erlang, especially Elixir, are very
| practical languages. I'm hard pressed these days to look
| any further than F# or Elixir for projects because they
| effectively cover all bases from soft real-time embedded
| and up.
| agumonkey wrote:
| There's even a paradox. Lisp like languages aims at not
| scaling, since you have control over parsing (to an extent)
| and interpretation (macros). If something requires a lot of
| hands.. people will compress that into a DSL, and keep the
| team small.
|
| It does create dialects and potential silo effect. I never
| worked in real CL projects but books and articles mention to
| not abuse macros and DSLs because of that, old lispers are
| also often very educated .. and they rarely do things for
| trivial reasons. I'm regularly surprised by how well thought
| out things are.
| naasking wrote:
| > He compared it with C or Go, where he realized that it was
| easier to him to read kernel code without any context,
| because there is no abstraction price to pay. What you see is
| what there is to understand.
|
| I don't get it. In C you're programming with structures, data
| types and functions. In ML and Lisp, you're programming with
| structures, data types and functions. Lisp lets you muck with
| syntactic forms so maybe that has some obscuring effect, but
| I expect most programs are written in fairly direct style.
| Where people do add abstractions, it's to reuse code so
| there's ostensibly less code to understand overall.
___________________________________________________________________
(page generated 2022-12-17 23:02 UTC)