4 ms·

Numeric code doesn't just mean matrix multiplication. If I have a random nested for loop, it will probably run at least as fast as those languages(apart from ma

Numeric code doesn't just mean matrix multiplication. If I have a random nested for loop, it will probably run at least as fast as those languages(apart from maybe Nim, never used it) if annotated with @simd and @inbounds. If I'm operating on a small array/matrix, then Julia will blow Go/Rust out of the water via stack-allocated static arrays (https://github.com/JuliaArrays/StaticArrays.jl https://github.com/JuliaArrays/StaticArrays.jl). These can't be implemented in Go because it doesn't support type parameters, let alone integer type parameters, and is only recently supported in Rust via const generics, which as far as I'm aware haven't stabilised yet.

komuher 7y ago
Ok let me get it here cause there are a lot of misunderstanding my post on top. Swift have built in simd same about Rust https://github.com/apple/swift-evolution/blob/master/proposals/0229-simd.md https://github.com/apple/swift-evolution/blob/master/proposa... Nim have arraymancer https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer @inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. But True about GO in that particular case.
- logicchains 7y ago
  >@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. I agree it wouldn't necessarily be faster, but it also wouldn't be slower. Plus in Rust at least disabling bounds checks requires marking code as unsafe, which really gets the community's hackles up.
  - steveklabnik 7y ago
    It only requires unsafe if the compiler can’t figure out that removing them is okay. Often bounds checks are not emitted, even in safe code.
eigenspace 7y ago
Actaully, julia for loops can be made to perform at BLAS levels with this package: https://github.com/chriselrod/LoopVectorization.jl https://github.com/chriselrod/LoopVectorization.jl. Here are my early experiments at making a pure-julia multi-threaded BLAS using LoopVectorization.jl https://github.com/MasonProtter/Gaius.jl https://github.com/MasonProtter/Gaius.jl. It absolutely blows a naive triple for loop out of the water and is quite competitive against OpenBLAS until you get to very big sizes.
- celrod 7y ago
  For small, statically sized arrays, LoopVectorization + tripple loops is also much faster than MArrays. LoopVectorization doesn't support SArrays yet, because you can't get pointers to them. MArrays will be stack allocated if they don't escape. One of my in development packages also uses it's own "stack" (MMap a chunk of memory), so that it can have pointers to fast "stack-alocated" arrays. I played around with LLVM's alloca a bit, but it seems like I could only ever use a single alloca at a time; if I ever used more than one, LLVM would just return the same pointer each time instead of incrementing it. If I have to manage incrementing the pointers myself anyway, I may as well use my own stack, too. For (the problems I have tested and tuned it on), LoopVectorization produces faster code than C/Fortran, e.g.: https://chriselrod.github.io/LoopVectorization.jl/latest/examples/filtering/ https://chriselrod.github.io/LoopVectorization.jl/latest/exa... But it may be more fair to compare it with plutocc. In my early tests (which involved much larger problem sizes), plutocc does a lot better, because (unlike LoopVectorization) it seems to consider memory/caches rather than just registers allocation and instruction costs.

komuher 7y ago

Ok let me get it here cause there are a lot of misunderstanding my post on top. Swift have built in simd same about Rust https://github.com/apple/swift-evolution/blob/master/proposals/0229-simd.md https://github.com/apple/swift-evolution/blob/master/proposa... Nim have arraymancer https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer @inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. But True about GO in that particular case.

logicchains 7y ago
>@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. I agree it wouldn't necessarily be faster, but it also wouldn't be slower. Plus in Rust at least disabling bounds checks requires marking code as unsafe, which really gets the community's hackles up.
- steveklabnik 7y ago
  It only requires unsafe if the compiler can’t figure out that removing them is okay. Often bounds checks are not emitted, even in safe code.

eigenspace 7y ago

Actaully, julia for loops can be made to perform at BLAS levels with this package: https://github.com/chriselrod/LoopVectorization.jl https://github.com/chriselrod/LoopVectorization.jl. Here are my early experiments at making a pure-julia multi-threaded BLAS using LoopVectorization.jl https://github.com/MasonProtter/Gaius.jl https://github.com/MasonProtter/Gaius.jl. It absolutely blows a naive triple for loop out of the water and is quite competitive against OpenBLAS until you get to very big sizes.

celrod 7y ago
For small, statically sized arrays, LoopVectorization + tripple loops is also much faster than MArrays. LoopVectorization doesn't support SArrays yet, because you can't get pointers to them. MArrays will be stack allocated if they don't escape. One of my in development packages also uses it's own "stack" (MMap a chunk of memory), so that it can have pointers to fast "stack-alocated" arrays. I played around with LLVM's alloca a bit, but it seems like I could only ever use a single alloca at a time; if I ever used more than one, LLVM would just return the same pointer each time instead of incrementing it. If I have to manage incrementing the pointers myself anyway, I may as well use my own stack, too. For (the problems I have tested and tuned it on), LoopVectorization produces faster code than C/Fortran, e.g.: https://chriselrod.github.io/LoopVectorization.jl/latest/examples/filtering/ https://chriselrod.github.io/LoopVectorization.jl/latest/exa... But it may be more fair to compare it with plutocc. In my early tests (which involved much larger problem sizes), plutocc does a lot better, because (unlike LoopVectorization) it seems to consider memory/caches rather than just registers allocation and instruction costs.