Multi-Core Chips And Software Licensing
i_r_sensitive writes "NetworkWorldFusion has an article on the interaction between multi-core processors and software licensed and charged on a per-processor basis. Interesting to see how/if Oracle and others using this pricing model react. Can multi-core processors put the final nail in per-processor licensing?"
I'm sure higher-end software will charge per physical chip if nothing else.
If the efforts of other corporations bent on protecting their intellectual property (RIAA) are any indication, per-processor licensing will move to per-core licensing. If the RIAA can force you to pay multiple times for the same song (which you, unfortunately, cannot move between preferred mediums), then it would make sense that software companies bent on collecting money would make you pay multiple times for one processor. On the other hand, they are somewhat different issues: usage of music would be governed under fair use (in theory), while usage of software (at in terms of licensing per processor) would be governed by the EULA or another contract between the corporation and customer.
I don't if it's any indication of what they'll do for dual-core, but on Hyperthreading Xeon's, Oracle charged us RAC licensing fees per physical processor, even though most OS tools show twice as many virtual processors.
11*43+456^2
A recent example would be the Hyperthreaded CPUs. SQL Server can be licensed per CPU and with Hyperthreading, the software does for all intents and purposes treat it as a second CPU. However, Microsoft's stance is surprisingly that you only license per the physical processor. Page has doc with more info on MS specifics
Most likely per-"Physical Processor" will be changed to per-"Physical Processor Die" since the multi-cores still share a die.
In the end isn't still just one processor? No matter how much stuff is added to it, it'll still just be a single processor.
No, but PostgreSQL and Linux can :)
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
As long as IBM is making mainframes there will be per processor fees...and they have been around for 40 years so I see at least another 40. Heck, now they even charge different amounts for a processor depending on what you are going to run on it.
Yeah, I'm looking forward to the day where you have to pay a license fee for each element in your toaster. Who needs to toast more than one slice of bread at a time, right?
www.kitchengeek.com -- Nosh for
I don't follow CPU development beyond what I need for my day job and what I read here (how's that for pathetic?), but do multi-core CPUs necessarily mean SMP on (in?) a single slab or does it more often mean more pseudo-SMP of the hyperthreading variety?
Businesses charge the maximum they can, for maximum total profit: "what the market will bear". Per-processor prices are just a way to negotiate how much money the customer can make from the software, therefore how much is available from their revenue to pay the software supplier. Just like when an employee negotiates their income, they are negotiating for a share of their employer's revenue to which their work contributes. I'd like to see a software licensing model that treats the software's work as automated labor, and negotiates accordingly. Like some kind of profit sharing. People don't get paid up front, why should the software company? That allows a timeframe for a "test drive" during which both parties can get benchmarks on the actual value of the software.
--
make install -not war
As far as the OS's are concerned Hyper-Threading already looks like two processors from a single processor in both Windows and Linux. Licensing for this is luckily done on paper and not through how many processors the OS thinks it has.
So in short will this change licensing, not for applications, but there might be some modifications for everybodies "favorite" OS.
what the hell difference does it make to Oracle how many CPU's your machine has? or how many people use it, or how big your company is, or all this license BS.
It's like if I broke my arm and the doctor charged me more depending on what I did for a living. "Wait a sec, you earn money with that arm? I want a piece of that."
Ahh, the joys of free software. No BS. (And yes, I know, no Oracle either).
demanding more money for multi-core is ridiculous. if you're going to do that, why not charge more for faster CPUs? why should it cost twice as much to use, for example, a 2-core 1GHz CPU than a 1-core 2GHz CPU?
on the other hand it may push more people to OSS.
Well, these rules are obviously not written in stone. "likely" is speculative. Let's wait and see what they *actually* decide to do. Rules can change as technology changes. The enterprise users should speak up about this issue and provide feedback.
Obviously Oracle considers an n-core chip as n processors. However they are not going to be able to compete if another database company does the opposite with its licensing. However, maybe they'll all follow each other just for the sake of quick $.
And I think single-core, single-CPU systems will stick around for a long time, if not for the indefinitely foreseeable future. CPUs get faster all the time, and since it's much easier to engineer single-core, single-CPU systems, so single-processor systems will remain the preferred solution for the low end. Look at something as basic as pipelining, that is an ancient technology in terms of processor design, yet there is still a place for non-pipelined processors at the very bottom of the chain, where microcontrollers are concerned.
Businesses charge the maximum they can, for maximum total profit: "what the market will bear".
Linspire looks poised to change the market.
Per-processor prices are just a way to negotiate how much money the customer can make from the software
Well exactly how much money does a residential customer customer make from the Windows XP Home Edition operating system software?
Microsoft Windows XP's desktop license model currently limits the home edition to one processor and the professional edition to two, counting a single-core multithreaded processor as one processor. However, if Windows XP counts a multi-core CPU as two processors, then it won't boot both processors, and by the time PC vendors phase out single-core x86 processors, all OEMs will have to pay extra for Windows XP Pro.
I say "by the time" rather than "if" because from the article:
I say "XP" instead of "Longhorn" because December 2005 is before Longhorn's estimated ship date.
I'm a network admin for a govt org. I'm about to buy a bunch of Oracle server licenses for a new records management system project. I specifically asked our Oracle govt sales rep about this issue and he unequivocally stated (and put in writing in the form of a formal price quote) that the Intel Xeon HT processors count as one processor per physical CPU each. He went on to explain that for other big-name Unix platforms, like certain IBM RS6000 boxes which have multiple processors included in their "cpu module" (i.e. ship with 6 procs in a module, but you may only buy the box with 2 or 4 actually enabled) that Oracle does indeed demand a per-processor license for even the dormant processors, becuae all it takes is a phone call and fee to IBM to run a firmware config utility to activate those dormant processors. If Oracle renegs on this deal, then I'll flat tell them to kiss my hiney, and kiss the $80K deal goodbye since the app I'm buying will run against MS SQL Server just fine too.
If Oracle and MS continue to use "per processor" licencing, I humbly speculate that it's just a matter of time until VMWare or some other Virtual Machine vendor/software supplier creates a "virtualized processor layer." VPLWare would present "n" processors as one large fast processor. Run your Oracle or MS application there. Problem solved. Wait, can't we do this already?
Unless SMP and/or dual-core becomes ubiquitous
Dual-core will become ubiquitous during 2006, even in home PCs. The article points out that "All chips [sold by Intel] will be dual-core by the end of 2005." This includes the Celeron processors used in low-end home PCs, which then won't be able to run a single-processor version of Microsoft Windows XP.
To help envision it, lets say its a firewall - the firewall has no concept of "users" really, it routes packets. (it's not a firewall, but the situation is close enough).
Now our basic question, which we reluctantly answered with per-processor licensing, was how to charge for it.
If you buy our software and your company of 20,000 people is RELYING on it you'd pay more than if your company of 50 people was RELYING on it.
We could have priced into the middle - but then companies under 2,000 people would feel (rightly) ripped off, while the GMs are getting a steal.
Charge per "user behind it"?
Charge by your corporate revenue?
"Pay what you feel is about right"?
On not so minor goal was to be able to make a living for 40 people and continue to develop a product that had, by and large, come up pretty short in the open source arena.
So what models of licensing do you WANT that will keep the vendor and the buyer in business and happy?
(and yes, I've slipped in a 4CPU license for 1-2 CPU price at a place with old, slow machines in use. We tried to do "right".)
Problem is: 1) The software doesn't regulate the license, so you don't even need to. 2) It's still illegal.
(for now). I've already seen official statements by vendors, explicitly saying that multi-core won't affect their licensing. I've seen none even hinting the other way. If this article says otherwise -- explicitly, naming names -- then that's news.
It might in theory be possible to make multiple processors appear as a single hyperthreading Pentium 4 processor, but it'd probably get you thrown in jail under the DMCA for selling a circumvention device should one of the DBMS vendors raise a fit.
Can multi-core processors put the final nail in per-processor licensing?"
So, like a nail in a voodoo doll, MCPs are tortuting per-processor licensing? Cool as that may be, I think the saying is "put the final nail in the coffin of [ . . . ]"
Sorry for being pedantic, but it sounds funny without the coffin part.
everything in moderation
I think it is interesting that, Windows running on a 2 CPU machine requires a 2 CPU license, but, say, 5 instances of VMWare running on a single CPU, each hosting an instance of Windows, requires five licenses. (Six if the instances of VMWare are themselves running on Windows)
Also, what if there was a VMWare-like program that simulated a SMP machine? Would that require a multiple CPU license to run Windows? Even if this program that emulated a SMP machine was running on a single CPU?
Unknown host pong.
Oracle count a Pentium IV HT as two CPUs. (I asked my account rep). So it gets legal definitional. What does the vendor define as a CPU or Processor?
Oracle used to have power based licensing ie: MHz x Number of Processors - they dropped that silly idea real quick.
Processor based licenses for Oracle is slowing the adoption of their 10g (grid) edition deployment on to arrays of low cost linux boxen.
These issues also apply to products like IBM WebSphere etc.
Market pressue in the end will fix this problem.
You want a signature? You can't handle a signature!!
I love the view that Linux can replace all machines. There's no place for proprietary software.
Now, I'll mostly agree with Windows because too often Windows is being cobbled together and shoved into the data center (my servers need a windowing system just to boot? I have machines I've never seen or touched that I've installed from 12000 miles away and run for years.
And yeah, BSD fills lots of places in the infrastructures, but BSD and Linux didn't come up with CrayLink or NUMA. And there's something kind of nice about when your $10million company has a problem with the $100,000 server that I can make a call and have a bunch of people answer who are PAID to run around and make my problem their high priority.
But yeah, that my PDA runs Postgres and smokes the trading floor servers I used put up 10 years ago is pretty cool.
Multiple cores on one little square are seprate physical processors, they just made a compact distribution of it. Oracle also didn't charge for hyperThreading, but they do with multiple cores, MS will more then likely do the same.
It could be an error of omission of "the coffin of", as you suggest. On the other hand, it could allude to crucifixion.
According to TFA, Sun is expecting to have more than 2 cores per die soon - up to 8 cores within a few years (I'd assume others will also, maybe I just didn't rtfa close enough). Maybe there is a happy medium for the companies that change prices based on the number of processors a system has.
Instead of gouging the price based on the number of physical processor slots are used or how many the OS sees, how about changing it to adapt to the changing technology quicker. For example, maybe they could license based on a range of procs (1-4, 4-8, 8-16, etc). I think the paying customers might end up liking this flexibility a little better so they don't have to take out a loan to turn on a virtual CPU or two.
--- "To ignore race and sex is racist and sexist!" -- Jesse Jackson
By licensing per core instead of physical chip, they make more money.
Not if Oracle's customers defect to less expensive competitors, as you begin to recognize with your reference to BSD.
...when I learned that enabling hyperthreading was going to allow MS to charge twice for a single processor.
KS
"demanding more money for multi-core is ridiculous. if you're going to do that, why not charge more for faster CPUs?"
1. Nothing new. It has been done for years on mainframes.
2. Don't assume that the two scenarios are equivalent. Ignoring issues of scaling at the hardware- or OS-level, aspects of *application* architecture may affect whether a 2Ghz processor has better or worse throughput than 2x 1Ghz.
Power 4 has been out for awhile. Does anyone have any experiences with multiprocessor licensing on these? The CPU is multi core and multi die in a single package. Do you get charged for each core, die, package?
Is licensing sensitive to whether these cores are hard or soft?
Yeah, postgres and linux do well on a pair of redundant 32CPU machine that's being HAMMERED, running with 32GB of memory in use and more waiting.
As you seem to recognize with your Windows reference, not all Oracle installations run on such big iron. There also exist small businesses with small iron, and if Linux takes those, then as the small businesses become big businesses, Linux will eventually run well on big iron as the support contracts fund development of Linux for over a thousand CPUs. There may still be a place for proprietary applications, especially in the entertainment field, but operating systems will be free.
Unfortunately, this cannot be done. Just like laws of physics cannot be repealed
Correct me if I'm wrong, but this way you would lose almost all of the benefit of multiple cores. At least, you would if you'd run an OS inside that VM/VPL, since not only would you have to have both a host and a guest OS (more licenses), but the guest would not be able to take full advantage of the hardware (by definition of the VM), which means more complexity with (be realistic) lower performance. Not running an OS inside this VM/VPL is silly, since it is then not a VM at all, and the VPL would be doing exactly what a normal OS does (shuffling threads), making its existence somewhat absurd. Bah. Leave that to marketing.
Although the valid point has been made elsewhere that it takes effort to make SMP-efficient apps, I think the multi-CPU licensing idea in many cases is crap because the OS should make it where the processes are running transparent to the application.
I think what you want is an new HAL paradigm that makes whatever massively-parallel Neumann machine we run to look like a single processor, and *function as one* (I know about mosix -- I mean with performance proportional to size). I agree that this could be a good idea. Maybe. In a decade.
Karma: Positive (mostly due to rash moderations)
If per processor licensing ever does go away, it will probably be replaced by some other insidious evil. Imagine having to run a program provided by Oracle that calculates the MIPS of your system...
Whoa. You're comparing RIAA tactics to non-free (as in _libre_ and dollars) software vendors.
Your comparison is totally inappropriate.
With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.
After all, whey you're paying for performance, the vendor (and buyer) wants to find a useful billing metric that's easy for everyone to understand. Anyone who's dealt with Veritas's 20 or so tiers will appreciate this.
Per cpu is the way to go then. The customer maximizes their investment when running on the fastest CPUs available, which isn't normally a big deal when the cost of the software far exceeds the cost of 3.2GHz Xeons or equivalent Athlons.
Per-cpu also solves the issue of pricing a single-cpu x86 (little $), versus a 32+ cpu sparc box (big $), versus 32x single-cpu x86 clusters.
So, when multiple-core chips come out, they'll essentially be multi-cpu. easy. Use them, pay more.
Because of competition from free ($/libre) software, licensing arrangements have gotten a lot more sane in the past couple years. Vendors are trying to stay away from that line in the sand where it becomes cheaper to re-train,re-build,re-deploy than to re-license.
This is very much unlike the RIAA,MPAA, and their friends in other countries who see it fit to take a much more extortive stance. Remember that most vendors let you move a per-cpu license around to different OSes and architectures, something that surely can't be said of the entertainment industry (oh, you own this on videocasette? You can have the DVD for media & packaging costs, or just download the content from http://videos.com)
You're right in questioning the home user's cost:benefit analysis in terms of revenue, although many people do use eg. Windows XP to make money, or save money, at home. But I haven't heard of Microsoft requiring non-business customers to pay a per-processor license - are there any (working) dual processor gaming machines which cost more for their Windows license than their single processor versions? AFAIK, WinXP Home shuts off all but one processor to keep corporate customers from buying it for less than Pro. So it's really just a sloppy way to split the market based on their ability to pay. If it affected a large enough boundary market, Microsoft would adjust their pricing to exploit it better.
Linspire is governed by the same basic dynamics. They're going to charge what the market will bear, but the market won't bear a Windows price for their product in 2004. Whether they keep their pricing model if they become a platform option on par with Windows in the market will remain to be seen. If they stay cheap, they will expand their market more - what the market will bear tends to resemble the ability of water to seek its own level.
--
make install -not war
You thought that you, and your butt-fucking friends could keep me from posting on your fucking shithole-in the wall site, BUT YOU WERE WRONG. ROFLS OMG!!!!
FIRst post all you slashbot whores... i totally pwned yuo alls.
Here we go yo, here we go you, so whats so whats the scenario?
2Tehmaxxxxxx
I don't mind paying Intel a little more for dual core machines. I don't mind paying Microstar extra for a motherboard that supports that processor. I don't mind paying Microsoft extra for using dual core processors. But... on a per app basis? So.. I'm paying for 2x the performance, right? What if I buy a machine with ~twice the megahertz?
Maybe I'm just knee-jerk reacting here. I'm just not all that impressed with this new scheme to wring money out of people, even if they are big corps etc. I mean, if the software did something special with more processors, that'd be a little different. I just don't want the double-dipping to happen. Hardware makes the speed.
Okay, I'm done redundantly ranting. I'm just annoyed with the prospect in a year or two of adding new machines to the render farm and then having to 'upgrade' the software.
"Derp de derp."
Assuming it is a firewall, just charge by the number of computers on the local side of the firewall that packets are being routed for. If the user pays for 50 users, have it remember the states of sockets for 50 computers. If the user pays for 20,000 users, it could handle the states of sockets for 20,000 computers.
I realize it isn't a firewall, but the solution works for nearly any networking tool. Charge by connected systems rather than users. Failing that, you can always assume the honesty of your customer and charge by the number of people relying on your product.
You can't judge a book by the way it wears its hair.
i_r_sensitive is extremely optimistic if he feels that multi-core processors are going to mean the end of per-processor licensing. I would think that most software licensors are looking toward multi-core chips as the gravy train finally pulling into town.
When you think about it, any licensing deal is a contract between a software provider and a software user. If the price doesn't make sense, then the contract won't happen.
Depending on the cost of the processor chips, the computer chassis they plug into, and the license cost -- per processor licensing could save people money when they move to multi-core machines -- assuming that the two-core machine really is twice as fast at the application as two single-core machines. If the chips don't cost much more, you save the hardware, energy, and cooling costs of the second chassis. This could be a big win.
This is one of those cases where the market will decide. In [my] visual effects business, company policies are all over the map. Pixar allows you to run RenderMan on dual-proc machines with a single license. It believe (could be wrong, we have only 2 proc machines)) that Shake will run on however many processors you have in one box using just one license. Other software requires a separate license for each processor.
But really, when I say "software requires", that's wrong and stupid. It's the contract you have with the software provider that requires it, and contracts are often quite malleable.
Thad Beier
I love Mondays. On a Monday, anything is possible.
Why are any of you surprised?
.. AND ITS FREEEEEE.
.....
... they really didnt like it when I pointed out that I'll be saving $52,000 by using MapServer + Postgresql + PostGIS over their ArcIMS + ArcSDE/Oracle setup.
Oh ya, its because you can only think with the open source half of your brain.
Of course software companies will try to charge you more money any chance they can!
Just like every other product you can buy anywhere, if they can sell it for more, they will.
Wake up!
Until you complain enough, they will reap what they can from this conundrum.
If you don't like how Oracle screws you on your new dual core processor, then send them packing, I'd bet that Postgresql / PostGIS is now sufficient for the needs of most enterprise database users
In fact, I personally am going to skip the chance at ever having the topic at hand affect me
Today I called, found out that, ESRI in canada charges $13,500 for a 1cpu license of ArcSDE or $19,000 for a 2cpu license, it remains to be seen what they define as a CPU.
But instead of blowing that $19,000, I am installing PostGIS to serve my spatial datasets. Screw them!
And the joke is on them as my system is faster, easier to setup / deploy, and can handle much bigger raster datasets in a fraction the time.
George Bush + Linux = "I will not let information get in the way of the fight against Windows"
Sometime recently (it's late and I need sleep, so if you want you can look for yourself), I believe Microsoft said that they would charge per socket when it came to multiple-core CPUs. This was an important point that was brought up when AMD announced that it would begin production of dual-core Athlon64 CPUs later this year.
How they would detect multiple cores in a single socket was not discussed. Maybe there will be something in the chipset that will cover that.
You can never go home again... but I guess you can shop there.
It's a complicated subject that gets even more complicated as time goes on. Like the Xeon Pentium chips that count as multiple processors in windows.... but it's really 1 physical chip. What if they were emulating stuff thru vmware. Now 1 chip is really on multiple OSes. Etc Etc.
No licenses today can contractually prepare for innovative stuff in the future. That's why 90% of hi-tech lawyers should quit and leave us techies alone.
I can't remember exactly, but back when I was working as a IBM mainframe software engineer I had a feeling the IBM and CA who provided various software for our mainframes charged some software based on MIPS (Million Instructions Per Second) ratings of the virtual machines that the software was running on. Why don't software companies just do the same thing. Establish a performance benchmark and charge based on that. That way you can use single, dual or multi core processors or multi CPU machines and not have to worry about all this licensing drama. If you real machine or "virtual machine" is bench-marked at x MIPS you pay y dollars, who cares what architecture you are running.
Let's say the basic components in a processor are: instruction fetch, instruction decode, load/store units (memory save/load), various execution units (that do the adds, multiplies, etc.), and a register file. Current hyperthreading allows for relatively fine grained switching between threads, so I believe there are two separate register files, but all the other units shared. (Are there two MMUs and TLBs? I'm not sure, but somehow they allow hyperthreading between two unrelated processes, supposedly.) Already we do have two of something (register file, and maybe the memory management hardware).
There's a continuum of possibilities. What if there are two of everything except the execution and load/store units? Note that the whole machine is massively pipelined, so there are multiples of these even when there is just one procesor. So do you have two processors which share execution units, or one processor with super-hyperthreading?
Assuming you consider it the former, then we can mix it up. Maybe there's two instruction fetch units, but a single instruction decoder. Etc. etc. Now, you could pick one thing, say instruction decode, and say 'there must be two of these to be considered two processors'. Oops, I forgot to mention, superscalar processors already can decode multiple instructions at once (just not from multiple instruction streams), and even so, different people are going to pick different definitions; there's no clear differentiator.
A pure two-core approach is just easier/cheaper to design, since you basically just design them separately, or really, design one and clone it. But you can probably get more performance for the same chip area by pushing those two cores together and allowing them to share resources, even though that will look more like hyperthreading in terms of design. Normally you think of hyperthreading as being less efficient than pure two separate processes, yet I claim this more-like hyperthreading design gets higher performance that two separate processors; I can't see how you wouldn't be better off sharing the 2N execution units rather than using a fixed N in each core.
In the end it boils down to (roughly) "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?"
"Life is wasted on the living. -- The Restaurant at the Edge of the Universe."
End. Not edge, end. For shame Slashdot.
multiproc is for biz, single-CPU is for home.
The article suggests that by the end of 2005, what you said will be equivalent to "new PC is for biz, PDA or used PC is for home," because all new Intel CPUs will have multiple cores by then.
Both HP and IBM have had dual core chips for a while now. There are a number of advantages to moving to dual core processors. The most important is that it helps to improve performance without as much heat generation as two single core processors. Another advantage to dual core processors is that you can share caches, which have some very distinct advantanges in multiprocessor environments. By sharing cache processors can check the shared cache without interupting eachother. By improving the performance of the processors, server vendors can actually cut software costs on a per processor basis, as fewer processors are required to perform the same workload.
The real issue for software licensing will be when virtualization becomes more widely used in the Risc and Intel space. How will software vendors charge for 2 tenth's of a processor? This will be the real challenge from a cost perspective, as there will be a number of applications that really only require that much of a processor.
Of course if everyone has dual-core processors then everyone will be using dual-core operating systems
If you're claiming that Longhorn is this "dual-core operating system", then according to Intel's timetable, "everyone" who buys a new Intel CPU will have a dual-core processor before Longhorn is released, so they'll need some other sort of dual-core operating system. Windows XP Home Edition isn't a dual-core operating system, and Windows XP Professional costs $50 more. Do you claim that OEMs will just pass that cost to the buyer when shipping PCs to homes? Or will more OEMs add Linspire as an option?
Veritas has a similar pricing structure. Different machines are delegated to different "Tiers," with different licensing costs. So for example, a Sun Fire 280r is "Tier 1" while a 480r is "Tier 2," and the same (Veritas) software is twice as expensive. Mind you, these machines actually have the exact same processing power (in my case, anyway).
At least Oracle's system is simple enough to be contained in a price list. Even Veritas reps can't ballpark software for you, it depends on the power of your processor, the depth of your racks, the phase of the moon....
...they will. HP, Sun, IBM, and whoever else is in the dual core market, are marketing these as n-way machines. Take a big 64-way server, drop in a pin-compatible dual core CPU (or swap around some modular boards), and you now have a 128-way machine!
If the machines are marketed as 128-way machines, you can bet your sweet ass Oracle and its ilk will charge according to whatever they advertise.
When encryption is outlawed, ou++1!@(93j++js-d9298yIUH(*Y24JKB!~
They say they can tell the difference between the logical and real processors (and I'm tempted to believe them since SQL2kSp3 does seem to handle the load distribution across the physical procs gracefully). They've got enough monkeys at enough keyboards that I'd wager they will be able to tell the difference . . . and as pointed out by the A/C above HT *is* different since they are logical procs, but if they keep the same stance and continue using the term 'Physical Processor', they might keep the licensing for the multi-cores to be associated to the number of chips going into sockets . . . I can dream anyways. I tried finding an article mentioning their stance on multi-core CPU's and failed . . . I'd definitely like to see it if someone can find it.
Are Siamese twins required to buy two tickets to the movies?
While I agree that there is nothing dodgy about it, one should also factor in processor speed and other issues that affect the amount of useful output that can be extracted from the s/w.
I point this out because it is not a theoretical possiblility, but has been used in the past. In the area that I work, in the early days of commercially available software, vendors tried to charge more when users wanted to move their software to faster machines. That idea did not last long and is now a distant memory.
So, while your idea seems good in theory, expect sufficient push-back from customers to make it non-viable.
The real "Libtards" are the Libertarians!
Er, since when? MS has always been HT friendly . . .
.Net setup to distinguish between the two and only count physicals against the processor limits
This doc even talks about how they have
Now, if you drop, say, 2000 server on a 4 proc HT enabled system, it's silly since it'll count the first 4 logical against the inherent processor limit so there isn't any reason to turn HT on . . . But they don't charge you *more* for licensing on a HT enabled system per logical processor. Similarly, using a dual P4 xeon with HT enabled on a Windows Xp professional install is silly for the same reasons. But you don't get charged more for turning on HT on a single proc XP pro system. It shows as two procs, you pay for one physical.
I suggest you review the following which details their licensing when it comes to HT.
For those that don't want to RTF-MSWordDoc, the pertinent line:
Windows Server licensing is based on the number of physical processors on a system
SQL Server is the same way. Physical procs count (and SQL server *can* tell the difference between logical/physical and spreads the workload across the physicals evenly rather than loading up logicals per processor disparately).
Which product did you find that they claim they are charging for logical processors?
Yup! I was at a technology day from UK Oracle User group last week where there was a presentation from Oracle on licensing. They basically said the above. The thinking seemed to be that HyperThreading isn't truly multicore processing (I don't know enough about the technology to comment on the accuracy of that assertion). Where they will charge more is for true Multicore chips where you essentially have two processors that just happen to both be etched on the same piece of silicon. Quite logical really, they're licensing by number of processing cores not by the number of slices of silicon.
Stephen
"Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall
With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.
I don't know. I think it's a bit, hmm, unnatural. You know, I pay the processor vendor (or computer vendor) for the additional power, why the software vendor?
Hmm, I didn't answer to defend the RIAA example, but thinking about it, there is an analogy with music. It's like saying you have to pay more for a CD because you have more appliances to play it on.
Oh wait, this is a possibility DRM gives them.
I also don't pay more for a DVD player just because I have a big TVB screen, just because this enables me to "get bigger value" out of that player.
HT lets you use the execution units in a core more efficiently; CMP (chip multi-processing) multiplies the quantity of execution units. Of course, CMP also multiplies the L1 cache amount, registers, decode units, etc.
aQazaQa
That's exactly what i was thinking......
Why should you pay more $$ to run the s/w on an old quad-pIII 450, compared to a dual-p4 (single core)3200. That just doesn't make sense to me.
If they want to charge based on how much you can squeeze out of the s/w, then by no means is the no. of CPU's or the no. of cores the best measure. The only fair way to do this would be to benchmark each system before deciding what to charge for the s/w.
All of this, to me, seems completely ridiculus. Even if they did use a fair and accurate way to measure how much you can get out of the s/w on a given system, it would effectively be encouraging companies to use older/slower hardware.
Why not encourage those who use your software to get as much out of it as possible? The only time i believe that something like this would be justified would be in cluster-type environments, eg. pricing should be per node, regardless of what each node has "under the hood".
per cpu licensing of platform's LSF was one of the reasons we migrated to Sun Gridware / Grid Engine (sun open source). not to mention grid engine performs 1000s of times better. but there is no license fee that wants to charge double if you boot a pentium 4 with hyperthreading enabled. ;)
If Oracle and MS continue to use "per processor" licencing, I humbly speculate that it's just a matter of time until VMWare or some other Virtual Machine vendor/software supplier creates a "virtualized processor layer." VPLWare would present "n" processors as one large fast processor. Run your Oracle or MS application there. Problem solved. Wait, can't we do this already?
Uh, that's about as feasible as it is to get 9 women pregnant in order to get a baby in one month.
Well, in a few years, you'll have to bring a complete description of your video playing system to the shop, where you then get a video stick (DVD will not be supported any more - too little control) for a price evaluated from your setup. Say, $2 per Display Inch (sum over all displays you want the DVD played on, other displays will not show it due to DRM), $1 per sound channel (stereo will only cost $2, while 5.1 comes at $6 extra cost), of course extra $3 for Dolby Digital. Of course, per playing you'll additionally pay 60 Cents for the connection to the DRM server (stopping and restarting will count as separate play, of course). Per-viewer licenses will come later, as soon as the person counting software will be reliable enough. Then a set of webcams connected to your video playing setup, installed by specially authorized personell, will be mandatory.
Ok, I agree that's not realistic: The specifications of your system will certainly be automatically received by the shop based on your account card data
SCNR
The Tao of math: The numbers you can count are not the real numbers.
A recent example would be the Hyperthreaded CPUs. SQL Server can be licensed per CPU and with Hyperthreading, the software does for all intents and purposes treat it as a second CPU. However, Microsoft's stance is surprisingly that you only license per the physical processor.
Pretty reasonable because the second virtual processor isn't as nearly as good as having two physical processors for most server applications since the virtual processor runs only when the real processor isn't busy. For regular systems, this is most of the time, but for most multi-threaded server apps running full blast, it's very seldom.
Multi-core, on the other hand, gives multiple independent physical processors that just happen to fit into one socket. Its more than likely multi-core systems will be priced according to the number of cores.
Some mods seem to have little or no grasp of reality, or ability to read.
What Trogre is saying is that because Open Source and Free Software doesn't impose per-processor restrictions, and because for many people these software products do the job, why is licensing multicore processors a problem?
Another thing that could be read into it is that if costs become too high because of multicore licences, more people will move to Open Source.
If the mod has a point he wishes to raise, or disagree with, then either forego mod rights in this article, or post as an AC. Badly targetted or biases mods are also offtopic.
From the article:
That meant W.L. Gore was faced with paying double what it originally expected to pay for licensing, amounting to $100,000 per server in additional costs
and
"In fact, I have spoken with clients who have been told exactly the opposite from the server vendors," says Jane Disbrow, a research director with Gartner. "They've been told, 'No, you don't have to pay double licenses. This is going to save you money in software.' I'm the one that has to give them the bad news."
Don't these people talk to their software vendors before they make upgrades that might cause them six-digit extra costs in licenses? Get the answer in writing so they have some proof?
Management at work...AAARRGGGHHHH
C - the footgun of programming languages
While heading in the direction of being offtopic, I would like to comment about the memory bandwidth of systems that employ multicore processors.
Adding more processors to the die may increase MIPs overall, but real world applications rely heavily on memory throughput. Most modern processors run faster than the system's main memory making high speed caches necessary. As we add processors and cores contention for the memory bus increases leading, often, to a drop off in effective power per processing core due to cache 'faults'. (daft term - doesn't mean there is something wrong with the cache, just that what you want isn't in it!)
Now, in systems terms, this may be acceptable but it will be hard to sell a solution where the license costs increase more rapidly than the performance benefits. If I pay double the money, I want double the results. Now that's not always possible, but one has to be at least within sight of the other.
When faced with such terms, many people will consider software where there is no per processor license, or where you pay for blocks of processors with the cost of each successive block falling rapidly (to make up for the progressive inefficiency).
Multiple processors have traditionally been the realm of big enterprises where budgets are more flexible, but with the advent of multicore, it will move into the desktop, home and small business. If companies wish to keep a foot-hold in these markets, they will have to embrace more enlightened licensing term or lose market share.
The number of posts concerning Oracle show that databases are a big issue. Now Open Source options are becoming more enterprise friendly, it won't matter that they are less efficient per processor unit if adding CPU cores improves performance adequately while keeping the overall system cost below that of commercial solutions.
If you want a stable, commercially supported DBMS wait until Ingres r3 is available free.
Personally, I don't think that it is practical to do what the parent suggested but, if it were possible, would it be illegal?
It would be running on a virtual system that had only one virtual processor. Even if the physical system had more than one, the emulated system would not. If you ran on a system that had a single processor, but emulated 4 way processing would the vendor charge for 1 or 4 processors? I'd suggest this tactic as a defense. If caught in this hypothetical position, get someone to emulate an SMP box and enter dialogue with the vendor. If they are charged for multiple processors then the vendors case will be compromised, logically and maybe legally.
I suggest that this is a very grey area where there are 2 opposing 'common sense' arguments and it would take a number of court cases to resolve.
The article misses a fundamental point about dual core CPUs. IBM calls a 32 CPU p690 a 32 CPU machine. It is actually a 8 CPU, 4 core per CPU as per the article definition. i.e. 32Check http://www-1.ibm.com/servers/eserver/pseries/hardw are/whitepapers/power4.html for more details.Quote "Four POWER4 chips can be packaged on a single module to form an 8-way SMP. Four such modules can be interconnected to form a 32-way SMP."
Sun on the other hand calls a 144 CPU E25K a 72 CPU machine. It is actually a 72 CPU, 2 core per CPU as per the article definition. Quote "Based on two UltraSPARC III pipelines".
Check http://www.sun.com/processors/UltraSPARC-IV/ for the detail.
It will be interesting to see what HP deliver for a dual core CPU this year.
Oracle must love the Sun E25K as they charge Enterprise licences based upon the size of machine.
True, but I doubt that a multi-core chip will be on par with a similar dual-cpu setup, you still need to get the heat away from that single cpu. It's very possible you will only get about the same 15-30% boost in speed you get from HT.
From what I understand multi-core designs have all cores on a single piece of silicon at the center of the CPU just like uni-core CPUs.
I always found the license model of the software companies to be outragous when i started working as an admin.
Where else can you find a model like this? they ask you to pay them more while they provide _nothing_ extra. nothing changes on the software side just because you add processors to your machine. (oh, some companies even use complex matrixes of cpu/ram/users/db size/etc. to make it even more rediculous)
Imagine paying more for a leaf of bread because your family contains 5 people, or paying more for fuel because when you use your car there are 3 people in it most of the time, it makes no freaking sense! The licensing model has been corrupt for a long time already, it needs to change yesterday not tomorrow.
On a long enough timeline, the survival rate for everyone drops to zero.
It would be nice to see some common sense invade the mindshare of Big Business. But I doubt it will happen. Greed will out.
--
If I actually could spell I'd have spelled it right in the first place.
Even if multi processor charging is no long possible or inconvenient, other options avail ie: MIPS processing such as Z/OS uses, etc.
Real men don't need signitures!!!
It will probably end up with a licensing cost per thread (even for multiple threads on a single processor), or maybe even a conversion factor (your 8 way dual core opteron is equivilent to 64 PIII 1Ghz)
You know, a lot of this just depends on the operating system. If Solaris reports through the appropriate sysconf() call that there are 8 cpu's, how is the software, in checking for license conformance, going to know that means 4 physical or 8 physical? There really isn't a way. In fact, to even determine if x86 hyperthreading is enabled is difficult (and on Windows requires forcing process affinity to each cpu in turn to examine its apic information).
Software vendors have to rely on the OS to speak the truth (or lie consistently). That's why Sun's dual-core chips count as double for Oracle and other vendors.
Note that when HP started doing dual-core PA-RISC chips, they never lied about anything. If you bought a machine with 4 dies, 8 cores, you bought a "8 cpu machine." It's really Sun's deception, calling such thing a 4-cpu machine, that is bringing this to the forefront. The UltraSPARC IV is two UltraSPARC-III cores glued together. They only share the L2 cache, and even there each core has a dedicated half of it. Sun marketing made this problem far worse than it had to be.
...but those that need it, are multithreadded. And remember that most common desktop use is multi-process. I got 37 processes running on this Windows machine, now if one of them starts pulling 100%, the machine will slow to a crawl. The problem with dual-processor machines have primarily been volume - dual CPU boards have been priced more than they're worth, sometimes requiring extra large mobos (EATX) with little choice in cases. With XPCs, finding space for dual procs is even worse than before (Even though someone did manage to get 2 Opterons into one). All this is making dual + 2xCPU poor value to most people.
Dual core CPUs on the other hand, seems to be able to operate just fine on what is otherwise a single core CPU board. As for CPUs, it would appear they will not be getting much faster by improving the design process. Going from 130nm to 90nm made it clear that we're approaching certain physical limits that aren't easily overcome.
The major gains in the future looks to be coming from process changes (like SOI) and architecture changes (HyperThreading, dual core etc.) Both on the low and high-end, dual core might be advantageous. Remember that two cores running at half speed put together uses 2x(1/2)^2 = 1/2 the power of one running at full speed.
Kjella
Live today, because you never know what tomorrow brings
I actually ran into the per-processor licensing with database connector software on Linux. A Xeon shows up in linux as two processors due to the hyper threading. Of course hyperthreading is not as fast as 2 distinct CPU's either. It threw the salesman for a loop - he had no idea what the license would be. Turned out they were way overpriced anyway, and a FOSS driver worked fine.
Oracle was licensing based on power units a while back. Any idea if they are stiill doing that? From what I understand, they basically benchmarked certain machines and price the software based on the performance of the box rather than pure # of CPU's. That solves the issue completely. Course we use MySQL and Postgres anyway, with a smattering of MS SqlServer (Yeah I know, but it IS a pretty good DB, and needed by some apps.)
No. If you could do this, then you would have worked out how to automatically parallelize arbitrary applications and you'd be extremely rich and famous.
Licensing per core or per processor is just as stupid as licensing per FLOP (speed of the processor). It should be up to you how much hardware and processing power you want to throw at your software - after all, it only really affects how fast it runs or perhaps how many connections it can handle.
:) Maybe per-core licensing discourages them from speeding up the single core implementation as they are keen to sell more multi-core licenses :)
If I want to speed up my database by giving it more processors or more RAM - I don't see why I should have to pay Oracle more money for the privilage. After all, if it was a faster database, I wouldn't necessarily *need* to purchase more licenses for it would I?
Windows XP and Server 2003 are based per socket/real CPU, each HT CPU counts as 1 CPU for the licensing so a dual Xeon with HT only counts as 2 CPU's.
Windows 2000 on the other hand sees a HT CPU as two CPU's and counts it's that way against it's licensing, I guess they didn't feel like patching that yet/ever.
Because of the quotes I assume that you are refering to Windows. Windows 2000 and XP handle hyperthreading just fine and it doesn't impact licensing. For example, you can install Windows XP Professional on a dual CPU hyperthreaded machine and it will install properly and the Task Manager will indeed show four CPUs even though it's only supposed to work with two. Obviously there is something detectable about hyperthreading.
Why not just take a tip from Sun's new pricing model and offer and infinite right to use and have the pricing based on a per employee cost.
Y employees * $X = resulting software cost
Do this on a year over year basis and you have recuring revenue.
It's not so much paying more because you've got more appliances as paying more for the right to use it on more appliances at the same time.
Stephen
"Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall
As stated before in these posts an Intel chip with HT is not a dual core chip is definitely not, nor should it be regarded as a dual core chip. HT basically just presents two threads to the execution core at once but there is still only one execution core hence the one CPU license
There is no way that MS or Oracle etc... could get away with charging you double for a HT processor as it is in no way two CPU's at best you only get maybe 10-30% increase in performance.
It said "windows 98 or better" so I installed Linux
In the area that I work, in the early days of commercially available software, vendors tried to charge more when users wanted to move their software to faster machines. That idea did not last long and is now a distant memory.
It is? I thought Oracle still did that. OK, a quick glance at their web site tells me that they aren't, but it's within the last 5 years that they've stopped, I'm sure of that.
My E2900 with 4 US-IV cpu's:
app1:$ psrinfo
0 on-line since 07/14/2004 04:24:26
1 on-line since 07/14/2004 04:24:32
2 on-line since 07/14/2004 04:24:32
3 on-line since 07/14/2004 04:24:32
512 on-line since 07/14/2004 04:24:32
513 on-line since 07/14/2004 04:24:32
514 on-line since 07/14/2004 04:24:32
515 on-line since 07/14/2004 04:24:32
app1:$ uname -a
SunOS app1 5.9 Generic_117171-05 sun4u sparc SUNW,Netra-T12
you can bet your a$$ that Oracle, BEA, IBM and most other "Enterprise" software infastructure providers will charge based on the CPU count that the OS sees, not on the physical number of ceramic packages installed in the box.
Makes me wonder what the market for the 16 core cpu's will be -- free software: free of licensing restrictions. J2EE implementations be wary of licensing costs!
...yup...
"Eric Kuzmack, IT architect at newspaper conglomerate Gannett in Silver Spring, Md., says he deploys dual-processor systems to have hardware redundancy."
DOH!
Somebody needs to tell Eric that Dual-processor systems are for increased throughput. They offer no redundancy.
I know of no Intel based system that will continue to run with a failed processor. There are high-end machines that offer this as a feature, but this is not the reason you choose SMP.
Godalmighty, guys like this make me normal people look like geniuses.
Actually, windows 2000 doesnt handle HT properly - it will report your system as having two physical processors. XP will say 1 physical and 1 logical, as will Win2003.
. htme valua tion/performance/reports/hyperthread.asp
Intel themselves recommend you disable HT under win2k, see:
http://www.intel.com/support/platform/ht/os
http://www.microsoft.com/windows2000/server/
I am a viral sig. Please copy me and help me spread. Thank you.
At least on the i5 side of things...
As several folks have mentioned the POWER5 processor actually has two physical cores within it. As IBM licenses, each core is actually considered a processor.
On the newest i5 systems, say a 1/2 way box, we may have one of those two cores active at order time, and then later via Capacity on Demand, activate the second core, thus making it a 2-way box.
Now, there are some apps which have what is known as subcapacity licensing available. Meaning if I only use 2 CPUs of a 4 way for app x I only pay for 2. Yes this rounds up, so 2.5 = 3.
For i5/OS, the most common OS on the i5 - you pay for the number of cores (CPUs) which will run that OS. I could have a 2-way partitioned box, with one i5/OS partition and one Linux partition and only pay for 1 license of i5/OS. In fact that one license is included in the system cost.
The i5 systems (and p5 as well on the AIX side) have introduced the Dual Chip Module (DCM) for the 520, 550 (p5 only) and 570 systems. What was referred to on the p690 (and i890) with POWER4 is a Multi-Chip Module or MCM. The MCM could (can) hold 4 * POWER4(5) chips, and thus be an 8 way. For the 32 way systems, you place four of those guys.
The DCM idea is a bit different. For the 2/4 way 570, I have two modules in the box - and we activate whatever the customer wants. They could buy it as a 2-way today and then via CUoD upgrade the thing to a 3 way or 4 way later. Any use of i5/OS above the original 2 processors would incur an OS license charge.
Confused yet?
GlobalMind.
BTW - I don't work for IBM but am a part of the distribution channel, and spend my day designing i5 solutions, mostly with logical partitioning.
Um, yes, it is rather dodgy.
Do they charge you per MHz of the processor core you run on? Per MB of RAM? Why not -- faster cores and more memory means you can do more with their software! Should the 64-bit version cost twice as much as 32-bit? Or perhaps 2^32 times as much?
The fact is that you're paying the software vendor for the -software-, which is identical regardless of the number of CPUs you put it on. You pay the hardware vendor for the -hardware- that you run the software on. Granted, these may be the same people, but frankly I don't see why Oracle or Microsoft should get more money because I decided to pay IBM more money for a bigger machine to run Oracle/Windows on. They are essentially trying to have tiered pricing based not on what they are selling you, but rather based on how you plan to use what they sold you after you've bought it. That is dodgy.
The only comparison with the Evil Media Associations of America is that both situations arise because corporations can use their IP in legal if not ethical ways to extract more money from their customers.
Frankly, I'm not worried about it. Free software will eventually take care of all this 'per-cpu/core/bit' nonsense.
P.S. I ignored support contracts, which are a different beast altogether.
The enemies of Democracy are
Even if they did use a fair and accurate way to measure how much you can get out of the s/w on a given system, it would effectively be encouraging companies to use older/slower hardware.
This will never happen. Every time you upgrade anything, even add a new disk to the system, you'd need to get the machine benchmarked again. Otherwise companies would spec out a system with 8 fast cpus but only 256mb RAM and a single ata/33, 5K rpm IDE drive, get it benchmarked, then add in the other 32GB RAM and U320, 15k SCSI drives.
But it would make for great benchmark wars, the kind only seen nowadays when really big companies vie for the really big sales.
You'll only need to present them with the serial number on the device you'll be playing the media on. Then the media will be encoded so as to only play on that device. Once you actually play the media, the player will be able to detect who is present by noting the chips in the room. Anyone caught attempting to shield their chip implants will be in violation of Patriot Act IV and sent off to Guantanamo or Abu Ghraib, so you don't want to bypass that. But at least we'll have the Gigli Act on our side: we only pay for the time we spend watching it in 1 second increments, so if the movie sucks we don't have to pay as much.
Ah, the dismal future. The glorious, dismal future.
As you can see here , Microsoft chanrges a $4,999 US per processor(retail) for standard edition, and $19,999 US per processor (retail) for SQL Server Enterprise Edition.
If I go to install on a hyperthreading system, is the software going to go ahead and install, or does the software insist on "charging" me for a second cpu? i.e. what does Microsoft do so that I can pay for a one cpu license and install onto my one cpu hyperthreading system? Does the software detect that it is a single processor with hyperthreading?
The price of freedom is eternal litigation.
SQL Server came from Sybase 10, and since then has been significantly upgraded by Microsoft. When I worked for Tivoli doing tech support, we benchmarked each of the four databases supported at the time - Sybase 11, SQL Server 7, Oracle 7 I think, but maybe 6, and IBM DB2. Interestingly, the faster the databases were, the less scalable they were, without exception. SQL Server was the fastest of all four, but when you really jammed the database full of data (the whole purpose obviously) SQL Server slowed down more than any other database. Sybase was next fastest, and scaled slightly better. Then Oracle, which had good scalability but was significantly slower, and finally DB2, which started out slow, but never really got any slower at all. Time has marched by somewhat since then, and this might not be perfectly accurate any more of course.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
How about just reading the CPUID? It will tell you what kind of processor it is.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
True, but I doubt that a multi-core chip will be on par with a similar dual-cpu setup, you still need to get the heat away from that single cpu. It's very possible you will only get about the same 15-30% boost in speed you get from HT.
Your doubts are baseless. IBM's Power4 CPUs, which have been out a couple of years, don't have any such problem.
If heat becomes enough of an issue, exotic (for a PC/workstation) solutions exist already. For example, water cooling has been an established solution in mainframes for decades before PC enthusiasts adopted it.
From what I understand multi-core designs have all cores on a single piece of silicon at the center of the CPU just like uni-core CPUs.
Yes, it's a single piece of silicon with two separate CPUs on it.
Most /. readers should be really happy about per processor licensing by Oracle. By segmenting the market into business and home users, Oracle is able to offer Personal Oracle as a free download, charge businesses depending upon how much they use Oracle (on a per processor basis, but other schemes could work, MIPS-based, datavolume-based, etc.), and still make enough money to plow into development of new sourcecode. Yeah, they make money too - companies sometimes need to do that. But overall, the use of tiered pricing has enabled Oracle to really keep prices down (free being one example) at the low end of the market.
In the end analysis, isn't it right a corporation using Oracle to make millions of dollars a day running a call center should pay more for it than a small business using it to maintain a few thousand human resource records? And shouldn't both of them pay more for it than a hacker just wanting to learn it at home? And isn't the number of processors running those databases a very good analog to determine each of those intended uses? Given that, the desire to end per processor pricing just leaves me baffled, unless the original poster believes that GPL alternatives can ONLY succeed with the extinction of per-profit databases like Oracle...I like to think the marketplace will drive the acceptance of MySQL and the others simply on their own merits.
The thing you have to realize is that in modern processors, what few execution units exist are starved already. Adding more doesn't really make that much difference. The performance problems come from the caches, and we already build the fastest L1 caches we can for the single processor case.
While your statement "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?" is mostly correct, it really doesn't fully recognize just how hard the processor works to feed instructions into those execution units. A more accurate description would be: "I can get so many transistors on a chip; what's the best way I can maximize the number of instructions executed (amount of work done), by any number of threads, on those transistors?" Currently the best way is to have a few execution units, and a LOT of cache.
Getting back to your original point, in general, a processor is any number of threads that share an L1 cache. Whether that processor shares execution units with another one is really irrelevent, and probably wouldn't offer the performance benefits necessary to make the added complexity worth it.
There are designs for which this wouldn't apply, but they would be "throughput computing" designs with big, slow L1 caches that have *dismal* uniprocessor performance. With poor uniprocessor performance the "work done" per instruction executed starts to go down, so these designs have their own set of problems.
Mainframe ISV software is licensed by the number of mainframe MIPS licensed to the LPAR. A mainframe's performance capacity is metered out by a licensed throttle. The ISV software is aware of how much processing power is available, and the mainframe is aware how many MIPS the ISV application is licensed to use. It is true utility computing.
I am probably missing something here, and am, based upon the general feeling here, going to attract a lot of flame for this comment, but, here goes:
What on Earth is the problem here? Per-processor licencing already exists; it is a fact of business computing. All a multi-core processor is, is two processors in one physical package. You cannot just whack two processors together and pretend that it's just one; no matter what they're packaged in two processors is still two processors.
Many companies give leeway to HT enabled processors as they are, essentially, one real CPU that uses, as previous posts have stated, neat low level tricks to squeeze a bit of extra performance out in the form of a second logical processor. This does *not* apply to a second core, as it is a totally physical entity.
Please re-read my posting. I stated "In the area that I work": did I talk about databases? No. Did I mention Oracle? No. I am talking aout a completely different software field.
The real "Libtards" are the Libertarians!
just read that Oracle has recently changed their license explicitly to say that each core counts as a processor.