By: none (none.delete@this.none.com), August 10, 2012 6:06 am
Room: Moderated Discussions
Eric (eric.kjellen.delete@this.gmail.com) on August 9, 2012 5:32 pm wrote:
[...]
> But doesn't
> this just mean that reducing memory latency has diminishing returns if memory
> bandwidth isn't also increased, which tends to be the case with advancing memory
> technology (and CPU caches, internal buses etc.) anyway? That is to say, is it
> really a problem that forces us to re-think memory technology or just a matter
> of naturally balancing latency and bandwidth improvements to existing memory
> subsystem models?
IMHO getting higher bandwidth often is easier than reducing latency: just increase bus width. OK it's not that easy as there has to be some tradeoffs: going too wide might impact latency; you'll also need more buffers; place and route will be harder; etc.
IIRC I measured a single core of my i7-920 fetching data from memory at about 16 GB/s (more cores increased that number, it looks like a single core can't saturate the memory controller and the 3 memory channels). Assuming it's running at about 3 GHz that means 5 bytes/cycle which I think is enough for many tasks. That's the reason why even if synthetic benchmarks show big increases with faster memories (both latency and bandwidth) the impact on application performance is not extremely important. (See this for example: http://www.bit-tech.net/hardware/memory/2011/01/11/the-best-memory-for-sandy-bridge/8.)
Note this perhaps only demonstrates how efficient Intel memory subsystem (from L1 down to memory controller) is :)
Of course some charges need huge bandwidth. Also using multiple cores that run threads with larger than "usual" cache miss rates might hit a bandwidth wall.
I guess this doesn't directly answer your question, I just wanted to point out that it looks like memory bandwidth is already very good on recent Intel CPUs, so a completely new memory technology wouldn't make our typical workload necessarily much faster.
Here is an article dealing with latency and bandwidth impact on some scientific applications: www.sandia.gov/~rcmurph/doc/latency.pdf
[...]
> But doesn't
> this just mean that reducing memory latency has diminishing returns if memory
> bandwidth isn't also increased, which tends to be the case with advancing memory
> technology (and CPU caches, internal buses etc.) anyway? That is to say, is it
> really a problem that forces us to re-think memory technology or just a matter
> of naturally balancing latency and bandwidth improvements to existing memory
> subsystem models?
IMHO getting higher bandwidth often is easier than reducing latency: just increase bus width. OK it's not that easy as there has to be some tradeoffs: going too wide might impact latency; you'll also need more buffers; place and route will be harder; etc.
IIRC I measured a single core of my i7-920 fetching data from memory at about 16 GB/s (more cores increased that number, it looks like a single core can't saturate the memory controller and the 3 memory channels). Assuming it's running at about 3 GHz that means 5 bytes/cycle which I think is enough for many tasks. That's the reason why even if synthetic benchmarks show big increases with faster memories (both latency and bandwidth) the impact on application performance is not extremely important. (See this for example: http://www.bit-tech.net/hardware/memory/2011/01/11/the-best-memory-for-sandy-bridge/8.)
Note this perhaps only demonstrates how efficient Intel memory subsystem (from L1 down to memory controller) is :)
Of course some charges need huge bandwidth. Also using multiple cores that run threads with larger than "usual" cache miss rates might hit a bandwidth wall.
I guess this doesn't directly answer your question, I just wanted to point out that it looks like memory bandwidth is already very good on recent Intel CPUs, so a completely new memory technology wouldn't make our typical workload necessarily much faster.
Here is an article dealing with latency and bandwidth impact on some scientific applications: www.sandia.gov/~rcmurph/doc/latency.pdf
