Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 76

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

  1. #11
    Join Date
    Apr 2009
    Posts
    108

    Default

    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.

  2. #12
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,209

    Default

    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.

  3. #13
    Join Date
    Aug 2008
    Posts
    220

    Default

    Quote Originally Posted by chris200x9 View Post
    it's over intel is finished. Long live AMD!
    What article were you reading?

  4. #14
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote 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.

  5. #15
    Join Date
    Jun 2006
    Location
    Denver
    Posts
    54

    Default

    Quote 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.

  6. #16
    Join Date
    Jun 2011
    Posts
    835

    Default

    Quote 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.

  7. #17

    Default

    Quote 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

  8. #18
    Join Date
    Apr 2009
    Posts
    108

    Default

    @ 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.

  9. #19
    Join Date
    Apr 2009
    Posts
    519

    Default

    Quote 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!

  10. #20
    Join Date
    Mar 2008
    Posts
    205

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •