Is x86 architecture hampering performance?

[oconnect]

Most people in the world use some sort of MS Windows product on there computer. As we all know a requirement to run windows is to have a computer that is based on x86 architecture. I've heard from many people mentioning architecture that is far superior to x86. We've reached the point that if you?re not running x86 you don't have much a variety in applications you can run thus less you can do on your computer.

While I don't know a whole lot about other architectures I have heard there are/were better types of architecture that can beat our current architecture. What do you guys think?

 

[imported_michaelpatrick33]

x86 is a cludged twenty year old piece of crap and yet, and yet still it lives and now AMD has the gall to expand to 64bit and double the registers and widen the registers and clean out some of the old x86 cludge. Damn them! x86 is a CISC with RISC all around it but it is fast enough and coders are good at it now and as the Windoze 64 (excuse me Windows 64) comes out the extra 8 general purposeregisters visible to coders will help things along. It is good enough for me, I guess.

 

[n0cmonkey]

I like a lot of the other archs out there. I've got almost as many SUN machines as I have x86. But with AMD64 out there now, we have just about everything worthwhile from the other architectures out there. I'd still like to see a replacement for the BIOS though.

There is plenty of software out there for other archs too. You're limited to non-Windows though, unless you want Windows NT.

 

[imported_michaelpatrick33]

I think Intel and Microsoft are currently tryint to kill the current Bios in order to create a new Propietary, monopolized Prescott only Microsoft driven palladium like beast that will control you. Sorry blacked out there for a moment.

Seriously, there are movements by Microsoft and Intel to redo the bios

 

[n0cmonkey]

Originally posted by: michaelpatrick33
I think Intel and Microsoft are currently tryint to kill the current Bios in order to create a new Propietary, monopolized Prescott only Microsoft driven palladium like beast that will control you. Sorry blacked out there for a moment.

Seriously, there are movements by Microsoft and Intel to redo the bios

Interesting. Hopefully they go with an open firmware type solution, instead of an insanely proprietary one.

 

[cquark]

Originally posted by: n0cmonkey

Originally posted by: michaelpatrick33
I think Intel and Microsoft are currently tryint to kill the current Bios in order to create a new Propietary, monopolized Prescott only Microsoft driven palladium like beast that will control you. Sorry blacked out there for a moment.

Seriously, there are movements by Microsoft and Intel to redo the bios

Interesting. Hopefully they go with an open firmware type solution, instead of an insanely proprietary one.

They're going for insanely proprietary. See the "Trusted Computing" FAQ

 

[lexxmac]

I'm a huge mac fan and I love the way they do their systems. Everytime they come out with a new system they always have tear-downs of how the internal architechture works and are always willing to show you how to get the most of out their hardware. Open Firmware is one of my favorite features....

 

[CTho9305]

Originally posted by: oconnect
Most people in the world use some sort of MS Windows product on there computer. As we all know a requirement to run windows is to have a computer that is based on x86 architecture. I've heard from many people mentioning architecture that is far superior to x86. We've reached the point that if you?re not running x86 you don't have much a variety in applications you can runv thus less you can do on your computer.

Windows NT, up through Windows 2000 (beta 2?) ran on Digital's Alpha CPUs. But I get your point.

Originally posted by: michaelpatrick33
x86 is a cludged twenty year old piece of crap and yet, and yet still it lives and now AMD has the gall to expand to 64bit and double the registers and widen the registers and clean out some of the old x86 cludge. Damn them!

You would prefer losing all of your current applications, having to buy everything again, or using old applications with slow, less-reliable emulation? In 64-bit mode, x86 is relatively sane.

To answer the original poster's question - yes, I believe x86 hampers performance. Take a look at the K7 and K8 pipelines - for K7, stages 2, 3 and 4 would not be required in an instruction set with fixed-length instructions (e.g. MIPS). For very advanced MIPS designs, you'd still probably need some equivalent of stages 5/6, and all architectures need stage 1. This affects performance when you mispredict a branch and have to stop all the work you're doing and start over. A longer pipeline means more wasted work, and a longer delay until you've finished executing the first correct instruction.

Also, the extra x86 decode logic consumes chip area (increasing cost), and requires additional power.

