Msieve not detecting L3 cache

10metreh · 2010-10-25, 08:09

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

Code:

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 · 2010-10-25, 10:52

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 · 2010-10-25, 12:30

Quote:

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 · 2010-10-25, 13:08

Quote:

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 · 2010-10-25, 13:10

Quote:

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 · 2010-10-25, 15:57

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 · 2010-10-25, 17:07

Quote:

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 · 2010-10-25, 19:11

Quote:

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 · 2010-10-26, 01:42

Thanks everybody.

2010-10-25, 08:09	#1
10metreh Nov 2008 2·3³·43 Posts	Msieve not detecting L3 cache I've just noticed that msieve doesn't detect the L3 cache on my Core i5. It seems to have only detected the L2: Code: 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.)

2010-10-25, 10:52	#2
jasonp Tribal Bullet Oct 2004 3,541 Posts	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. Last fiddled with by jasonp on 2010-10-25 at 12:21

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Detecting bigInt roots	mathPuzzles	Computer Science & Computational Number Theory	9	2017-07-01 03:35
Problem detecting GPU	VoltsNCodes	Msieve	13	2013-06-14 15:14
8k fft and L2 cache	pman	Information & Answers	1	2012-05-23 14:00
Detecting arithmetic progressions	grandpascorpion	Math	18	2007-03-28 15:08
L3 cache. What could it buy us?	nomadicus	Hardware	3	2003-08-09 22:23

2010-10-25, 15:57	#6
jasonp Tribal Bullet Oct 2004 3,541 Posts	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 :)

2010-10-26, 01:42	#9
jasonp Tribal Bullet Oct 2004 3,541 Posts	Thanks everybody.