Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Numba: A High Performance Python Compiler

numba.pydata.org

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Numba: A High Performance Python Compiler

#51

Post by PartiallyTyped »

PheonixPharts wrote: post #37
grej wrote: post #12

We were very heavy numba users at my former company. I would even go so far as to say numba was probably the biggest computational enabler for the product. I’ve also made a small contribution to the library. It’s a phenomenal library for developing novel computationally intensive algorithms on numpy arrays. It’s also more versatile than Jax. In presentations, I’ve heard Leland McInnes credits numba often when he spea…

> It’s also more versatile than Jax Does numba do automatic differentiation? I view JAX as primarily an automatic differentiation tool with the bonus that it makes great use of XLA and can easy make use of GPU/TPUs. I don’t usually see numba and JAX as solving the same problem, but would be excited to be wrong

They solve different problems.

Numba compiles functions down to machine code or cuda kernels, that's it. XLA is "higher level" than what Numba produces.

You may be able to get the equivalent of jax via numba+numpy+autograd[1], but I haven't tried it before.

IMHO, jax is best thought of as a numerical computation library that happens to include autograd, vmapping, pmapping and provides a high level interface for XLA.

I have built a numerical optimisation library with it, and although a few things became verbose, it was a rather pleasant experience as the natural vmapping made everything a breeze, I didn't have to write the gradients for my testing functions, except for special cases that involved exponents and logs that needed a bit of delicate care.

[1] https://github.com/HIPS/autograd

Re: Numba: A High Performance Python Compiler

#52

Post by melling »

dang wrote: post #47
melling wrote: post #5

[flagged]

That's a bit too cynical, I think. People post follow-up/related stories because the brain likes to follow chains of associations. You're right that these chains tend towards already-familiar associations, which lower their value as HN stories. The best HN stories are the ones that can't be predicted from any existing sequence: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

Sure. Some people do. While others…

https://news.ycombinator.com/item?id=34110321

Re: Numba: A High Performance Python Compiler

#53

Post by college_physics »

hedgehog wrote: post #44
itamarst wrote: post #15

Quick overview of the design space: * PyPy JITs everything, so it can do _normal_ Python numerical code that is quite fast and regular Python code that is fast. However, its interactions with libraries like NumPy add overhead, and it seems like it can't JIT code that interacts with NumPy in a useful way (AFAIK, would be happy to be proven wrong). So not useful for optimizing numeric functions that interact with libra…

Good overview. "Vectorized" is an old term that's been around since the early days of supercomputers and maybe before, not sure where it came from. Numba does a bunch of different things for code written to the Numpy API including CUDA acceleration. Certain machine learning frameworks like PyTorch and JAX also roughly follow the Numpy API because it is widely familiar and easy enough to work with. The kind of code th…

Cray supercomputers used to have special "vector" units that would perform operations on multiple scalars (eg 128 doubles) in parallel. A bit like gpu units. Any algorithm that could be cast in a form that benefited from this type of parallelism would be called vectorizable. Linear algebra obviously fits perfectly (but, depending on the problem, you might0 need to juggle the vector dimensions).

Vectorizing code was fairly straightforward using the latter versions of fortran. It was all quite sweet and productive but could not provide the required hpc scaling so was eventually abandoned in favor of massively parallel designs.

Re: Numba: A High Performance Python Compiler

#54

Post by asidogbniobio »

m_c_g wrote: post #19
chestertn wrote: post #16

I will save you the pain: switch to Julia.

Indeed! Converting one's entire code base to a different language ecosystem, finding equivalents to each of your third-party dependencies, is less painful than employing a library to selectively compile a few performance bottlenecks in your code. (Modules like PyJulia facilitate a more incremental approach.)

Normally I'd agree with your sarcasm, but Python is such a disaster that I am in favor of ditching it ASAP in favor of literally anything else.

Re: Numba: A High Performance Python Compiler

#55

Post by dilawar »

fwilliams wrote: post #13
gjvc wrote: post #4

Earlier quoted context omitted.

What if I'm (in Python) doing non-numerical stuff like parsing text and generating code? What JIT / AOT tooling (if any) is suitable?

I have personally gotten a lot of mileage from just writing the compute heavy parts of my code in C++ and exposing it to Python with a tool like PyBind11 [1] or NumpyEigen [2]. I find tools like numba and cython to be more trouble than they're worth. [1] https://github.com/pybind/pybind11 [2] https://github.com/fwilliams/numpyeigen

+1 for pybind11. I wrote python bindings using pybind11 for two C++ based simulators: MOOSE and Smoldyn. It was surprisingly easy to use given how badly Python C-API and c++ tooling suck. Though you have to create binary wheels for every version of python and platform separately.

