5 ms·

One of the neighboring comments mentioned something about changing assumptions. This is what limits the creation of decades-stable stuff. If you leave the perfo

One of the neighboring comments mentioned something about changing assumptions. This is what limits the creation of decades-stable stuff. If you leave the performance crucial stuff in C, that stuff will not operate with the novel code you wrote (autodiff, probabilistic programming, GPU/TPU hardware, etc). Julia is now experimenting with pure-Julia code that is faster than many LAPACK/BLAS implementations. But I actually care little about the fact that they are a bit faster. Same with the new ODE package in Julia, which is unsurpassed in terms of functionality. The actual reason these pure-Julia packages excite me is that they are generic enough to run relatively easily on different hardware (GPUs for instance), they are on top of modern compilers (LLVM), and most importantly, they are written in a language that permits much higher level of interoperability. To rephrase it much more simply: The fact that you can not use scipy special functions efficiently inside of any of the autodiff frameworks is exemplary of how incredibly limiting python is, when it comes to developing new numerical techniques. Julia does not have that problem as far as we know.

cozzyd 6y ago
The "using Julia from other languages" story doesn't look that great though: https://docs.julialang.org/en/v1/manual/embedding/ https://docs.julialang.org/en/v1/manual/embedding/ Mostly the bits about how you have to workaround the Julia GC. So it doesn't seem like a great option for libraries that might have lots of different bindings, where C/C++/Fortran (and maybe Rust?) seem to be the only reasonable choices.
- ChrisRackauckas 6y ago
  Using it from other interpreted languages is pretty great though. I got a JIT for R ODE solving up and running in a day: https://www.stochasticlifestyle.com/gpu-accelerated-ode-solving-in-r-with-julia-the-language-of-libraries/ https://www.stochasticlifestyle.com/gpu-accelerated-ode-solv...
UMetaGOMS 6y ago
> faster than many LAPACK/BLAS implementations IMO this is worth very little; as long as there is a heavily optimized version written in C/assembly (ie MKL), the fact that Julia might be faster than standard-but-slower versions like OpenBLAS doesn't actually gain me anything as a user.
- newen 6y ago
  Some people want to use their own types and number formats, so it can potentially be very useful.
imtringued 6y ago
>The actual reason these pure-Julia packages excite me is that they are generic enough to run relatively easily on different hardware (GPUs for instance) Only if they were specifically written for GPUs. GPUs are incredibly limited. Expecting to run arbitrary code on them is only going to disappoint you. If you could just run regular code on GPUs then everyone would have done so. Programming language support is not a barrier. The GPU itself is. In fact, you should consider yourself lucky if you have problems that don't need GPUs.
- dklend122 6y ago
  That's patent false. Julia has abstractions that make it very easy to write generic code . Sure, no arbitrary loops though,..but a constrained subset will work (see kernel abstractions.jl)

cozzyd 6y ago

The "using Julia from other languages" story doesn't look that great though: https://docs.julialang.org/en/v1/manual/embedding/ https://docs.julialang.org/en/v1/manual/embedding/ Mostly the bits about how you have to workaround the Julia GC. So it doesn't seem like a great option for libraries that might have lots of different bindings, where C/C++/Fortran (and maybe Rust?) seem to be the only reasonable choices.

ChrisRackauckas 6y ago
Using it from other interpreted languages is pretty great though. I got a JIT for R ODE solving up and running in a day: https://www.stochasticlifestyle.com/gpu-accelerated-ode-solving-in-r-with-julia-the-language-of-libraries/ https://www.stochasticlifestyle.com/gpu-accelerated-ode-solv...

UMetaGOMS 6y ago

> faster than many LAPACK/BLAS implementations IMO this is worth very little; as long as there is a heavily optimized version written in C/assembly (ie MKL), the fact that Julia might be faster than standard-but-slower versions like OpenBLAS doesn't actually gain me anything as a user.

newen 6y ago
Some people want to use their own types and number formats, so it can potentially be very useful.

imtringued 6y ago

>The actual reason these pure-Julia packages excite me is that they are generic enough to run relatively easily on different hardware (GPUs for instance) Only if they were specifically written for GPUs. GPUs are incredibly limited. Expecting to run arbitrary code on them is only going to disappoint you. If you could just run regular code on GPUs then everyone would have done so. Programming language support is not a barrier. The GPU itself is. In fact, you should consider yourself lucky if you have problems that don't need GPUs.

dklend122 6y ago
That's patent false. Julia has abstractions that make it very easy to write generic code . Sure, no arbitrary loops though,..but a constrained subset will work (see kernel abstractions.jl)