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.
it took 2 or really positive events (or maybe masterpieces of the applemanagement, if you like) that apple didn't get into deep shit. iMacs, G5, and iPod come to mind.
If Sun pulls something out of their hat, the same might happen. The difference is that MS or IBM don't need that to keep afloat.
No, it isn't. I think also I did not express myself clearly. I think it might be the database vendor who wants to have the possibility of independence from the host OS's filesystem implementation. Think Microsoft, NTFS and MSSQL. If I were Oracle I'd want to have this possibility as a door into the windows world, in order to make it not too easy for MS to tune the filesystem against my application (the same is true for IBM etc.) This might be less important today (and raw partitions are losing their importance), but for a long term strategy which began 5 to 10 years ago, it's quite evident, IMO.
Those that want raw partition access, IMO, are simply living in the past.
Or do it because their corporate strategy is to be independent on filesystem implementations in the OSs their db runs on (maybe just in case the vendor screws up or his new filesystem performs bad with oracle etc.). Also not important for postgres.
To add some freakish numbers (source, oh, and lets not discuss Mr. ferrari)
VAM (Vm/h) Vertical Metres Per Hour (Vm/h)
1800+ Vm/h: Lance Armstrong - and Pantani of olden days 1650-1800 Vm/h: Top 10 / TdF GC or mountain stage winner. 1450-1650 Vm/H: Top 20 / TdF GC; top 20 on tough mountain stage. 1300-1450 Vm/h: Finishing TdF mountain stages in peloton 1100-1300 Vm/h: The Autobus Crew
This means that Armstrong has the ability to climb 1800 meters altitude in one hour. Btw. this translates to more or less 500 Watts power output for one our.
No, they do not require more CPU. Several parts of our application actually run faster than the C version. I credit the Hotspot on-the-fly optimization crap for this to some degree, but I'm honestly not sure what the deal is. (And I'm our profiling guy. Ain't that sad?:-)
Maybe it's the fact that java has a far better standard library that makes the new application faster. I often see C programmers confusing the C language's potential(!) for higher speeds somehow with their programming skills, and they seem to be suffering alot more from the not-invented-here syndrom.
"still out there" != on Bruce Peren's website, you know.
I didn't know about that TIGER stuff.
Remember Mr Perens
on
Open Maps?
·
· Score: 4, Informative
Bruce Perens once bought a data set of AFAIK exactly what you want from his own money and put it on his server for free use. Look here http://perens.com/FreeSoftware/ Though I didn't get into the ftp server, I'm sure the files are still out there.
What people need to understand is that back then people could get into huge arguments about thinks like microkernel vs monolithic and not really hate one another.
"back then" == Outside slashdot
Microkernel is not dead. I want to see an OO based OS.
Sure, we have emacs, so why not an OS based on OpenOffice?;)
Does this guy know how much energy that goes into mining the Uranium? (Clue: Quite alot)
I don't one can successful argue against nuclear energy with scientific or economical reasons. I think nuclear power _is_ the best option we have if everything goes like it should. I am even willing to accept that the economical and safety and deposit issues are solved. But I think one has to include a "politic" or "social" component. Fact is, there are many interfering factors which you can't eliminate. For instance, there are criminals, and there's a lot of money to be made if you are a criminal in the nuclear industry. Not only weapons stuff, but also not caring for security as you should, or illegally deposing nuclear waste (there's a lot of contaminated stuff to be deposed).
With nuclear power, in my opinion, the cost of a "failure" like described above in the whole system (which is bound to happen, make no mistake) is just too expensive.
Hey, don't forget the fsking IDLE process of the OS, which always takes up 99% of my CPU. It would be a huge boast if this could be offloaded to a seperate processor.
Re:Why is ADTI's (and MS's) FUD so obvious?
on
More From Tanenbaum
·
· Score: 1
Because in other domains, every FUD target has much more enemies, and thus parties who might be the hidden originator of the FUD. Therefore it's harder to track down the "covert" attacker.
When it comes to FUD against linux, there's really mostly MS as someone who can profit from this. Who else? One could quickly check if SUN is behind an attack, but then?
This is partly created by Microsoft, by destroying all direct competitors and by creating an atmosphere in the industry where nearly everyone profits if Microsofts looses, thus they have no natural allies. Even MS-only application providers are very aware of their weak position.
And partly it's because of the GPL, because everyone of the competing entities in the Linux game profits if Linux profits, therefore making fights about/against the codebase itself pointless.
But it's the most logical way to go. If you buy players from your direct rival (i.e. same league), you get approx. double the benefit. 1. Strenghten your team, 2. Weaken your rival's team.
But currently Opteron, Power4 or even Pentium IV Procs _all_ outperform anything Sun has to offer - in terms of the CPU speed, mind you. One core of the Power4 is nearly twice as fast as the fastest _available_ Sparc Proc. See? Intel and IBM are late to the game because they didn't see the need to be earlier. The gap between Sparcs and other CPUs has been getting bigger and bigger. It will come to the point where even the most loyal customers won't be able to justify buying Sun equipment because they are so damn slow per dollar spend. And don't tell me about high I/O and stuff, IBM's offers in that area also aren't too shabby.
Yes, Sun may be a little bit farther in putting as much cores as possible in one CPU, the point is that CPUs are measured by real-world performance, not by number of cores.
It's the same thing that's been happening for the last decade. As x86 slowly creeps in on Sun/IBM/Whatever's market, they have to come up with something "bigger".
This is not bigger. Taken to the extreme, this is like if Commodore was still in business and tried to sell computers with 2^32 6502 procs. Look at the chart in the article to see how desperate Sun is: They admit that existing Opterons Xeons not only kick the ass of their newest, existing architecture for a single thread, they also concede that even their not-existant future proc won't even be faster for single threaded apps. Ok, you say, but it is faster for multithreaded apps. The only problem with that is that I bet that a recent multiproc Opteron/Xeon will give the future Sun architecture a run for its money. And IBM/Intel won't have any problems building multicore procs, if they want. They just don't need to, at the moment. IOW, looking at this chart one might ask himself why tSun even tries to build processors nowadays.
So, with the necessary Solaris installed, your existing Tomcat running on your existing JVM will see all the benefits.
Not it won't. At least not so simply. It will see the benefits if there are enough concurrent threads running (as you said), and even that if these are not waiting for each other. So it will work for many clients at once. I have my doubts that this architecture will help with most real world tasks - even real world server tasks - even with completely blown out of proportion threading like java seems to lead people to. Let's face it, the reason Intel or IBM are not going into that direction that far are not that they couldn't if they wanted to. It's more that they still have other tricks in their sleeves to ramp up their processor power, and Sun hasn't - or can't afford them. For me this is the last desperate attempt from Sun to prolong their relevance in the processor arena.
Hmm, can someone who knows this stuff comment on how these guys want to get to these unbelievable throughput numbers? I vaguely remember there's something like Shannon's law, and a crude calculation should be able to show that wireless (4G) 100mbits per user is quite a feat in high populated places. Wouldn't they at least need a ridicoulous small meshed antenna infrastructure? How about energy consumption of mobiles with these high frequencies? What I'm looking for is some principal, simple calculations casting some doubt on the thought that wireless throughput is as scalable as processor power.
There's no "basically" or "relatively" or "almost" lossless! If it's not lossless, it's lossy.
Well, in that special case, it "lossless" might even be correct, for a special quality of lossless. It might mean that concatenation of encoding transformations is a transitive operation, i.e.
downcode_to_a(downcode_to_b(original)) = downcode_to_a(original) for quality parameters a < b
.
In that sense, downcoding to b would have been "lossless", since normally concatenated downcoding would lead to worse quality.
The way it works now is amd pays intel for the "intellectual property" they use, but the agreement favors intel as they don't have to pay amd for copying their technology. Don't you just love our legal system?
Bullshit, that's just how it should be. Intel ownes (owned) the x86 market, so AMD can be happy to be allowed to use Intel "technology". OTOH, AMD can be happy to not have to pay Intel to "adopt" their technology, because otherwise no proprietary software package would use AMD's extensions.
All in all, we can be glad for the existance of linux and also OS X, because that pressured Microsoft to contemplate supporting x86-64 even against Intel, for fear that they might loose the high-end x86 server market. Surely Microsoft did a lot of behind-the-scenes "convincing" with the Intel management. OTOH, without a proprietary OS dominating the market, we probably could choose between a whole lot of competing CPU-architectures without thinking about stuff like "binary compability".
It is fairly well-known to insiders that Dave Cutler, chief software architect for Windows NT at Microsoft, approached AMD with the concept of extending the x86 instruction set for 64-bit instructions and data.
Interesting, that would be the link Cutler -> DEC -> Alpha -> Compaq -> AMD.
They want to make sure that the OS they are buying with their million dollar setup is supported by the vendor for at least 10 years.
For that you need the vendor to still be existant in 10 years, and a growing number of people have their doubts if that's the case with sun... Really, in the market of servers with around 4 procs, people are getting rid of their old sun boxes like mad, and more than a handful think sun is doomed.
Slashdot Mirror
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.
Well, knowing what I know about SCO (only what I read here and on groklaw)
Dude, then you know probably more than SCO's lawyers.
But you must admit,
it took 2 or really positive events (or maybe masterpieces of the applemanagement, if you like) that apple didn't get into deep shit. iMacs, G5, and iPod come to mind.
If Sun pulls something out of their hat, the same might happen. The difference is that MS or IBM don't need that to keep afloat.
No, it isn't. I think also I did not express myself clearly. I think it might be the database vendor who wants to have the possibility of independence from the host OS's filesystem implementation. Think Microsoft, NTFS and MSSQL. If I were Oracle I'd want to have this possibility as a door into the windows world, in order to make it not too easy for MS to tune the filesystem against my application (the same is true for IBM etc.)
This might be less important today (and raw partitions are losing their importance), but for a long term strategy which began 5 to 10 years ago, it's quite evident, IMO.
Those that want raw partition access, IMO, are simply living in the past.
Or do it because their corporate strategy is to be independent on filesystem implementations in the OSs their db runs on (maybe just in case the vendor screws up or his new filesystem performs bad with oracle etc.). Also not important for postgres.
considering racing on two wheels is much harder than four, i would expect him to out drive any f1 driver, if given the chance.
I also think so, NOT!
To add some freakish numbers (source, oh, and lets not discuss Mr. ferrari)
VAM (Vm/h) Vertical Metres Per Hour (Vm/h)
1800+ Vm/h: Lance Armstrong - and Pantani of olden days
1650-1800 Vm/h: Top 10 / TdF GC or mountain stage winner.
1450-1650 Vm/H: Top 20 / TdF GC; top 20 on tough mountain stage.
1300-1450 Vm/h: Finishing TdF mountain stages in peloton
1100-1300 Vm/h: The Autobus Crew
This means that Armstrong has the ability to climb 1800 meters altitude in one hour. Btw. this translates to more or less 500 Watts power output for one our.
No, they do not require more CPU. Several parts of our application actually run faster than the C version. I credit the Hotspot on-the-fly optimization crap for this to some degree, but I'm honestly not sure what the deal is. (And I'm our profiling guy. Ain't that sad? :-)
Maybe it's the fact that java has a far better standard library that makes the new application faster. I often see C programmers confusing the C language's potential(!) for higher speeds somehow with their programming skills, and they seem to be suffering alot more from the not-invented-here syndrom.
"still out there" != on Bruce Peren's website, you know.
I didn't know about that TIGER stuff.
Bruce Perens once bought a data set of AFAIK exactly what you want from his own money and put it on his server for free use. Look here
http://perens.com/FreeSoftware/
Though I didn't get into the ftp server, I'm sure the files are still out there.
Very nice and forthlooking of him.
What people need to understand is that back then people could get into huge arguments about thinks like microkernel vs monolithic and not really hate one another.
;)
"back then" == Outside slashdot
Microkernel is not dead. I want to see an OO based OS.
Sure, we have emacs, so why not an OS based on OpenOffice?
SCNR
Does this guy know how much energy that goes into mining the Uranium? (Clue: Quite alot)
I don't one can successful argue against nuclear energy with scientific or economical reasons.
I think nuclear power _is_ the best option we have if everything goes like it should. I am even willing to accept that the economical and safety and deposit issues are solved.
But I think one has to include a "politic" or "social" component.
Fact is, there are many interfering factors which you can't eliminate. For instance, there are criminals, and there's a lot of money to be made if you are a criminal in the nuclear industry. Not only weapons stuff, but also not caring for security as you should, or illegally deposing nuclear waste (there's a lot of contaminated stuff to be deposed).
With nuclear power, in my opinion, the cost of a "failure" like described above in the whole system (which is bound to happen, make no mistake) is just too expensive.
Hey, don't forget the fsking IDLE process of the OS, which always takes up 99% of my CPU. It would be a huge boast if this could be offloaded to a seperate processor.
Because in other domains, every FUD target has much more enemies, and thus parties who might be the hidden originator of the FUD. Therefore it's harder to track down the "covert" attacker.
When it comes to FUD against linux, there's really mostly MS as someone who can profit from this. Who else? One could quickly check if SUN is behind an attack, but then?
This is partly created by Microsoft, by destroying all direct competitors and by creating an atmosphere in the industry where nearly everyone profits if Microsofts looses, thus they have no natural allies. Even MS-only application providers are very aware of their weak position.
And partly it's because of the GPL, because everyone of the competing entities in the Linux game profits if Linux profits, therefore making fights about/against the codebase itself pointless.
But it's the most logical way to go. If you buy players from your direct rival (i.e. same league), you get approx. double the benefit.
1. Strenghten your team, 2. Weaken your rival's team.
Who wouldn't prefer that?
But currently Opteron, Power4 or even Pentium IV Procs _all_ outperform anything Sun has to offer - in terms of the CPU speed, mind you.
One core of the Power4 is nearly twice as fast as the fastest _available_ Sparc Proc.
See? Intel and IBM are late to the game because they didn't see the need to be earlier. The gap between Sparcs and other CPUs has been getting bigger and bigger. It will come to the point where even the most loyal customers won't be able to justify buying Sun equipment because they are so damn slow per dollar spend. And don't tell me about high I/O and stuff, IBM's offers in that area also aren't too shabby.
Yes, Sun may be a little bit farther in putting as much cores as possible in one CPU, the point is that CPUs are measured by real-world performance, not by number of cores.
It's the same thing that's been happening for the last decade. As x86 slowly creeps in on Sun/IBM/Whatever's market, they have to come up with something "bigger".
This is not bigger. Taken to the extreme, this is like if Commodore was still in business and tried to sell computers with 2^32 6502 procs.
Look at the chart in the article to see how desperate Sun is:
They admit that existing Opterons Xeons not only kick the ass of their newest, existing architecture for a single thread, they also concede that even their not-existant future proc won't even be faster for single threaded apps.
Ok, you say, but it is faster for multithreaded apps. The only problem with that is that I bet that a recent multiproc Opteron/Xeon will give the future Sun architecture a run for its money.
And IBM/Intel won't have any problems building multicore procs, if they want. They just don't need to, at the moment.
IOW, looking at this chart one might ask himself why tSun even tries to build processors nowadays.
So, with the necessary Solaris installed, your existing Tomcat running on your existing JVM will see all the benefits.
Not it won't. At least not so simply. It will see the benefits if there are enough concurrent threads running (as you said), and even that if these are not waiting for each other. So it will work for many clients at once.
I have my doubts that this architecture will help with most real world tasks - even real world server tasks - even with completely blown out of proportion threading like java seems to lead people to.
Let's face it, the reason Intel or IBM are not going into that direction that far are not that they couldn't if they wanted to.
It's more that they still have other tricks in their sleeves to ramp up their processor power, and Sun hasn't - or can't afford them.
For me this is the last desperate attempt from Sun to prolong their relevance in the processor arena.
Hmm, can someone who knows this stuff comment on how these guys want to get to these unbelievable throughput numbers?
I vaguely remember there's something like Shannon's law, and a crude calculation should be able to show that wireless (4G) 100mbits per user is quite a feat in high populated places. Wouldn't they at least need a ridicoulous small meshed antenna infrastructure? How about energy consumption of mobiles with these high frequencies?
What I'm looking for is some principal, simple calculations casting some doubt on the thought that wireless throughput is as scalable as processor power.
Well, in that special case, it "lossless" might even be correct, for a special quality of lossless.
It might mean that concatenation of encoding transformations is a transitive operation, i.e..
In that sense, downcoding to b would have been "lossless", since normally concatenated downcoding would lead to worse quality.
The way it works now is amd pays intel for the "intellectual property" they use, but the agreement favors intel as they don't have to pay amd for copying their technology. Don't you just love our legal system?
Bullshit, that's just how it should be. Intel ownes (owned) the x86 market, so AMD can be happy to be allowed to use Intel "technology".
OTOH, AMD can be happy to not have to pay Intel to "adopt" their technology, because otherwise no proprietary software package would use AMD's extensions.
All in all, we can be glad for the existance of linux and also OS X, because that pressured Microsoft to contemplate supporting x86-64 even against Intel, for fear that they might loose the high-end x86 server market. Surely Microsoft did a lot of behind-the-scenes "convincing" with the Intel management. OTOH, without a proprietary OS dominating the market, we probably could choose between a whole lot of competing CPU-architectures without thinking about stuff like "binary compability".
It is fairly well-known to insiders that Dave Cutler, chief software architect for Windows NT at Microsoft, approached AMD with the concept of extending the x86 instruction set for 64-bit instructions and data.
Interesting, that would be the link Cutler -> DEC -> Alpha -> Compaq -> AMD.
A google check confirms this.
They want to make sure that the OS they are buying with their million dollar setup is supported by the vendor for at least 10 years.
...
For that you need the vendor to still be existant in 10 years, and a growing number of people have their doubts if that's the case with sun
Really, in the market of servers with around 4 procs, people are getting rid of their old sun boxes like mad, and more than a handful think sun is doomed.
I didnt even read your post since you seem to think smokers have a handicap. (yes I am talking about weed)
...
What if he wasn't talking about weed. Crack comes to mind
Alas, while I'm in doubt about the "easily assimilated" part, they have a lot of reports there att ing/
http://www.osdl.org/lab_activities/kernel_tes
Just look around there.