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

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

CSP doesn't scale very well to hundreds of simultaneously executing threads (my claim, not, as far as I've found yet, anyone else's). It is very well suited to a small number of threads that need to communicate, and as a model of concurrency for tasks with few points of contact. For performance, the channel locks become a bottleneck as the number of cores scale up. As far as expressiveness, there are still issues with composability and correctness as the number of threads interacting increases. Yes, you at least get local stacks, but the work seems to get exponentially harder as the number of systems in the simulation (um, game engine) increases.

By shared cache I mean any number of caches that are kept coherent at the hardware level without serializing instructions.

Programming the memory hierarchy is really a specific instance of programming for masking latency. This goes well beyond inserting prefetches in an optimization stage, presenting itself as problem decompositions that keep the current working set in cache (at L3, L2, or L1 granularity, depending), while simultaneously avoiding having multiple processors chewing on the same data (which leads to vast amounts of cache synchronization bus traffic). Successful algorithms in this space work on small bundles of data that either get flushed back to memory uncached (to keep more cache for streaming in), or in small bundles that can be passed from compute kernel to compute kernel cheaply. Having language structures to help with these decompositions and caching decisions is a great help - that's one of the reasons why functional programming keeps rearing its head in this space. Without aliasing and global (serializing) state it's much easier to analyze the program and chose how to break up the computation into kernels that can be streamed, pipelined, or otherwise separated to allow better cache utilization and parallelism.

Currently, the best performing programs I know for exploiting the memory hierarchy are C and C++ programs written in a "kernel composition" kind of model that the language supports poorly. You can do it, but it feels more like coding in assembly than like expressing your algorithms. Much of the template metaprogramming is about taking measures of cache spaces and data sets and turning out code (statically) tuned to those sizes. There's a huge opportunity for a JIT language to allow better adaptability to changing data sets and numbers of active threads.

Paul

On 2-Mar-08, at 10:59 AM, erik quanstrom wrote:


Almost certainly. And so is C. Programming many-core shared-cache
machines in languages with global state and aliasing is just plain
wrong, in the same way that programming in assembly instead of C is
wrong. Add a highly heterogeneous real-time task mix on top of that,
and you're in for a world of poor cache performance and deadlocks,
which could be avoided by better choices of implementation language.

i don't understand this argument. are you saying that csp doesn't work
in c? or are you saying that csp has caching problems that some other
languages solve?

also, could you define what you mean by "shared cache" a bit more.
would you consider an intel quad core cpu to be a "shared cache"
machine, since the two l2 caches sit on the same fsb?

Programming for the memory hierarchy is way more important than
optimizing CPU clocks anymore (though that winds up still having a
place in some compute kernels). I wish our programming languages
reflected that change in perspective.

what do you mean by "programming for the memory heirarchy"?

- erik


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

iD8DBQFHyw9XpJeHo/Fbu1wRAgNJAJ9pCFh0kixsaCir2fGKXBZhXTXsDQCfROva
LKnBfk+TaRKNrih36OBexbA=
=Mhdg
-----END PGP SIGNATURE-----
.

Relevant Pages

  • Re: C++ pushback
    ... Haskell is an excellent language, but it is not a system programming ... Kernel programming does not fit well into the functional model. ... a lot of functions/methods have identical names. ...
    (Linux-Kernel)
  • Re: [9fans] GCC/G++: some stress testing
    ... programming for masking latency. ... amounts of cache synchronization bus traffic). ... otherwise separated to allow better cache utilization and parallelism. ... language for what seems to be an embarrassingly parallel problem. ...
    (comp.os.plan9)
  • Re: forth and virtual memory
    ... Using a file-backed memory area and relying on the kernel and ... part which handles the MMU tries to do smart ... in which not only the RAM is used as a cache over the ... programming did not wait for him to get the point. ...
    (comp.lang.forth)
  • Re: OOP Language for OS Development
    ... > Effectiveness on System Programming, ... > 2) Which OOP language would be better for OS development? ... What is your point against using C++ in the kernel? ... for a lot more compiler bugs and compiles are usually slower. ...
    (comp.lang.cpp)
  • Re: forth and virtual memory
    ... Using a file-backed memory area and relying on the kernel and ... part which handles the MMU tries to do smart ... in which not only the RAM is used as a cache over the ... programming did not wait for him to get the point. ...
    (comp.lang.forth)