Announcement

Collapse
No announcement yet.

AMD Ryzen 3 1200 & Ryzen 3 1300X Linux Performance

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

  • AMD Ryzen 3 1200 & Ryzen 3 1300X Linux Performance

    Phoronix: AMD Ryzen 3 1200 & Ryzen 3 1300X Linux Performance

    At the end of July AMD began shipping the Ryzen 3 entry-level Zen processors. While it may not be as exciting as a 16-thread Ryzen 7 or Threadripper, the Ryzen 3 1200 and Ryzen 3 1300X offer surprising value with being quad-core parts priced at just above $100 USD. With Linux users especially craving multi-core systems if running Arch or other distributions where you are frequently compiling your own packages, the Ryzen 3 CPUs can make for a low-cost but practical Linux system. Here are my initial benchmarks of these first two Ryzen 3 processors.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Typos:

    Originally posted by phoronix View Post
    the FX-8350 was an eight-cire part with
    Originally posted by phoronix View Post
    while still having a 125 Watt tDP for the 32nm processor.
    Originally posted by phoronix View Post
    but behind the COre i3 7100.

    Comment


    • #3
      Originally posted by tildearrow View Post
      Typos:




      Whoops, thanks, long day testing...
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        Does this mean that recent games actually use over 4 threads?

        Michael This is a thorough review, once again. Thanks a lot!

        Comment


        • #5
          This article (and future CPU comparisons articles) would be so much easier to read if:

          1) it specified which tests are single threaded and which are multithreaded
          2) it had only comparable CPUs (in price and/or cores configuration) - I'm not sure why Intel 7900X, AMD 1800X, etc. were included - they might have been relevant when comparing gaming performance but not here
          3) if it had a comparison in regard to IPC - e.g. comparing all the CPUs at the same frequency, say 3.5GHz
          4) too many generations of Intel CPUs are not that interesting. I'd have included only Kaby Lake, Sandy Bridge and much less likely Haswell.

          Comment


          • #6
            Originally posted by birdie View Post
            This article (and future CPU comparisons articles) would be so much easier to read if:

            1) it specified which tests are single threaded and which are multithreaded
            2) it had only comparable CPUs (in price and/or cores configuration) - I'm not sure why Intel 7900X, AMD 1800X, etc. were included - they might have been relevant when comparing gaming performance but not here
            3) if it had a comparison in regard to IPC - e.g. comparing all the CPUs at the same frequency, say 3.5GHz
            4) too many generations of Intel CPUs are not that interesting. I'd have included only Kaby Lake, Sandy Bridge and much less likely Haswell.
            1. it generally is specified if looking at pthreads or fopenmp in the build strings on the graphs... If you have a better way to mark it on the graphs or something, patches welcome.

            2. High end CPUs since I already had them tested and shows how well a particular test is possible of scaling or not, and for those weighing what the want.

            3. If only I had unlimited time and resources...
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #7
              The benchmarks in this case happen to be irrelevant to the conclusion. I would very strongly suggest that people do not buy any Ryzen CPUs whether it's a new release or previously released till AMD acknowledges and fixes some rather serious flaws with the CPU architecture regarding long term stability and segfaulting while compiling that eventually causes a complete system crash. A couple of hours of compiling software isn't enough to catch the bug. The bug shows up in Windows, Linux, and FreeBSD and it's been determined to not be a software bug. There is no currently reliable workaround and AMD has been mute on the issue.





              I have a Ryzen 5 1600 on an MSI motherboard and I can confirm that my CPU will do the same thing sooner or later with simply building LLVM/Clang with a full thread load -- in my case I was using make -j 24 and crashed with a segfault with a little less than 90 minutes the first time it happened on Ubuntu 17.04.

              If you want a box to do compiling loads on get an Intel system, at least till AMD actually fixes this major screw up in QA.

              Comment


              • #8
                Originally posted by stormcrow View Post
                If you want a box to do compiling loads on get an Intel system, at least till AMD actually fixes this major screw up in QA.
                I second that, I also have an 1700x that crashes in heavy compilations. If your machine has more than 16Gb , It is easy to reproduce
                under Ubuntu. Just do a

                git clone https://github.com/suaefar/ryzen-test.git

                move to the ryzen-test directory and run ./kill-ryzen.sh It will ask your password to install gcc and run the test. This is a simple script that downloadas gcc 7.1 code an put into a virtual memory drive. It then starts #threads of your processor compilations in parallel. After a while you should get a message like:

                [loop-15] TIME TO FAIL: 88 s

                Which means that one of the compilations segfaulted (in 88s in this case).

                If you are using stock BIOS parameters it should segfault in less than one hour. If you turn off opcache or SMT it may take many hours, but still fails.

                Michael, could you test those processors (or a Ryzen 5 that has SMT so it fails faster)? It would be interesting to know if you can reproduce the problem. The problem seems very prevalent, if you go to Gentoo's wiki on Ryzen and look at the troubleshooting section you will find a datasheet with more than 60 Gentoo users and just by looking at it you can see that at least half of them are having problems with this processor. I am very sorry for AMD. I want it to succeed, but it needs to fix this ASAP. It should start acknowledging the problem in public.

                Comment


                • #9
                  wow! they run great, but what happen with avx? some bug somewhere or just the avx unit in those cpu suck? also i think it will be interesting a comparison bewteen the intel's avx & amd's one with the power consumption of both the platform under load... one little bird had told me the intel one drain a lot...... but maybe is wrong xD

                  Comment


                  • #10
                    wow! they run great, but what happen with avx? some bug somewhere or just the avx unit in those cpu suck?
                    Ryzen has half the FMA throughput per core and clock cycle compared to Intel's current lineup. But that doesn't explain the Himeno results. Even the Pentium G4400, which doesn't have AVX and therefore no FMA, destroys Ryzen in that test. And Ryzen does well in some other FPU-heavy workloads.

                    Still no word from AMD on the compilation segfaults? Guess I'll keep my Phenom II for another year or two then...

                    Just how the hell do they plan on selling their Threadripper and Epyc products when they aren't even capable of what is an everyday task for some potential customers?

                    Comment

                    Working...
                    X