Re: [Help-gsl] gsl performance

[Sam Mason]

On 7 October 2013 22:02, onefire <address@hidden> wrote:
> Sam Mason wrote:
> "I tried this technique with the ODE solvers in the GSL and it gave me
> about 5% overall performance improvement so I dropped it from my code,
> it was a fiddle to maintain and the user would barely notice the
> difference.  I was doing quite a lot of other things, so maybe if your
> overall time is dominated by malloc/free it may help."
>
> I am not surprised by your results because, contrary to what my previous
> messages might suggest, I think that the main problem is not the allocations
> themselves but memory location. At least for certain problems, the machine
> is just much more efficient at accessing stack memory.

No, all accesses that actually hit RAM (i.e. compiler optimisations
and caches are important) will go at about the same speed.  I've seen
comments like this before from users of Fortran, however it has better
defined semantics that allow a fortran compiler to do more aggressive
optimization than a C compiler could.  This often gives the impression
of differences in speed between the stack and heap, but to the CPU
it's all just  RAM.

I'd recommend benchmarking with a reset, it shouldn't take long and
may help you understand where the CPU is spending its time.  I've just
tried testing your hypothesis above and get statistically
indistinguishable results from the stack and the heap for a variety of
block sizes that will be contained within L1 cache, L2 cache and hit
RAM.

  Sam