4 ms·

Oracle has brilliant opportunities at the moment: they own a great processor (Sparc) that they could closely integrate with their database, application software

by 10ren 16y ago

Oracle has brilliant opportunities at the moment: they own a great processor (Sparc) that they could closely integrate with their database, application software and even Java... and (finally!) give IBM a run for their money. They have the cool and fast technology of both Sun's JVM and BEA's JVM (JRockit). They have acquired other brilliant technologies, and have in practice endless resources to acquire more: http://en.wikipedia.org/wiki/List_of_acquisitions_by_Oracle http://en.wikipedia.org/wiki/List_of_acquisitions_by_Oracle http://www.oracle.com/us/corporate/acquisitions/index.html http://www.oracle.com/us/corporate/acquisitions/index.html But... although it's simple to appreciate the advantages of combining technologies, it's very very hard to actually do. For example, the IBM 360 project, of a series of machines of increasing power (and price), that were all compatible, so customers could upgrade, is a simple idea. But implementing this was a bet-the-company project, it was celebrated as an incredible, miraculous achievement, and the lessons learnt from it remain popular to this day (The Mythical Man Month, by the leader of the 360 project, Fred Brooks.) To pull off these technical feats, you need the public superstar developers, but also the hidden superstar developers (the x100 coders; the people who, after working closely with them for a while, you observe, oh that guy's a genius); and then the x10 coders, who want to hang out with the geniuses and learn from them. It's places like HP used to be, where Woz wanted to work, at almost all costs (Woz himself being a x100 guy.) If you only have x5 or x7 coders; and if you don't support them (with infrastructure, secretarial etc - not just compensation, adequate decision-making power, and some kind of recognition.), then, well, you can't do these technical feats. You may seek but not find; ask but it shall not be given; knock but it shall not be opened. Though this is not a disruptive issue, the same factors occur of the difficulty for an established successful company to change its culture and business architecture. And Oracle doesn't want to change anyway.

Tamerlin 16y ago
" they own a great processor (Sparc)" I'm not so sure about that. For years x86 has been chewing up the market for Sparc processors, and one of the reasons that Sun had such poor finances is that it was selling x86-based servers more than Sparc based servers (they cost considerably less, and perform better). Fujutsu's Sparc implementation significantly outperforms Sun's. Contemporary Xeons outperform both these days. Besides, Sun has had a long history of massive screwups -- and they put "don't tell anyone we screwed up" clauses in their support contracts. One company just gave up when they got their UltraSPARC3 rig, found that not only was it not nearly performant enough to meet expectations, but also in order for it to function reliably, they had to disable the 2nd level cache on every CPU, or else a cache glitch would bring down the entire server (32 procs). It's not a great processor. It hasn't been for a long time. Sun has been the "flock of chickens" vs the POWER "bull" as a result.
- deleted 16y ago
  [deleted]
- rbanffy 16y ago
  > One company just gave up when they got their UltraSPARC3 rig On the other hand, the Niagara family seems very interesting. Sadly, never had the chance to characterize its performance under my loads, but I suspect there is a lot of stuff they can do better than the same price x86 box. A T3, with its many multi-threading cores resembles much more a "flock of chickens" than a Xeon does.
- brisance 16y ago
  Gosling also wrote about being at the mercy of suppliers impacting SPARC and it probably contributed to the problems. http://nighthacks.com/roller/jag/entry/at_the_mercy_of_suppliers http://nighthacks.com/roller/jag/entry/at_the_mercy_of_suppl...
  - hga 16y ago
    Do some Googling and mroe reading and you'll find their problem was that they cut costs by assuming the memory supplied was perfect and that they didn't need to include parity checking or error detection and correction. This is the UltraSPARC3 problem that Tamerlin is talking about.
- jbarham 16y ago
  For those who don't get the chickens vs. bulls reference: "If you were plowing a field, which would you rather use?... Two strong oxen or 1024 chickens?" - Seymour Cray There are a lot of other great Cray quotes.
  - sprout 16y ago
    Of course, look at any modern Cray ads and Cray is using the same 1024 chickens everyone else in the livestock industry is using. Sparc isn't failing because it's inferior to x86. Sparc is failing because Solaris is failing, and no other OS is built from the ground up for Sparc. You can run Linux and other Unix-likes on it, but given the choice between x86 and Sparc, you choose x86 because that's what's least likely to cause incompatibility issues.

by 10ren 16y ago

Tamerlin 16y ago

" they own a great processor (Sparc)" I'm not so sure about that. For years x86 has been chewing up the market for Sparc processors, and one of the reasons that Sun had such poor finances is that it was selling x86-based servers more than Sparc based servers (they cost considerably less, and perform better). Fujutsu's Sparc implementation significantly outperforms Sun's. Contemporary Xeons outperform both these days. Besides, Sun has had a long history of massive screwups -- and they put "don't tell anyone we screwed up" clauses in their support contracts. One company just gave up when they got their UltraSPARC3 rig, found that not only was it not nearly performant enough to meet expectations, but also in order for it to function reliably, they had to disable the 2nd level cache on every CPU, or else a cache glitch would bring down the entire server (32 procs). It's not a great processor. It hasn't been for a long time. Sun has been the "flock of chickens" vs the POWER "bull" as a result.

deleted 16y ago
[deleted]
rbanffy 16y ago
> One company just gave up when they got their UltraSPARC3 rig On the other hand, the Niagara family seems very interesting. Sadly, never had the chance to characterize its performance under my loads, but I suspect there is a lot of stuff they can do better than the same price x86 box. A T3, with its many multi-threading cores resembles much more a "flock of chickens" than a Xeon does.
brisance 16y ago
Gosling also wrote about being at the mercy of suppliers impacting SPARC and it probably contributed to the problems. http://nighthacks.com/roller/jag/entry/at_the_mercy_of_suppliers http://nighthacks.com/roller/jag/entry/at_the_mercy_of_suppl...
- hga 16y ago
  Do some Googling and mroe reading and you'll find their problem was that they cut costs by assuming the memory supplied was perfect and that they didn't need to include parity checking or error detection and correction. This is the UltraSPARC3 problem that Tamerlin is talking about.
jbarham 16y ago
For those who don't get the chickens vs. bulls reference: "If you were plowing a field, which would you rather use?... Two strong oxen or 1024 chickens?" - Seymour Cray There are a lot of other great Cray quotes.
- sprout 16y ago
  Of course, look at any modern Cray ads and Cray is using the same 1024 chickens everyone else in the livestock industry is using. Sparc isn't failing because it's inferior to x86. Sparc is failing because Solaris is failing, and no other OS is built from the ground up for Sparc. You can run Linux and other Unix-likes on it, but given the choice between x86 and Sparc, you choose x86 because that's what's least likely to cause incompatibility issues.