4 ms·

Do you have any source on well written julia being any slower than well written C?

bigdict 4y ago
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- webshit2 4y ago
  It says right there: "Always look at the source code" fannkuch-redux, n-body, spectral-norm, reverse-complement: the fastest C wins by a large margin because it's an unreadable mess of vector intrinsics. If you really wanted to, you can do that in Julia too (and it might read better). Julia looks pretty even with C in the ones that were faithfully translated.
jakobnissen 4y ago
Don't be unreasonable. Numerical Julia code is just as fast, precisely because it's easy to design efficient high-level APIs and let the compiler optimise it. Try timing Julia's IO, or it's string processing, or it's hash tables, or its array allocation or it's GC - you know, nearly everything other that mathematical operations on floats or ints. Nearly everything leaves performance on the table. Sure Julia is fast, but not on a C level in these areas. There is still lots of room for optimisation, though.
- jkrubin 4y ago
  What’s your point?
  - anewhnaccount2 4y ago
    The point is that these things (string processing/hash tables) are typically done using custom/tuned code in C and so would be faster than the generic, and not particularly carefully tuned Julia implementations. However, given this library seems to be about passing NumPy arrays to/from Julia, the application is almost certainly to expose numerical stuff from Julia to Python. Basically, the use case is similar to Numba, but it works by producing a C-extension from a Julia system image (if I understand correctly). The main advantage over something like Numba would be access to the Julia ecosystem.
  - jakobnissen 4y ago
    The point is that when adgjlsfhk1 doubts that Julia is slower than C, he does so from a background where "data" is a synonym for arrays of numbers, and "computing" means processing these arrays. Julia shines here, precisely because the people developing Julia have a similar focus. In contrast, if your performance bottlenecks are IO, parsing and hash table operations, then Julia's performance will be in par with Python and get absolutely crushed by Rust (I have less experience with C, but would imagine Rust and C are about equally fast). The major difference with Python is that Julia's implementation of these things _could_ be fast in a way that Python's can't. They just aren't.
    - adgjlsfhk1 4y ago
      on par with python is way off. Julia in these areas definitely isn't fully optimized, but the performance will be much closer to something like Java for these cases. a dict in Julia will still have 1 pointer indirect compared to the python one where all your objects have 16 bytes overhead and an extra pointer indirection.
      - jakobnissen 4y ago
        Python's dicts are way more optimised and have an implementation closer to Dictionaries.jl. Anyway, I think it might be a good exercise for me to make a repo with a few test cases of where I think Julia could use some optimisations, and compare to Rust and Python.
    - ChrisRackauckas 4y ago
      Some of these are just safety-by-default things. For example, IO in Julia is thread-safe by default, which I think is a good idea because safety-first programming is good for say throwing `print` into a threaded loop written in the REPL. Here for example, https://github.com/aaronang/stl-benchmark/pull/3 https://github.com/aaronang/stl-benchmark/pull/3, was a case where Julia saw a performance hit from C++ and I was curious and tracked it down to this locking-by-default behavior. I'm not sure of a better way of handling it: the C/C++ behavior of not locking by default would make doing things correctly simply would be very hard to use (and is very hard in those languages). Though I agree parsers haven't gotten much love in Julia. That said, this repo is saying it's for implementing NumPy extensions, and I don't think NumPy has many parsers it's using.
cycomanic 4y ago
I did a comparison of Julia vs numpy, cython and pythran [1] some time ago, for a typical dsp routine we use in our work, and Julia was quite a bit slower than the alternatives. Now I'm by no means a Julia expert so I might have missed an optimisation opportunity (although I posted this and nobody could point to something obvious) , however the whole advertisement behind Julia is that one gets essentially C speed with the ease of Python. That's actually my main gripe with Julia, the community advertises it as something that it isn't. I think otherwise some really cool stuff is happening in Julia Land. [1] https://jochenschroeder.com/blog/articles/DSP_with_Python2/ https://jochenschroeder.com/blog/articles/DSP_with_Python2/
- meta2meta 4y ago
  You should run Julia code directly to benchmark instead of calling it in Python through pyjulia.
  - cycomanic 4y ago
    Actually I benchmarked inside Julia as well and didn't see a difference so left it like this.
- salty_biscuits 4y ago
  I only had a quick look, but I would guess the slicing is what makes it slower than you would expect. Julia copies on an array slice, but you can use the @view macro or do some loops with a preallocated array to make it faster.
  - cycomanic 4y ago
    Thanks I'll have a look and post and update sometime later.
- webshit2 4y ago
  wxy[:,:,k] += mu*conj(err[i,k])*X This should probably be wxy[:,:,k] .+= mu*conj(err[i,k]).*X so allocations are avoided. This doubled the speed for me, although I don't what size inputs are realistic. The @benchmark and @profile macros are good for this stuff.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

