8 ms·

Have a citation on the performance vs Rust? I'm skeptical any GC'd language can approach C/Rust unless they have explicit mechanisms to do data layout for usin

Have a citation on the performance vs Rust? I'm skeptical any GC'd language can approach C/Rust unless they have explicit mechanisms to do data layout for using the cache/prefetcher to the fullest degree.

faitswulff 9y ago
Julia's website has some benchmarks: https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ C is the leftmost dot, Julia is just to the right.
- vvanders 9y ago
  According to that JavaScript is faster than both Julia and C by a significant margin in iter_mandelbrot ;).
  - 3JPLW 9y ago
    Yup, it's really amazing what millions of hours of development time will do! That benchmark in particular is a little deceiving — and we take those benchmarks very seriously! See this issue for more details: https://github.com/JuliaLang/julia/issues/24097 https://github.com/JuliaLang/julia/issues/24097
- pollitos 9y ago
  Just to note, these benchmarks are biased. This is a competition between highly-tuned-to-the-processor Julia with tuned BLAS vs other languages out-of-the-box binaries. Additionally, the benchmarks tests are written inefficiently in the comparison languages. But even then Javascript comes out on top on some benchmark tests.
  - dnautics 9y ago
    That's because the jit compiler in the Julia standard library selects the blas for you. As a programmer you don't have to optimize beyond using idiomatic type strategies. You could, say write a galois field type and use the \ solve operator to solve a Reed Solomon Erasure using old fashioned lu decomposition (automatically without pivoting, even), and then turn around and use the same \ operator with floats one line down and it will give you highly optimized blas.
  - ViralBShah 9y ago
    Only one of the benchmarks is BLAS dependent and the point is to make sure that it is easy to get a tuned BLAS in that system. If these benchmarks have resulted in all the languages focusing on a fast BLAS, I think that is fantastic.
  - 3JPLW 9y ago
    Yes, these benchmarks do tend to be a lightning-rod for controversy. You have two complaints: 1. Yes, some languages do not make it easy to install and link against a well-tuned BLAS. The benchmarks were very recently updated, and you can see the level of effort required to get everything installed and working properly. This was all done in the open on the discourse message board. 2. Yes, the benchmarks involve testing very specific language-level features like iteration, recursion, and IO. And they're testing the ability of specific languages to do these things. Yes, of course in Python you'd look towards a vectorized library call instead of a `for` loop, but then you're not testing Python itself anymore.
    - bjourne 9y ago
      How come there are no entries for Julia on the Benchmarks Game? http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/ Given Julia's good performance, it is a little strange. :)
      - ihnorton 9y ago
        Inclusion is by selection of the admin [1,2]. There are Julia implementations available for most of the benchmarks [3] so perhaps eventually they will be included. [1] https://alioth.debian.org/forum/message.php?msg_id=182495&group_id=100815 https://alioth.debian.org/forum/message.php?msg_id=182495&gr... [2] http://benchmarksgame.alioth.debian.org/play.html#languagex http://benchmarksgame.alioth.debian.org/play.html#languagex [3] https://github.com/JuliaLang/julia/tree/master/test/perf/shootout https://github.com/JuliaLang/julia/tree/master/test/perf/sho...
        bjourne 9y ago
        Interesting! Does that mean the Benchmarks Game is not open for new languages? The faq entry is kind of ambiguous.
        igouy 9y ago
        It means -- "If you're interested in something not shown on the benchmarks game website then please take the program source code and the measurement scripts and publish your own measurements." Like this guy did -- https://pybenchmarks.org/ https://pybenchmarks.org/
