5 ms·

Last week's discussion on matrix multiply: https://news.ycombinator.com/item?id=17164737 https://news.ycombinator.com/item?id=17164737 I guess the claim is th

Last week's discussion on matrix multiply: https://news.ycombinator.com/item?id=17164737 https://news.ycombinator.com/item?id=17164737 I guess the claim is that you could write all that in Julia, and hope to be competitive, while you could never do this in (pure) Python. It would still be a lot of work, and would require you to think about the cache, there's no way around that. The selling point here (it seems to me) is that you can easily doodle up the most naive version of whatever algorithm you're thinking about, and then start optimising to the degree needed, where needed, without having to start over in C or something.

hellofunk 8y ago
I thought Python offers an entry into the performance space via Cython, which seems to nearly map directly to C. Is Cython not a viable alternative to Julia?
- improbable22 8y ago
  Yes, this is aimed at the same people, I believe. Doodle in Python and then work harder on the critical part. I think this works best when you have some loops pushing arrays of Float64 around. And worst if you'd like to pass some library a million little functions to optimise which depend on some strange data type you just defined... Cython is quite a limited sub-language. But certainly many current Julians made a living this way in the past.
- ChrisRackauckas 8y ago
  One of the main issues is that, because you compile things separately with a context-switch managed by python in the middle, if you pass a Cython compiled function to code that is calling compiled code (C/Fortran/etc.), then you still get a huge overhead. We tested this with ODE solvers, and things like Numba+SciPy odeint were still about 10x slower than they should be because of this phenomena ([1] mentions some of our tests). In the end, we found a very good reason to make sure the whole stack can compile together! [1]: http://juliadiffeq.org/2018/04/30/Jupyter.html http://juliadiffeq.org/2018/04/30/Jupyter.html
- simondanisch 8y ago
  I wouldn't say so. Cython is quite literally C for python, basically making all your python code look like C with most disadvantages, while not always reaching C performance. Julia in comparison is a fully featured language, with a lot to offer - you can write highly generic + fast code in a very high-level way. E.g. have a look at https://medium.com/@Jernfrost/defining-custom-units-in-julia-and-python-513c34a4c971 https://medium.com/@Jernfrost/defining-custom-units-in-julia... You can see, that Julia can be more elegant than python while being a lot faster.

hellofunk 8y ago

I thought Python offers an entry into the performance space via Cython, which seems to nearly map directly to C. Is Cython not a viable alternative to Julia?

improbable22 8y ago
Yes, this is aimed at the same people, I believe. Doodle in Python and then work harder on the critical part. I think this works best when you have some loops pushing arrays of Float64 around. And worst if you'd like to pass some library a million little functions to optimise which depend on some strange data type you just defined... Cython is quite a limited sub-language. But certainly many current Julians made a living this way in the past.
ChrisRackauckas 8y ago
One of the main issues is that, because you compile things separately with a context-switch managed by python in the middle, if you pass a Cython compiled function to code that is calling compiled code (C/Fortran/etc.), then you still get a huge overhead. We tested this with ODE solvers, and things like Numba+SciPy odeint were still about 10x slower than they should be because of this phenomena ([1] mentions some of our tests). In the end, we found a very good reason to make sure the whole stack can compile together! [1]: http://juliadiffeq.org/2018/04/30/Jupyter.html http://juliadiffeq.org/2018/04/30/Jupyter.html
simondanisch 8y ago
I wouldn't say so. Cython is quite literally C for python, basically making all your python code look like C with most disadvantages, while not always reaching C performance. Julia in comparison is a fully featured language, with a lot to offer - you can write highly generic + fast code in a very high-level way. E.g. have a look at https://medium.com/@Jernfrost/defining-custom-units-in-julia-and-python-513c34a4c971 https://medium.com/@Jernfrost/defining-custom-units-in-julia... You can see, that Julia can be more elegant than python while being a lot faster.