5 ms·

Numba package for Python gives you the LLVM JIT for numerical work. I really don't see how Julia is relevant anymore.

tavert 10y ago
Types that aren't dense numpy arrays.
ska 10y ago
Python really doesn't (and cannot) address many of the design goals of Julia. At least as I understand them (and I'm not a Julia user). Whether or not Julia has/will achieve them either is a separate issue. Python can be a very useful mess for this sort of work (numerical analysis etc.), and is succeeding at that quite well. In fact, that's it's main challenge to something like Julia. Not design, that ship sailed a long time ago. But practicality and availability of packages and bindings. Once you get too far ahead in that, it's hard to justify using any other platform for "real work", rather than because it's fun to hack on.
- marmaduke 10y ago
  Python is a mess if you make it that way. What are these design principles in Julia that Python can't possibly uphold?
srean 10y ago
Numba acceleration is way too brittle as of now.
cschmidt 10y ago
In my (somewhat limited) experience, Numba works great until it doesn't. Loops on numpy arrays work great. Other stuff becomes super slow, without any real way to understand what is happening. Julia sees more understandable.
- marmaduke 10y ago
  Lol, "works great until it doesn't" applies to any abstraction, including your L3 cache. What's specifically better about Julia here?
  - cschmidt 10y ago
    Numba seems to fall back to regular slow python code when it can't handle things, without any warning. I couldn't find a way to tell if a routine was compiling to fast code, or dropping back to slow code. (As I say, I didn't use it that much, so it might exist.) With Julia is it more well defined when your code is fast. Write type stable code, according to these guidelines... http://docs.julialang.org/en/release-0.4/manual/performance-tips/ http://docs.julialang.org/en/release-0.4/manual/performance-... and you code will be going fast. Specifically, @code_warntype tells you when your code is going to be slow.

Types that aren't dense numpy arrays.

ska 10y ago

Python really doesn't (and cannot) address many of the design goals of Julia. At least as I understand them (and I'm not a Julia user). Whether or not Julia has/will achieve them either is a separate issue. Python can be a very useful mess for this sort of work (numerical analysis etc.), and is succeeding at that quite well. In fact, that's it's main challenge to something like Julia. Not design, that ship sailed a long time ago. But practicality and availability of packages and bindings. Once you get too far ahead in that, it's hard to justify using any other platform for "real work", rather than because it's fun to hack on.

marmaduke 10y ago
Python is a mess if you make it that way. What are these design principles in Julia that Python can't possibly uphold?

srean 10y ago

Numba acceleration is way too brittle as of now.

cschmidt 10y ago

In my (somewhat limited) experience, Numba works great until it doesn't. Loops on numpy arrays work great. Other stuff becomes super slow, without any real way to understand what is happening. Julia sees more understandable.

marmaduke 10y ago
Lol, "works great until it doesn't" applies to any abstraction, including your L3 cache. What's specifically better about Julia here?
- cschmidt 10y ago
  Numba seems to fall back to regular slow python code when it can't handle things, without any warning. I couldn't find a way to tell if a routine was compiling to fast code, or dropping back to slow code. (As I say, I didn't use it that much, so it might exist.) With Julia is it more well defined when your code is fast. Write type stable code, according to these guidelines... http://docs.julialang.org/en/release-0.4/manual/performance-tips/ http://docs.julialang.org/en/release-0.4/manual/performance-... and you code will be going fast. Specifically, @code_warntype tells you when your code is going to be slow.