ViralBShah 9y ago
The point around Julia's performance is often in the context of mathematical computing. The two languages are designed for very different use cases. Julia is designed to make it extremely easy to write high performance mathematical programs with ease. Rust is designed to make it easy to do systems programming. Both are high performance for the things they are designed to do. Just like I wouldn't do systems programming in Julia (although I am certain KenoFischer would), I wouldn't want to do mathematical computing in Rust.
- vvanders 9y ago
  Sure but mathematical problems don't exist in isolation. I used to do a ton of 3D graphics work with matrices, vectors, etc. We definitely couldn't use something that didn't have the right support for data layout and good runtime semantics. C/Rust/C++ fit that very well so I wanted to understand how similar claims were made for a GC'd language. C# for instance can work with value types and was wondering is Julia has similar constructs.
  - ballenarosada 9y ago
    Value types are also addressed in the article
    - vvanders 9y ago
      From what I can find[1] it looks like while Julia has compact values it doesn't have what I'd traditionally call value types. Specifically value types that live on the stack unless they are a member of a reference type(which is what C# does). Looking at the performance docs[2] this is pretty clear in that array types(which looks like how Julia does Matrices) get allocated on the heap. You can clearly see the performance impact in the docs(1.95s vs 0.08s) that this type of behavior has. While you can preallocate(which the docs suggest and is the only path for GC'd languages) it's not an ideal solution. If your type is smaller than a single cache line, like in the example above, you've just flushed a whole cache line just to bring in that one pre-allocated value. You also run into the issue if you don't know exactly how many values you need upfront which leads to pooling. In that scenario your pool may be large enough that you're bouncing between cache lines on different pooled objects. This is the type of thing that you really need control over if you want performance "as good as C". Anything less will be a compromise. There's also the whole class of zero-cost abstractions that can get from C++/Rust which leverage all the above to great effect. That lets you get things like nom[3] which gives you high level semantics + productivity while maintaining parity with C. None of this is academic, these are all optimizations I've used on shipping products that went out to millions of users. In each case we had fixed hardware with a limited execution budget and the 5-20x improvements we made were critical to us shipping a product that people wanted to use. [1] https://discourse.julialang.org/t/how-to-know-if-object-memory-resides-on-stack-or-heap/4927 https://discourse.julialang.org/t/how-to-know-if-object-memo... [2] https://docs.julialang.org/en/release-0.4/manual/performance-tips/#pre-allocating-outputs https://docs.julialang.org/en/release-0.4/manual/performance... [3] https://github.com/Geal/nom_benchmarks/tree/master/http https://github.com/Geal/nom_benchmarks/tree/master/http / https://github.com/Geal/nom https://github.com/Geal/nom
jernfrost 9y ago
The language page shows micro benchmarks that Julia is comparable to C in performance, when optimized. I've seen various users of the language report similar experience for packages they've built. Since C and Rust are similar in performance I would assume Julia is close to Rust in performance. You can also easily verify this yourself by looking at assembly code dumps for JITed Julia functions. You can see that the amount of code would be comparable to that of C for many common scenarios. As for cache and data layout. That GC'd language can't control data layout and cache usage is simply wrong. Best known example is probably Go. You can nest structs to create contiguous blocks of memory in Go, just like in C. You can also create arrays of structs as contiguous blocks of memory. Just because Java and C# doesn't work that way, doesn't mean all GC'd languages are like that. A struct of concrete types in Julia is just like a struct in C in the way it is packed in memory. An array of structs in Julia or a nesting of structs will have similar memory layout as in C. So I know this sounds really odd, but Julia despite being a dynamic language thus allows more optimal memory layout than a statically typed languages such as Java. What is frustrating with promoting Julia, is that it simply sounds way too good to be true, so people dismiss the language before they have actually read up on it. I advice you to read up a bit more on the details of how the language works. It will then become clear why it can pull off stuff which seems far too good to be true.

faitswulff 9y ago

Julia's website has some benchmarks: https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ C is the leftmost dot, Julia is just to the right.

vvanders 9y ago
According to that JavaScript is faster than both Julia and C by a significant margin in iter_mandelbrot ;).
- 3JPLW 9y ago
  Yup, it's really amazing what millions of hours of development time will do! That benchmark in particular is a little deceiving — and we take those benchmarks very seriously! See this issue for more details: https://github.com/JuliaLang/julia/issues/24097 https://github.com/JuliaLang/julia/issues/24097
pollitos 9y ago
Just to note, these benchmarks are biased. This is a competition between highly-tuned-to-the-processor Julia with tuned BLAS vs other languages out-of-the-box binaries. Additionally, the benchmarks tests are written inefficiently in the comparison languages. But even then Javascript comes out on top on some benchmark tests.
- dnautics 9y ago
  That's because the jit compiler in the Julia standard library selects the blas for you. As a programmer you don't have to optimize beyond using idiomatic type strategies. You could, say write a galois field type and use the \ solve operator to solve a Reed Solomon Erasure using old fashioned lu decomposition (automatically without pivoting, even), and then turn around and use the same \ operator with floats one line down and it will give you highly optimized blas.
- ViralBShah 9y ago
  Only one of the benchmarks is BLAS dependent and the point is to make sure that it is easy to get a tuned BLAS in that system. If these benchmarks have resulted in all the languages focusing on a fast BLAS, I think that is fantastic.
