4 ms·

One thing I've wondered about: I see it frequently written that someone new to Julia sits down and write an algorithm, and despite that language's marketing, th

One thing I've wondered about: I see it frequently written that someone new to Julia sits down and write an algorithm, and despite that language's marketing, the code runs at a fraction of C++ speeds. Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience. That concerns me that this would be the common scenario, and I see this written often in articles, blog posts, forums, etc. It's the one point that has turned me off of diving too deeply into it.

ChrisRackauckas 6y ago
>Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience I wouldn't say it's non-obvious: the things you have to do would be obvious to any programmer who's written code in something like C++. The problem usually tends to be that MATLAB, R, and Python tend to train people to want to use sub-optimal programming styles, like something heavy on array allocations, even if writing a function that does a loop is perfectly optimal. If someone is always told that mapping one function at a time ("vectorization") is the optimal way to do things, then they will try it when they go to a more optimal language. So it's really just a re-education issue.
ddragon 6y ago
That's true, but it's because Julia looks like Python/Fortran/Matlab on the surface but it's a really unique language that you can't really learn in one day or two. Write Julia like Python and it will be slow (dynamic languages are slow after all), write Julia like Fortran and it will be fast (static languages are fast, but they are restrictive). And after you actually learn the language you can fairly easily write extremely dynamic code that is around 80% of the speed of C just following a few rules (only consts on global namespace, type stability, typing containers like struct, abusing multiple dispatch/parametric types and profiling the eventual inference failures). Being permissive lowers the barrier for non CS people, one of the main target of the language, to start using the language, especially in the REPL/Notebook, even if they are not the most effective at the language.
- appleiigs 6y ago
  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.
snicker7 6y ago
There aren't a ton Julia-specific tuning. Off the top of my head, the main performance gotchas are: type unstable code, closures, globals, and (in some cases) passing by functions instead of function pointers. Most performance tips are similar across most fast languages: minimize OS-managed allocations, use cache and SIMD friendly memory layouts, better algo design in general. I find that these optimizations are typically easier in Julia than in most languages.

ChrisRackauckas 6y ago

>Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience I wouldn't say it's non-obvious: the things you have to do would be obvious to any programmer who's written code in something like C++. The problem usually tends to be that MATLAB, R, and Python tend to train people to want to use sub-optimal programming styles, like something heavy on array allocations, even if writing a function that does a loop is perfectly optimal. If someone is always told that mapping one function at a time ("vectorization") is the optimal way to do things, then they will try it when they go to a more optimal language. So it's really just a re-education issue.

ddragon 6y ago

That's true, but it's because Julia looks like Python/Fortran/Matlab on the surface but it's a really unique language that you can't really learn in one day or two. Write Julia like Python and it will be slow (dynamic languages are slow after all), write Julia like Fortran and it will be fast (static languages are fast, but they are restrictive). And after you actually learn the language you can fairly easily write extremely dynamic code that is around 80% of the speed of C just following a few rules (only consts on global namespace, type stability, typing containers like struct, abusing multiple dispatch/parametric types and profiling the eventual inference failures). Being permissive lowers the barrier for non CS people, one of the main target of the language, to start using the language, especially in the REPL/Notebook, even if they are not the most effective at the language.

appleiigs 6y ago
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.

snicker7 6y ago

There aren't a ton Julia-specific tuning. Off the top of my head, the main performance gotchas are: type unstable code, closures, globals, and (in some cases) passing by functions instead of function pointers. Most performance tips are similar across most fast languages: minimize OS-managed allocations, use cache and SIMD friendly memory layouts, better algo design in general. I find that these optimizations are typically easier in Julia than in most languages.