Cems/sec slowdown???

[Slatz]

several of my Anandtech teammates and myself are reporting that with the k/n values that we have gotten in the last few days have slowed down the rates significantly...>10% in most cases.

My rates fell from the low 90's a week ago to the low 80's the last few days, even with a higher n.

Any suggestions, explanations or is this happening to everyone

Slatz

[MathGuy]

This happened to me also, but since my rankings didn't drop substantially, I suspect that it is fairly uniform. Don't know the reason, though...

[Stricker]

i notice almost a 20% slow down on one machine but i haven't been able to figure out the slow down on my linux boxen

[Frodo42]

Well my computer has not yet slowed down, on the other hand it is a couble of days since I last recieved a new test.

Perhaps it is because the sieving is falling behind (or at least the file thats included in the version of SB we have)?
I don't fully understand how the sieving works (anyways not the math part of it), just a wild guess ...

[nuutti]

May be client has changed to longer fft lenght because
numbers are longer (?). I think that math code is hand written asm and there is several versions of the code and client choose
right one based on number lenght. System is not optimal, but it is a lot faster than using same code for every lenght.

This is wild guess also.

Nuutti

P.S. SB clien is based on Mersenne95 :
http://www.mersenne.org/source.htm

[Mystwalker]

@Frodo42:

Sieving only eliminates tests, it has no influence on the tests that haven't been sorted out yet and are sent to the SB client.

[jjjjL]

nuutti's "wild guess" is the right one.

same thing happened when we got to this "n" level with k=27653.

the FFT length just doubled so the tests will all run ~10% slower.

-Louie

[Mystwalker]

This also happened 1-2 times before, right?
At least I sometimes had the impression the rate dropped although the n value increased.

[nuutti]

Probably. I guess that fft size changes when number lenght doubles but it can be denser. It just requies more work to code
many different fft sizes.

Nuutti

P.S. Here is some infotmation what fft means(It is a method to multiple big numbers very fast) :http://www.tasam.com/~lrwiman/FAQ-mers

[MAD-ness]

Dang. I came over to say that I realized we were into tests where n was greater than ~2.6 million, but people beat me to it.

BTW, does anyone know at which cross-over the FFT exceeds the 256k L2 of the Tbird and newer Athlon CPUs? If not I will ask the GIMPS guys if they remember the cross-overs that fit into the various levels of L2.

[nuutti]

I made speed test to prime 95 and got following things :
fft lengths are 1792K, 1536K, 1280K, 1024K, 892K, 768K, 640K, 512K, 448K, 384K, 320K, 256K
So this might give some picture about fft length changing frequency.

Yours,

Nuutti

[the weaz]

we've really got to get this cem/s thing fixed. I can handle even stand to look at my stats, it's just painful.