- 3JPLW 9y ago
  Yes, these benchmarks do tend to be a lightning-rod for controversy. You have two complaints: 1. Yes, some languages do not make it easy to install and link against a well-tuned BLAS. The benchmarks were very recently updated, and you can see the level of effort required to get everything installed and working properly. This was all done in the open on the discourse message board. 2. Yes, the benchmarks involve testing very specific language-level features like iteration, recursion, and IO. And they're testing the ability of specific languages to do these things. Yes, of course in Python you'd look towards a vectorized library call instead of a `for` loop, but then you're not testing Python itself anymore.
  - bjourne 9y ago
    How come there are no entries for Julia on the Benchmarks Game? http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/ Given Julia's good performance, it is a little strange. :)
    - ihnorton 9y ago
      Inclusion is by selection of the admin [1,2]. There are Julia implementations available for most of the benchmarks [3] so perhaps eventually they will be included. [1] https://alioth.debian.org/forum/message.php?msg_id=182495&group_id=100815 https://alioth.debian.org/forum/message.php?msg_id=182495&gr... [2] http://benchmarksgame.alioth.debian.org/play.html#languagex http://benchmarksgame.alioth.debian.org/play.html#languagex [3] https://github.com/JuliaLang/julia/tree/master/test/perf/shootout https://github.com/JuliaLang/julia/tree/master/test/perf/sho...
      - bjourne 9y ago
        Interesting! Does that mean the Benchmarks Game is not open for new languages? The faq entry is kind of ambiguous.
        igouy 9y ago
        It means -- "If you're interested in something not shown on the benchmarks game website then please take the program source code and the measurement scripts and publish your own measurements." Like this guy did -- https://pybenchmarks.org/ https://pybenchmarks.org/

ViralBShah 9y ago

The point around Julia's performance is often in the context of mathematical computing. The two languages are designed for very different use cases. Julia is designed to make it extremely easy to write high performance mathematical programs with ease. Rust is designed to make it easy to do systems programming. Both are high performance for the things they are designed to do. Just like I wouldn't do systems programming in Julia (although I am certain KenoFischer would), I wouldn't want to do mathematical computing in Rust.

vvanders 9y ago
Sure but mathematical problems don't exist in isolation. I used to do a ton of 3D graphics work with matrices, vectors, etc. We definitely couldn't use something that didn't have the right support for data layout and good runtime semantics. C/Rust/C++ fit that very well so I wanted to understand how similar claims were made for a GC'd language. C# for instance can work with value types and was wondering is Julia has similar constructs.
- ballenarosada 9y ago
  Value types are also addressed in the article
  - vvanders 9y ago
    From what I can find[1] it looks like while Julia has compact values it doesn't have what I'd traditionally call value types. Specifically value types that live on the stack unless they are a member of a reference type(which is what C# does). Looking at the performance docs[2] this is pretty clear in that array types(which looks like how Julia does Matrices) get allocated on the heap. You can clearly see the performance impact in the docs(1.95s vs 0.08s) that this type of behavior has. While you can preallocate(which the docs suggest and is the only path for GC'd languages) it's not an ideal solution. If your type is smaller than a single cache line, like in the example above, you've just flushed a whole cache line just to bring in that one pre-allocated value. You also run into the issue if you don't know exactly how many values you need upfront which leads to pooling. In that scenario your pool may be large enough that you're bouncing between cache lines on different pooled objects. This is the type of thing that you really need control over if you want performance "as good as C". Anything less will be a compromise. There's also the whole class of zero-cost abstractions that can get from C++/Rust which leverage all the above to great effect. That lets you get things like nom[3] which gives you high level semantics + productivity while maintaining parity with C. None of this is academic, these are all optimizations I've used on shipping products that went out to millions of users. In each case we had fixed hardware with a limited execution budget and the 5-20x improvements we made were critical to us shipping a product that people wanted to use. [1] https://discourse.julialang.org/t/how-to-know-if-object-memory-resides-on-stack-or-heap/4927 https://discourse.julialang.org/t/how-to-know-if-object-memo... [2] https://docs.julialang.org/en/release-0.4/manual/performance-tips/#pre-allocating-outputs https://docs.julialang.org/en/release-0.4/manual/performance... [3] https://github.com/Geal/nom_benchmarks/tree/master/http https://github.com/Geal/nom_benchmarks/tree/master/http / https://github.com/Geal/nom https://github.com/Geal/nom

jernfrost 9y ago

The language page shows micro benchmarks that Julia is comparable to C in performance, when optimized. I've seen various users of the language report similar experience for packages they've built. Since C and Rust are similar in performance I would assume Julia is close to Rust in performance. You can also easily verify this yourself by looking at assembly code dumps for JITed Julia functions. You can see that the amount of code would be comparable to that of C for many common scenarios. As for cache and data layout. That GC'd language can't control data layout and cache usage is simply wrong. Best known example is probably Go. You can nest structs to create contiguous blocks of memory in Go, just like in C. You can also create arrays of structs as contiguous blocks of memory. Just because Java and C# doesn't work that way, doesn't mean all GC'd languages are like that. A struct of concrete types in Julia is just like a struct in C in the way it is packed in memory. An array of structs in Julia or a nesting of structs will have similar memory layout as in C. So I know this sounds really odd, but Julia despite being a dynamic language thus allows more optimal memory layout than a statically typed languages such as Java. What is frustrating with promoting Julia, is that it simply sounds way too good to be true, so people dismiss the language before they have actually read up on it. I advice you to read up a bit more on the details of how the language works. It will then become clear why it can pull off stuff which seems far too good to be true.