Hello everyone.
I just did a simple test to compare Python NumPy vs VEX speed the result surprised me a lot!
The algorithm is pretty simple:
1- takes a 2D grid and creates 8 point attributes randomly
2- roll the attributes from the previous point to the next repeatedly for 15000 times
The result is interesting:
- VEX version takes about over 10 seconds to cook
- Python version takes about under 3 seconds to cook
I put the file so that you can watch it yourselves.
Although VEX is multithreaded it is completely defeated by vectorized NumPy code which is weird for me!
Can anyone explain why there is a huge difference between these two implementations?
Is there a way to get VEX version faster?
Thanks a lot in advance!

There are some instances where Python defeats VEX in performance. One of the advantage you are getting here (other than numpy) is you are able to get and set all attribute values at once using a single function call. VEX doesn't have this unfortunately. I asked for this ability long ago, so maybe in a future version we might have a similar functionality.

Other than that you can squeeze a bit more performance by storing some of the things in variables rather than recomputing each time:

Not the fairest comparison.
Even empty wrangle inside for loop takes more time than this python sop.
It's a feedback loop overhead, not the processing problem.

Vex is still way faster than numpy on one iteration (vex also utilizing simd btw).
Or you can put your python sop in the same loop network and see the results.

animatrix_
There are some instances where Python defeats VEX in performance. One of the advantage you are getting here (other than numpy) is you are able to get and set all attribute values at once using a single function call. VEX doesn't have this unfortunately. I asked for this ability long ago, so maybe in a future version we might have a similar functionality.

Other than that you can squeeze a bit more performance by storing some of the things in variables rather than recomputing each time:

int count = @ptnum - 1;
int col = detail(0, "columns");
int n = count % col;

f@a = point(0, 'a', n);
f@b = point(0, 'b', n);
f@c = point(0, 'c', n);
f@d = point(0, 'd', n);

f@e = point(0, 'e', n);
f@f = point(0, 'f', n);
f@g = point(0, 'g', n);
f@h = point(0, 'h', n);

Thanks a lot, man!
Don't you think that this bottleneck is due to reading and writing back to Houdini's main data structure geometry over and over again via VEX?
I'm wondering since in Python version we are constantly writing back the rolled array to NumPy data structure in each iteration but it happens really fast!

elovikov
Not the fairest comparison.
Even empty wrangle inside for loop takes more time than this python sop.
It's a feedback loop overhead, not the processing problem.

Vex is still way faster than numpy on one iteration (vex also utilizing simd btw).
Or you can put your python sop in the same loop network and see the results.

I don't think it's overhead of for loop since you can use for loop in Python SOP to access Houdini's geometry data structure with nearly the same slowness!

N-G

animatrix_
There are some instances where Python defeats VEX in performance. One of the advantage you are getting here (other than numpy) is you are able to get and set all attribute values at once using a single function call. VEX doesn't have this unfortunately. I asked for this ability long ago, so maybe in a future version we might have a similar functionality.

Other than that you can squeeze a bit more performance by storing some of the things in variables rather than recomputing each time:

int count = @ptnum - 1;
int col = detail(0, "columns");
int n = count % col;

f@a = point(0, 'a', n);
f@b = point(0, 'b', n);
f@c = point(0, 'c', n);
f@d = point(0, 'd', n);

f@e = point(0, 'e', n);
f@f = point(0, 'f', n);
f@g = point(0, 'g', n);
f@h = point(0, 'h', n);

Thanks a lot, man!
Don't you think that this bottleneck is due to reading and writing back to Houdini's main data structure geometry over and over again via VEX?
I'm wondering since in Python version we are constantly writing back the rolled array to NumPy data structure in each iteration but it happens really fast!

Yes that would be my guess and having to use them inside a for loop network.