Slashdot Mirror


Reverse Multithreading CPUs

microbee writes "The register is reporting that AMD is researching a new CPU technology called 'reverse multithreading', which essentially does the opposite of hyperthreading in that it presents multiple cores to the OS as a single-core processor." From the article: "The technology is aimed at the next architecture after K8, according to a purported company mole cited by French-language site x86 Secret. It's well known that two CPUs - whether two separate processors or two cores on the same die - don't generate, clock for clock, double the performance of a single CPU. However, by making the CPU once again appear as a single logical processor, AMD is claimed to believe it may be able to double the single-chip performance with a two-core chip or provide quadruple the performance with a quad-core processor."

11 of 263 comments (clear)

  1. I suggest a compromise by Quaoar · · Score: 5, Funny

    I believe that one and a half cores, sideways-threaded, is the way to go.

    --
    I'll form my OWN solar system! With blackjack! And hookers!
    1. Re:I suggest a compromise by mctk · · Score: 5, Funny

      Of cores!

      --
      Paul Grosfield - the quicker picker upper.
  2. Scheduling Threads by mikeumass · · Score: 5, Insightful

    If the OS scheduler only know about one core, how in the world would it ever know to set two threads in the execute state simultaniously to take advantage of the extra horsepower. This article is lacking any substantial detail.

    1. Re:Scheduling Threads by DerGeist · · Score: 5, Informative
      It's not, you're actually losing parallism here. The idea is to hide the multiple processors from the OS and make it think it is scheduling for only one. The OS is so good at single-processor scheduling that allowing the CPUs to take care of who does what will effect better performance than splitting up the tasks among the processors at the OS level.

      At least that's the idea. Whether or not it works is yet to be seen.

  3. Sounds familiar by Anonymous Coward · · Score: 5, Funny

    Didn't they do this on Star Trek once to get more power or something?

  4. may not want to go back.. yeah right by igotmybfg · · Score: 5, Funny
    However, by the time the technology ships - if it proves real, and ever becomes more than a lab experiment - the software industry will have had several years focusing on multi-threaded apps, and it may not want to go back.

    Hah, yeah right, we started parallel programming just this semester and already I want to kill myself. "May not want to go back"? I'd go back in a heartbeat!

  5. Gotta love these CPU companies... by __aaclcg7560 · · Score: 5, Funny

    First, they get the software industry's licensing panties in a knot because users only want to pay a license fee for one physical chip instead of paying for each processor on the chip. Now, twisting the panties in other direction, they want to reverse all that by representing multiple processors as one virtual processor. Would that be covered by a multi or single processor license agreement? Do I still get free wedgie with that one?

  6. No, superscalar is different by overshoot · · Score: 5, Interesting
    Superscalar refers to having multiple execution paths inside of a single processor, allowing the dispatch of multiple instructions in a single clock cycle. However, the register sets (etc.) maintain a common state (although keeping the out-of-order updates straight sucks a huge amount of complexity and power.)

    In this case, AMD appears to be trying to decouple the states enough that the out-of-order resolution doesn't require micromanaging all of the processes from a single control point.

    --
    Lacking <sarcasm> tags, /. substitutes moderation as "Troll."
    1. Re:No, superscalar is different by RalphTWaP · · Score: 5, Insightful

      What AMD appears to be trying isn't the same as superscalar processing, but it might run into a similar problem.

      Where superscalar requires a good dispatcher to minimize branch prediction misses, AMD appears to be making decisions, not about dispatch, but about how to do locking of shared memory (think critical sections).

      Critical section prediction might prove less expensive than branch prediction in practice even if they are similar in theory (http://www.cs.umd.edu/~pugh/java/memoryModel/Doub leCheckedLocking.html shows the problem, which already is an issue on 64-bit hardware).

  7. Shi's law by G3ckoG33k · · Score: 5, Informative

    From here:

    Researchers in the parallel processing community have been using Amdahl's Law and Gustafson's Law to obtain estimated speedups as measures of parallel program potential. In 1967, Amdahl's Law was used as an argument against massively parallel processing. Since 1988 Gustafson's Law has been used to justify massively parallel processing (MPP). Interestingly, a careful analysis reveals that these two laws are in fact identical. The well publicized arguments were resulted from misunderstandings of the nature of both laws.

    This paper establishes the mathematical equivalence between Amdahl's Law and Gustafson's Law. We also focus on an often neglected prerequisite to applying the Amdahl's Law: the serial and parallel programs must compute the same total number of steps for the same input. There is a class of commonly used algorithms for which this prerequisite is hard to satisfy. For these algorithms, the law can be abused. A simple rule is provided to identify these algorithms.

    We conclude that the use of the "serial percentage" concept in parallel performance evaluation is misleading. It has caused nearly three decades of confusion in the parallel processing community. This confusion disappears when processing times are used in the formulations. Therefore, we suggest that time-based formulations would be the most appropriate for parallel performance evaluation.

  8. Or maybe predicting both branches? by silverdirk · · Score: 5, Interesting
    As one reply stated, you can't know which is right unless you had 3 cores.

    But, with two cores, you could have a way to predict "branch" and "not branch" at every prediction spot. The core that gets it right sends the registers to the other core so they can continue as if every branch were predicted correctly...

    That would only work if you had a nice fast way to copy registers accross in a very small number of clock cycles... so again, just a bunch of speculation. But it was a neat enough idea I had to say it.

    --
    Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.