One interesting design is a Trace Cache (found currently only in P4s, I think), which saves the work of decoding instructions once they've been decoded the first time. With a trace cache, after you've executed a set of instructions, they are saved in a decoded form for use in the future, so the next time around, instructions effectively only have to go through the pipeline starting at state 5 or 6, rather than 1. This is advantageous because instructions are fetched from memory as variable-length and densely packed (so they're generally only a couple bytes long), meaning a given amount of memory bandwidth can supply many more x86 instructions (1-15 bytes, but the vast majority are in the very small size range) per microsecond than the same memory could supply MIPS instructions (all are 4 bytes). Once the instructions make it to the trace cache, both the x86 CPU with trace cache and MIPs CPU without would probably need similar pipeline lengths.

This doesn't mean the backend of the x86 CPU is going to become as easy to design as the MIPs CPU. In x86, for example, you need hardware that can multiply 8 bits * 8 bits with a 16 bit result, 16b*16b and 16b result, 16b*16b and 32b result, 32b*32b with 32b result, and 32b*32b with 64-bit result. In MIPS32, I believe you just need 32b*32b with 64-bit result. This means you need to wrap a lot of extra logic around the x86 multiplier than you do for the MIPS one. That means extra delays, extra power usage, etc.

 

[imported_Nail]

You would prefer losing all of your current applications, having to buy everything again, or using old applications with slow, less-reliable emulation?

That's what happened with Mac OS X. In a year or two, you won't care about your old apps or have any use for emulation.

 

[CTho9305]

Originally posted by: Nail

You would prefer losing all of your current applications, having to buy everything again, or using old applications with slow, less-reliable emulation?

That's what happened with Mac OS X. In a year or two, you won't care about your old apps or have any use for emulation.

No. In Mac OS X, only system calls had to be translated. It's pretty much like using WINE to run windows binaries on Linux. Changing the instruction set requires emulation of every single instruction. In the case of doing something like WINE or OS X, actual number crunching still runs on the CPU at full speed - only things like accessing the network, opening files, etc has to be done differently. When you change the instruction set, instead of having an x86 CPU completing between 2 and 3 instructions per cycle, you have to spend maybe 5-10 native instructions per x86 instruction, and since those native instructions wouldn't be independent, you couldn't even execute them in parallel. Virtual PC for Mac did this, as does Bochs. VMware doesn't - it uses some smart tricks to run as much code as possible on the CPU at full speed.

edit: I wasn't a computer geek at the time, but the transition from M68k to PowerPC is probably a better example.

edit2: This would also be a problem for businesses. At the previous place I worked, we had everything from P2s running NT4 to P4s running 2000. If the next batch of machines bought didn't natively run standard software, or there was a performance hit for emulation or compatibility problems, that would not be acceptable.

 

[n0cmonkey]

Originally posted by: CTho9305

Originally posted by: Nail

You would prefer losing all of your current applications, having to buy everything again, or using old applications with slow, less-reliable emulation?

That's what happened with Mac OS X. In a year or two, you won't care about your old apps or have any use for emulation.

No. In Mac OS X, only system calls had to be translated. It's pretty much like using WINE to run windows binaries on Linux. Changing the instruction set requires emulation of every single instruction. In the case of doing something like WINE or OS X, actual number crunching still runs on the CPU at full speed - only things like accessing the network, opening files, etc has to be done differently. When you change the instruction set, instead of having an x86 CPU completing between 2 and 3 instructions per cycle, you have to spend maybe 5-10 native instructions per x86 instruction, and since those native instructions wouldn't be independent, you couldn't even execute them in parallel. Virtual PC for Mac did this, as does Bochs. VMware doesn't - it uses some smart tricks to run as much code as possible on the CPU at full speed.

Is that all it is to run a Classic app on OS X? It seemed much more complex the few times I tried it.

edit: I wasn't a computer geek at the time, but the transition from M68k to PowerPC is probably a better example.

PPC emulates m68k pretty well. The transition was supposedly quite easy.

edit2: This would also be a problem for businesses. At the previous place I worked, we had everything from P2s running NT4 to P4s running 2000. If the next batch of machines bought didn't natively run standard software, or there was a performance hit for emulation or compatibility problems, that would not be acceptable.

That's one of the big problems people can't get a grasp on when they say Sun should drop the SPARC line. It's a shame.

Oh, BTW, NT also ran on PPC and MIPS.

 

[CTho9305]

Originally posted by: n0cmonkey
Is that all it is to run a Classic app on OS X? It seemed much more complex the few times I tried it.

I'm guessing it's loading up the whole environment... old versions of shared libraries and so on.

edit: I wasn't a computer geek at the time, but the transition from M68k to PowerPC is probably a better example.

PPC emulates m68k pretty well. The transition was supposedly quite easy.

I think the PPCs were a lot faster than the M68ks. I don't think your x86-replacement is going to be that much faster than the x86 chip.

 

[Burbot]

Yes, x86 is full of useless and outdated crud. However, all this crud is one of it's most important features. since many people are willing to pay a lot of money to avoid architecture migration headache. Even if getting a fixed amount of perfomance out of x86 chip requires twice the effort of getting it from a New Amazing Architecture, millions of customers willing to pay for an x86 solution are going to bring in more then enough money to finance such an effort. And if x86 *does* eventually die from crud overload and some new bright and shiny architecture takes it place, the same thing will happen to it - it will start accumulate crud, since there are a lot more existing customers to be lost then new ones to be won. And then a Much Newer Shiny Architecture will come...

Think of architecture as a city. Yes, no matter what big city you take, a lot of things could be done better, but are now set in stone. The developers end up adding hacks upon hacks to fix some things. However, unless there is a Really Big Problem with the city (like Moebius highway exits), most people will stay in it, possibly moving to outer, more recent parts of it. Not many will abandon the city for some perfectly designed and delineated town. And if they would, after some time the perfect small town is going to turn into big, hacky megapolis once again.

 

[imgod2u]

Yes and no. Some people think that the ISA has little if nothing to do with performance anymore. In some ways, they're right. With modern MPU's, microarchitectural finess and a good memory subsystem will impact performance much more than the ISA would. Netburst pretty much proved that almost any ISA drawback (even complexity of decoding the instructions themselves) can be circumvented with clever methods.

The question being, everything else being equal, would we have much higher-performing processors if we didn't have to use x86? That's actually not as easily answered as you'd think it would be. x86, while ugly, and full of faults, has its advantages as well over RISC/EPIC. One such advantage is code density. x86 instructions take up less space and thus, more can be put into cache, less memory bandwidth is needed to read them, etc. And in an age where memory dominates performance, I'd say that's a pretty good advantage. The lack of registers has been fixed with x86-64, the decoding complexity has (somewhat) been fixed with a trace cache (although a trace cache has its disadvantages as well), and as most modern x86 MPU designers (especially the Netburst team) have found out, the best way to gain performance is to simply make all of the simple, commonly used x86 instructions go really really fast and the rest (the more complex and rarely used ones) go slow (not divote too much hardware to supporting them). This has effectively killed most of x86's disadvantages to the point where, despite the extra design complexity, performance isn't hampered by x86 anymore.

As for the future. We're seeing power become the next big performance hampering scheme. Design complexity (and therefore, power requirement) will become a dominant factor in the future and this may indeed by x86's downfall.

As for software compatibility, how many of you require full 3.2+ GHz P4 performance out of your older software? The amount of high-performance demanding software isn't as big (nowhere near I'd say) as the total amount of software in general. Most people could probably use emulation (and yes, emulation, developed with as much attention as an actual processor itself, works just as well as native in terms of reliability), with Word or IE and never notice the difference. Their high-performance demanding software (latest and greatest games, multimedia applications, etc.) will probably be ported to whatever new platform becomes dominant anyway.

 

