Interesting presentation
|
Prev: Multi-core lag for Left 4 Dead 1 and 2 and Quake 4 on AMD X23800+ processor... why ?
Next: Which is the most beautiful and memorable hardware structure in a CPU?
From: nmm1 on 7 Apr 2010 04:28 In article <6unt87-6he.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <4BBC0C0C.8010803(a)patten-glew.net>, >Andy \"Krazy\" Glew <ag-news(a)patten-glew.net> wrote: >>On 4/6/2010 11:18 AM, Robert Myers wrote: >> >>IIRC the payoff for increasing L3 cache much beyond the 2M/core (that we see now) to 16M per core is small. Well into >>diminishing returns. But there will certainly be apps for which incrementally larger cache helps right away, there will >>certainly be a point at which a new working set plateau fits, and certainly software footprint increases over time. > >Do you have references for that? > >I see clear and consistent results from benchmarks on kamailio, asterisk, >apache, linux itself, and various media servers that fitting the working >set of these applications in L3 is essential. > >The number of simultaneous calls in asterisk went from 1400 to 9000 just >by increasing the L3 size from 16M to 72M and doubling the L2 cache sizes. There is an old saying about chickens and eggs. I remember when the same was said about other sizes of cache, memory and bus width. Some applications will make use of larger caches immediately, others will need retuning to do that, and others will see little gain. I see the real benefits in changing direction from the current one, which is extremely complicated and scales badly, to one that is both simpler and scales better. Of course, we wouldn't see those benefits immediately, so the marketdroids would try yo kill it :-( But there just ain't no way that the current approaches can be made to fly as the number of cores per system reaches the hundreds, and single programs start making use of most of those cores. Regards, Nick Maclaren. |