Re: [boost] interest in structure of arrays container?

Subject: Re: [boost] interest in structure of arrays container?
From: Andreas Schäfer (gentryx_at_[hidden])
Date: 2016-10-26 04:23:02

On 22:13 Tue 25 Oct     , Michael Marcin wrote:
> On 10/25/2016 12:22 PM, Larry Evans wrote:
> >
> > Hmmm.  I didn't realize you'd have to run the benchmark
> > several times to get stable results.  I guess that reflect
> > my ignorance of how benchmarks should be run.
> 
> The code was just a quick example hacked up to show large difference 
> between different techniques.
> 
> If you want to compare similar techniques you'll need a more robust 
> benchmark.
> 
> It would be easy to convert it to use:
> https://github.com/google/benchmark
> 
> Which is quite good.

When doing performance measurements you have to take into account the
most common sources of noise:

1. Other processes might eat up CPU time or memory bandwidth.

2. The OS might decide to move your benchmark from one core to
   another, so you're loosing all L1+L2 cache entries. (Solution:
   thread pinning)

3. Thermal conditions and thermal inertia may affect if/when the CPU
   increases its clock speed. (Solution: either disable turbo mode or
   run the benchmark long enough to even out the thermal
   fluctuations.)

AFAIK Google Benchmark doesn't to thread pinning and cannot affect the
turbo mode. LIKWID ( https://github.com/RRZE-HPC/likwid ) can be used
to set clock frequencies and pin threads, and can read the performance
counters of the CPU. Might be a good idea to use both, Google
Benchmark and LIKWID together.

> > Could you explain how running a couple of times achieves
> > stable results (actually, on some occassions, I've run the
> > benchmark and got results completely unexpected, I suspect
> > it was because some application deamon was stealing cycles
> > from the benchmark, leading to the unexpedted results).
> >
> >> Interestingly your SSE code is ~13% faster than the
> >> LibFlatArray code for large particle counts.
> >
> > Actually, the SSE code was the OP's.
> >
> 
> Actually it originates from:
> 
> https://software.intel.com/en-us/articles/creating-a-particle-system-with-streaming-simd-extensions

Ah, thanks for the info.

> > From the above, the LibFlatArray and SSE methods are the
> > fastest.  I'd guess that a new "SoA block SSE" method, which
> > uses the _mm_* methods, would narrow the difference.  I'll
> > try to figure out how to do that.  I notice:
> >
> >   #include <mmintrin.h>
> >
> > doesn't produce a compile error; however, that #include
> > doesn't have the _mm_add_ps used here:
> >
> > https://github.com/cppljevans/soa/blob/master/soa_compare.benchmark.cpp#L621
> >
> >
> > Do you know of some package I could install on my ubuntu OS
> > that makes those SSE functions, such as _mm_add_ps,
> > available?
> >
> > [snip]
> 
> If you're using gcc I think the header <xmmintrin.h>

The header should not depend on the compiler, but on the CPU model. Or
rather: the vector ISA supported by the CPU:

  http://stackoverflow.com/questions/11228855/header-files-for-simd-intrinsics

Cheers
-Andreas

-- 
==========================================================
Andreas Schäfer
HPC and Supercomputing
Institute for Multiscale Simulation
Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
[phone]
PGP/GPG key via keyserver
http://www.libgeodecomp.org
==========================================================
(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!