News for hackers. Stuff that matters.
Re:Fast.ai and why Python is not the future of ML with Jerem... by BadInformatics on Tuesday September 08, 2020 @11:33AM (#24409408)
> although no one has done it yet

This may be generally true (though the benchmarks I've seen show Knet.jl and sometimes Flux.jl on par with TF/PyTorch with a single machine + single GPU), but there are definitely domains where it is categorically not. The most prominent one is neural *DEs, where the SciML [1] ecosystem has SOTA performance. You can really see Python/C++-based frameworks struggle here because they have slow "glue code" and don't (one could argue can't effectively) optimize for latency. That's not a problem for most CV models and transformers, but really stunts research into more dynamic approaches.

[1] https://sciml.ai/

Re:Fast.ai and why Python is not the future of ML with Jerem... by nl on Tuesday September 08, 2020 @06:35PM (#24414393)
This sounds more like it's a new field.

I started looking for benchmarks (because it sounds like the kind of thing JAX would do well) and the very first link I clicked included:

Wraps for common C/Fortran methods like Sundials and Hairer's radau

which is exactly what was claimed wasn't needed.

Re:Fast.ai and why Python is not the future of ML with Jerem... by ChrisRackauckas on Wednesday September 09, 2020 @04:19AM (#24418651)
>I started looking for benchmarks (because it sounds like the kind of thing JAX would do well)

Currently Jax has an in-progress stiff ODE solver that's about 200x slower than SciPy

https://github.com/google/jax/issues/3686#issuecomment-65709...

and SciPy (with JIT) is about 50x-100x slower than the pure Julia methods

https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa...

so Jax has more than a little bit of a way to go.

Re:Fast.ai and why Python is not the future of ML with Jerem... by amkkma on Tuesday September 08, 2020 @08:27PM (#24415287)
Those aren't needed, but they are options. "he templated implementation allows arbitrary array and number types to be compatible, giving compatibility with arbitrary precision floating point numbers, GPU-based computations, unit-checked arithmetic, and other features. "

Those are exactly the things wrapping fortran and c won't give you