Slashdot Mirror


The Economics of Chips With Many Cores

meanonymous writes "HPCWire reports that a unique marketing model for 'manycore' processors is being proposed by University of Illinois at Urbana-Champaign researchers. The current economic model has customers purchasing systems containing processors that meet the average or worst-case computation needs of their applications. The researchers contend that the increasing number of cores complicates the matching of performance needs and applications and makes the cost of buying idle computing power increasingly prohibitive. They speculate that the customer will typically require fewer cores than are physically on the chip, but may want to use more of them in certain instances. They suggest that chips be developed in a manner that allows users to pay only for the computing power they need rather than the peak computing power that is physically present. By incorporating small pieces of logic into the processor, the vendor can enable and disable individual cores, and they offer five models that allow dynamic adjustment of the chip's available processing power."

30 of 343 comments (clear)

  1. How is this new? by lintux · · Score: 3, Informative

    IIRC this is done in mainframes for *ages* already...

    1. Re:How is this new? by jorenko · · Score: 3, Informative

      Except that they do this because manufacturing chips is not an exact science -- some turn out better than others, and these are able to handle higher clock speeds with less chance of failure and less power usage. Thus, the quality of each individual chip determines its clock speed and its price. While the enthusiast will always be able to increase that with no problem 90% of the time, that's quite a different thing from selling a chip that's supposed to be turned up. These would need to be good enough to handle the heavier usage from any user at all, and fully supported all the while.

  2. Hardware DRM.... by foobsr · · Score: 5, Funny

    In related news, an initiative of car manufacturers spearheaded by Ford has introduced an enabling 'cylinder per need' model. Car performance is wirelessly monitored in real time to give the customer the option to add in additional power according to his needs if he has signed to a plan designed to optimally fit his profile (composed on his overall lifestyle information). This also creates a new exciting opportunity to reduce individual carbon tyreprints for the consumer.

    CC.

    --
    TaijiQuan (Huang, 5 loosenings)
    1. Re:Hardware DRM.... by peas_n_carrots · · Score: 5, Funny

      Those 100-cylinder engines sure are light. After all, the metal necessary to build such an engine would only make up the majority of the weight of the car. Use 10 cylinders to drag around the rest of the 90, now that's efficiency.

    2. Re:Hardware DRM.... by gnasher719 · · Score: 5, Funny

      It's a valid point. Certainly the European car manufacturers have a "gentleman's agreement" to limit their high-end sports cars to a maximum speed of 155mph (around 250km/h). Now, I know that I wouldn't use that kind of power every day, but it would annoy me to know that the car was capable of more but prevented from doing so by an artificial limitation. If I'm paying for a 500bhp car, I want it to run like a 500bhp car... I suppose people like you are the reason for the limitation.
    3. Re:Hardware DRM.... by LWATCDR · · Score: 3, Informative

      Okay even turning off cores that you don't isn't dump. A lot of the time a pc really is just doing nops waiting for you to do something. Powering down cores when they are not needed will save power just like turning off cylinders in an engine...
      What is dumb is this pay me to turn on more cores idea.
      It really goes counter to the idea of of OWNING or BUYING a pc. If I BUY the computer I OWN the computer. I shouldn't have to pay you to unlock some part of the that computer.
      Yes it is going back to the days of the Mainframe and frankly I don't think that is a good idea.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  3. same old as software rental... by k-zed · · Score: 5, Insightful

    I don't want to "rent" the processing power of my own computer, thank you. Nor do I want to "rent" my operating system, or my music, or movies. I buy those things, and I'm free to do with them as I wish.

    Renting your own possessions back to you is the sweetest dream of all hardware, software and "entertainment" manufacturers. Never let them do it.

    --
    we discovered a new way to think.
    1. Re:same old as software rental... by ozmanjusri · · Score: 4, Insightful
      Life just sucks that way

      Microsoft != Life.

      --
      "I've got more toys than Teruhisa Kitahara."
  4. You know what I don't get? by Moraelin · · Score: 3, Interesting

    You know what I still don't get? Why's everyone acting like dividing a CPU into several separate cores is a good thing?

    Let me compare it to, say, a construction company having a number of teams and a number of resources, e.g., vehicles:

    1. One team, 4 vehicles. That's classic single core. Downside, at a given moment it might only need 2 or 3 of those vehicles. (E.g., once you're done digging the foundation, you have a lot less need of the bulldozer.)

    2. Two teams, can pick what they need from a common pool of 4 vehicles. That's classic "hyperthreading". Downside, you're not getting twice the work done. Upside, you still paid only for 4 vehicles, and you're likely to get more out of them.

    3. Two teams, each with 4 vehicles of its own. They can't borrow one from each other. This is "dual core." Downside, now any waste from point 1 is doubled.

    But the one I don't see is, say,

    4. Two teams with a common pool of 8 vehicles. It's got to be more efficient than number 3.

    Basically #4 is the logical extension of hyperthreading, and it seems to me more efficient any way you want to slice it. Even if you add HT to dual-core design, you end up with twice #2 instead of #4 with 4 teams and a common pool. There is no reason why splitting the pool of resources (be it construction vehicles or execution pipelines) should be more efficient than having them all in a larger dynamically-allocated pool.

    So why _are_ we doing that stupidity? Just because AMD at one point couldn't get hyperthreading right and had its marketers convince everyone that worse is better, and up is down?

    --
    A polar bear is a cartesian bear after a coordinate transform.
    1. Re:You know what I don't get? by lintux · · Score: 3, Insightful

      You know what I still don't get? Why's everyone acting like dividing a CPU into several separate cores is a good thing?

      AFAIK adding more MHz was getting more and more complicated, so it was time to try a new trick.

    2. Re:You know what I don't get? by RzUpAnmsCwrds · · Score: 5, Informative

      Your metaphor on multi-issue CPUs is interesting, but not necessarily valid.

      Instruction scheduling is the biggest fundamental problem facing CPUs today. Even the best pipelined design issues only one instruction per clock, per pipeline (excluding things like macro-op fusion which combine multiple logical instructions into a single internal instruction). So we add more pipelines. But more pipelines can only get us so far - it becomes increasingly more difficult to figure out (schedule) which instructions can be executed on which pipeline at what time.

      There are several potential solutions. One is to use a VLIW architecture where the compiler schedules instructions and packs them into bundles which can be executed in parallel. The problem with VLIW is that many scheduling decisions can only occur at runtime. VLIW is also highly dependent on having excellent compilers. All of these problems (among others) plagued Intel's advanced VLIW (they called it "EPIC") architecture, Itanium.

      Another solution is virtual cores, or HyperThreading. HTT uses instructions from another thread (assuming that one is available) to fill pipeline slots that would otherwise be unused. The problem with HTT is that you still need a substantial amount of decoding logic for the other thread, not to mention a more advanced register system (although modern CPUs already have a very advanced register system, particularly on register-starved architectures like x86) and other associated logic. In addition, if you want to get benefits from pipeline stalls (e.g like on the P4), you need even more logic. This means that HTT isn't particularly beneficial unless you have code that results in a large number of data dependencies or branch mispredicts, or if pipeline stalls are particularly expensive.

      Multicore CPUs have come about for one simple reason: we can't figure out what to do with all of the transistors we have. CPUs have become increasingly complex, yet the fabrication technology keeps marching forward, outpacing the design resources that are available. This has manifested itself in two main ways.

      First, designers started adding larger and larger caches to CPUs (caches are easy to design but take up lots of transistors). But after a point, adding more cache doesn't help. The more cache you have, the slower it operates. So designers added a multi-level cache hierarchy. But this too only goes so far - as you add more cache levels, the performance delta between memory and cache decreases, because there's only a finite level of reference locality in code (data structures like linked lists don't help this). You may be able to get a single function in cache, but it's unlikely that you're going to get the whole data set used by a complex program. The net result is that beyond a certain point, adding more cache doesn't do much.

      What do you do when you can't add more cache? You could add more functional units, but then you're constrained by your front-end logic again, which is a far more difficult problem to solve. You could add more front-end logic, which is what HyperThreading does. But that only helps if your functional units are sitting idle a substantial percentage of the time (as they did on the P4).

      So you look at adding both functional units and more front-end logic. You'll decode many instruction streams and try to schedule them on many pipelines. This is what modern GPUs do, and for them, it works quite well. But most general-purpose code is loaded with data dependencies and branches, which makes it very difficult to schedule more than a very few (say, 4) instructions at a time, regardless of how many pipelines you have. So, now, effectively, you have one thread that is predominantly using 4 pipelines, and one that is predominantly using the other 4.

      Wait, though. If one thread is mostly using one set of pipelines, and one is mostly using the other, we can split the pipelines into two groups. Each will take one thread. This way, our register and cache systems are simpler (because

    3. Re:You know what I don't get? by Antity-H · · Score: 3, Insightful

      noone is chump enough to make something totally different that nothing runs on.
      I guess that's why IBM did not develop the cell processor which is therefor not used in PS3s or why no supercomputer is built using it.

      All this also explains why IBM did not develop a new product line of cell based blade servers. And neither are grids being built around cell based servers.

      Of course even if IBM did develop it and sony did use it in the PS3, it would be unable to run anything which is why there isn't any game for the PS3 or why there are not linux distribution for the PS3.

      Sorry, but a different architecture doesn't mean nothing runs on it, nor does it mean noone will develop for it if the promised power is cheap and proficient enough.
  5. Requires a near-monopoly by Ed+Avis · · Score: 5, Insightful

    In mainframes you have pretty much a single vendor (IBM). Even in the days of Amdahl and Hitachi, once you were committed to a single vendor they had a lot of market power over you. So the vendor can set its own price, and squeeze as much money out of each customer as possible by making variable prices that relate to your ability and willingness to pay, rather than to the cost of manufacturing the equipment.

    In a competitive market where 100-core processors cost $100 to produce, a company selling 50-core crippled ones for $101 and 100-core processors for $200 would quickly be pushed out of business by a company making the 100-core processors for $100 and selling them, uncrippled, for $101. I expect the Intel-AMD duopoly leaves Intel some scope to cripple its processors to maintain price differentials (arguably they already do that by selling chips clocked at a lower rate than they are capable of). But they couldn't indulge in this game too much because customers would buy AMD instead (unless AMD agreed to also cripple its multicore chips in the same way, which would probably be illegal collusion).

    Compare software where you have arbitrary limits on the number of seats, incoming connections, or even the maximum file size that can be handled. It costs the vendor nothing more to compile the program with MAX_SEATS = 100 instead of 10, but they charge more for the 'enterprise' version because they can. But only for programs that don't have effective competition willing to give the customer what he wants. Certainly any attempt to apply this kind of crippling to Linux has failed in the market because you can easily change to a different vendor (see Caldera).

    --
    -- Ed Avis ed@membled.com
    1. Re:Requires a near-monopoly by Anonymous Coward · · Score: 3, Insightful

      To be fair to the graphics companies, they sometimes at least did that because of relatively low yields. If you can take a chip that has ten pipes, two of which are faulty, and disable those two faulty pipes, you've effectively created an eight pipe chip for nothing. This reduces the overall cost of producing a single chip, because a partial failure is still usable.

      This is also why Sony used a Cell with only seven SPUs instead of the eight designed on the chip: if a single SPU fails (which is much more likely than none) in test, the chip is still usable. It pushes up yields significantly.

      IOW: you're comparing the wrong business model. The model you're describing is "oh, this chip isn't quite up to spec, let's put it in a lower spec card where it will meet the spec", rather than "let's sell a fully capable chip deliberately crippled, and re-enable the crippled part later if the customer pays for it."

    2. Re:Requires a near-monopoly by ElDuque · · Score: 3, Insightful

      That's a common misconseption there - prices in a competitive market are based on the consumer's willingness to pay, and nothing else. The cost of manufacturing equipment would only come into play in a monopoly situation, where the seller is able to "set" prices (because she will be sure to set them higher than her per-unit production costs.)

      This is the same misconseption people often apply to baseball player salaries - they do NOT drive ticket prices. Baseball ticket prices are set at the highest level the market will bear - a price that is determined as consumers make decisions between countless sources of entertainment and leisure.

      What is confusing is that the quality of a product (and therefore the market demand for it, sometimes) is often related to the cost of production, so it looks like production costs set prices. But remember when Homer designed a car? It was $80,000, and no one wanted to buy it at that price! The consumers decided there were better uses for their car-buying dollars. This is a perfect (although fictional) illustration of why costs != prices in a competitive market.

  6. Do I understand this right? by Dr.+Spork · · Score: 5, Insightful
    TFA is written really badly, but from what I gather, the "more advanced" models of figuring out how much to charge for chips goes like this:

    1. Everybody gets the same chip, but it will be crippled unless you pay the highest price.

    2. Everybody gets the same uncrippled chip, but there's a FLOPS meter on it that phones home, and you pay Intel according to the amount of numbercrunching your chip did for you.

    Both of these models seem completely retarded to me, although the first is already sort of in use in the CPU/GPU market. Have modern processors overshot our needs by so much that our big worry now is to find innovative ways to cripple them? If so, maybe this processor war we're fighting is ultimately not even worth winning.

  7. Calculators by Detritus · · Score: 3, Interesting

    Someone already mentioned mainframes. Something similar is often done with calculators. Rather than design a new chip for each model, they design a single chip with all of the features. In mid-range and low-end models, it is crippled by the design of the keyboard and/or jumpers. It is often cheaper to dumb down a single hardware design than to produce unique designs for each segment of the market.

    --
    Mea navis aericumbens anguillis abundat
  8. Re:Why? by Anne+Thwacks · · Score: 4, Insightful
    Because in reality, it costs $4.99 to make the chip, and $10,000,000 to design it.

    The cost of designing one core is the same as the cost of designing 10 or 100 cores, because copy and paste was invented several years ago. The cost of adding a core to the design is about 1%.

    There might be a case for powering down unused processors to save energy, and there is a case for selling cheaper processors with reduced core counts where some cores don't work, but there is no case for disabling working processeors for economic reasons.

    Sun's Niagra technology differs, cos it has "virtual cores" which gives you more virtual cores but slower. Its very good if you multi-thread (run apache) and p*ss- poor if you dont (run Windows).

    --
    Sent from my ASR33 using ASCII
  9. Re:How is this [business model] new? by ozmanjusri · · Score: 4, Informative
    Why not their economic model?

    Because it's dumb.

    In 1999 I paid about AU$600 for a midrange Pentium Pro CPU. In 2008, I bought a midrange Xeon Dual-core for the massively increased price of... AU$600.

    In 2000, I bought a shiny new Intergraph TDZ2000 with two PII 350s for the bargain cost of just $5,000. Now, Apple is prepared to sell me a Mac Pro with two 2.8GHz, quad core Xeons for the stupefying price of $2,799.00.

    Now, explain to me again why it would be in my best economic interest to buy a computer with cores that could be disabled if I don't pay my rent?

    --
    "I've got more toys than Teruhisa Kitahara."
  10. Re:How is this [business model] new? by argiedot · · Score: 3, Insightful

    Now, explain to me again why it would be in my best economic interest to buy a computer with cores that could be disabled if I don't pay my rent? I suppose because you could just buy the ones with some cores disabled and get someone who knows stuff to enable them again, like the way people did for some of the older nVidia cards that had some things disabled. Or maybe I don't know anything about how the two things work.
  11. STOP TAGGING whatcouldbpossiblygowrong ALREADY by quitte · · Score: 3, Insightful

    really. STOP IT!

  12. Crippleware... by Bert64 · · Score: 4, Insightful

    This is crippleware, and a terrible idea for the average consumer...
    Paying more for a product that costs the same to produce, or potentially even less because they don't have to disable the extra cores is a terrible rip off, and it happens already...

    The same people who currently overclock, will buy the cheaper cpus with cores disabled and re-enable them... You will also get third parties who make a business out of doing the same, tho without the "exceeding design spec" risks of overclocking.

    Personally, I will never pay more for a more expensive version of the same product, i will buy the cheapest available just as soon as people have worked out how to re-enable the disabled cores, and i will help my less technical friends do the same.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  13. Would we know the difference? by SanityInAnarchy · · Score: 5, Informative

    I know that on Linux, I cannot immediately tell the difference between an SMP-enabled kernel on a single-core Hyperthreading system, and an SMP-enabled kernel on a dual-core system with no hyperthreading.

    In either case, I'm fairly sure I see at least two items in /proc/cpuinfo, I need an SMP kernel, etc. So if someone (Intel) suddenly decided to make a dual-core hyperthreaded design in which the "teams" actually shared a common pool, would I notice, short of Intel making an announcement?

    As for your assertion, a quick scan of Wikipedia suggests that you're a bit naively wrong here. (But then, I'm the one pretending to know what I'm talking about from a quick scan of wikipedia; I suppose I'm being naive.) Wikipedia makes a distinction between Instruction level parallelism and Thread level parallelism, with advantages and disadvantages for each.

    One of the advantages of thread-level parallelism is that it's software deciding what can be parallized and how. This is all the threading, locking, message-passing, and general insanity that you have to deal with when writing code to take advantage of more than one CPU. As I understand it, a pipelining processor essentially has to do this work for you, by watching instructions as they come in, and somehow making sure that if instruction A depends on instruction B, they are not executed together. One way of doing this is to delay the entire chain until instruction A finishes. Another is to reorder the instructions.

    But even if you consider this a solved problem, it requires a bit of hardware to solve. I'm guessing at some point, it's easier to just throw more cores at the problem than to try to make each core a more efficient pipeline, just as it's easier to throw more cores at the problem than it is to try to make each core run faster.

    There's also that user-level interface I talked about above. With multicore and no hyperthreading, the OS knows which core is which, and can distribute tasks appropriately -- idle tasks can take up half of one core, the gzip process (or whatever) can take up ALL of another core. With multicore and hyperthreading, the OS might not know -- it might simply see four cores. And with multicore, hyperthreading, and shared pipelines, it gets worse -- as I understand it, there's no longer any way, at that point, that an OS can specify which CPU a particular thread should be sent to. Threading itself may become irrelevant.

    Well, anyway... What confuses me is that we still haven't adopted languages and practices that naturally scale to multiple cores. I'm not talking about complex threading models that make it easy to deadlock -- I'm talking about message-passing systems like Erlang, or wholly-functional systems like Haskell.

    Hint: Erlang programs can easily be ported from single-core to multi-core to a multi-machine cluster. Haskell programs require extra work at the source code level to be made single-threaded, and can (like Make) use an arbitrary number of threads, specifiable at the commandline. They're not perfect, by far; Haskell's garbage collector is single-threaded, I think. But that's an implementation detail; most programs in C and friends, even Perl/Python/Ruby, will not be written with multiple cores in mind, and, in fact, have single-threaded implementations (or stupid things like the GIL).

    --
    Don't thank God, thank a doctor!
  14. Dude... wait, what? by The+Master+Control+P · · Score: 4, Insightful
    So Intel is going to design a CPU with N cores on it, then add hardware that disables half of them, then manufacture the chip with all N cores and sell it for less, even though it actually costs more to design/build because of the added hardware to cripple it, then try and make us pay for access to the other half of the cores and hope we don't notice that our computers have suddenly become a constant expense instead of a one-time purchase?

    And moreover, they apparently forgot which problem they're trying to solve between paragraphs 4 and 5. They start talking about the real problem of many cores creating a very large space of core/memory architectures that would be difficult to choose between and support. Then they veer off into the rent-your-own-hardware-back-to-you idea and never finish reasoning out just how it would work before they come back. A few minor things they ignored:
    • How do they turn cores on? Difficult level: No, you can NOT have a privileged link through my firewall onto my network.
    • How do they stop me from hacking it and enabling it all myself? Difficulty level: Mathematically impossible since you can't stop Eve from listening if Eve and Bob are the same person.
    • How do they propose to bill me? Difficulty: No, I will NOT let my CPU spy on me.
    • Why should I hand you everything you need to force me to upgrade against my will?
    • What happens if you go out of business and leave me stranded?
    • Even if you don't see what's wrong with charging me continually to access my own hardware, do you actually think I won't?
    In conclusion, Profs. Sloan & Kumar of the University of Illinois, I believe the premises and reasoning behind your proposal to be flawed, and the proposal itself to be unworkable and contradictory to openness in computing. Or, as we say on the Internet, wtf r u doin???
  15. Re:How is this [business model] new? by CheShACat · · Score: 3, Funny

    That was my first thought. Then my second thought was having to go through the "Intel Genuine Advantage" activation process every 45 minutes.

  16. Re:How is this [business model] new? by TheThiefMaster · · Score: 3, Informative

    I've done this kind of thing. nVidia 6800LE with half it's shader processors disabled (had 4 blocks of 4, 2 blocks disabled), which could have half of those (1 block of 4) re-enabled without issue. Athlon XP 2500+ that could have the FSB changed to 200MHz instead of 166 and it would BECOME a Athlon XP 3200+ (name and all).
    And the best one: Two Athlon XP 2400+ cpus that I unlocked with a conductive pen to be Athlon MP 2400+s, and I still use in a dual-cpu board now.

    Generally, unlocked or overclocked pc parts burn out faster than if they'd been left alone (e.g. the 6800LE I mentioned died a horrible death, and now doesn't work at all). However if the chip was DESIGNED to be able to be unlocked, it would be perfectly safe.

  17. Re:Why? by Alsee · · Score: 4, Funny

    The cost of designing one core is the same as the cost of designing 10 or 100 cores, because copy and paste was invented several years ago.

    Copy-pasting a hundred cores will cost almost ten times as much as copy-pasting 10 cores because you have to pay the patent holder who invented copy-paste.

    -

    --
    - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
  18. Re:How is this [business model] new? by Anonymous Coward · · Score: 5, Insightful

    Generally, unlocked or overclocked pc parts burn out faster than if they'd been left alone (e.g. the 6800LE I mentioned died a horrible death, and now doesn't work at all). However if the chip was DESIGNED to be able to be unlocked, it would be perfectly safe.

    Design is one. Manufacturing is two. Chip manufacturing is not perfect. It is more likely that the disabled parts failed full test, but that parts were still working (and thus make it sellable as a downgraded chip). All you did was enable the defective parts. And then it blew. No surprise there.

  19. Re:How is this [business model] new? by Anonymous Coward · · Score: 5, Informative

    Having worked at nvidia, there is a reason those extra TPCs were disabled and its not because of a cripple ware model but because of yield. We cannot produce chips that are perfect all the time. So we settle for chips that are perfect a small percentage of the time, mostly perfect an ok percentage of the time, and half working a good percentage of the time. We then make 3 or 4 different series (GS/GT/GTX/GTS/Ultra) with different TPCs in each series, disable the TPCs in each chip that doesn't work or fails to pass QA and then ship them. If you unlock them, you are frying you working card because some of the faults could be things like "Oops, there was a short in the TPC because the transistors cooked too close to each other" or "Oops, the clock passes too close to the +12V in this module -- if it hits 50 Celcius, it could turn into a short". This model helps products from being prohibitively expensive for a fabless company because we are billed on "silicon wafers used" on not on "number of fault free chips produced".

  20. The rent model is flawed because ... by BeanThere · · Score: 3, Informative

    ... for CPUs, there are effectively ZERO variable costs to the producer once you've purchased the chip and it's in your hands.

    Dedicated circuitry to create artificial scarcity and control actually adds unnecessary costs.

    This might be useful in very specific scenarios where somebody, say, owns a supercomputer and rents it out, but even there, I'm sure there are far better solutions that don't involve the CPU hardware.

    This is, like you suggest, just a BS wet dream of the manufacturers ... make something once, get money forever.

    Right now we probably have few enough major chip vendors that with a little bit of collusion, if they decided not to compete, they could probably pull something like this on us. This doesn't look likely right now, but it seems possible. Hopefully some other (possibly foreign) company would enter the market if that happened. Competition is healthy for a market.