It’s wild to me that this is said almost between the lines. In this particular benchmark, it obviously didn’t help, but for many workloads that’s going to make a massive difference or even leave Clojure as the only viable choice.
Indeed, and it’s also worth noting that doing parallelism in Clojure is inherently easier than in an imperative language since data is immutable by default. If you’re using Python or Ruby then you have to consider parallelism up front in your design, meanwhile with Clojure you can just swap map with pmap.
Ah, interesting. I’m currently in the Rust rabbit hole, which takes a very different path towards race condition safety (it’s imperative and the compiler separately checks that you’re not using mutability in parallel contexts), but you actually get quite a similar feature, in that you can swap .iter().map() with .par_iter().map() (via a library).
Yeah, borrow checking approach in Rust is pretty neat since it lets the compiler track exactly where a data structure is being mutated at compile time. Rust approach is more efficient overall as well, but structural sharing has its own benefits as well since you get stuff like history for free. XTDB is a neat project that leverages this property for a temporal db.
I’m not sure what the author meant by this. Python does support parallelism via multiprocessing (and in experimental versions, via threads in no-GIL builds), e.g. like this. It’s a bit questionable whether it’d help in this particular benchmark, because the overhead of sending the inputs between workers may be comparable to the speedup, but it’s certainly possible, and very common in real tasks.
(I’m not familiar with Ruby, but from some googling it seems the situation is about the same as Python, but there’s not a stdlib implementation and instead you need to use something third-party like the parallel gem.)
The author is referring to the GIL, I’m pretty sure. Both Python and Ruby have it. I guess, they should’ve written “only Clojure supports true multithreading”, but that you’re able to spawn multiple processes is kind of a given (and has quite some disadvantages for certain workloads).
That Python has experimental no-GIL builds is good, but I wouldn’t seriously consider using that until they’ve had it in a stable release and thrown some bug fixes onto it. Well, and even then, there might not be much point in trying to use it, until libraries have adopted it…
It’s wild to me that this is said almost between the lines. In this particular benchmark, it obviously didn’t help, but for many workloads that’s going to make a massive difference or even leave Clojure as the only viable choice.
Indeed, and it’s also worth noting that doing parallelism in Clojure is inherently easier than in an imperative language since data is immutable by default. If you’re using Python or Ruby then you have to consider parallelism up front in your design, meanwhile with Clojure you can just swap
mapwithpmap.Ah, interesting. I’m currently in the Rust rabbit hole, which takes a very different path towards race condition safety (it’s imperative and the compiler separately checks that you’re not using mutability in parallel contexts), but you actually get quite a similar feature, in that you can swap
.iter().map()with.par_iter().map()(via a library).Yeah, borrow checking approach in Rust is pretty neat since it lets the compiler track exactly where a data structure is being mutated at compile time. Rust approach is more efficient overall as well, but structural sharing has its own benefits as well since you get stuff like history for free. XTDB is a neat project that leverages this property for a temporal db.
I’m not sure what the author meant by this. Python does support parallelism via multiprocessing (and in experimental versions, via threads in no-GIL builds), e.g. like this. It’s a bit questionable whether it’d help in this particular benchmark, because the overhead of sending the inputs between workers may be comparable to the speedup, but it’s certainly possible, and very common in real tasks.
(I’m not familiar with Ruby, but from some googling it seems the situation is about the same as Python, but there’s not a stdlib implementation and instead you need to use something third-party like the
parallelgem.)The author is referring to the GIL, I’m pretty sure. Both Python and Ruby have it. I guess, they should’ve written “only Clojure supports true multithreading”, but that you’re able to spawn multiple processes is kind of a given (and has quite some disadvantages for certain workloads).
That Python has experimental no-GIL builds is good, but I wouldn’t seriously consider using that until they’ve had it in a stable release and thrown some bug fixes onto it. Well, and even then, there might not be much point in trying to use it, until libraries have adopted it…