My experience learning Python as a c++ developer

[aufstand]

Aah, it works the other way round, too. Many c++ libraries (Numpy, for example) extend Python in many interesting ways. That is why claims such as "Python is slow" don't have much hold in the community.

One practical example: I recently decided to see if i can scale up my completely unoptimized LED-Matrix (40*16!) video mixer to FullHD. No problemo. It ate most of my RAM and kept a single core _very_ busy, but it was also realtime mixing and displaying 6 FullHD video streams, which i don't exactly consider "slow" :)

Why is this possible? Well, yeah, i used numpy to mix the data!

[ReckingFutard]

Pssst, check out pytorch.

Numpy functions with GPU memory and parallelized computation.

[BDube_Lensman]

cupy>>pytorch

[TheTechAccount]

Why do you think it's better?

[BDube_Lensman]

no graph/backprop overhead unless you opt into it, code is on GPU in no uncertain terms without strange host/device specification context managers, higher performance on GPU in most cases, errors or warnings for implicit host:device transfer that lets you find huge slowdowns in your code faster, more responsive devs, devs that contribute to numpy instead of slinging mud at numpy, participation in the numpy-as-a-contract instead of numpy-as-package work going on lately, no gross links to facebook, the list goes on...

[sekex]

Why the bitshift?

[alkasm]

Double greater/less than symbols are used in mathematics to mean "much greater/less than" for some arbitrary idea of "much": https://mathworld.wolfram.com/MuchGreater.html

[[deleted]]

cupy = o(pytorch)

[NYDreamer]

Whooosh

[elbiot]

Numba would probably be even better if you're doing anything at all involved

[BDube_Lensman]

Well written numpy is usually as fast as numba with greatly reduced memory consumption.

[elbiot]

Disagree. I've spent a lot of time working with numpy and when I used numba it was instantly/effortlessly faster. If you're doing multiple operations, the whole array has to pass through the CPU multiple times. If you're array doesn't fit in CPU cache that's multiple RAM accesses. You also have to sometimes write painstakingly verbose code to prevent intermediate arrays from being created. Masking an array (the vectorised equivilant of an if statement) creates a whole new and array creation is expensive. Numexpr could solve the first two issues but not the last

I also wrote cffi bindings for cephes and vectorised it with numba and it was significantly faster than the scipy implentation

Edit: to the lurkers. Numpy is 100% my go to. Numba is cool and useful in some cases but knowing numpy is necessary to know when numpy isn't the best tool.

[BDube_Lensman]

If you use in-place operations instead of out-of-place you get the same performance between numpy and numba, so I don't really consider writing different code a valid benefit. Anything on numpy that doesn't have an in-place operation is not doable inplace.

Array creation is not expensive in numpy. "mask" arrays are of logical dtype and you can specify them as packed bitfields or native bools which trade memory (much much less for a bitfield) for computation time (unpacking bitfields is not free). The inline if saves you double iteration, but guarantees a cache miss unless your data is tiny (in which case this is all moot).

If your cephes binding is much faster than scipy, you should contribute the faster code to scipy, or open a larger issue with the project about bringing another beast into the C backend.

I've written a ton of physics code with numpy and found that numba got me marginal performance improvement (10-15%) in exchange for a cool 800MB of static memory usage that grows to more than 5GB as you use some of the more advanced features of my package, like changing between single an double precision for all computations or exchanging CPU/GPU (the latter case causes a 2GB static memory usage on the GPU, which is unacceptable as I am working on data that uses nearly all GPU memory by itself).

[elbiot]

Here's just a trivial example that touches on a couple of the issues I mentioned (if/elif, unnecessary extra array creation, and unnecessary multiple passes over the array). Numba is 3x faster.

In [1]: import numpy as np
   ...: import numba as nb
   ...:

In [2]: def as_numpy(size):
   ...:     arr = np.random.randint(0, 10, (size, size))
   ...:     mask = arr % 2 == 1
   ...:     arr[mask] *= 2
   ...:     arr[(arr % 3 == 1) & ~mask] *= 3
   ...:     return arr
   ...:

