4 ms·

This is a feature of Julia I like. I write in my pythonic way, slow but good enough. Then I tune it when I really need the speed. As you and others mentioned

This is a feature of Julia I like. I write in my pythonic way, slow but good enough. Then I tune it when I really need the speed. As you and others mentioned, there's only a few things to do to get most of the way - put things in functions, type stability, optimize array allocations. Also more here: https://docs.julialang.org/en/v1/manual/performance-tips/ https://docs.julialang.org/en/v1/manual/performance-tips/

eigenspace 6y ago
It's important to emphasize that while this may sound like what Python people do with Numba or Cython, it's actually quite different because whether or not you write "slow julia code" or write "fast julia code", it's all seen by the same compiler. A highly tuned kernel function can be inlined into a not so finely tuned outer function and vice versa, our metaprogramming tools see both functions the same, etc.
- ddragon 6y ago
  Plus high performance Julia code (at the 80% of C range, maybe not at the 100% range where micro-optimizations start to happen) isn't any less readable than low performance Julia code. A common misconception is that annotating every type and making it more imperative and C-like makes code faster, but as long as you internalized what makes code slow, making fast code is surprisingly just as concise as it would be in Python without any type annotation. But since fast and slow code are so similar, and both give the same ultimate result, it becomes less obvious for someone who is reading someone's code to see what was made to make it fast (even if it's easy to see what the code does because of it's high level nature). I think that's something that could improve over time with better tooling, using the meta-capabilities of the language to create linters and compiler suggestions that guide the users into making the small changes in the code that makes the most difference.

eigenspace 6y ago

It's important to emphasize that while this may sound like what Python people do with Numba or Cython, it's actually quite different because whether or not you write "slow julia code" or write "fast julia code", it's all seen by the same compiler. A highly tuned kernel function can be inlined into a not so finely tuned outer function and vice versa, our metaprogramming tools see both functions the same, etc.

ddragon 6y ago
Plus high performance Julia code (at the 80% of C range, maybe not at the 100% range where micro-optimizations start to happen) isn't any less readable than low performance Julia code. A common misconception is that annotating every type and making it more imperative and C-like makes code faster, but as long as you internalized what makes code slow, making fast code is surprisingly just as concise as it would be in Python without any type annotation. But since fast and slow code are so similar, and both give the same ultimate result, it becomes less obvious for someone who is reading someone's code to see what was made to make it fast (even if it's easy to see what the code does because of it's high level nature). I think that's something that could improve over time with better tooling, using the meta-capabilities of the language to create linters and compiler suggestions that guide the users into making the small changes in the code that makes the most difference.