21–30 of 63 posts
I think numba still makes sense for loopy algorithms but not so much if youre more vector oriented given that Jax is more or less a drop in replacement for numpy and is shockingly fast.
I remember the team being really responsive to feature requests back then and I had a lot of fun working with it. IIRC compared to using numpy we managed to get speedups of up to 60x for the most critical pieces of code.
[1]: https://github.com/fbpic/fbpic [2]: https://github.com/fbpic/fbpic/blob/1867a4f216baf4269f2314ab...
How would this compare to Pypy? I didn't think Pypy uses LLVM so I wonder who produced better code. That said, they're targeted at different audiences. I feel Numba is targeted at data science and machine learning and even AI. I feel a large portion of using or programming a computer is structural and not the actual work of adding numbers together. Very little of the code generated does the useful part a computer doe…
> let the computer do the arrangement Isn't that constraint propagation? I'm discovering JS at the moment. I don't fully understand the async model, but the promise seems like a generic constraint of "the result is now available" Maybe you could have the "flow managements" as other constraints?
I'm thinking the code for your average CRUD or even desktop compositor. A compositor copies pixels from multiple places into one place. Surely that can be defined with a simple loop? But no there's hundreds of APIs in the way. Add Wayland and X11 and you have something that is opaque and understood by very few people.
The motivation behind my comment was that most of programming computers is gluing together APIs to shift data from one place to another before doing something useful with it. The APIs themselves do very little addition or subtraction of data but actual just moving data around and placing it into the right place.
Maybe defining where things should be, declaratively, in order to do a calculation would be useful. So the shape of the calculation defines the data structure, rather than the data structure defining the caclulation.
As a side note, now it is easy to write Rust code, which can be directly used in Python - https://github.com/PyO3/pyo3 . It cannot use NumPy and other libraries (since it is Rust), but at the same time, I see its potential in creating high-performance code to be used in Python numerical environment.
I think numba still makes sense for loopy algorithms but not so much if youre more vector oriented given that Jax is more or less a drop in replacement for numpy and is shockingly fast.
I have used pytorch as a (almost) drop in replacement for numpy. Are there good reasons to look at jax instead assuming I'm doing DSP and not ML?
I think numba still makes sense for loopy algorithms but not so much if youre more vector oriented given that Jax is more or less a drop in replacement for numpy and is shockingly fast.
I have used pytorch as a (almost) drop in replacement for numpy. Are there good reasons to look at jax instead assuming I'm doing DSP and not ML?
JAX introduced a lot of cool concepts (e.g. autobatching (vmap), autoparallel (pmap)) and supported a lot of things that PyTorch didn't (e.g. forward mode autodiff).
And at least for my applications (scientific computing), it was much faster (~100x) due to a much better JIT compiler and reduced Python overhead.
...but! PyTorch has worked hard to introduce all of the former, and the recent PyTorch 2 announcement was primarily about a better JIT compiler for PyTorch. (I don't think anyone has done serious non-ML benchmarks for this though, so it remains to be seen how this holds up.)
There are still a few differences. E.g. JAX has a better differential equation solving ecosystem. PyTorch has a better protein language model ecosystem. JAX offers some better power-user features like custom vmap rules. PyTorch probably has a lower barrier to entry.
(FWIW I don't know how either hold up specifically for DSP.)
I'd honestly suggest just trying both; always nice to have a broader selection of tools available.
Earlier quoted context omitted.
> let the computer do the arrangement Isn't that constraint propagation? I'm discovering JS at the moment. I don't fully understand the async model, but the promise seems like a generic constraint of "the result is now available" Maybe you could have the "flow managements" as other constraints?
Thank you for your reply. I'm thinking the code for your average CRUD or even desktop compositor. A compositor copies pixels from multiple places into one place. Surely that can be defined with a simple loop? But no there's hundreds of APIs in the way. Add Wayland and X11 and you have something that is opaque and understood by very few people. The motivation behind my comment was that most of programming computers is…
Unchanged? Don't bother, leave it as-is. I think that's how Intel power saving works.
Now think about the MVC model: some changes in the data could result in a change in the view if the data currently shown on screen is what has changed - like triggers in SQL.
I wonder if you could have everything work like that?