Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Effective Concurrency with Algebraic Effects in Multicore OCaml

kcsrk.info

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#21

Post by [deleted] »

johnnycerberus wrote: post #19
wtetzner wrote: post #14

Earlier quoted context omitted.

Algebraic data types are not the same as an algebraic effects system.

Java's checked exceptions can be considered an effect system and coupled with ADTs I suppose we can call it an algebraic effects system. I mean the domino effect in which the exception has to be handled in each method that calls that is what seems to me the effect/handler counterpart that is present in Java. In the end an algebraic effect is just an extension of a type system that supports ADT, or is my memory from u…

[deleted]

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#22

Post by octachron »

johnnycerberus wrote: post #19
wtetzner wrote: post #14

Earlier quoted context omitted.

Algebraic data types are not the same as an algebraic effects system.

Java's checked exceptions can be considered an effect system and coupled with ADTs I suppose we can call it an algebraic effects system. I mean the domino effect in which the exception has to be handled in each method that calls that is what seems to me the effect/handler counterpart that is present in Java. In the end an algebraic effect is just an extension of a type system that supports ADT, or is my memory from u…

You cannot resume a computation with exceptions. At most, exceptions are a subset of effects. Similarly, a lot of the issues with checked exceptions in Java come from the lack of exception polymorphism in the checked exception type system. Adding the two points, you cannot really call checked exceptions an effect system.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#23

Post by shwestrick »

johnnycerberus wrote: post #19
wtetzner wrote: post #14

Earlier quoted context omitted.

Algebraic data types are not the same as an algebraic effects system.

Java's checked exceptions can be considered an effect system and coupled with ADTs I suppose we can call it an algebraic effects system. I mean the domino effect in which the exception has to be handled in each method that calls that is what seems to me the effect/handler counterpart that is present in Java. In the end an algebraic effect is just an extension of a type system that supports ADT, or is my memory from u…

The defining feature of these effect systems is "resumable continuations". Essentially, at the point where you catch an exception, you have the option of resuming the code which threw the exception, and you can tell it how to proceed.

So, whereas exceptions only jump backwards in the stack, resuming a continuation sorta lets you jump forwards again, back to where you were. It's really powerful stuff.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#24

Post by nsonha »

octachron wrote: post #22
johnnycerberus wrote: post #19

Earlier quoted context omitted.

Java's checked exceptions can be considered an effect system and coupled with ADTs I suppose we can call it an algebraic effects system. I mean the domino effect in which the exception has to be handled in each method that calls that is what seems to me the effect/handler counterpart that is present in Java. In the end an algebraic effect is just an extension of a type system that supports ADT, or is my memory from u…

You cannot resume a computation with exceptions. At most, exceptions are a subset of effects. Similarly, a lot of the issues with checked exceptions in Java come from the lack of exception polymorphism in the checked exception type system. Adding the two points, you cannot really call checked exceptions an effect system.

not to mention that exceptions as flow control is frowned upon in java, so while there are similarities, they are different in designation.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#25

Post by weatherlight »

papercrane wrote: post #18
weatherlight wrote: post #16

Earlier quoted context omitted.

Compared to Erlang, Haskell, an other FP languages, Java's concurrency story leaves a lot to be desired. https://medium.com/traveloka-engineering/cooperative-vs-pree...

In fairness to the JVM, the work on Project Loom would bring the JVM inline with what that document describes as the Erlang/Haskell "Hybrid threading" model.

In OpenJDK, Java threads are just thin wrappers around OS threads and OS threads are a very precious resource; a modern OS can't support more than a few thousand active threads at a time.

I'm not sure how one would get there with the JVM's memory model. you'd need something like actors and a preemptive scheduler per core at the VM level with a share nothing state between actors/virtual threads. Erlang utilizes message passing and immutability to do this.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#26

Post by LeonidasXIV »

pjmlp wrote: post #7
nextaccountic wrote: post #5

