Oracle tunes Solaris for Intel's big Xeons

Re: M Series Hot Plug CPUs

True, the M4000 and M5000 don't support hot swap of cpu/memory boards. I think they did this as a cost savings for the midrange Sparc64 based systems since it wasn't a feature most people used on the SunFire midrange line. Just look at the cost of a M8000/9000 cpu/mem board compared to a M5000.

You can still however use hardware domains on the M4000 and M5000 servers and DR components around between the domains. But you will need an outage if you have to replace a component that failed.

x86 hoovers ...

... them all up. If that's what you mean by "sucks", I fully agree.

Instruction set these days are much less of a distinguisher than they used to be. You say "transistor count" - well, add two million or so additional transistors to the next-gen x86 for improvements on the CISC decoder stages, i.e. roughly quadruple them - that's far less than 0.1% of the total additional transistor budget for a new-gen CPU (remind me, how many billions of transistors does a 8-core chip have ?). In the big picture of things, having 1 million or 10 million transistors doing instruction predecoding, so what. There's orders of magnitude more in caches, buffers, interlinks and other glue these days.

If instruction efficiency were really key to the success of anything, then we'd never have seen Java get to where it is - the bytecode being a stack machine is just about as hardware-implementation-scalability unfriendly as could be. Who (apart from JVM/JIT implementors that have both my pity & admiration) cares ?

Also, wrt. to what current x86/x64 actually are:

First, both Intel as well as AMD have used RISC engines in their cores for many years (variously called my-ops, micro-ops, R-Ops or some such), including superscalar/VLIW-style instruction bundling. The x86 instruction set compatibility is only a shim layer.

Second, current x86 optimization guides by both Intel and AMD actually state (if phrased less in-your-face): You want this thing fast, use simple instructions, order them for no/little interdependency - in short, use RISC, the x86/x64 bits mapping 1:1 to what the low-level engine does are by far the best for you.

Third, agreed that x86/x64 may have a few thousand instructions (the instruction set reference manuals have 1600+ pages these days). But have you ever made the experiment how many of them are indeed used in executable binary code on your systems ? When teaching low-level debugging and x86 assembly language, one of my favourite experiments was to let students write a little perl script that found all ELF i386/x64-64 executables, disassembled the code, sorted by instruction and then created an instruction set histogram. Invariably, one found that 99.9% were made up from a set of no more than about 50 opcodes. Programming a CPU using only ~50 instructions, where have I heard that before ? Ah - yes, I think it's called "RISC".

That's not to say splashing resources and giant transistor counts all over it is the only way to get decently-performing CPUs. It's just the one that, by experiment, in the last 20 years has proven to create the best-performing server / workstation class CPUs. But you only need to look beyond that space, what do you see ? Set-top boxes, mobile phones, tablet devices, consoles, the entire "embedded" space uses MIPS, ARM, PPC and other, elsewhere forgotten/abandoned architectures. And Intel's attempt to push x86 into that space isn't anywhere near as simple as Intel dreamt it to be.

To sum this up:

x86/x64, in the high-end, "stationary" systems space, has proven to be just about efficient and performant enough to beat everything else. There, it sucks ... up all the competitors.

x86/x64, in the mobile/embedded space, never made inroads. There SoC solutions, tiny power/thermal/form factors are mandatory, and implementors want to license modular designs to combine cores, graphics, comms etc. into a single package. Off-the-shelf components there are frowned upon. Here, x86 sucks.

Gosh, you're right after all. No matter how you look at x86/x64, it always sucks !

except POWER?

Are you sure? I'm underwhelmed by the performance of the Power5/6's at work given their massive ghz lead.

They sure don't feel fast, maybe its something else that slows them down, maybe the LPAR tech itself, or maybe its the downtime to rejig that flaky interconnect that needs reseating every few months?

jlocke

"...Mr Kebap, living up to your reputation as a food with rotten meat, I suggest you check your facts...." Well, I suggest you check up YOUR facts. I have always explained that I am able to backup whatever I claim. You, OTOH makes unsubstantiated claims and is therefore revealed as a Liar and someone who can not back up your "facts". It is even better when you accuse a mathematician with double Masters degree that always talks about the importance of being able to prove one's claims. In the future, a hint: dont FUD about a mathematician that he is does not know what he is talking about, ok? It only makes you look silly, when he is able to show links that back ups his claim, which you have denied.

.

"...Indeed x86 is an old instruction set, but neither Intel nor AMD has problems with delivering chips that do what they are intended to..." You clearly have never heard about the many bugs that x86 has had. AMD has had many bugs, for instance, AMD could not release their first true quad core Phenom because of a TLB bug. A quick googling shows:

http://en.wikipedia.org/wiki/AMD_Phenom

And intel also had lots of bugs. You missed the excel division bug?

http://en.wikipedia.org/wiki/Pentium_FDIV_bug

Earlier, Intel had to with draw all Pentium(?) cpus and swap them for bug free ones. You missed that too? It costed lots of money. If I really took time and googled, I could present you many links showing a list of many expensive bugs in x86 for you. But I am not convinced that list would make you change your mind.

In fact, an Intel engineer said about Phenom TLB bug that "intel has much worse bugs, I dont understand the fuzz about TLB bug, it is nothing". I think there is a huge list showing all bugs in intel x86 somewhere?

.

Here are people complaining about all the bloat in the buggy x86 instruction set, and it should be cleaned up:

http://www.anandtech.com/show/3593

- The total number of x86 instructions is well above one thousand" (!!)

- "CPU dispatching ... makes the code bigger, and it is so costly in terms of development time and maintenance costs that it is almost never done in a way that adequately optimizes for all brands of CPUs."

- "the decoding of instructions can be a serious bottleneck, and it becomes worse the more complicated the instruction codes are"

- The costs of supporting obsolete instructions is not negligible. You need large execution units to support a large number of instructions. This means more silicon space, longer data paths, more power consumption, and slower execution.

.

There are managers that never would let x86 into their computer halls. You clearly have missed that, too. Totally off from reality. Jeez.