Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Elmer Phud who wrote (252880)	6/5/2008 3:35:33 PM
From: dougSF30	Respond to of 275872

Yeah, there's that problem as well. Even if that number is actually '3', mas will still be screeching about a larger, slower L2 being better than a smaller, faster L2 together with an L3, no matter the application, no matter the other details of the cache subsystem... at least until all the benchmarks prove him wrong, once again.

To: Elmer Phud who wrote (252880)	6/5/2008 3:43:59 PM
From: mas_	Read Replies (1) \| Respond to of 275872

Intel's slide says L1 cache same as core uArch. Same size. They also didn't advertise Prescott's 4 cycle L1 either ;-). Where do these numbers come from? It was measured using this utility cpuid.com cpuid.com and also already forecast realworldtech.com Nehalem’s L1D cache has retained the same size and associativity (check) as the previous generation, but the latency increased from 3 to 4 cycles to accommodate timing constraints. Each core in Nehalem has a private unified 256KB L2 cache that is 8 way associative and provides extremely fast access to data and instructions. The load to use latency was not precisely disclosed, but Intel architect Ronak Singhal indicated that it was less than 12 cycles. In the best case, i.e. phase aligned operation and frequencies that differ by an integer multiple, Nehalem’s L3 load to use latency is somewhere in the range of 30-40 cycles according to Intel architects.