Slashdot Mirror


Ars Technica on Hyperthreading

radiokills writes "Ars Technica has a highly-informative technical paper up on Hyper-Threading. It's a technical overview of how simultaneous multithreading works, and what problems it will introduce. It also explains why comparing the technology to SMP is Apples to Oranges, in a sense. Starting with the 3 GHz Pentium 4, this tech will be standard in Intel's desktop lines (it's already in the Xeon), so this is important stuff."

11 of 235 comments (clear)

  1. "It's already in the Xeon" by Theatetus · · Score: 4, Insightful

    Yes, but since no one has a supersentient compiler and assembler like ht requires, very few programs are able to really take advantage of this.

    I dig innovation. I dig more impressive chips. But it's getting to the point where boxes with top of the line CPUs are like those old VWs with Porsche engines in them: there comes a point when improving one part doesn't really matter any more.

    --
    All's true that is mistrusted
    1. Re:"It's already in the Xeon" by be-fan · · Score: 4, Insightful

      Um, HT doesn't require supersentient compilers, it requires mildly sentient developers. Namely, developers have to make their programs multithreaded. In the Windows world, this happens already, far less so in the Linux world. Speaking of supersentient compilers, Intel C++ 6.0 supports OpenMP, even on Linux.

      --
      A deep unwavering belief is a sure sign you're missing something...
    2. Re:"It's already in the Xeon" by Anonymous Coward · · Score: 2, Insightful

      > Well, not if you actually understand Computer Science.

      I disagree. I will not be able to get you see the thing from my side, but let's state a few of thing:

      1/ I know computer science.
      2/ I wrote multi-threaded apps. Hell, I even wrote an IP stack and a B-Tree base transactional system. Those worked.
      3/ I painfully debugged other people multi-threaded race conditions that only occurs twice a day on a heavily loaded server.
      4/ I saw my co-workers writing bad multi-threaded code
      5/ I maintained code I wrote for years, so I know the cost of the mistakes and complex features
      6/ I now reject most designs that contains multiple threads.

      > You can either do it, or you shouldn't be trying.

      Most software is written by youngsters that did not realize that they should not be trying to write multi-threaded code. See the swing source code for instance. It is a pathetical mess of code made by (mostly) clueless coders that thought they were smart.

      I am not saying that I cannot write multi-threaded app, or that you cannot write one. I was arguing that the original poster, the Be Fan, was deadly wrong when he said that multi-threaded apps were easy, that "Namely, developers have to make their programs multithreaded."

      And that moderators that gave him that +5 never debugged production multi-threaded code.

      Cheers,

      --fred

    3. Re:"It's already in the Xeon" by spitzak · · Score: 5, Insightful
      I would agree with the rest of the responders here that you have no idea what you are talking about.

      A correct multithreaded program is HARD!!!!! Anybody who thinks otherwise is an idiot. I have seen the results. All the systems I have seen are either broken or have so many locks in them that they may as well be single-threaded. Most Windows programmers use multithreading so that they can keep more state in local variables, which may be an ok goal but has nothing to do with speed. One of biggest buggiest programs here is a multh-threaded monstrosity written by a Windows program where there are 50 threads, ALL WAITING ON THE SAME SOCKET, and it crashes sparodically in the rare cases when two threads actually become alive at the same time. Every single rewrite to reduce the number of threads has greatly improved performance and reliability.

      I have no idea why you think GUI should be multi-threaded. GUI has no reason to be fast, computers are MUCH faster than humans, at least at drawing junk on the screen. In fact the best way to do it is pseudo-multithreading, such as the method windows uses (gasp! Fact alert: it is NOT multithreaded, only one "DispatchMessage" is running at a time!).

      I think perhaps you mean that the GUI should be running in a parallel thread with the calculations and there you have a point, however a lot of the problems are solved by deferred redraw, which the X toolkits do quite well (and in fact Windows is broken because it produes WM_PAINT events without knowing if the program has more processing to do).

      Now if there are intense calculations I grant that parallel threads are necessary, and I am working on such a program, but I must warn you that it is extremely difficult: the GUI cannot modify ANY structure being used by the parallel thread, instead it must kill the threads, wait for them to stop, modify the structure, and start them again. If in fact nothing changed you need to restart so the partially-completed answer from last time can be reused, this means you must write all the code you would for a single-threaded appliation, it does NOT save you anything. If you restart the complete parallel calculation you will get an unresponsive program if that parallel calculation takes more than a second or so. You could instead do a fancy test to see if your modifications will change the data before you kill the threads and commit them, but this often requires you to calculate the modifications twice, and the overhead of this may well kill the advantage of the parallel thread, and at least in my example this was far worse than reusing all the single-threaded restart code.

    4. Re:"It's already in the Xeon" by juggy · · Score: 2, Insightful

      I have no idea why you think GUI should be multi-threaded. GUI has no reason to be fast

      Yes, it does: If you multithread it, you can e.g. show debug output, update controls and enable the user to still use the GUI. In many unix-apps your gui sort of freezes while the processes/threads are running in the background (doxygen had/still has this problem, if I remember correctly).

      the GUI cannot modify ANY structure being used by the parallel thread, instead it must kill the threads, wait for them to stop, modify the structure, and start them again

      This is not correct. It only happens when you don't know how to correctly implement a threading model, e.g. if you use journal-based threads instead of log-based you won't have any of those problems whatsoever. For example, the folks using Scheme48 implemented this, and it made a lot of their problems just vanish.

  2. SYMMETRIC Multi Threading by keytoe · · Score: 5, Insightful

    They call this stuff Symmetric Multi Threading, but I think that name is a bit misleading. While the thread scheduling itself is symmetric (all process threads are created equal and receive equal execution time), the shared resources on the CPU (cache, shared registers) are NOT symmetric. Since these shared resources are in essence handled on the way in to the execution unit, it becomes really easy to starve the processor when you have contention for one of those resources.

    While proper application development can alleviate some of this issue, it will depend heavily on the actual usage patterns of the system. When you have a lot of overlap coming in from memory (like the file system cache on a web server), you don't worry too much about threads stepping on each others' registers. This sounds fantastic for data servers.

    Desktop systems, on the other hand, almost never work this way. When you're playing MP3s in the background while web surfing and checking your email, you're already working with vastly different areas of data. Throw the OS and any various background processes into the mix and you've pretty much eliminated any gain and possibly slowed down due to cache contention.

    While this was touched on at the end of the article, I don't think it was given enough weight. It doesn't just depend on what applications you're running and wether they were written to take advantage of it. It depends on what you want to do with the whole system. For serving data, this will certainly be good (especially with multiple CPUs!). For desktop systems, this is a non-starter.

    I'm not disparaging the technology - far from it. I'm just waiting for Intel and Microsoft to market this to my mom as a way to have higher quality DVD playback - at twice the cost. And her buying it. Again.

  3. Re:Hyperthreading on Windows by nick-less · · Score: 2, Insightful


    2) the lame part is that you have to pay to not have to pay for your logical processors. linux doesn't have these lisensing issues.


    yep - it might be lame to force people to buy new licenses, but hey we're free to run other operating systems and I'm sure any real microsoft zealot upgrades to .NET server years before he get's his first desktop Xeon ;-)

  4. Re:Oracle, W2K Enterprise by Anonymous Coward · · Score: 1, Insightful
    http://kerneltrap.org/node.php?id=391

    It's not 2.4, but it gives you an idea about how things work.

  5. Re:AMD by Anonymous+DWord · · Score: 3, Insightful

    From http://www.hardocp.com/article.html?art=MzEw :

    As Barton and MP were mentioned, I did think to ask what [Richard Heye, AMD Vice President of Platform Engineering and Infrastructure and the Computation Products Group] thought about the threat of Intel's Hypertheading. While I see Hyperthreading as possibly becoming a very useful add-on for the Intel CPU, I can assure you that Richard Heye does not. In fact, the subject of Hyperthreading seemed to excite him. Mr. Heye explained that he had been reading papers on the subject for years and that for Intel to bring Hyperthreading to market successfully, they (Intel) were going to have to throw many more dollars at the marketing side than the development side of the issue.

    --
    "If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
  6. Re:Oracle, W2K Enterprise by Perdo · · Score: 3, Insightful

    How many processor licenses does Oracle charge for a Power4, which is literally 4 PPC processors on a single die? What about a clustering approach that presents a server farm as a single virtual CPU?

    So many technologies can interfere with processor count that Oracle and Microsoft are using whatever is a best case scenario for them. If licensing is by physical silicon only, future iterations of multi-processing on die will really hamper software provides profitability - something you know they will not stand for.

    If it was exclusively per CPU, you would also see a lot of shops always buying the absolute fastest processors available, and specialty shops selling factory over clocks of those processors. Reduced licensing costs would actually make the price of exotic cooling methods and reduced cpu life look good.

    Same rule applies to Co-location in a different way. How much power can you stuff into 1u of rack space?

    If the most costly machine you can buy is a 48 CPU machine that can fit into 3u using Quad processors cards on a back plane but costs less in the long term because you are not paying for 24u of rack space that dual processor 1u machines would take, you buy it. Even if your per cpu cost is 10 times the cost of more conventional systems, the machine pays for itself in rack space costs in 10 months. After 18 months you upgrade the machine because by then you are paying twice as much for per cpu licenses as you could be paying with modern hardware.

    Note to businesses: Upgrade now while prices are depressed, and interest rates are low. Sticking with your old hardware is costing you in the long term.

    Take out a loan and upgrade. If your hardware is over 18 months old, you can cut your licensing costs in half. Don't sit on hardware when you are just waiting for it to break.

    IT is not a static business. Do not keep your hardware until it has no resale value. Do not keep your hardware until you are paying twice as much for licenses as you could be paying. Do not balk at high up front costs if it saves you 10 times it's upfront cost due to licensing/rack space costs. Do not keep old machines that are costing you three times as much in electricity at a given performance level.

    Do a real cost analysis, put in the time. This is the perfect time to upgrade. Competition has never been more fierce for the dollars you have to spend. You will get more value for your dollar now than you ever have been able to.

    IT is crap as capital. It has no value in three years. Keep you IT expenditures dynamic to avoid riding your capital investment into the ground. Playing the depreciation tax game will not save you nearly as much as keeping old hardware costs you in other areas.

    Disclaimer: I am not invested in any IT infrastructure provider and I do not do IT consulting. I just have to run my own shop like the rest of you.

    --

    If voting were effective, it would be illegal by now.

  7. Re:SMP performance by Anonymous Coward · · Score: 1, Insightful

    did you read the article?

    applications have to be specifically programmed to take advantage of SMT. Apps that are not (i can imagine most apps for freebsd are not) will suffer from performance degredation. Now, go read the article, its very well written and is deserving of your time.