6 ms·

Version 1.5 is an awesome release with some really nice stuff. That said, I can't help but feel frustrated by all the attention and effort being poured into com

Version 1.5 is an awesome release with some really nice stuff. That said, I can't help but feel frustrated by all the attention and effort being poured into compiler latency. I get that some people value it very highly, but to me it just seems silly to put so much effort towards this big group of whiners who find it unacceptable to wait __ seconds for the compiler to run before their first plot is produced (especially when PackageCompiler.jl exists!). To me, the important thing about julia is runtime performance. I'd gladly pay hefty compile times to have even minuscule runtime improvements. To be clear, I'm not saying the Julia devs have been ignoring runtime performance, far from it, but I just sometimes feel the need to chime in like this because I often feel the compiler latency complainers are disproportionately squeaky wheels, so I'd hate to see that cause the devs to over-correct.

celrod 6y ago
I don't really want to sacrifice runtime performance for compile time performance, so long as the compilation time is "reasonable", but so far we've mostly been having our cake and eating it too. The eliminating-invalidations work for Julia 1.6 is a great example of that. When it comes to explicit trade-offs, like setting the optimization level, they've given us finer control by letting us specify it at the module level. Now Plots.jl can favor compile time, while I'll numerical libraries can favor runtime.
- eigenspace 6y ago
  Right, so what I'd say is that while latency improvements and runtime improvements to julia aren't necessarily in conflict, the core developer's time is a zero sum competition between these things (among others). I'm just saying that for selfish reasons, I'd rather they spent their time on runtime and infrastructure improvements than reducing compile times. And of course, I say this while acknowledging that I am in no position to demand how they spend their time.
ChrisRackauckas 6y ago
Sometimes aspects that help the community are a better long term investment, and I think that most people would point to compile times as the key thing to nail down in order to grow the community at a faster rate.
deleted 6y ago
[deleted]
tastyminerals2 6y ago
But the runtime performance is not that great either. Dot product: NumPy 0.03528 vs 0.03 Julia (x1/1.1) Element-wise sum: NumPy 0.00379 vs 0.0063 Julia (x1.6) Element-wise mul: NumPy 0.00419 vs 0.00617 Julia (x1.5) L2 norm: NumPy 0.02391 vs 0.097 Julia (x4.1) Matrix product: NumPy 0.00186 vs 0.01988 Julia (x10.7) Matrix sort: NumPy 0.01033 vs 0.0161 Julia (x1.6)
- tgv 6y ago
  Numpy is written in C. What are Julia’s functions written in?
  - tastyminerals2 6y ago
    Julia was written in C++ in early stages if I remember correctly then Julia ;) The point here is that NumPy is heavily fine-tuned and will beat almost any other language implementation out there. The community is bigger and therefore there are much more free hands.
    - pdeffebach 6y ago
      In Julia's case, there are maybe more "free hands" who can contribute to performance critical code. To contribute to `NumPy` you have to know how to program in C.
    - johnmyleswhite 6y ago
      One of the important facts about OSS development is that the number of users doesn't scale linearly with the number of "free hands. There are less than 2 FTE's working on Python at any given time these days.
- kristofferc 6y ago
  Aren't many of those benchmarks mostly comparing MKL vs OpenBLAS (the default BLAS library used)? Also, it's unlikely that Julia will handily beat the handwritten, carefully optimized C-code in numpy. At that level, it isn't very much about the language but more about the programmers implementing the algorithms. A major selling point of Julia is that you will have fast code even in cases where the code doesn't neatly factor into calling static kernels written in e.g. C.

celrod 6y ago

I don't really want to sacrifice runtime performance for compile time performance, so long as the compilation time is "reasonable", but so far we've mostly been having our cake and eating it too. The eliminating-invalidations work for Julia 1.6 is a great example of that. When it comes to explicit trade-offs, like setting the optimization level, they've given us finer control by letting us specify it at the module level. Now Plots.jl can favor compile time, while I'll numerical libraries can favor runtime.

eigenspace 6y ago
Right, so what I'd say is that while latency improvements and runtime improvements to julia aren't necessarily in conflict, the core developer's time is a zero sum competition between these things (among others). I'm just saying that for selfish reasons, I'd rather they spent their time on runtime and infrastructure improvements than reducing compile times. And of course, I say this while acknowledging that I am in no position to demand how they spend their time.

ChrisRackauckas 6y ago

Sometimes aspects that help the community are a better long term investment, and I think that most people would point to compile times as the key thing to nail down in order to grow the community at a faster rate.

deleted 6y ago

[deleted]

tastyminerals2 6y ago

But the runtime performance is not that great either. Dot product: NumPy 0.03528 vs 0.03 Julia (x1/1.1) Element-wise sum: NumPy 0.00379 vs 0.0063 Julia (x1.6) Element-wise mul: NumPy 0.00419 vs 0.00617 Julia (x1.5) L2 norm: NumPy 0.02391 vs 0.097 Julia (x4.1) Matrix product: NumPy 0.00186 vs 0.01988 Julia (x10.7) Matrix sort: NumPy 0.01033 vs 0.0161 Julia (x1.6)

tgv 6y ago
Numpy is written in C. What are Julia’s functions written in?
- tastyminerals2 6y ago
  Julia was written in C++ in early stages if I remember correctly then Julia ;) The point here is that NumPy is heavily fine-tuned and will beat almost any other language implementation out there. The community is bigger and therefore there are much more free hands.
  - pdeffebach 6y ago
    In Julia's case, there are maybe more "free hands" who can contribute to performance critical code. To contribute to `NumPy` you have to know how to program in C.
  - johnmyleswhite 6y ago
    One of the important facts about OSS development is that the number of users doesn't scale linearly with the number of "free hands. There are less than 2 FTE's working on Python at any given time these days.
kristofferc 6y ago
Aren't many of those benchmarks mostly comparing MKL vs OpenBLAS (the default BLAS library used)? Also, it's unlikely that Julia will handily beat the handwritten, carefully optimized C-code in numpy. At that level, it isn't very much about the language but more about the programmers implementing the algorithms. A major selling point of Julia is that you will have fast code even in cases where the code doesn't neatly factor into calling static kernels written in e.g. C.