Closed tbekolay closed 7 years ago
This was easier than I expected to fix. Take a look at #133 and if you're happy, go ahead and merge it.
I have one request, though: Can you make sure that the tests don't take significantly longer with the change, and that the benchmark in examples/benchmark_circconv.py
also doesn't take longer? I just want to make sure we're not losing anything by not putting the Copy into MultiDotInc.
Take a look at #133 and if you're happy, go ahead and merge it.
Your changes look good to me; I added some commits to keep compatibility with older Nengo versions and a few other things; take a look and merge away if you're OK with them.
Can you make sure that the tests don't take significantly longer with the change, and that the benchmark in examples/benchmark_circconv.py also doesn't take longer?
Done! tl;dr: On my machine there's very little difference in speed. Details follow:
v2.3.0
, Nengo OCL master
: 165.64 secondsv2.3.0
, Nengo OCL plan_copy
: 140.33 secondsmaster
, Nengo OCL plan_copy
: 141.29 secondsplan_copy
might be a tiny bit slower, but in general pretty close:
Prepping the 2.3.1 release and getting the following failure when building with Nengo OCL:
This happens for all models, so the specific test isn't relevant. Since this deals with the
Copy
operator, it seems quite likely that the issue is related to https://github.com/nengo/nengo/pull/1083 though https://github.com/nengo/nengo/pull/1245 also touches the op graph so that might play a role.Let me know if this is an easy fix that I can do @hunse, or if you want me to hold off on the Nengo release.