Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Be careful if you use that code on a 32-bit system. That
    Code:
    i * i
    multiply would overflow because 1e7 (10,000,000) * 1e7 is 1e14, well over the 2.1e9 signed int32_t limit.

    Comment


    • #22
      Originally posted by Raka555 View Post

      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:

      Code:
      $ time ./prime_gcc
      664580
      
      real    0m8.030s
      user    0m8.030s
      sys     0m0.000s
      Last edited by birdie; 02-08-2020, 06:18 PM.

      Comment


      • #23
        Originally posted by Raka555 View Post

        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"

        Code:
        #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.

        Comment


        • #24
          Originally posted by atomsymbol View Post
          Maybe the compiler should be more clever and use floating-point division if it produces an exact result when dividing integers.
          Merge requests accepted.

          Comment


          • #25
            Originally posted by Zan Lynx View Post
            Be careful if you use that code on a 32-bit system. That
            Code:
            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

            Comment


            • #26
              Originally posted by Zucca View Post
              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

              Comment


              • #27
                Originally posted by atomsymbol View Post

                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.

                Comment


                • #28
                  Originally posted by atomsymbol View Post

                  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.

                  Comment


                  • #29
                    Originally posted by Raka555 View Post

                    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.

                    Comment


                    • #30
                      Originally posted by Zan Lynx View Post

                      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.

                      Comment

                      Working...
                      X