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."
IIRC this is done in mainframes for *ages* already...
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)
This should lead itself to a whole new form of hacking - buy the 10 core system and tweak it to use all 100
Well mainframe technology does migrate down. Why not their economic model?
I've been looking for a new web host recently, and I'm consistently attracted to ones based on the Virtual Private Server concept -- your own box within another box. The multicore economics argument is definitely tied in here, where we can balance demand not just within our own enterprise, but between different consumers of computing time.
Beyond that, I don't really get it... if I have a certain computational workload X, I'd probably prefer to use more cores temporarily rather than pace the work longer over a smaller number of cores. Can they really make the cost incentives enough to fight that? They're really trying to change the model from paying for hardware to paying for cycles, but it's not clear why that should imply a time factor.
--
Get your code outside the computer! Microcontroller kits for the digital generation.
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.
So, Intel is going to charge us less for a processor with 4 cores because we can turn three off most of the time? Or is the power saving supposed to make the cost of the chip less prohibitive?
.99 cents per minute every time you turn another core on.
Maybe it'll be a subscription service, 9.99 per month and
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.
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
First of all, most people buy low to mid-range CPUs and other goods, and while this may be enough to cover the production costs, the manufacturers' largest profits are on the high end CPUs, cars, watches, etc. Currently the increased price tag is justified to some extent by the increased quality, performance and even status given by the high end goods. But under the proposed model, there would be no physical difference between the CPUs, other than artificial limitations imposed by the manufacturer. Suddenly the increased price would be seen not as a result of a better product, but of greed.
Which brings me to the next point. If there are no physical differences, what would stop someone from removing them? Intel has a long history of shipping higher spec CPUs underclocked so not to swamp the market with fast CPUs. And yet in all cases people found ways to overclock them. The major factor that prevented many from doing so was the uncertainty of whether their CPU could handle the increased speeds or not. But when KNOWING they are identical?
And how would the manufacturer upgrade or downgrade the CPU? Yet another Windows Genuine (dis)Advantage?
If one could make a 5 core processor for the price of $300 and be able to sell it with 5 cores enabled to a customer for $600. Why would he sell the same unit for $400 with only 2 cores enabled?
Wouldn't he profit more if he could sell the 5 core processors all at $600 and make a separate 2 core processor for the price of $200 and sell it for $400?
Well if they're going to rent it (as some of TFA said), it would make sense but if they're not, then it would be a profit not maximized.
WTF was that?!
In theory it makes sense and some of you might point at mainframes as an example. However that would like comparing cars to trucks (real trucks not big cars), they are both vehicles and a company might use both but their usage is totally different.
PC's just ain't upgraded, either they are good enough or they are replaced. I love building my own computer but am not as crazy as to replace the CPU whenever a new clockspeed comes out and this means that even a self-builder will often have to bite the bullet and just replace everything.
Be honest, how often in business do you upgrade your desktops by replacing the CPU?
We can test this easily, in the era of the P3 a lot of office systems were DUAL ready, so that when your needs increased you could ad another P3 and have lots more power. How many of you did that with a P3 that had been in the office for more then a year?
This scheme seems like overthinking the problem. PC's in my experience either last until they die and by that time it cheaper to buy new then upgrade/repair, or they are simply replaced with the latest shining model because tech moves so fast that upgrading just the CPU will turn everything else into a bottle neck. Just check how many different types of memory we have had over the years. Would you really want a quad core on your IDE-33 motherboard? Play DVD's on a single speed cd-rom?
Either you need all the cores now, or by the time you activate them because your apps need them everything else will need to be upgraded too and a brand new CPU will be available that is far better AND cheaper.
But in a way we have had this solution for a long time now, but instead of activating extra cores when paid for, chipmakers instead sell defective chips for a reduced price so your still got a 4 core inside your machine but only 2 actually function (not sure wether this happens with entire cores but it is offcourse the case with cache memory).
I don't see this happening, especially if you consider that an army of nerds would be trying their best to break the enabling code to get their extra cores for free, just see what happened with the "dual" P2 and cheapo P3's, Intel would have a heart attack.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
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.
All I can see is another fight between hackers and chip makers to "unlock" the chips.
Well, yes, obviously. But that's not what I was asking. My question was _not_ "why don't they stick to the MHz race?"
What I'm saying is: ok, so now they have to expand in width, so to speak, instead of in MHz. Fine. But why is (A) two separated sets of, say, 3 pipelines better (B) than a set of 6 with two execution units, allocated dynamically? It's still 8 pipelines, only the second one can be dynamically allocated with better results. If one particular thread could use 4 while another used only 2, solution A results in wasted cycles, solution B does not.
A polar bear is a cartesian bear after a coordinate transform.
Will it work with Linux?
Seriously though, how will this be managed, how will this tie in with open source business models. If anyone can see the source code of the program "managing" this, anybody can open up whatever cores they need.
I can't see this working.
Seven Days with Ubuntu Unity
CPU economics are all about yields. They will design a chip, say with 8 cores. Some of the cores might have manufacturing problems so they disable them. The chips with all 8 working cores cost more while the chips with 4 or 6 working cores cost less.
Back in the "olden" days of two years ago the same would happen but with clock speed. The chips that could clock higher without problems got sold as the 1800+ while ones that failed under testing at higher frequencies would get sold as 1600+.
Chips use so much power that if all circuits were enabled for any given period of time the whole chip would fry. We already disable/undervolt quite a lot. There are chips out there already where entire cores get shut off.
----
Go canucks, habs, and sens!
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
Can we add 'nigger' and 'gnaa' to the lameness filter? while we're at it any link that redirects to myminicity?
This business model is dead meat to me. I think that the market will continue to offer processors classified on the maximum data processing rate and pricing them accordingly. I don't see a future for this Processor Restriction Managment nor for the career of the guy who wrote the article in the first place. Suggestion: after he's been dumped from University don't get him as datacenter manager.
And when your software is licensed per processor at (let's say) $100 per cpu, your extra, unwanted, 50 processors quickly become a burden. I'd be willing to pay more for a crippled processor if it saved me money elsewhere, and there was no way to slice up domains to reduce the liability
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
1) Sell your super high power 20 cores CPU uncrippled.
2) Make a platform where researchers can rent CPU power.
3) Allow your customers to rent their unused CPU power/cores.
4) Charge double what you give to your customers to the researchers.
5) Profit! (From both the sale and the rental afterwards).
And there is no ?...
No, everything _you_ answered was irrelevant, because you don't even seem to understand the question. You just repeat the marketing line without even understanding what was asked.
Yes, we need to do more things in parallel. That much is clear, Captain Obvious. The question is how we do that the most efficiently, with the same amount of silicon.
The question was, yes, if other CPU architectures and designs could still do those background tasks, but make better use of the same number of transistors. Or does going in such details go so far over your head as to not even make sense?
So, heh, yeah. I'll answer with your own question: why are _you_ on Slashdot? I mean, seriously, if thinking deeper than repeating the marketing line isn't your thing, shouldn't you be more at home on some other sites?
A polar bear is a cartesian bear after a coordinate transform.
Rediculousness. Besides which, it's a no-brainer that it'd be a zero-day hack to enable all the available processing power on a given chip.
IMHO, this should be illegal. Compete in improving, not crippling.
So, what would happen if the Microsoft DRM update management and monitoring "feature" has a "bug" and hits 100% utilization as it tries to verify the authenticity and my right to possess my entire music collection... do i have to pay a processor tax for that? What about a runtime condition? An app locks up and hits 100% utilization until it is killed. OOPS, I need to ante up for the Tflop tax. Or when I file my annual procmon return I cna apply for earned op/sec credit, filing as head of household...
I'm not about to pay a tax on other peoples poorly written software.
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
It just won't work.
Why don't you shut the fuck up. Noone cares what you think about Slashdot trolls, and your racist, juvenile take on racism is embarrassing.
This morning a manufacturer of toilets presented their new SecureProtect(tm) flushing technology. The new toilet range, sold at a 20% discount to toilets that lack SecureProtect(tm), will contain a level of flushing power that is enabled by default. For the occasion where the user is experiencing additional load, the user may swipe a credit card through the SecureProtect(tm) slot and double or even triple (by choice) the flushing power available.
I've never understood how customers really benefits from a model of produce x-core productand sell it as x-y cores, especially as we all know that they never sell any type of the product below what it actually costs to produce, so at minimum you're paying for what it cost them to make the product anyway, and at maximum, you're paying for having the product locked in some arbitrarily stupid way.
When you're already profiting from making the product at the lowest tier.. with highest tier capability already in it...
If you people were guessing:
1) Create a single production line for your product making it cheap and affordable
2) add in arbitrary, stupid lock-in to increase perceived value of an unlocked product
3) Profit!
I'll never buy anything sold with this model, it's stupid and meaningless.
K.
Well, yes, that's what I was getting at.
Sure, each HT pseudo-core still has a decoder. So does a separate core. So IMHO 2x cores with 2x decoders and 4x pipelines each, should really be roughly the same amount of silicon as 1x core with 4x decoders and 8x pipelines each. It's still a total of 4 decoders, 4 register files, and 8 pipelines, right? The question is whether we could make better use of those in other ways than splitting it down the middle.
If one thread is mostly using one set of pipelines and the other is mostly using the other, yes. But IMHO:
A) "mostly" doesn't mean all the time. If only 5% of the time one core could use one extra pipeline, while the other is idle, you'd still see slightly better speed out of a shared design.
B) That's already assuming you'll know exactly how many pipelines will each thread ever need. Unless you're also writing all the software for that CPU, that seems a bit less clear.
Point in case, look at all the CPUs with 2 or 4 cores _and_ 2 decoders per core. Are you sure that the two decoders on core 1 combined will never ever need an extra pipeline, while core 2 has one that's currently stalling?
But, really, I'd buy the argument if they didn't also pack HT on those cores. Once they went that route, it tells me that they're already not entirely sure how that 1 decoder will always need exactly X pipelines. Never more, never less.
That said, though, ok, I'll concede the point about simplicity. I can see how a multi-core design would be simpler.
A polar bear is a cartesian bear after a coordinate transform.
really. STOP IT!
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!
Search on google for "Intel" and "Larrabee" if you need to know slightly more. Rumors have floated around for almost two years now about that project, with a release date estimated to 2009 or so.
Also, if you need a job in the multicore business, check out http://www.intel.com/jobs/careers/visualcomputing/
In short, visual computing (read gaming) will use all those cores mentioned in the article, word processing will not. Be so sure.
.
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.
/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?
In either case, I'm fairly sure I see at least two items in
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!
that future is most certainly now. It's been here for a while.
Parallel processing is not some weird dream, way off in the future, that lots of people here on slashdot think it is. It's a reality and it's here now.
In fact it's been with us since the 70s in the form of multi-process software.
Multithreading has some idiots running scared ("It's so *hard*!" being their favourite lie), but it's been with us for quite some time. I've been writing multi threaded server and workstation software for about 8 years now and I'm not any sort of pioneer.
The fact that GAMES currently don't usually have threads is not in any way the same thing. And even a game benefitss from being able to run on one of the cores whilst the whole OS (and anything else running) gets shipped off to the other.
While I'll concede the point that Intel's first implementation was flawed, you can't judge and damn a technology for all eternity just by its first implementation. In the meantime even Intel's competitors (e.g., Sun) are implementing it, so it can't be that horribly worse than nothing.
Plus, then by the same kind of historical reasoning we should have said goodbye a long time ago to such stuff as:
- any kind of computing or calculating machines. After all, Babbage tried pawning off that idea to the market, and his implementation was never even finished.
- heavier than air airplanes. The first attempts with kites and bird wings were an outright disaster. We should have buried that idea right there and then.
- using rockets for space travel. There was this medieval Chinese dude who tried it first, with completely disastrous results.
- breech loaded guns. The first attempts had _major_ problems with sealing the barrel, because of poor tolerances.
- cavalry. It just wasn't that horribly good before it successively also got a good saddle, horseshoes, stirrups, and specially bred horses. There's a reason why the Romans created their empire with elite infantry, and the cavalry was just some specialized auxiliary.
- in fact, even earlier, we shouldn't have had even chariots. I mean, until someone invented a harness that allowed horses to pull one, it was pretty much useless. We know that the Sumerians tried using oxen there, and it couldn't have been that horribly effective. Should have discarded that idea right there and then.
- agriculture. Until the right plants, irrigation and cats became available, it was very much a losing proposition wherever it was tried.
Etc, etc, etc.
A polar bear is a cartesian bear after a coordinate transform.
Use FOSS, and tell them where to stick their core tax.
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???Well, yes, the thing about thread level parallelism vs instruction level parallelism is very insightful and true, but it only says why we're leaving case #1 behind. Cases #2, #3 and #4 all had thread level parallelism.
As for the languages, good question. I guess because it's cheaper to use existing skills and libraries than to port everything to Erlang? No real idea, though. I'm sure someone is better qualified than me to answer that.
A polar bear is a cartesian bear after a coordinate transform.
-1 Car analogy
Will it automatically up/down grade our Microsoft licenses and make the proper deductions from our bank accounts too? Microsofts accounting staff would love that feature!
Also in Unix/Linux Pseries and AS/400 Iseries servers. It is called Capacity On Demand :) CoD
I'm actually looking forward to when articles on ./ will simply be tagged "whatcouldpossiblygowrong" and nothing else.
Just need to find a guy able to unlock such CPU's for $30
With regards to multi-core processors in conjunction with video editing work, we've discovered that it's a waste of money having two x quad core processors on a motherboard.
Given that you need about 1GB of RAM to make efficient use of a core, a maximum of 4GB on a Win32 machine means that you're only going to use 4 cores properly at most. Anything else has been a waste of money.
Another nickel-and-dime strategy! Those work very well in the hardware market because, you know, hardware isn't just an end to a means, like software.
Sort of, as many other people have said, about overclocking and such, its not necesarily a scam, it makes things more cost effective for the company and can benefit the consumer who would take the effort to overclock. Lets say Intel (or AMD, doesnt matter, they both do it) does a run of chips. The specs call for the chip to run at, for simplicities sake, 2Ghz, with stock AMD cooling. But no manufacturing process is perfect, and lets say 25% of the chips arent good enough to run at 2ghz without frying. They then clock these chips to 1.5Ghz and sell them as such. This allows them to do a smaller run of specced 1.5Ghz chips and save themselves money. Its not really a scam, theyve been doing this forever, and arent the only industry to do it either. In this case, the consumer can benifit. Someone can buy a 1.5Ghz chip (although they might have to exchange it till they get one of the ones from the 2Ghz production run), and most of the time it'll run fine at the 2Ghz speed with improved cooling.
"Sic Semper Tyrannosaurus Rex."
IBM's been doing this for years with some of their smaller servers http://www-03.ibm.com/systems/i/hardware/cod/index.html/
... much easier sale. Or remember the "performance" of Amazon's servers last Christmas when they put up their special sale items? If they could have just paid for a 24-hr keycode to enter the night you can bet the IT guys would have had a much easier time getting that in the budget.
The cost in IT labor and lost productivity during the downtime that old methods need to add processing capacity can be a *lot* for servers hosting your important applications but its awfully expensive to pay upfront for enough power to keep up with ordering spikes during the Christmas buying season (for example) if that spikes way beyond your normal needs. Much cheaper to pay for only enough to handle your normal needs and then pay for the extra needed to handle oddball spikes only during the time you need it.
There's no way Ticketmaster's IT budget would agree to pre-pay for enough computing capacity to not bog down when the Hannah Montana tickets went on sale but if they could pay for just an hour of it
Or as IBM puts it:
"Imagine you launch a dynamite new Web application for the holiday season, and it's getting more traffic than you expected. What do you do to avoid disruptions in service? You turn on available inactive processors and memory to handle every hit, then turn the extra capacity off when the application requires less capacity in the new year. You pay only for what you have activated.
Or say you tell your business analysts they now have access to all the company's business intelligence data. The danger is that, with your current processor configuration, increased demand could slow response times to a crawl. The solution? You activate reserve processing power to meet the new user demands without disrupting current operations."
The other beauty is that once the computer manufacturer has built in the ability to activate or inactivate processors and memory on the fly those same mechanisms make it natural to shuffle processors and memory between virtualized servers on the machine without restarting them.
And yes, it runs Linux.
Somebody please tag this 'theibmmainframechargingmodel'.
${YEAR+1} is going to be the year of Linux on the desktop!
Steven Pinker has a pretty good article in the NYTimes about moral instincts. By one method of hamming the hog, there are five core instincts: Harm, fairness, community (or group loyalty), authority and purity.
http://www.nytimes.com/2008/01/13/magazine/13Psychology-t.html
Unfortunately, he leaves out gratification entitlement, which is a shame, since without the archetype of Darth Diggler, you can't even explain most children's cartoons.
they will solve all our problems as has been shown time and time again.
As the island of our knowledge grows, so does the shore of our ignorance.
Why not just go the whole hog, and sell people more cores than they actually need, then let them use BOINC-style software to rent out their otherwise unused CPU power to other people? Surely with our current technology in terms of the Internet and encryption, it should be relatively safe to farm out certain CPU intensive tasks to strangers and pay them for the privilege of using their processing power, as long as protocols and software exist to avoid the obvious security risks to both parties.
This is the greatest opportunity for vendors and consumers to finally have robust systems. Couple specific functions to a core or cores such that for instance all security, encryption and housekeeping functions, all patch management and all other back office requirements are bound to a core to allow them to run flat out all the time. This would require changes to an OS to partition those functions and run them essentially in their own OS image.
Of course we all know that in application there will be all sorts of issues and problems. ......
From teh core hackers to laws making it illegal to hack your cpu to then embedded spyware tosystem filure on serious systems due to accidently lock out to
And all this for what? A way for the CPU manufacture to control how much of something you own, can you use.
Wouldn't that be sweet?
If you mod this up, your slashdot background will turn into a beautiful sunset!
This is just mean-spiritedness on the manufacturers' part. If you can sell a multicore chip for a certain amount of money and still make a profit, turning off some of the cores is just ..... mean.
Je fume. Tu fumes. Nous fûmes!
This sounds a lot like all the flavors they offer Windows in. You can pony up extra cash to activate the extra cores. What's next, a Core 2 'Ultimate' CPU? This could work for game consoles as well. Buy some points cards and apply them towards more CPU speed and increase your framerates.
... for CPUs, there are effectively ZERO variable costs to the producer once you've purchased the chip and it's in your hands.
... make something once, get money forever.
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
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.
http://en.wikipedia.org/wiki/Multi-Displacement_System
a unique marketing model for 'manycore' processors
Nothing UNIQUE about this strategy. It's a model growing in popularity. Traditionally companies that wanted to capture several levels of market would make several models of a unit. Like buying a laptop with a better graphics chip or bus speed etc. This cost them more because they had to produce three different units which triples costs on some of their overheads. What this is doing is allowing them to produce one high end product, and configure it easily, post-production, to any of the three units they want to market. The same capabilities are present in all models, but features are disabled/crippled/nerfed in the less expensive models. This allows them to sell their product in the lower cost market without losing sales in their high end market, and without the additional expense of producing several different models.
It's a good idea for the manufacturer, but introduces the problem of what happens when the consumer figures out how to "enable" disabled features in their low end model? This always results in a little war of sorts, where the manufacturer takes steps to make de-nerfing difficult or impossible. It always aggravates the consumer to find out that after he conceded to buying the model that didn't do everything he wanted it to due to cost, CAN do it, it just refuses to. The consumer feels cheated that he payed for a gadget that CAN do what he wants it to, but can't take advantage of it.
Interestingly, it doesn't become a problem until the consumer realizes the product that they were obviously happy to pay the small amount for can do more than they bargained for. The producer would argue that you didn't pay what they were asking for those additional features and so you should not feel cheated, and that you agreed to the advertised feature set when you purchased the product.
The consumer then will try to modify the product to restore the disabled features, and can get upset if it's not possible or is made deliberately difficult.
As much as it causes aggravation in the consumer (that'd be ME) I think it's not a bad idea. What it all boils down to is you can't complain about a product being capable of performing beyond the advertised and accepted expectations at the time you purchased it. You agreed to buy it Just because it's done on purpose does not change the situation. If it CAN do more than advertised and claimed, and you can make it do that, good for you. If you can't, then too bad.
In the end, this DOES result in slightly higher cost for the low end model, because the cost of production (or development) of the low end product is higher than it would have been, if the company had only been making the low end model, and that money ends up in the pockets of the manufacturers who shave overhead on production. So from that point of view it's not a good thing for the consumer, but not for the reason they are seeing.
I work for the Department of Redundancy Department.
Indeed, because CPUs for mainframes were sereriously expensive, it would make sense to do "capacity on demand" or "dynamic domain reconfiguration" (The current marketing names for the "Limited Up/Downgrade model".
In fact, however, adding cores is seriously cheap: Azul sells 48-core Java offload engines, Sun has 8-core chips, and everybody credible has two.
That means buying excess capacity is easy and inexpensive, so one can trivially size for your highest spikes
--dave
davecb@spamcop.net
Considering how fast memory becomes cheaper, any respectable workstation will soon come with 8 GByte or more. At that point, Win32 will be unsuitable to use all of the system resources. Which leaves you with three options to make full use of your new machine:
;-)
-XP 64 bit: reportedly far from perfect, and might disappear from the market soon.
-Vista 64 bit: For all its faults, probably your best bet if you want to stay with Microsoft. But I still don't like it...
-Linux 64 bit: mmmh, yes
C - the footgun of programming languages
I suppose with a thermal diode used as a thermostat you could do something like this. I had to do some temperature measurements a few years back with 350 MHz PPC VME processor bards used in realtime systems to see what the worst case scenario was when all the fans in the crate were off. I was only able to get almost but not quite 1 C/min and that was in a crate where the boards were horizontal and when I was using the CPU, memory, and IO to maximize the heat generated. I could see a chip that does something like that to let you run more cores for short burst of time. (The PPCs could shut-off unused parts of the die, just cut-off clock and since it is CMOS virtually no power used heat generated and you could dynamically change the clock multiplier so you don't even need to use multiple cores.) You could have firmware in the chip that also ties the thermostat to a bus cycle counter to prevent people simply using the less expensive models with better cooling.
But I am unsure how this would really make sense economically.
I've been buying 2-socket, 8-core servers for use with VMware ESX server for more than a year now. I can tell you that while everything on the system benefits hugely from 8 cores vs. 4, it can be hard to predict how much you can really throw at a box. What I'd really like to save is power - build in the hooks for an OS to take cores or an entire socket off-line to cut back on power use even more. The HP servers we're using do some dynamic power saving (an 8-core, 10-12 virtual machines, 16Gb of RAM server uses barely 80 watts more power on average during a day than a single, standalone 4-core server running Windows or Linux), but I'd like to do better. By the way, I just replaced an older DL380 G4 - a dual 3.6 ghz Xeon with 8GB of RAM - with a DL380 G3 with dual quad-core 3ghz processors and 32GB of RAM. For the same amount of money, not adjusting for inflation. That's essentially 8x the server for the same amount of money.
Actually it's not necessarily so dumb. Modern engines are often massively overpowered than what they actually need to be to simply move the vehicle(even loaded) down the road at 75 mph. Worse yet, a steady cruise at 40 or even through a neighborhood at 25 mph.
There are certain fuel ranges where a cylinder is more efficient - on some larger engines you end up injecting a non-optimal amount of air-gas because there just isn't enough demand, especially at lower speeds.
Of course, the same arguement can be said for CPUs. Why would a user buy a chip 'license' for 2 of the 4 cores on the CPU, knowing that he'll have to spend MORE money to get the other 2 activated(discounting hacking to activate them without paying). From the business side, you now have activation sales, tracking, and support to worry about. Not to mention extra engineering to enable that model, worries about people hacking it, etc...
I don't read AC A human right
This assumes that chips are not a commodity. Commodity prices are usually determined by the cost to the seller. (Non-commodity prices are usually determined by the value to the buyer.)
That's not to say supply/demand don't determine prices -- they do. But the supply of a commodity goes up, driving the price down towards the lowest-cost producer.
Read the paper instead, it's linked from the TFA (here).
I don't like their proposed models. I wouldn't buy crippled hardware.
I instead propose another model.
In my model the customer would buy non-crippled hardware and use all of its cores. But at the time of the purchase seller and purchaser would sign a contract indicating that the seller would have to buy the hardware back from the buyer at a pre-agreed price if the buyer so wished after two or three years, as long as the hardware is within acceptable working condition. Then the original seller would make further money by reselling the hardware to other consumers, perhaps in developing countries, perhaps without a buy-back contract.
Or, the contract could indicate that instead of reselling the hardware the buyer could swap it for new hardware.
In fact right now that's what is happening. People in developed countries buy shiny new hardware. They sell it on eBay after a year or two. Others buy it and do the same, until the hardware reaches developing countries.
There is however much administrative overhead in managing sales through eBay etc. If the original seller (the shop or the manufacturer) could assume these overheads, I as a customer would be willing to pay some more. In that way I would retain ownership of my hardware, with all its cores, and the option to keep it forever, but if I wanted I would have the right to exercise the contract's provision and sell it back to the original seller for a preagreed price within certain time limits and acceptable hardware conditions (or I could sell it for a market price depending on the contract).
So, instead of me assuming all the administrative overhead of selling my old hardware away, the original seller where I purchased it from would do it.
This has been done already by IBM in pSeries and mainframe. You buy a system with more cores than you need, activate a portion for regular use and you can either activate the remainder on a timed rental basis or permanent activate. Where is the news here?
In the early 90s, Intel marketing had a similar idea involving "renting" the floating point processor; each CPU would come with (say) a billion ops, with cryptographically protected fuses to open up more blocks. You'd pay for software that would blow the fuses and give you more ops, if you ran out.
Stupid idea (even if it was implementable, which I doubt).
And then Quake came along, and suddenly people were using floating point ops for things other than spreadsheets...
Any sufficiently advanced technology is insufficiently documented.
http://www-03.ibm.com/servers/eserver/about/cod/about/types.html
Dear Sirs with your kind indulgence, as I am not from Nigeria I have difficulty comprehending this exciting new economic model. Allow me to outline how this would work, as far as I can tell, and please correct my misapprehensions. (Step 1) Invest several billion dollars in researching, developing, and tooling for the production of a manycore chip. [Analogy] Develop a completely new, superbly engineered high-performance sports car. (Step 2) Massively subsidize the first few production cycles of this chip in order to penetrate the PC market. [Analogy] Hire someone from Enron to write your shareholder reports. (Step 3) Develop the personnel resources necessary to collect a small amount of revenue from each of the millions of owners of your chip as it runs at a tiny fraction of its capacity, most of the time. [Analogy] Use your incredible new sports car as a 50 cent fun ride for the very timid at the local fair. A million times over. By mail. Provide free (a 45 penny value) postage. Rev the engine every so often to scare small children. (Step 4) ? ? ? [plus a gnome shrugging.] [Analogy] The invisible hand of the market playing a complicated etude by Chopin. Without a piano. (Step 5) BIG PROFITS ! ! ! ! [Analogy] Just like Enron! What *is* Step 4? Does one introduce a run-time system built around a Java interpreter written in BASIC, or does one sit back and let the the slow, insidious malice of an economic model that actually *rewards* the computer industry (as a whole) for the production of inefficient and deficient software do its work?
Yeah, there are vehicles that already adjust the number of cylinders on demand. One of them is a large domestic SUV. The advertising slogan is something like "Eight cylinders when you need them. Four when you don't."
The benefit to the vehicle owner is lower fuel costs, not an economic model to transmit his cylinder utilization to the manufacturer for a reduction in his vehicle loan payments. That'd just be silly.
If you want a car with less power, you opt for a smaller engine. If you want a single-core processor with less power, you opt for a slower clock speed. The processor you buy might be manufactured alongside the ones sold at higher speeds, but it failed testing or was intentionally crippled to maintain a distinction between high-end and low-end.
Sometimes it's easier for the manufacturer to make everything the same and then cripple or add on to create different classes. Suppose Initech developed a screaming-fast processor that they could sell for servers at $90,000 a piece. It also happens to cost only $90 to manufacturer. They could have priced them at $100 and sold 100 times as many for desktops, but the loss of profit in the server market would make it a loss. So instead they chop off 90% of the cores or reduce the clock speed by 90% on the processors destined for desktops. It's cheaper for Initech than to manufacture a second low-performance design and even the crippled processors are a better buy than the competition. It's economically wise and perfectly moral.
The tricky part with manycore processors is that halving the clock speed is usually more crippling than halving the number of cores. But it all depends on how well the software parallelizes. It could make sense to sell the somecore processors at a discount, and then three years later when the customer is thinking about buying new machines say "We could double the performance of your existing hardware for half the cost."
It might have been dumb of the customer to buy the crippled processors in the first place, but if a competitor can offer uncrippled processors for the same price then the customer won't make that mistake. And sometimes making half of a capital investment now and half later is a good business plan.
That's all rather irrelevant, though, since changing the internal scheduling doesn't need a different set of instructions, as seen from the outside. The exact same programs would still run on that machine, with or without SMT.
In fact, here's more food for thought there:
- the internal architecture of an x86 CPU already changed several times. Like, for example, when it replaced the thoroughly-CISC 8086 design with a rather RISC-like pipeline in the IIRC Pentium Pro and AMD K-5. (Or was it K6?) The architecture of a Core Duo or Athlon 64 nowadays doesn't even vaguely resemble that of an original 8086, but they still run the same programs.
- since it's already an extension of SMT, you may notice that Intel's adding SMT in the P4 didn't break existing programs. Whether it's one core, two cores, or two decoders on one core, the instruction set for the outside world is exactly the same.
But the even more damning detail is:
- the 64 bit extensions _already_ rewrote the whole freakin' instruction set, and nobody moaned about that. So, yes, someone came with some crazy new shit, and guess what? It wasn't the end of the world. Someone was already chump enough to double the number of general purpose registers, for example.
So, heh... what can I say? Try reading at least the wikipedia pages about how a CPU works before going into snarky answers about what's "crazy shit". The lost art about sarcasm and arrogance is that it generally helps if you're actually right. Being snarky just because you're too fucking stupid to understand the question, or what it's _real_ effects would be... is just stupid. Sorry. The only "crazy shit" there is between your ears.
A polar bear is a cartesian bear after a coordinate transform.
People with unused cores can just sign up with SETI@Home or Folding@Home, or join some math team to factor large numbers or whatever. AMD/Intel/IBM should talk this up. If people buy into it, chipmakers get full price for their parts up front, and get good PR to boot. If the software to enable easy and reliable *sandboxed* remote computation improves fast enough, there may even be a market for selling unused capacity (micro payments for work units completed).
as a consumer, the whole notion that the thing I paid good money for includes the purchase of compnents whose only purpose is to artificially cripple the rest abhors me.
Really, if any of you think the practice of crippling a product to lower it's retail price is not common, you must have lived under a rock for many, many years. What do you think cost the most: Developing or manufacturing? Developing of course. Create a superb circuit board for a HDTV, with support for a flavors of connectors and converters. Consumers want both high price/functions and low price/function HDTV, for all budgets. What costs the least: Developing a new board without all the extra flavoring? No. Just take the same marvelous board, and rip off the extra connectors, put a IF in the firmware code, replace the costly decoder chip with a placeholder one. And sell it cheap. You see it in cars with the small plastic pieces where you could have taken the ventilation option, in TVs with the small flat piece where higher priced ones have a connector... In friggin toothpaste where they are all the same except for the price! Take a clue, crippling is not only common, it's mandatory.
Bah.
I didn't RTFA, but one justification I can see for having disabled cores on a chip is redundancy. If you manufacture a chip that has 120 cores, you can have 20 fail testing and still sell a 100 core chip. If more than 100 survive testing, disable the others and keep them as spares that can be automatically activated if cores fail after the chip is in use.
to me it sounds like buying a car that has a V-8 but since I only paid the V-6 price I missing 2 cylinders.
I wish I was clever!
This model would force me to claim chapter 7 considering I need infinite CPU power.
in practice, the more cores you put on a chip the more likely one of the cores is going to fail during the QA stage. companies have mitigated this by, for example Sun and the niagara processor, selling chips with a variety of cores. in other words, you can buy an 8-core niagara, or for a lot less, a 6-core version. both chips go through the exact same manufacturing process, but even these billion dollar fab-labs are prone to problems. therefore, it makes the most economic sense to tailor the product line to the very expensive manufacturing process and maximize production, thereby ultimately lowering individual chip costs.
Erm, yeah, I'll take the single core please, I'll just need it to get to the Internet and download a single, probably quite small file, thanks.
The idea of decreasing yield and increasing die size for something that's arguably worse than the status quo is pretty dumb, but the key is this sentence:
When tens or hundreds of cores are the norm, practical considerations will limit the number of unique designs to a very small subset of possible core layouts.
What the authors are saying is that in the future, when there may be hundreds of possible chip configurations, it will no longer be cost effective to individually design enough variations to cover the whole market, and that a more general approach will be needed. I don't know if their assumptions about core count or market coverage are valid, but it's not as stupid an idea as people are making it out to be.
While renting a CPU has a lot of problems, permanent and temporary upgrades may not. Make the upgrade interface write-only and use one-time pads determined at manufacturing time for the keys, and you've got something that would be very hard to crack and wouldn't require any surveillance hardware. Of course, that does add yet more cost overhead...
Visit the
Eh, I don't think it necessarily makes the low end model more expensive. If a company makes only one model then all of the overhead is borne by that model. If they also make a high end model then the overhead can be shared. Even if the total overhead goes up due to complexity, the portion on the low end could go down due to sharing.
When I worked at [a major, recently reported litigious auto maker] they switched their low end cars from offering a variety of sound systems to one standard system. Their profit improved by simplifying production and installing the formerly premium system on every car. In that case the price of the low end model went up, although by less than it previously cost to upgrade individually.
But for some features they continued to offer low end options even when it made production more expensive. Some "extremely budget conscious" consumers view power windows as luxuries and will buy only cars with manual windows. Adding the manual window option probably makes the low end cars more expensive than if they just put in power windows universally. But since that cost gets lost in the total price of a car, it's wise to avoid the appearance of expense rather than lose a sale to an expense-averse customer.
"By incorporating small pieces of logic into the processor, the vendor can enable and disable individual cores" so, why build multicore machines and then disable the cores?
The monitored part is questionable, but I certainly wouldn't mind being able to "shut down" unused cylinders. The general rule is that the more cylinders you have, the more torque, which means you can carry heavier loads. At the same time, the more cylinders, the lower MPG. However, cars that can pull heavy loads aren't always loaded up, so the extra gas used is wasted.
If I were driving a light truck to a nearby shopping mall to buy myself a complete home theater system, I wouldn't need all 6 or 8 cylinders. However, when driving back fully loaded, I probably wouldn't be able to move without 6 cylinders. Or, if I needed to drive up a steep hill with my load, I might need yet another 2 cylinders.
I'd imagine it would be economically and environmentally friendly to be able to turn on an extra 2 cylinders when necessary, and to turn them off when not.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Next on the market is a house with 5 rooms for rent. Only 2 rooms are available for use, the other 3 can be purchased later on and if not used will simply sit empty and rott! Sound familiar to anyone? smart economics...I don't think so.
When GM introduced the 350 ci V8 in the 70's, it was based on the 305 ci V8. Because of the gas shortage at the time, GM advertised the larger engine as, "Having more metal removed from the cylinders to reduce weight..." Technically, it was true - a 350 was just a bored-out 305. Supposedly, lightening the car in this manner would improve fuel efficiency, though I doubt the reduced weight was enough to compensate for the increased displacement.
The society for a thought-free internet welcomes you.
Which is why we have all of those excellent movies of late
every day http://en.wikipedia.org/wiki/Special:Random
I was waiting for someone to say this was like totally GAY but can't find the comment anywhere!
How about a model that borrows from micro-generation? Just as power from solar or micro-hydro that isn't used in my house goes into the grid and gets paid for by the power company, computing power that I don't use could be sold to the grid. Then I could decide between buying the cores up front or renting them.
Stremo
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.
This is known as a 486SX.
XKCD:Xeric Knowledge Comically Dispen
Comment removed based on user account deletion
Of course Intel and AMD are going to say this. For them, it's the truth.
Intel: Has fabs
AMD: Has fabs
nVidia: Doesn't has fabs....
Am you be getting mine picture?
-- Warning! Grammar check be corrupt! AYB!
Chas - The one, the only.
THANK GOD!!!
The CPython interpreter is open source - if you think the GIL is so stupid, where's your patch to get rid of it without destroying performance? Python programmers that actually understand the GIL and what it is for appreciate the fact that simple data structures don't have to go through synchronisation primitives on every access.
Besides, while multi-core is the norm in servers and becoming the norm in desktops, there are still a hell of a lot of single-core laptops and embedded systems out there. Add to that the fact that using threads with shared memory is a lousy way to try to take full advantage of multiple cores and the massive amount of developer effort needed to switch to a free-threading model starts to look like a pretty inefficient way of expending resources.
I have found that my overclocks generally don't reach, or even establish, what the processor is actually capable. Something else always craps out first. Maybe it's the northbridge, or a cheap stick of RAM, or the SATA controller that craps out around 226 MHz and frags your entire disk (grr...).
Recently, if you're willing to invest in support hardware that's reasonably capable of overclocking, you're also able to afford a faster-out-of-the-box CPU but cheaper support hardware, which is the route I went this time around. I still tried to crank it up but I knew the wall I'd hit probably wouldn't be the CPU.
Mal-2
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
So you give away processors and sell the cycles? brilliant
I think I'll charge my customers 1 cent per cycle. 16 cents if you use all 16 cores.
“Common sense is not so common.” — Voltaire
I would love to pay low dollar for a high end machine that has been crippled......
For years we have unlocked and over clocked hardware. This will be no different.
200 bucks for a quad core, full blown smoking system that I will have to tinker with voiding all contracts and warranties?? Sign me up!
Just a quick google search will give me all the information I need to break their encryption, activate all hardware and emulate a untouched PC....
We have DEV teams forming all over the world, this would be right up their alley....
How would this reduce the cost of chips for the manufacturer (and consumer)? Aren't they complex and buggy enough already?
...The entire staff are gathered around waiting for the results of a 30 year calculation breaking down all known components and matching them against cancer cells to get the cure. Just before the results are be posted on the screen and saved to an 8" floppy disc, a BSOD appears with the message, "CPU cycles payment has gone 30 days past due. Contact your sales rep to get system started after payment." The system then goes dark.
I just skimmed it, so tell me if I'm missing something, but did they just not know about functional languages?
A purely functional language can, indeed, thread as much as you care to. A function without side effects can't really have any contention issues with any other functions, right?
In fact, I think that is the main distinction -- ever play with make? Did you notice that it's a declarative language? Check out the "-j" option -- unless you've done something clever, your Makefile will already scale to as many cores as you have, and if you wrap gcc (with distcc and such), it will scale to quite a few machines, too.
Or just take any purely functional language like Haskell, and you find similar features, where it's basically a matter of tuning performance settings -- much like tweaking the cache values on a MySQL database.
Now, they are correct in that it's very unlikely that you'll find an auto-parallelizing C compiler anytime soon. Or C#, or Java, or any imperative language, which is a shame -- I know I think and program much more quickly in an imperative language than in a functional one.
And they are also correct in that language constructs can make the job a lot easier, even in imperative languages. Erlang is mostly functional, but not quite purely functional -- functions can have side effects (though they generally don't), and functions are guaranteed to be executed in order. But Erlang also has lightweight green threads (it calls them "processes"), and extremely powerful language constructs, to the point where I've heard it called "Concurrency-Oriented Programming" -- your entire program is already built around message passing. And while multicore isn't automatic, it does become trivial to modify your code to run on multiple cores or computers (it has its own built-in RPC), and the sockets library is good enough that you can do it the old-fashioned way, too.
And, of course, there's Python's continuations and other neat toys.
Don't thank God, thank a doctor!