Something I rarely see addressed: why was multicore ocaml blocked on having full-fledged effects? Couldn't multicore have landed years ago, and then gradually insert effects in the language?

I guess to avoid nuking the ecosystem Python 3 style.

Which also didn't add multicore support, it still has a GIL. But it has been an extremely valuable lesson for other systems, so there's tha.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#27

Post by pjmlp »

weatherlight wrote: post #25
papercrane wrote: post #18

Earlier quoted context omitted.

In fairness to the JVM, the work on Project Loom would bring the JVM inline with what that document describes as the Erlang/Haskell "Hybrid threading" model.

In OpenJDK, Java threads are just thin wrappers around OS threads and OS threads are a very precious resource; a modern OS can't support more than a few thousand active threads at a time. I'm not sure how one would get there with the JVM's memory model. you'd need something like actors and a preemptive scheduler per core at the VM level with a share nothing state between actors/virtual threads. Erlang utilizes messag…

Which is precisely why Java language specifications doesn't state if they are green or red threads, they just happened to evolve into red threads across multiple implementations.

Project Loom is bringing green threads back, now officially as virtual threads.

Additionally there is java.util.concurrent and for those that care to really go deep enough, custom schedulers.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#28

Post by solmag »

sadiq wrote: post #10
nextaccountic wrote: post #5

Something I rarely see addressed: why was multicore ocaml blocked on having full-fledged effects? Couldn't multicore have landed years ago, and then gradually insert effects in the language?

Multicore upstreaming wasn't blocked on having fully-fledged effects. If you look at the diff between multicore 5.00 and trunk OCaml, the changes required for fibers is pretty small relative to the multicore GC and making the rest of the runtime thread-safe. The original plan was to upstream only the multicore GC. This was sped up on the suggestion of the core developers and now 5.0 will bring parallelism and effect…

Seems to me this multicore journey was quite a barn burner; might as well have gone all the way to linear types as your GC.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#29

Post by valenterry »

papercrane wrote: post #18
weatherlight wrote: post #16

Earlier quoted context omitted.

Compared to Erlang, Haskell, an other FP languages, Java's concurrency story leaves a lot to be desired. https://medium.com/traveloka-engineering/cooperative-vs-pree...

In fairness to the JVM, the work on Project Loom would bring the JVM inline with what that document describes as the Erlang/Haskell "Hybrid threading" model.

This has nothing to do with the JVM. Scala for example is already capable of exactly what Erlang/Haskell do. This is merely about the language Java, which lacks support for to make such a programming style ergonomic. You either need a language with very powerful type-system or a dynamically typed language. (or specific support for it, like in Go, but even in Go you are limited to what the language designers forsaw)

Project Loom will not change that, but it will improve performance for certain scenarios.

Re: Effective Concurrency with Algebraic Effects in Multicore OCaml

#30

Post by papercrane »

weatherlight wrote: post #25
papercrane wrote: post #18

Earlier quoted context omitted.

In fairness to the JVM, the work on Project Loom would bring the JVM inline with what that document describes as the Erlang/Haskell "Hybrid threading" model.

In OpenJDK, Java threads are just thin wrappers around OS threads and OS threads are a very precious resource; a modern OS can't support more than a few thousand active threads at a time. I'm not sure how one would get there with the JVM's memory model. you'd need something like actors and a preemptive scheduler per core at the VM level with a share nothing state between actors/virtual threads. Erlang utilizes messag…

> I'm not sure how one would get there with the JVM's memory model. you'd need something like actors and a preemptive scheduler per core at the VM level with a share nothing state between actors/virtual threads.

Part of what Project Loom is doing is bringing lightweight usermode threads, called "Virtual Threads" and it's own scheduler.

Importantly you don't need share nothing state or immutability to add preemption, the JVM already has points during code execution where it knows the full state of the program. They call these "safepoints" and they're important for the GC to work properly. With the current implementation of Loom virtual threads are preempted when they do any blocking I/O or synchronization, but there's no reason why in the future they couldn't preempt them at any safepoint.

Post reply on HN