This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-22
Channels
- # aleph (5)
- # announcements (9)
- # babashka (9)
- # beginners (127)
- # cherry (1)
- # cider (48)
- # clj-kondo (5)
- # cljdoc (1)
- # clojure (70)
- # clojure-berlin (1)
- # clojure-europe (57)
- # clojure-france (2)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-norway (4)
- # clojure-uk (1)
- # clojurescript (2)
- # css (1)
- # cursive (6)
- # emacs (6)
- # gratitude (1)
- # honeysql (5)
- # introduce-yourself (5)
- # jobs-discuss (7)
- # joyride (1)
- # kaocha (3)
- # lsp (1)
- # malli (9)
- # nbb (2)
- # off-topic (91)
- # pathom (7)
- # pedestal (14)
- # re-frame (4)
- # reitit (67)
- # shadow-cljs (46)
- # spacemacs (3)
- # squint (3)
- # tools-build (14)
- # tools-deps (1)
- # vim (3)
would it be hard to try aleph on virtual thread? I heard / read in a few places that it is comparable to native performance. https://medium.com/@zakgof/a-simple-benchmark-for-jdk-project-looms-virtual-threads-4f43ef8aeb1
my naive and unresearched opinion is that if you can get a virtual thread executor and give it to aleph, you can try it
We've been playing around with it, and I've started work on a Manifold-compatible successor that uses vthreads, but off the top of my head, I'm not sure how much higher performance we could expect to see in Aleph, from switching over immediately.
Part of the underlying machinery is based off Netty, which is entirely event-driven off platform threads at the moment. An https://github.com/netty/netty/issues/12348 wasn't promising, but there's more to look into, to make netty take advantage of vthreads. It's not a simple drop-in, unfortunately, since things like ThreadLocal caches will hurt performance in a vthread world, if copied rampantly.
Ultimately, though, the event-driven paradigm doesn't make much sense if vthreads are super-cheap. It's a shame https://github.com/puniverse/pulsar died out (one of the Pulsar authors went on to work on Loom); it was the first clj lib built for fibers.
For now, you can partially try it out by redefining the wait-pool
and executor-pool
in manifold.executor
to use the new vthread executor. Let us know what you find.
there are caveats https://github.com/netty/netty/issues/12348
We've been playing around with it, and I've started work on a Manifold-compatible successor that uses vthreads, but off the top of my head, I'm not sure how much higher performance we could expect to see in Aleph, from switching over immediately.
Part of the underlying machinery is based off Netty, which is entirely event-driven off platform threads at the moment. An https://github.com/netty/netty/issues/12348 wasn't promising, but there's more to look into, to make netty take advantage of vthreads. It's not a simple drop-in, unfortunately, since things like ThreadLocal caches will hurt performance in a vthread world, if copied rampantly.
Ultimately, though, the event-driven paradigm doesn't make much sense if vthreads are super-cheap. It's a shame https://github.com/puniverse/pulsar died out (one of the Pulsar authors went on to work on Loom); it was the first clj lib built for fibers.
For now, you can partially try it out by redefining the wait-pool
and executor-pool
in manifold.executor
to use the new vthread executor. Let us know what you find.