Re: [9fans] GCC/G++: some stress testing

[Paul Lalonde <plalonde@telus.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mar 3, 2008, at 4:49 PM, erik quanstrom wrote:
> really?  to out-predict the cache hardware, you have to have pretty
> complete knowlege of everything running on all cores and be pretty
> good at guessing what will want scheduling next.  not to mention,
> you'd need to keep close tabs on which memory is cachable/wc/etc.

On the flip side, ignoring the cache leads to algorithms whose
working sets can't fit in cache, wasting a considerable amount of
processing to cache misses.  Being able to parameterize your
algorithms to work comfortably in one or two ways of your cache can
bring *huge* performance improvements without dropping to the
traditional assembly.  I'm arguing that being aware of the caches
lets the system better schedule your work because you aren't
preventing it from doing something smart.

>
> aren't these arguments for networked rather than shared memory
> multiprocessors?

Yes.  Although I work for a company that prides itself on its cache
coherence know-how, I'm very much a believer in networked
multiprocessors, even on a chip.   I like Cell better than Opteron,
for example.  They are harder to program up front, however, which
causes difficulties in adoption.  Flip-side, once you've overcome
your startup hurdles the networked model seems to provide more
predictable performance management.

Paul

>
> - erik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFHzLEdpJeHo/Fbu1wRAkNNAKC54Me95evWld4cUlUb0Wd9NXQF7QCfZ9zn
QZ5kn6JLfK3EXocNz+plF4c=
=xSzm
-----END PGP SIGNATURE-----