4 ms·

Note that the compile times of julia are not included in the benchmarks. If you read the website, you'd seen that the grapsh show the first (excluding the compi

Note that the compile times of julia are not included in the benchmarks. If you read the website, you'd seen that the grapsh show the first (excluding the compilation) and the second run (with hot cache). Also in the second run, julia is not the fastest. Julia would not be faster than Rust, its got a garbage collector. This is what you see in the join benchmarks that really push the allocator. Next to that, the databases run in in-memory mode, so there is not disk overhead. Spark is slower because JVM + row-wise data.

rscho 5y ago
> Julia would not be faster than Rust, its got a garbage collector. Having a garbage collector does not intrinsically make things slower. Especially so outside of the benchmarking microcosm.
- adgjlsfhk1 5y ago
  that said, Julia currently has a slow GC so it does hurt. GC performance is being worked on though. I have high hopes for a year or 2.
sdfgsdf 5y ago
> Note that the compile times of julia are not included in the benchmarks. If you read the website, you'd seen that the grapsh show the first (excluding the compilation) and the second run (with hot cache). Here's my view: The author of that page has commented here on HN; If my claim was so outrageously wrong as you claim, he would've corrected it.
- fault1 5y ago
  yeah, but your claim was "Note also that Julia would be number 1 in almost all of those benchmarks if you were to rank by speed of second run" notice this isn't even a language vs language benchmark. it's libraries and frameworks. plus I don't think even the author of the julia library in question would agree with your statement: https://discourse.julialang.org/t/the-state-of-dataframes-jl-h2o-benchmark/43081 https://discourse.julialang.org/t/the-state-of-dataframes-jl... as mentioned in that thread, GC and strings, or especially a combination of the two, can be very much a downer in terms of julia performance. That's actually pretty surprising since strings are often as important if not more important than numbers for a lot of data processing needs. I'd also say in terms of compilation time, some autocaching layer outside of precompilation would do wonders.

rscho 5y ago

> Julia would not be faster than Rust, its got a garbage collector. Having a garbage collector does not intrinsically make things slower. Especially so outside of the benchmarking microcosm.

adgjlsfhk1 5y ago
that said, Julia currently has a slow GC so it does hurt. GC performance is being worked on though. I have high hopes for a year or 2.

sdfgsdf 5y ago

> Note that the compile times of julia are not included in the benchmarks. If you read the website, you'd seen that the grapsh show the first (excluding the compilation) and the second run (with hot cache). Here's my view: The author of that page has commented here on HN; If my claim was so outrageously wrong as you claim, he would've corrected it.

fault1 5y ago
yeah, but your claim was "Note also that Julia would be number 1 in almost all of those benchmarks if you were to rank by speed of second run" notice this isn't even a language vs language benchmark. it's libraries and frameworks. plus I don't think even the author of the julia library in question would agree with your statement: https://discourse.julialang.org/t/the-state-of-dataframes-jl-h2o-benchmark/43081 https://discourse.julialang.org/t/the-state-of-dataframes-jl... as mentioned in that thread, GC and strings, or especially a combination of the two, can be very much a downer in terms of julia performance. That's actually pretty surprising since strings are often as important if not more important than numbers for a lot of data processing needs. I'd also say in terms of compilation time, some autocaching layer outside of precompilation would do wonders.