> In fact the more I think about it, the more it seems like having > a direct way of manipulating L1/L2 caches would be more of a benefit > than a curse at this point. Prefetches are nothing but a patchwork > over the fundamental need for programming memory hierarchy in an > efficient way. But, I guess, there's more to it on the hardware side > than just crafting additional opcodes. >
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. maybe system management mode makes too much of an impression on me. but on an intel system, there's on way to prevent the cpu/bios/ipmi from issuing an smm interrupt anytime it pleases and taking over your hardware. my conclusion is we don't have as much control over the hardware as we think we do. > > 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. aren't these arguments for networked rather than shared memory multiprocessors? - erik
