sim_npy slower than reference simulator about nengo-ocl HOT 4 CLOSED

I'm afraid this is essentially expected and by design. The sim_npy simulator ultimately does all the same things for number crunching as the reference simulator (e.g. calling np.dot, numpy broadcasting, etc.) but each step involves a lot more overhead because, for one, of all the indexing into the raggedarray. The sim_npy simulator could be sped up, but probably not beyond the reference implementation.

I'm tempted to close this issue, I'm not sure what can/should be done about this.

from nengo-ocl.

Perhaps add a docstring to the top of the sim_npy file explaining why it's slower than the reference?

from nengo-ocl.

I guess I had assumed that any overhead would be minimal, but apparently there's a lot! There's no need for sim_npy to go fast, but I agree with Trevor that a note would be nice, just saying that the simulator's slow and only meant for helping to test and debug the OCL simulator. I can add that tomorrow.

from nengo-ocl.

More radically, consider a mandatory argument to the sim_npy.Simulator
constructor like i_really_want_the_slow_npy_version :) That would make
anyone think twice about creating that class directly.

On Wed, Sep 18, 2013 at 8:48 PM, Eric Hunsberger
[email protected]:

I guess I had assumed that any overhead would be minimal, but apparently
there's a lot! There's no need for sim_npy to go fast, but I agree with
Trevor that a note would be nice, just saying that the simulator's slow and
only meant for helping to test and debug the OCL simulator. I can add that
tomorrow.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-24710598
.

from nengo-ocl.