CPUs From 2004 Against AMD's New 64-Core Threadripper 3990X + Tests Against FX-9590

[Zan Lynx]

Be careful if you use that code on a 32-bit system. That

i * i

multiply would overflow because 1e7 (10,000,000) * 1e7 is 1e14, well over the 2.1e9 signed int32_t limit.

[birdie]

I repeated it several times.
Even my 4600u intel laptop is faster than the 3700x with this.

You can check for yourself:

What are your numbers? Here on Ryzen 7 3700X:

$ time ./prime_gcc
664580

real    0m8.030s
user    0m8.030s
sys     0m0.000s

[atomsymbol]

I repeated it several times.
Even my 4600u intel laptop is faster than the 3700x with this.

You can check for yourself:
Compile with "gcc -O3 prime.c -o prime_gcc"

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>

//
// https://stackoverflow.com/questions/37513311/prime-number-generator-in-c
//

bool IsPrime(int test)
{
// i <= sqrt(test)
// but to avoid sqrt you can do i * i <= test
for(int i= 2; i * i <= test; i++){
if(test%i==0){
return false;
}
}
return true;
}

int main()
{
int count=0;
for (int i=1;i<1000*1000*10;++i) {
if (IsPrime(i)) {
count++;
}
}
printf("%d\n",count);
}

Yes, you are right. But by using floating-point division the performance of this code on Ryzen improves by a factor of 4 (from IPC=0.5 to IPC=1.94).

Maybe the compiler should be more clever and use floating-point division if it produces an exact result when dividing integers.

[programmerjake]

Maybe the compiler should be more clever and use floating-point division if it produces an exact result when dividing integers.

Merge requests accepted.

[atomsymbol]

Be careful if you use that code on a 32-bit system. That

i * i

multiply would overflow because 1e7 (10,000,000) * 1e7 is 1e14, well over the 2.1e9 signed int32_t limit.

Some notes:

• The multiplication almost never overflows in this case because the loop terminates due to (i*i <= test), where "test" is an int and "i" increases by 1 per loop iteration
• The C/C++ type int is 32-bit even on 64-bit systems

[kenjo]

Ouch.
My FX-8350 now seems quite a slow CPU... :|

Its not actually. remember that you paid about 200USD for that CPU. if you spend the same amount of money today you get a cpu that is about 80-90% faster on single threaded tasks and about 120-130% on multi threaded. So in 7-8 years for the same money you dont even get a CPU that is twice as fast on most tasks

[Zan Lynx]

Some notes:

• The multiplication almost never overflows in this case because the loop terminates due to (i*i <= test), where "test" is an int and "i" increases by 1 per loop iteration
• The C/C++ type int is 32-bit even on 64-bit systems

Automatic integer promotion rules happen, I think. I'm almost sure I've seen the multiply happen in 64-bits and then compare against a 64 bit register value even if it's an int. Because otherwise the compiler would have to output lame assembly to truncate the result, and there's a reason int overflow is undefined. Especially on uarch like PowerPC. I'll have to compile this one and look at the machine code I guess.

[Zan Lynx]

Some notes:

• The multiplication almost never overflows in this case because the loop terminates due to (i*i <= test), where "test" is an int and "i" increases by 1 per loop iteration
• The C/C++ type int is 32-bit even on 64-bit systems

Oh and sorry, you are correct about the comparison. It will exit the loop before it overflows. But that multiply did jump out at me.

[smitty3268]

I repeated it several times.
Even my 4600u intel laptop is faster than the 3700x with this.

You can check for yourself:
Compile with "gcc -O3 prime.c -o prime_gcc"

It's worth pointing out that such a simple calculation could be parallelized trivially, so AMD's core-count lead over Intel should be considered when looking at these results.

However, it's safe to say that integer division isn't a strong suit for AMD's current architecture. I think most non-trivial number crunching applications are a lot smarter about how they do that kind of thing and would be using AVX(2/512) instead.

[Zan Lynx]

Automatic integer promotion rules happen, I think. I'm almost sure I've seen the multiply happen in 64-bits and then compare against a 64 bit register value even if it's an int. Because otherwise the compiler would have to output lame assembly to truncate the result, and there's a reason int overflow is undefined. Especially on uarch like PowerPC. I'll have to compile this one and look at the machine code I guess.

Oh well, I was wrong. I guess the C Committee at some point decided integer promotion had gone on long enough and it was a bad idea, so it stops at int. Everything gets promoted to int but not to long. And multiplication is truncated to its operand types even though it really ought to promote to the double-length type if available. No wonder this area is such a minefield of security problems. I just always assume it's doing something weird.