Is Haswell the new i8 or still i7 is in the name.

Discussion in 'CPUs and Overclocking' started by tweakboy, May 25, 2012.

  1. ShintaiDK

    ShintaiDK Lifer

    Joined:
    Apr 22, 2012
    Messages:
    20,395
    Likes Received:
    128
    Nice try, but its you who got caught with your pants down. Try see if you can get out of it.

    You basicly made TSX into something it aint. And now you cant prove your hyped claims.
     
  2. BenchPress

    BenchPress Senior member

    Joined:
    Nov 8, 2011
    Messages:
    392
    Likes Received:
    0
    I've read all of it. Including the spec. Stop making false assumptions.
    Contrary to you I don't need Intel for that; I can explain it in my own words thanks to actually having lots of experience writing multi-threaded software. First of all, there is no such thing as software that can't be multi-threaded. Just create more than one thread, make them do something concurrently, and ta-da you've got yourself a multi-threaded application. Finding something to do in parallel isn't hard. It's the basis of out-of-order execution, and today's CPUs only extract a fraction of the theoretical ILP.

    The real issue is that you need the overhead of synchronizing between threads to be low enough to make it worthwhile. Also, it is prohibitively complex to use non-blocking algorithms and still guarantee correctness. So guess what, TSX addresses such issues!

    If you really want an Intel example, just read one of the links I've provided before: Coarse-grained locks and Transactional Synchronization explained. That's an example of something that previously was very hard to multi-thread and gain good performance from. TSX makes it easy.

    Q.E.D.
     
  3. ShintaiDK

    ShintaiDK Lifer

    Joined:
    Apr 22, 2012
    Messages:
    20,395
    Likes Received:
    128
    You keep refering to hard before and then easier. Singlethreaded got nothing to do with it as you previously claimed.

    Nowhere does Intel say or refer to any benefit for singlethreaded applications. They always refer to already existing multithreaded applications for any benefits. And not only that, they even break it down into specifics:
    And TSX wont magicly turn alot of current code with serialized structure into parallel. Meaning we wont see any change on that area compared to today.

    So really, read the documents again. Because you seem to loop around in some illusion on what TSX will bring.
     
    #53 ShintaiDK, May 26, 2012
    Last edited: May 26, 2012
  4. BenchPress

    BenchPress Senior member

    Joined:
    Nov 8, 2011
    Messages:
    392
    Likes Received:
    0
    I never claimed anything about TSX speeding up single-threaded software as-is. Don't contest things I never said.

    I only claimed that TSX greatly helps to make more software multi-threaded and get good performance out of it. Huge difference.
    And neither do I.
    No, they don't. It doesn't have to be "existing" multi-threaded software. It can also be multi-threaded software that was previously single-threaded.
    What they're saying is that it helps cases that were previously hard if not impossible to multi-thread successfully. Applications where threads don't have to actively share data were already easy to multi-thread!

    What you seem to fail to understand is that a lot of today's single-threaded software isn't single-threaded because it's inherently sequential, but because multi-threading it would add more overhead than what you gain, or because it would just take too much effort. TSX both lowers the overhead and greatly helps reduce the required programming effort. Hence a lot of today's single-threaded software can become multi-threaded in the future.
     
    #54 BenchPress, May 27, 2012
    Last edited: May 27, 2012
  5. Idontcare

    Idontcare Elite Member

    Joined:
    Oct 10, 1999
    Messages:
    21,130
    Likes Received:
    9
    Very wise observation, and its the truth.

    Amdahl nailed the part of the problem that is a limitation of the people writing the software ("can I be clever enough to figure out how to reduce the percentage of serial operations in my code?"; whereas, Almasi and Gottlieb nailed the part where the limitation in scaling comes from hardware limitations that must be addressed by the clever guys designing the chips and the interprocessor communications fabric.

    [​IMG]

    Screw up that last part and you'll actually see a loss in thread scaling (your calcs take longer to compute if you add more cores and threads)

    [​IMG]

    There was a time when Intel totally sucked in this aspect of thread-scaling, but they've addressed the gap (relative to AMD) when they moved away from the FSB topology and brought the memory controller on-die.

    [​IMG]