Re: Numba: A High Performance Python Compiler

#56

Post by dilawar »

auxym wrote: post #9
gjvc wrote: post #4

Earlier quoted context omitted.

What if I'm (in Python) doing non-numerical stuff like parsing text and generating code? What JIT / AOT tooling (if any) is suitable?

Pypy, probably. You could also consider writing pre compiled extensions for your "hot" code, eg. in Cython.

pypy is great if you are not already using numpy heavily. Pure python libraries like networkx and myhdl showed 20x speedup when I used it a couple of years ago. For pure python code, pypy provides free lunch.

Re: Numba: A High Performance Python Compiler

#57

Post by brnt »

dilawar wrote: post #55
fwilliams wrote: post #13

Earlier quoted context omitted.

I have personally gotten a lot of mileage from just writing the compute heavy parts of my code in C++ and exposing it to Python with a tool like PyBind11 [1] or NumpyEigen [2]. I find tools like numba and cython to be more trouble than they're worth. [1] https://github.com/pybind/pybind11 [2] https://github.com/fwilliams/numpyeigen

+1 for pybind11. I wrote python bindings using pybind11 for two C++ based simulators: MOOSE and Smoldyn. It was surprisingly easy to use given how badly Python C-API and c++ tooling suck. Though you have to create binary wheels for every version of python and platform separately.

> Though you have to create binary wheels for every version of python and platform separately.

cibuildwheel makes this easy.

Re: Numba: A High Performance Python Compiler

#58

Post by hedgehog »

college_physics wrote: post #53
hedgehog wrote: post #44

Earlier quoted context omitted.

Good overview. "Vectorized" is an old term that's been around since the early days of supercomputers and maybe before, not sure where it came from. Numba does a bunch of different things for code written to the Numpy API including CUDA acceleration. Certain machine learning frameworks like PyTorch and JAX also roughly follow the Numpy API because it is widely familiar and easy enough to work with. The kind of code th…

Cray supercomputers used to have special "vector" units that would perform operations on multiple scalars (eg 128 doubles) in parallel. A bit like gpu units. Any algorithm that could be cast in a form that benefited from this type of parallelism would be called vectorizable. Linear algebra obviously fits perfectly (but, depending on the problem, you might0 need to juggle the vector dimensions). Vectorizing code was f…

I think this is backwards, the early Crays and maybe other machines used essentially serial + aggressively pipelined CPUs while modern CPUs do actually execute operations in parallel via multiple ALUs but are from a programmer point of view kind of similar (fixed size vector).

Re: Numba: A High Performance Python Compiler

#59

Post by college_physics »

hedgehog wrote: post #58
college_physics wrote: post #53

Earlier quoted context omitted.

Cray supercomputers used to have special "vector" units that would perform operations on multiple scalars (eg 128 doubles) in parallel. A bit like gpu units. Any algorithm that could be cast in a form that benefited from this type of parallelism would be called vectorizable. Linear algebra obviously fits perfectly (but, depending on the problem, you might0 need to juggle the vector dimensions). Vectorizing code was f…

I think this is backwards, the early Crays and maybe other machines used essentially serial + aggressively pipelined CPUs while modern CPUs do actually execute operations in parallel via multiple ALUs but are from a programmer point of view kind of similar (fixed size vector).

What is a vector unit was is simd etc can be confusing but at least some wikipedians are sure the early Crays had true vector processing (which may not be parallel processing according to your definition)

https://en.m.wikipedia.org/wiki/Vector_processor

Re: Numba: A High Performance Python Compiler

#60

Post by hedgehog »

college_physics wrote: post #59
hedgehog wrote: post #58

Earlier quoted context omitted.

I think this is backwards, the early Crays and maybe other machines used essentially serial + aggressively pipelined CPUs while modern CPUs do actually execute operations in parallel via multiple ALUs but are from a programmer point of view kind of similar (fixed size vector).

What is a vector unit was is simd etc can be confusing but at least some wikipedians are sure the early Crays had true vector processing (which may not be parallel processing according to your definition) https://en.m.wikipedia.org/wiki/Vector_processor

Yes, in the Cray design a vector instruction processes one item per clock so total latency increases with number of elements. Only parallel in the sense of pipelining being a form of parallelism. Something like an AVX-equipped Intel CPU processes all elements in parallel to deliver a result in an essentially constant number of cycles.

Edit: There's a period write-up of the general Cray 1 design here: https://inst.eecs.berkeley.edu/~n252/sp07/Papers/Cray.pdf

Post reply on HN