[zephyrprime]

Yeah, x86 architechture sucks. Everyone knows that.

But with x86-64, at least we have some more registers to work with which is one of the biggest single drawbacks of the x86. Now if we could only get rid of the sucky FP stack the x86 architechture would actually be tolerable.

 

[imgod2u]

Originally posted by: zephyrprime
Yeah, x86 architechture sucks. Everyone knows that.

But with x86-64, at least we have some more registers to work with which is one of the biggest single drawbacks of the x86. Now if we could only get rid of the sucky FP stack the x86 architechture would actually be tolerable.

Already done, it's called SSE/SSE2/SSE3.

 

[CTho9305]

Originally posted by: imgod2u

Originally posted by: zephyrprime
Yeah, x86 architechture sucks. Everyone knows that.

But with x86-64, at least we have some more registers to work with which is one of the biggest single drawbacks of the x86. Now if we could only get rid of the sucky FP stack the x86 architechture would actually be tolerable.

Already done, it's called SSE/SSE2/SSE3.

One of the other threads here says Windows XP 64-bit requires that you use SSE instead of x87/MMX/3dnow!, so maybe we can ditch all of those in a few more years .

 

[Sunner]

Originally posted by: CTho9305
I don't think your x86-replacement is going to be that much faster than the x86 chip.