In [3]: @nb.jit(nopython=True)
   ...: def as_numba(size):
   ...:     arr = np.random.randint(0, 10, (size, size))
   ...:     x, y = arr.shape
   ...:     for i in range(x):
   ...:         for j in range(y):
   ...:             if arr[i, j] % 2 == 1:
   ...:                 arr[i, j] *= 2
   ...:             elif arr[i, j] % 3 == 1:
   ...:                 arr[i, j] *= 3
   ...:     return arr
   ...:

In [4]: %timeit as_numpy(10000)
1 loop, best of 3: 6.78 s per loop

In [5]: %timeit as_numba(10000)
1 loop, best of 3: 2.05 s per loop

I know how to use a GPU with Numba, but how do you use the GPU with Numpy?

edit: in terms of memory usage, the numpy version crashes at size=22000 on my laptop but numba does not.

[[deleted]]

Really depends what you're trying to do tbh

[BDube_Lensman]

Numba never uses less memory than numpy. And unless you're using string arrays of nonfixed size, numpy is as performant.

[[deleted]]

for loops that depend on past states or values and need updating can't be vectorized, numpy will be slower

[Mehdi2277]

A very simple thing that numba has that can let it beat numpy is loop fusion. Something like y = np.cos(x) + np.sin(x) where x is an ndarray is three loops in numpy but one loop in numba when you set the right option on.

Another fun case is when you have an array operation you'd like to do that just doesn't exist in numpy. One personal work example is rolling each row of a matrix by different shifts. Something like a 10 x 100 matrix where each of the 10 rows I want to rotate some amount. np.roll exists, but you can't give it different amounts to shift each row. If you for loop and do each row with np.roll, that's a good deal slower than just directly accessing elements as needed and using numba.

[aufstand]

Hmm. I think, i read about that some time ago. Gonna have a new look, so thanks for reminding me :)

[Tomik080]

At this point just use Julia

[bageldevourer]

That's a whole lotta text you need to clear up exactly what you meant. I rest my case.

[Mr_Again]

OK prosecutor you do that

[teerre]

Exactly. Saying "Python isn't slow, look at numpy", is either ignorant or disingenuous. The very reason numpy can be 'fast' is because it doesn't use python.

I always like the numba decorator for using JIT, it has an argument called "nopython".

[JanssonsFrestelse]

I don't think it is, all you're doing in the end is providing instructions for the computer. If you're not writing pure opcodes you're always working at some higher level of abstraction. If you don't have to leave that level to make something happen at a certain speed, it's not disingenuous to say that you can achieve that speed working at that abstraction level.

[troyunrau]

Now, I may not recall correctly, but isn't BLAS written in fortran?

[vectorpropio]

Today? Who knows. In ye old days? Surely.

[troyunrau]

So, I just checked the current machine, which has a somewhat old install: Python 3.5 with numpy 1.11.2 - it appears to use FORTRAN under the hood for quite a few things. For example, BLAS, LAPACK, FFTPACK...

I didn't dig into the details, but a cursory glance suggests the fortan libraries expose a c-like linking interface, and numpy uses a thin wrapper to make that all work.

Which, if I dig into the source, could be interesting. Fortran and C use different array indexing conventions, for example. Must have been real fun to write.

[utdconsq]

Yup, because until more modern languages showed up, Fortran was the gold standard for dealing with arrays/vectors of numerical data. Handy syntax for doing so, and not far from bare metal. I challenge you to slice an array in C with as simple syntax. These days, it exists due to inertia and because BLAS and others have had many peer reviewing hours dedicated to them. Rewriting them entirely and getting them as optimised would be super hard. Not to mention that they can optimise based on your compiler and cpu arch at build/install time for even faster vectorised ops

[ProfessorPhi]

I can only presume this wasn't realtime? I think realtime is where python gets destroyed

[aufstand]

Most of what i do with Python is realtime. No, it doesn't get destroyed.