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

Julia 1.6 Highlights

julialang.org

Post reply on HN
Print view View original

31–40 of 224 posts

Re: Julia 1.6 Highlights

#31

Post by paul_milovanov »

fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

looks like they're just multiplying two 100x100 matrices, once? (maybe I'm reading it wrong?) in Julia, runtime would be dominated by compilation + startup time.

A fair comparison with C++ would be to at least include the compilation/linking time into the time reported.

Ditto for Java or any JVM language (you'd have JVM startup cost but that doesn't count the compilation time for bytecode).

Generally, for stuff (scientific computing benchmarks) like this you want to run a lot of computation precisely to avoid stuff like this (i.e you want to fairly allow the cost of compilation & startup amortize)

Re: Julia 1.6 Highlights

#32

Post by machineko »

paul_milovanov wrote: post #31
fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

looks like they're just multiplying two 100x100 matrices, once? (maybe I'm reading it wrong?) in Julia, runtime would be dominated by compilation + startup time. A fair comparison with C++ would be to at least include the compilation/linking time into the time reported. Ditto for Java or any JVM language (you'd have JVM startup cost but that doesn't count the compilation time for bytecode). Generally, for stuff (scie…

If u just look on the main page u would see they are excluding jitting time (using warm start to measure jitted languages) Dunno why this people cant just read few lines of comments in github page before posting :D

Re: Julia 1.6 Highlights

#34

Post by stabbles »

adgjlsfhk1 wrote: post #26
fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

They are measuring compile time, not runtime speed.

They are measuring compile time and runtime speed, not just runtime speed like for statically compiled langauges

Re: Julia 1.6 Highlights

#35

Post by f6v »

psychometry wrote: post #13
f6v wrote: post #9

Is there a per-project way to manage dependencies yet? I find global package installation to be the biggest weakness of all the R projects out there. Anaconda can help, but it’s not widely used for R projects. And Docker... well, don’t get me started.

renv is how R projects do per-package dependency management. Before renv there was packrat. This has been a solved problem for years now...

Doesn’t mean it’s adopted though.

Re: Julia 1.6 Highlights

#36

Post by machineko »

fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

I think i can answer that, first of all Julia isnt as fast as C/C++/Nim etc. in most cases Julia is just fast in scientific computing that's all. (there is only one "scientific" benchmark on kostya benchmarks)

Second to write very fast julia u need to knew a lot of "tricks" and in most cases u won't be doing it as easy as writing normal code.

And all people writing this benchmark is measuring compilation time (XD?) or not including jitting time they could just look at code/readme for 5s before commenting.

Julia is fast and can be as fast as C but not in all cases and not as easy at it seems.

Re: Julia 1.6 Highlights

#37

Post by triztian »

noisy_boy wrote: post #23

How easy it is to produce a compiled executable in 1.6? I took a cursory look at the docs but couldn't spot the steps for doing so.

I’ve also looked for this, does it mean that I have to install julia on the target machine and it’ll recompile when running?

Or are there steps to produce a binary (much like Go or C or Rust)??

Re: Julia 1.6 Highlights

#38

Post by stabbles »

fermienrico wrote: post #22

Are the performance claims of Julia greatly exaggerated? Julia loses almost consistently to Go, Crystal, Nim, Rust, Kotlin, Python (PyPy, Numpy): https://github.com/kostya/benchmarks Is this because of bad typing or they didn't use Julia properly in idiomatic manner?

I think it's more interesting to see what people do with the language instead of focusing on microbenchmarks. There's for instance this great package https://github.com/JuliaSIMD/LoopVectorization.jl which exports a simple macro `@avx` which you can stick to loops to vectorize them in ways better than the compiler (=LLVM). It's quite remarkable you can implement this in the language as a package as opposed to having LLVM improve or the julia compiler team figure this out.

See the docs which kinda read like blog posts: https://juliasimd.github.io/LoopVectorization.jl/stable/

And then replacing the matmul.jl with the following:

    @avx for i = 1:m, j = 1:p
        z = 0.0
        for k = 1:n
            z += a[i, k] * b[k, j]
        end
        out[i, j] = z
    end
I get a 4x speedup from 2.72s to 0.63s. And with @avxt (threaded) using 8 threads it goes town to 0.082s on my amd ryzen cpu. (So this is not dispatching to MKL/OpenBLAS/etc). Doing the same in native Python takes 403.781s on this system -- haven't tried the others.

Re: Julia 1.6 Highlights

#40

Post by oxinabox »

adgjlsfhk1 wrote: post #11
f6v wrote: post #9

Is there a per-project way to manage dependencies yet? I find global package installation to be the biggest weakness of all the R projects out there. Anaconda can help, but it’s not widely used for R projects. And Docker... well, don’t get me started.

Yeah. Julia's had that since (at least) 1.0. Environments are built-in, and you specify project dependencies in a Projects.toml file https://pkgdocs.julialang.org/v1/toml-files/ .

Since 0.7 (which was 1.0 with deprecations) In julia 0.6 and before it was exactly as bad as described. (though there were things like Playground.jl to kind of work around it)
Post reply on HN