Madison's x86 emulation(or whatever you wanna call it) runs at something like 60-65 percent of it's native performance.
And Intel is aiming higher than that for future chips.

Maybe if Intel manages to increase the speed of IA-64 chips more rapidly than IA-32, they'll be a viable replacement in 5-10 years or so?
Of course IA-64's int performance isn't nearly as impressive as the fp performance, and a consumer grade IA-64 CPU wouldn't include 9 MB on die cache

Also, the fact that it's an entirely closed architecture makes it a very bad path as far as consumers are concerned, having AMD around to provide competition makes my interest in computers much more wallet-friendly

Oh well, time will tell.

 

[zephyrprime]

Already done, it's called SSE/SSE2/SSE3.

SSEn does not yet provide a full alternative to all the FP operations.

 

[imgod2u]

Originally posted by: zephyrprime

Already done, it's called SSE/SSE2/SSE3.

SSEn does not yet provide a full alternative to all the FP operations.

They do to some degree. Transcendentals can be replicated using system calls which use SSE scalar instructions instead of x87 transcendental calls. While this may be slower, transcendentals are rare in most code.

As for 80 bit extended precision. As I recall, that was done entirely internally. There is no 80 bit operand. So it isn't a matter of being able to handle a larger FP data type, it's simply a matter of different results. Which isn't to say it's neccessarily a bad thing.

 

[kautilya]

better to create a new scaleable and compatible architecture to ensure the legacy systems can still be used.

 

[jhu]

Originally posted by: imgod2u

Originally posted by: zephyrprime

Already done, it's called SSE/SSE2/SSE3.

SSEn does not yet provide a full alternative to all the FP operations.

They do to some degree. Transcendentals can be replicated using system calls which use SSE scalar instructions instead of x87 transcendental calls. While this may be slower, transcendentals are rare in most code.

As for 80 bit extended precision. As I recall, that was done entirely internally. There is no 80 bit operand. So it isn't a matter of being able to handle a larger FP data type, it's simply a matter of different results. Which isn't to say it's neccessarily a bad thing.

with that in mind, there's also no need for an fpu either since all fpu operations can be replicated using integer operations.

also, 80-bit extended precision can be used, but not under windows nt (or at least the last time i checked) due to compatibility with other architectures.

 

[imgod2u]

Originally posted by: jhu

Originally posted by: imgod2u

Originally posted by: zephyrprime

Already done, it's called SSE/SSE2/SSE3.

SSEn does not yet provide a full alternative to all the FP operations.

They do to some degree. Transcendentals can be replicated using system calls which use SSE scalar instructions instead of x87 transcendental calls. While this may be slower, transcendentals are rare in most code.

As for 80 bit extended precision. As I recall, that was done entirely internally. There is no 80 bit operand. So it isn't a matter of being able to handle a larger FP data type, it's simply a matter of different results. Which isn't to say it's neccessarily a bad thing.

with that in mind, there's also no need for an fpu either since all fpu operations can be replicated using integer operations.

The problem with that is that it's much slower. 64-bit SSE operations are generally not slower than x87. Internal precision simply follow IEEE floating point standards instead of the x87 standards. This isn't, again, neccessarily a bad thing.

 

[jhu]

the x87 is the ieee compliant. i wasn't aware of sse2 being ieee compliant, but perhaps i'm wrong.

also, sse2 is better than x87 for addition, subtraction, multiplication, and division. for anything else, it's worse.

 

[Sahakiel]

Last I checked, x87 is IEEE compliant. The internal 80-bit precision is not.