webshit2 4y ago
It says right there: "Always look at the source code" fannkuch-redux, n-body, spectral-norm, reverse-complement: the fastest C wins by a large margin because it's an unreadable mess of vector intrinsics. If you really wanted to, you can do that in Julia too (and it might read better). Julia looks pretty even with C in the ones that were faithfully translated.

jakobnissen 4y ago

Don't be unreasonable. Numerical Julia code is just as fast, precisely because it's easy to design efficient high-level APIs and let the compiler optimise it. Try timing Julia's IO, or it's string processing, or it's hash tables, or its array allocation or it's GC - you know, nearly everything other that mathematical operations on floats or ints. Nearly everything leaves performance on the table. Sure Julia is fast, but not on a C level in these areas. There is still lots of room for optimisation, though.

jkrubin 4y ago
What’s your point?
- anewhnaccount2 4y ago
  The point is that these things (string processing/hash tables) are typically done using custom/tuned code in C and so would be faster than the generic, and not particularly carefully tuned Julia implementations. However, given this library seems to be about passing NumPy arrays to/from Julia, the application is almost certainly to expose numerical stuff from Julia to Python. Basically, the use case is similar to Numba, but it works by producing a C-extension from a Julia system image (if I understand correctly). The main advantage over something like Numba would be access to the Julia ecosystem.
- jakobnissen 4y ago
  The point is that when adgjlsfhk1 doubts that Julia is slower than C, he does so from a background where "data" is a synonym for arrays of numbers, and "computing" means processing these arrays. Julia shines here, precisely because the people developing Julia have a similar focus. In contrast, if your performance bottlenecks are IO, parsing and hash table operations, then Julia's performance will be in par with Python and get absolutely crushed by Rust (I have less experience with C, but would imagine Rust and C are about equally fast). The major difference with Python is that Julia's implementation of these things _could_ be fast in a way that Python's can't. They just aren't.
  - adgjlsfhk1 4y ago
    on par with python is way off. Julia in these areas definitely isn't fully optimized, but the performance will be much closer to something like Java for these cases. a dict in Julia will still have 1 pointer indirect compared to the python one where all your objects have 16 bytes overhead and an extra pointer indirection.
    - jakobnissen 4y ago
      Python's dicts are way more optimised and have an implementation closer to Dictionaries.jl. Anyway, I think it might be a good exercise for me to make a repo with a few test cases of where I think Julia could use some optimisations, and compare to Rust and Python.
  - ChrisRackauckas 4y ago
    Some of these are just safety-by-default things. For example, IO in Julia is thread-safe by default, which I think is a good idea because safety-first programming is good for say throwing `print` into a threaded loop written in the REPL. Here for example, https://github.com/aaronang/stl-benchmark/pull/3 https://github.com/aaronang/stl-benchmark/pull/3, was a case where Julia saw a performance hit from C++ and I was curious and tracked it down to this locking-by-default behavior. I'm not sure of a better way of handling it: the C/C++ behavior of not locking by default would make doing things correctly simply would be very hard to use (and is very hard in those languages). Though I agree parsers haven't gotten much love in Julia. That said, this repo is saying it's for implementing NumPy extensions, and I don't think NumPy has many parsers it's using.

cycomanic 4y ago

I did a comparison of Julia vs numpy, cython and pythran [1] some time ago, for a typical dsp routine we use in our work, and Julia was quite a bit slower than the alternatives. Now I'm by no means a Julia expert so I might have missed an optimisation opportunity (although I posted this and nobody could point to something obvious) , however the whole advertisement behind Julia is that one gets essentially C speed with the ease of Python. That's actually my main gripe with Julia, the community advertises it as something that it isn't. I think otherwise some really cool stuff is happening in Julia Land. [1] https://jochenschroeder.com/blog/articles/DSP_with_Python2/ https://jochenschroeder.com/blog/articles/DSP_with_Python2/

meta2meta 4y ago
You should run Julia code directly to benchmark instead of calling it in Python through pyjulia.
- cycomanic 4y ago
  Actually I benchmarked inside Julia as well and didn't see a difference so left it like this.
salty_biscuits 4y ago
I only had a quick look, but I would guess the slicing is what makes it slower than you would expect. Julia copies on an array slice, but you can use the @view macro or do some loops with a preallocated array to make it faster.
- cycomanic 4y ago
  Thanks I'll have a look and post and update sometime later.
webshit2 4y ago
wxy[:,:,k] += mu*conj(err[i,k])*X This should probably be wxy[:,:,k] .+= mu*conj(err[i,k]).*X so allocations are avoided. This doubled the speed for me, although I don't what size inputs are realistic. The @benchmark and @profile macros are good for this stuff.