On Fri, Oct 22, 2010 at 2:13 PM, Sebastian Sturm Sebastian.Sturm@itp.uni-leipzig.de wrote:

...

I'm surprised about the grid:gref result.   Please run a profiler and confirm that the time consumed is within grid:gref and its callees,

I tried using sb-sprof, but as a complete CL newbie I had a hard time making sense of its output and thus ended up ignoring the profiler and using trial-and-error again. It seems that a fair amount of consing is due to the index linearization. Simply replacing grid:gref by grid:gref* for one-dimensional arrays reduces consing by a factor of 3 in my experiments. It seems that the rest can be eliminated by specifying the data type (here it's :double) at compile-time; incorporating this as an option to grid:gref via some macro-trickery would probably uglify the GSLL framework somewhat (I guess?), but I'd be willing to pay that price in return for an order-of-magnitude speedup. Also, I haven't tried if similar problems arise (and if similar workarounds are available) for the case of complex-valued arrays.

Interesting. It's plausible to me that linearization is causing the problem; I think that there is room for improvement there. Your example with the mem-aref show that it's got to be that and/or generic function dispatch, because as you can see on line 35 of http://repo.or.cz/w/gsd.git/blob/e537bd9be551b90c9fbfb6020a6119f3df00d650:/f..., gref* essentially just calls mem-aref. So maybe if we can add declarations and inlining, we can get the same effect with the current code.

If you can't make sense of sb-prof and you use slime, you might try the slime profiler: http://lhealy.livejournal.com/8495.html I find its output much clearer.

I'm not sure where you are putting a :double declaration to get that speedup; can you post some example code? It's possible that there is some loss of effiicency in using CLOS (generic function dispatch) that could be remedied by declarations or compiler macros. That's beyond my realm of expertise, but I'm willing to dig into it.

Liam