Announcement

Collapse
No announcement yet.

Intel Core i7 4770K "Haswell" Benchmarks On Ubuntu Linux

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

  • #11
    Do you have performed the benchmark with Hyper-Threading enabled from the BIOS?
    I've read somewhere that applications are not prepared for multiple threads go faster if you have the Hyper-Threading disabled. I think the "gamers" usually disable it.
    Anyway, you could add that to the benchmark to see if there are differences with the Hyper-Threading enabled or disabled.

    Comment


    • #12
      I'm surprised to see that linux had such a relatively wide performance margin. In Windows, the 4770 was almost identical in performance with the 3770, CPU wise anyway. I'm also surprised to see the FX-8350 outperforming the 4770 as often as it did. Good day to be a linux user, where no matter what you spend your money on, it'll be good at SOMETHING.

      Comment


      • #13
        Originally posted by chris200x9 View Post
        it's over intel is finished. Long live AMD!
        What article were you reading?

        Comment


        • #14
          Originally posted by mendieta View Post
          ... but a lot of the humble bundle games will not run (and run instead on my son's $200 intel's chromebook, which makes you wonder).
          Sounds like the issue might just be a feature that defaults to off in radeon but on in the intel driver. Not sure what current state is, but floating point textures and texture compression/s3tc used to be the main areas.
          Test signature

          Comment


          • #15
            Originally posted by schmidtbag View Post
            I'm surprised to see that linux had such a relatively wide performance margin. In Windows, the 4770 was almost identical in performance with the 3770, CPU wise anyway. I'm also surprised to see the FX-8350 outperforming the 4770 as often as it did. Good day to be a linux user, where no matter what you spend your money on, it'll be good at SOMETHING.
            Good day to be a Phoronix reader, is what. This is one impressively useful test suite you've put together, Michael. And a nice selection of HPC codes we don't see much elsewhere. Good to see cross-brand cpu, compiler, temperature, and perf/watt comparisons as well. Shows the bennies of moving voltage regulation on-chip. Really Nice. Thanks.

            Comment


            • #16
              Originally posted by YAFU View Post
              Do you have performed the benchmark with Hyper-Threading enabled from the BIOS?
              I've read somewhere that applications are not prepared for multiple threads go faster if you have the Hyper-Threading disabled. I think the "gamers" usually disable it.
              Anyway, you could add that to the benchmark to see if there are differences with the Hyper-Threading enabled or disabled.
              No the reason some applications go faster is not due to them not being prepared for multiple threads but due to the nature of SMT. Basically the way SMT works is that there are 2 (Can be more in non-Intel implementations) threads queued up in any particular core at any one time, and so when one thread stalls out or sleeps it switches over to the other thread, now this is all nice and fine for workloads that are heavily threaded but are not processor intensive, but it is detrimental in cases where the threads are processor intensive, because instead of just having to wait for it to finish what it's doing now it stalls out and the other thread steps in and it has to wait for that thread to stall out before it can start processing again, thus resulting in a loss of performance.

              It's important to point out that although the front end is currently a massive bottleneck (which will be fixed by steamroller) the Bulldozer architecture and derivs don't have this problem because instead of a processing queue they are doing processing on the threads. That said AMD does have a more interesting problem because of this in terms of how to handle scheduling.

              Comment


              • #17
                Originally posted by Tgui View Post
                What article were you reading?
                The one where an ~8 month old chip beat a 0 day old chip in some tests despite being a hundred and fifty dollars cheaper? Not to mention how many tests where only 20-40% faster when the next amd core is estimated at 30% faster per clock. Also unlike intel AMD is boosting clocks with each generation 5800k vs 8350 vs 6800k

                Comment


                • #18
                  @ Luke_Wolf, thanks for the explanation.
                  ===
                  By the way, would have been nice to have also the comparison of power consumption and heat generation with the FX-8350, in any of the other applications that use intensively the CPU.

                  Comment


                  • #19
                    Originally posted by chris200x9 View Post
                    The one where an ~8 month old chip beat a 0 day old chip in some tests despite being a hundred and fifty dollars cheaper? Not to mention how many tests where only 20-40% faster when the next amd core is estimated at 30% faster per clock. Also unlike intel AMD is boosting clocks with each generation 5800k vs 8350 vs 6800k
                    Yes, AMD has come back considerably lately (which I love to see). But keep in mind that the FX lines doesnt have integrated graphics, so you need to buy some graphic card to have something comparable. Plus, the Intel chip has a lot more OC'ing potential because it has a much saner TDP. In terms of graphics, you need to compare with an amd APU, and those are a lot slower for CPU usage (even the i5's beat them)

                    Cheers!

                    Comment


                    • #20
                      Originally posted by Luke_Wolf View Post
                      No the reason some applications go faster is not due to them not being prepared for multiple threads but due to the nature of SMT. Basically the way SMT works is that there are 2 (Can be more in non-Intel implementations) threads queued up in any particular core at any one time, and so when one thread stalls out or sleeps it switches over to the other thread, now this is all nice and fine for workloads that are heavily threaded but are not processor intensive, but it is detrimental in cases where the threads are processor intensive, because instead of just having to wait for it to finish what it's doing now it stalls out and the other thread steps in and it has to wait for that thread to stall out before it can start processing again, thus resulting in a loss of performance.

                      It's important to point out that although the front end is currently a massive bottleneck (which will be fixed by steamroller) the Bulldozer architecture and derivs don't have this problem because instead of a processing queue they are doing processing on the threads. That said AMD does have a more interesting problem because of this in terms of how to handle scheduling.
                      Wierd. I do scientific heavy threaded stuff and my testing showed 20% performance improvement on core i7 with HT enabled over disabled. And yes it is very cpu heavy and I burn up core i7 laptops (the RAM isn't throttled and causes the hard crash).

                      I am curious how amd's new architecture might handle things but since we're so heavy on double precision I'm not confident we would get good performance. Our software running on core i7 runs circles cpu wise around the pre bulldozer opterons (dual socket sandy-e easily outruns quad socket opteron, about 2x faster on cpu heavy loads).

                      I noticed on other reviews how the 3930k still outruns this new haswell on heavily threaded loads.

                      Comment

                      Working...
                      X