Thanks for your help. FYI, there are 2 reasons I passed a slice instead of a single element:
1. This is just the first of several types of FIR filter. In the case of an (efficient) decimating FIR filter, the length of the slice is >1 element 2. I want to see how well julia can handle slices Sam L wrote: > u[i:i] or view(u, i:i) create a one element array/view, so the u in > shift_and_compute1 and compute1 always has length 1. I changed those > functions to take a scalar instead of an array and got about a 6 to 9x > speed up. > > Also, you can get rid of most of the type annotations without affecting the > performance. The only ones you need are in compute and compute1 functions, > because the types are used in those functions. You could alternatively get > the types with eltype(f.in) for example and drop those too. > > My version is here: https://gist.github.com/lendle/897eea1e5458eedb8e43. > > On Thursday, July 31, 2014 10:10:13 AM UTC-7, Neal Becker wrote: >> >> Daniel Jones wrote: >> >> > >> > Here's a version that's 7x faster (and almost 8x if you disable bounds >> > checking). The main thing is to avoid indexing into arrays with ranges >> (as >> > in u[i:j]) if you can, since that will allocate and copy a new array >> each >> > time. And also, like Patrick said, globals should usually be declared >> with >> > 'const'. >> > >> > On Thursday, July 31, 2014 8:38:33 AM UTC-7, Neal Becker wrote: >> >> >> >> Attached is my 1st attempt at julia, it is a simple FIR filter, which I >> >> translated from my c++ version. >> >> >> >> It is benchmarking about 10x slower than python wrapped c++ version. >> >> >> >> Any suggestions? >> >> I was concerned about that indexing arrays causing copying, and to get >> closer to >> the c++ version (which does not copy), I tried out ArrayViews. I'll >> attach that >> version, but I did not see any speedup.
