Msieve not detecting L3 cache

[10metreh]

I've just noticed that msieve doesn't detect the L3 cache on my Core i5. It seems to have only detected the L2:

using block size 10922 for processor cache size 256 kB

I knew that the code used not to be able to detect L3 cache, but I thought that had been fixed. (This is with 1.47.)

[jasonp]

Grrr. The problem is Intel's scheme for reporting cache sizes; basically every new processor that comes out has its own code for its cache size, although the L2 size is also reported in a standard way. That basically means that your cache size detection code has to be updated about once a year to account for new Intel processors.

Edit: OK, fixed in SVN now. It turns out that Intel moved to a more general architecture for reporting cache sizes around last year, and this should hopefully avoid having to touch the code over and over again.

@Brian Gladman: Does MSVC have an intrinsic that runs the CPUID instruction with *both* EAX and ECX specified? The one you used in the current code only specifies EAX, and so the cache size is still misreported when compiling with MSVC.

[R.D. Silverman]

Originally Posted by jasonp

Grrr. The problem is Intel's scheme for reporting cache sizes; basically every new processor that comes out has its own code for its cache size, although the L2 size is also reported in a standard way. That basically means that your cache size detection code has to be updated about once a year to account for new Intel processors.

Edit: OK, fixed in SVN now. It turns out that Intel moved to a more general architecture for reporting cache sizes around last year, and this should hopefully avoid having to touch the code over and over again.

@Brian Gladman: Does MSVC have an intrinsic that runs the CPUID instruction with *both* EAX and ECX specified? The one you used in the current code only specifies EAX, and so the cache size is still misreported when compiling with MSVC.

Actually, a generic, algorithmic solution is possible.

Take a small array. Time how long it takes to fill/empty it. Keep increasing
the size of the array until the fill/empty time jumps suddenly. You've now
exceeded the cache....

[Prime95]

Originally Posted by R.D. Silverman

Keep increasing
the size of the array until the fill/empty time jumps suddenly. You've now exceeded the cache....

...or discovered when some other CPU intensive program has grabbed a time slice.

[R.D. Silverman]

Originally Posted by Prime95

...or discovered when some other CPU intensive program has grabbed a time slice.

Yep. It works only if nothing else is running........

[jasonp]

No matter how complex it is to read the Intel cache codes, that has to be better than figuring out the size dynamically. Look at the source for LMBench if you don't believe me; you need to fool the hardware prefetch mechanism, get timing information that is portable enough and accurate enough (and multiprocessor safe, which the x86 cycle counter is not), then time for long enough to get a robust answer, which is guaranteed to be longer than an entire small QS job takes.

Plus the machine has to be idle :)

[Robert Holmes]

Originally Posted by jasonp

@Brian Gladman: Does MSVC have an intrinsic that runs the CPUID instruction with *both* EAX and ECX specified? The one you used in the current code only specifies EAX, and so the cache size is still misreported when compiling with MSVC.

Yes, __cpuidex.

[Brian Gladman]

Originally Posted by jasonp

Grrr. The problem is Intel's scheme for reporting cache sizes; basically every new processor that comes out has its own code for its cache size, although the L2 size is also reported in a standard way. That basically means that your cache size detection code has to be updated about once a year to account for new Intel processors.

Edit: OK, fixed in SVN now. It turns out that Intel moved to a more general architecture for reporting cache sizes around last year, and this should hopefully avoid having to touch the code over and over again.

@Brian Gladman: Does MSVC have an intrinsic that runs the CPUID instruction with *both* EAX and ECX specified? The one you used in the current code only specifies EAX, and so the cache size is still misreported when compiling with MSVC.

Yes - I have now added it in the SVN version.

Brian

[jasonp]

Thanks everybody.