The JVM supports hot code loading, although this article seems to imply only BEAM supports it.
Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
11–20 of 114 posts
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#12> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…
It's fine if you know what you're doing and are the primary maintainer. As someone who's encountered code maintained over a long period of time with lots of people coming and going, concurrency using locks is quite ugly, especially as people cargo cult "better performing" solutions that aren't actually & just add complexity/race conditions. My experience is primarily C/C++ but this is all agnostic to the language.
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#13Can someone steer me to some good benchmarks, discussions of perf characteristics and gotchas of the BEAM? My search-fu is weak and I'm not finding the sort of content I'm after. I'm trying to learn Elixir and being a systems thinker so before I (can) get too comfortable I'm gonna want to dive into origin stories to build up my holistic map of why things are the way they are, what can be done and what can't be done,…
In general I would say there's no good single book or resource that describes everything comprehensively. There's a lot of resources, though, but mostly scattered in various places. The BEAM Book [1] is a good, though unfinished resource talking in general about the implementation - the memory model and the interpreter. If you're interested in some very low-level details of the runtime, the internal documentation [2]…
I want to know the constraints to, and evolution of, sequential computation on the BEAM. I want to form opinions on how that landscape is likely to change within the lifespan of a project I'm affiliated with.
I get mostly false positives trying to find those sorts of discussions or metrics.
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#14> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…
It's fine if you know what you're doing and are the primary maintainer. As someone who's encountered code maintained over a long period of time with lots of people coming and going, concurrency using locks is quite ugly, especially as people cargo cult "better performing" solutions that aren't actually & just add complexity/race conditions. My experience is primarily C/C++ but this is all agnostic to the language.
[deleted]
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#15The JVM supports hot code loading, although this article seems to imply only BEAM supports it.
Do you have a reference on that?
I want to make sure you're talking about the same thing.
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#16> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…
"Concurrency primitives" here is probably referring to Java's fundamental mutex system as used with `synchronized`, `wait()`, and `notify()`. Java's thread pools and concurrent data structures are built on top of these and as you noted are relatively straightforward to use correctly, as they take care of the actual coordination of threads for you.
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#17BEAM is amazing and IMHO there's one very sweet spot ready for optimization: math functions. I know I can escape out to C/Rust/etc. yet the majority of what I do is simple float math such as stddev and vector normalization. The article states benchmark of 5000% speedup on floats when switching from BEAM to the JVM. I would like to offer $100 as a gift incentive to anyone here who wants to work on optimizing BEAM math…
People say this isn't what BEAM is intended for an it excels elsewhere, which yes I'm sure it does. But why can't it be both? Why can't you do everything that BEAM does... and then also have an optimising JIT for the straight line maths code? Couldn't you leave all the other parts of the system the same and keep all the existing benefits? Improving one doesn't damage the other does it?
I think this is what akka and quasar gives you. There might be some other trade offs at play though I can't say.
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#18The JVM supports hot code loading, although this article seems to imply only BEAM supports it.
Do you have a reference on that? I want to make sure you're talking about the same thing.
Clojure does hot code reloading as a built in. You essentially send code to a running system and you change it. It’s enabled by a dynamic class loader. I wouldn’t say it’s common outside of Clojure though, the whole language and ecosystem is built around this concept.
To be clear: JVM enables the feature, so “technically” JVM allows hot code reload. Not sure how useful this is in practice for non-Clojure JVM users.
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#19The JVM supports hot code loading, although this article seems to imply only BEAM supports it.
Do you have a reference on that? I want to make sure you're talking about the same thing.
ClassLoader [1] in the small, and OSGi [2] in the large, are good starting points for comparison.
[1] https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoa...
Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines
#20The JVM supports hot code loading, although this article seems to imply only BEAM supports it.
Do you have a reference on that? I want to make sure you're talking about the same thing.