Slashdot Mirror
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?"
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.
no, but i bet linux can.
Oracle runs on Linux.
Oracle charges per CPU.
Your point was?
Agile Artisans
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
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
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.
multi-core means more than one physical chip. hyperthreading means more than one thread sharing resources in a single core. for example, the ibm power5 chip that just came out is a multi-core hyperthreaded chip, with 4 logical processors and 2 physical cores, on 1 total chip.
- tristan
Last time I looked Linux wasn't a DBMS. Oracle, SQL Server, DB2 they have per processor licensing. How will Linux stop this?
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".)
Oracle charges for cores individually. (see the Processor section)
Perhaps a compromise will result. Eventually a 2CPU license could entirely replace a single CPU license. At such a stage licenses could be bundled as 2CPU, 4CPU, etc. As multicores become the norm, naturally 1CPU licenses should phase out entirely.
This would allow companies to keep their per core licensing scheme. Customers would get the feeling of a deal by getting a muticore license. Perhaps the market would lower the cost of 2CPU license to what a single CPU would be worth.
HT is another matter - architecturally and performance-wise.
(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.
His point being:
Many Linux afficianados don't know the first thing about the software industry or how it works.
I thought this was fairly well communicated.
Hey freaks: now you're ju
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.
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.
I'm sure higher-end software will charge per physical chip if nothing else.
I am sure that newly licensed software will explicitly state whether it means physical chips or cores, but remember, companies exist to make money. By licensing per core instead of physical chip, they make more money. The software is the same no matter how many chips, only the price varies.
The real issue is how current licenses handle multiple cores per chip. This may wind up in the courts, or licensees may wind up being extorted for extra money they probably do not owe.
Despite being dead, BSD scales well with SMP and runs SMP apps very well, plus it is free. I know what license I will use...
24 beers in a case, 24 hours in a day. Coincidence? I think not!
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.
Losing money, normally gets a companies attention, that perhaps their customers think that their licensing is getting too expensive for them to consider Oracle.
I havn't looked into database pricing for a long time (ignoring MySql type "free" databases), but from what I remember, Oracle was one of the more expensive ones. Is it so now?
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)
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
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."
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.
Insulting linux zealots on slashdot? Think of your karma man!
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.
If I had modpoints, I'd mod you up. It's as silly as charging more for *the same car* depending on how many passengers you want to carry.
0: I need a car.
1: Sure, how about this little one? Only $14000!
0: Nice, my wife will love it!
1: It's for your wife?
0: No, but I give her a ride to work each morning.
1: Oh, you want to drive with your wife in it too? That'll be another $6000.
0: Huh? What do I get for the extra $6000?
1: Well, we remove the factory installed passenger door lock that your key doesn't fit.
0: That's it? I could do that myself!
1: Yes, but we require you to sign this form giving us permission to check your car whenever we like to make sure you haven't bypassed our security and aren't driving with unauthorised passengers. And if we suspect you have been doign so, we'll prosecute to the fullest extent of the law for misuse of our product.
0: But if I buy it, it's MY car!?
1: Yes, but the design and processes are still ours. You're buying a license to use the implementations provided with the car, and unapproved use with a passenger therefor illegal. The car is yours, but we still own it's usage...
Yes, arbitrary licensing and the current commercial software business model is complete BS.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
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?"
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.
But my Gov charges different road tax/license fees depending on the car engine's cubic capacity.
It does make the RX7 road tax rather cheaper. And I wonder how they'd deal with fuel cell electric cars.
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?
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?
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.
The #1 reason I don't use PostgreSQL is because I've no idea how to make it do NT integrated logins, and because the app I use doesn't use ODBC, but the SQL API directly.
Which sucks. I fucking hate this vendor. I wish I could spit in all their eyes and rub acid in them...
Hey shitheads, they invented ODBC for a reason, you know!!!
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.)
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...
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.