Regular rather than matrix addition

[TristanTrim]

The cube_vertices function in pycraft/util.py is manually doing addition to every element in a list. I'm about 60% sure that this needs to be happening in numpy or pyglet to be a reasonable speed.

If this get's fixed, the blocks could be moved over .5 and normalize swapped to using floor as described in #45 . This may cascade into other logic though, idk.

[TristanTrim]

The change_sector function could also benefit from being matrix addition.
https://github.com/traverseda/pycraft/blob/master/pycraft/world.py#L302

[TristanTrim]

I notice that I'm confused, but re-implementing cube_vertices in numpy made it slower. If anyone knows why this is, I'm pretty curious.

Check it out on this branch if you curious:
https://github.com/TristanTrim/pycraft/blob/numpy_cube_vertices/pycraft/util.py

Original cube_vertices function:
Average time for moving a cube is 3.7735462188720705e-06 over 10000 tests
Numpy re-implementation:
Average time for moving a cube is 1.2723827362060548e-05 over 10000 tests
Numpy re-implementation without (necessary) array.reshape call:
Average time for moving a cube is 8.726072311401368e-06 over 10000 tests

[traverseda]

It seems to be because the costs of creating an array in numpy are a lot more then the costs of creating an array in plain python.

[ghevcoul]

NumPy is generally only faster than pure Python for operations on large arrays. I don't remember the exact switching point, but most of the benchmarks I've seen don't show benefits for NumPy arrays over Python lists until you have on the order of a few thousand array elements.

I don't have a good sense of everywhere the cube_vertices() function is used in the code, but if it was refactored to take a list of blocks in a region and return the list of vertices for each block, rather than taking a single block, then a NumPy implementation might be faster.

[TristanTrim]

if it was refactored to take a list of blocks in a region and return the list of vertices for each block

Yeah, this sound's good. I'm attempting it now, with some other refactoring.