Performance Discussion - The Biggest Bottleneck

Quote:

---

Originally posted by zombor:
i was just thinking about this in class:
what if someone built a PC that was all on die exept for the hard drive off course. Think about it...the proc would have direct access to the gpu, the ram, sound card, everything...sure you wouldnt be able to upgrade it at all, but wouldnt it be alot faster than having to go thru busses to et to everything? Just an idea

---

What you refer to has been branded by computer architects as the SoC processor (System on a Chip). SiS is coming out with a form of SoC processor, which has integrated video, sound, northbridge, and southbridge. VIA is making a Cyrix processor with integrated video, sound, and northbridge. Intel's Timna processor was supposed to integrate video and northbridge, and just because that project was cancelled, I don't think you'll see the last of that technology.

Right now, integrating DRAM is a very difficult task. Nintendo has managed to create a platform called the Gamecube, which will be its next generation console, and that will be using integrated DRAM. However, it will only be 24MB. It will take semiconductor manufacturers a long time before larger amounts will be able to be integrated inexpensively. Though, they might start by including a small amount of embedded DRAM (say, 16 or 32MB), to act as an L3 cache, perhaps.

Zombor, what you say is true! Integration is in the future for both high and low performance systems.

but is there that much of a speed increase in these integrated systems? Id think there would be due to the speed jump with moving L2 ondie. And if everything was integrated, nobody better realase a new system every 3.546 days https://www.sharkyforums.com/images/.../2005/06/6.gif

------------------
Compaq Armada E500
650MHz PIII 128MB RAM
8MB ATI rage mobility
11GB hard drive/DVD
dual booting win98/2k

who said you cant game on a notebook????

A few words about Motherboards and Ram.

Up until about 7 years ago motherboard speed kept up with processor speed. This has changed a lot and I'd like to take a few minutes to discuses why. But first some history.

When the IBM XT came out the ISA bus could be used as an expansion port to add additional RAM. It didn't take all that long before RAM outpaced the ISA bus but for many years RAM and Motherboards at least kept up with the FSB of the processor even if it took some latency hits along the way.

Back in the 486 days we first started to see the processors pull ahead of motherboards. Intel had a 50 MHz 486 on the market for some time, but even though a 50 MHz motherboard spec was available the chipsets and boards themselves were almost non-existent. Intel finely got feed up and took maters into their own hands and produces the 486 DX2 50 and DX2 66, the first x86 processors with clock multipliers. (This was also when they got into the chipset business) The first generation of Pentiums did not have multipliers but it didn't take long before they had them also.

The reason why motherboards now require multipliers is size. Electrically speaking they have become huge. I say electrically speaking because in many cases it is better measure electronics in wavelengths instead of inches or cm. The original XT board was physically large by today's standards, something on the order of 50 cm by 50 cm. (I don't feel like looking up the exact numbers but these make my calculations easier)

Using an 8 MHz clock and assuming the signal propagate at .667 c (2X10^8) m/s one wavelength is 200000000/8000000 or 25 m. The board itself is 1/50 of a wavelength across. This is a relatively simple thing to design. Even with harmonics it is unlikely you would have to deal with transmission line effects.

I guess at this point I should explain harmonics and transmission lines. If you want to transmit a square wave of a given frequency it is not good enough to transmit that frequency you also have to transmit harmonics. A harmonic is a sine wave that occurs at specific frequencies relative to the original signal. A square wave has harmonic frequency at multiples of every odd number. You usually require a couple harmonics at least to get a decent square wave.

For example, to get a square wave you would add a sine wave at F1, third harmonic at 3xF1 and the fifth harmonic at 5xF1. Each harmonic is smaller then the one below it so higher harmonics play an ever smaller role in the signal. So you need to allow for frequencies 3 -5 time that of your digital signals.

Transmission line effects come into play any time a signal must travel more then about 1/10 of a wavelength. They cause a number of bizarre effects if not carefully managed, like causing open circuits to act like short circuits; short circuits to act like capacitors, etc.

So on the old XT even the fifth harmonic could travel all the way across the board without having to worry about transmission line effects. A 33 MHz board 33 cm across would be almost 1/20 wavelengths across, but if you are careful with your traces and avoid having any (33 MHz) trace being more the 20 cm you can at least get the full third harmonic and probably most of the fifth so you are still OK.

Consider a modern 133 MHz board that is say 25 cm across. The board is now 1/6 of a wavelength across. At this frequency even your primary frequency may be subject to transmission line effects. You now need to carefully control things like impedance, trace length etc to send digital signals around the board. (These effects start to kick in around 1/10 of a wavelength but don't get into full gear until about 1/4 of a wavelength)

Around this frequency you start to run into other problems as well. If two signals travel different distances the difference in travel time can become important. Imagine having two memory chips far enough apart that one receives a second clock pulse half a clock pulse after the first. By the time they send data back to the CPU the second bit of data from the first chip arrives around the same time as the first bit from the second chip. Not a good thing.

This is what is likely to stop parallel busses from operating faster then about 200 MHz and why the really fast memory like RDRAM or SLDRAM use serial busses.

I think it's the laws of physics that are starting to take their toll on the materials used nowadays. Anyway I've always loved wearing turtleneck sweaters. Why not bottleneck sweaters for computers nerds?

Wwwwhhhhhhhooooooosssssshhhhh! -- that was the sound of 90% of what Moridin wrote flying completely over my head https://www.sharkyforums.com/images/.../2005/06/5.gif But at least he summed it up nicely in the last paragraph, so I think I know what he's talking about now. Enlightening https://www.sharkyforums.com/images/.../2005/06/5.gif

Anyway, I still stand by the hard drive as the biggest bottleneck. Now maybe all you guys ever do with your computer is play games, in which case I guess your HD doesn't matter. But I don't, and (I know this is a shock) a lot of other people don't either. And I know that if I look down at my computer, there's a lot of times when that hard drive light is on those things are thrashing away: like any time I want to open an application that I haven't used for a while, or need to save a file and the entire directory structure has to get listed again, or I want to go to a website and it's reading and writing back to the cache folder, etc. Like I said before, all that takes milliseconds. Which might not seem like that much, unless you consider that everything else the computer's doing is measured in nanoseconds. So in other words...seems to me that every time your hard drive is being used, your computer is being slowed down.

And just one final point: the biggest bottleneck in computers is not really the hard drive, the chip, memory or bus speeds. It's really the average consumer that buys their box at Circuit City and is happy with it for 5 years. If all computer users were a bunch of tech geeks, things would certainly move a hell of a lot faster https://www.sharkyforums.com/images/.../2005/06/5.gif

------------------
www.nweb-design.com <-- Send me a client, I'll send you a 5% finder's fee

"You have just destroyed one model XQJ-37 nuclear powered pansexual roto-plooker....and you're gonna have to pay for it." -- Frank Zappa

Moridin was simply explaining one of the many reasons why it is so difficult to move up speeds on the motherboard. These days in modern electronics, you can easily crank up the speed of ICs to over 1GHz. In fact, in other industries other than CPUs, it is even common to see ICs on the order of 40-80GHz with need technology like SoI or Silicon Germanium BJT transistors. However, once you leave the safe confines of your die, you begin to feel the wrath of onboard electrical wiring.

For the reason Moridin gave, and others, it is very difficult to get wide pathways going in excess of certain speeds. Harmonic noise is just one of the factors you start to have to deal with. The front side bus on the Intel and AMD micrprocessors that people use today have 64bits used for data, and many other bits used for address and protocol. Getting these to run at the speed of a microprocessor is not possible with todays electronics, which is why CPUs have multipliers.

However, getting information to the processor faster than it's going right now is only part of the problem. My opinion of the system bottleneck is that it is a number of things that cause current systems to not perform as well as they can. Processor to memory bandwidth is one of them, and perhaps an important one, too. However, even if you were to give a processor an unlimited amount of free information (in other words, the processor receives information instantly without any latency), it still wouldn't be able to process everything it receives.

Perhaps this sounds a little obvious, but consider how much of a bottleneck the CPU really is. My feeling is that the x86 architecture is the bottleneck. Because of the antique nature of the architecture, it is very difficult to improve upon. I am really looking forward to Intel's new architecture, IA64, because that will be the first new architecture Intel has used in it's main processor line since the 8086.

In the future, I see faster systems doing the following.

1) Moving to IA64, or other non-x86 architecture. This will undoubtably be IA64, but I am opening myself to the possibility that IA64 might fail, and another architecture comes to fill its shoes. On this same topic, we'll call it 1b) Paralellize data. In other words, SMP configurations are good for now, but I see symmetric multiprocessing on the core level in the future. Read another post on this forum for more information, but I believe SMT and CMP to be the future. More paralellized code will also be necessary so that each of the processor cores and threads will be given data 'a plenty to sort through.

2) Integrating everything. Like I said, speed is only found on the die, and as soon as you move off of it, you face nature's wrath. So the solution is to integrate CPU, video, memory, I/O, and the kitchen sink all on to the very same die.

3) Serialize I/O. If you have to move off the chip, it isn't going to be using wide parallel interfaces. Rather, everything will move to high speed serial. Serial can move much faster, and can scale well by adding more channels. Since data from different channels don't have to sync up like in parallel, this gives the designer a lot more room to speed things up.

4) Getting rid of rotating media. Nkeezer is mostly correct in sticking with his argument about hard drives. Frankly, a lot of programs out there are hard drive limited, and there may be even more in the future with all the streaming media that is becoming more common. If we want to speed up hard storage, we have to find a way to create cheap media that is not mechanical in nature. Spinning plates will NEVER reach microseconds of access time, let alone nanoseconds. Unfortunately, technology to do this may be a long ways off.

5) Make outside lines optical. So far, we have seen no cable capable of producing more throughput than optical. However, the disadvantage right now is that you can't bend an optical cable because the photons travelling through the cable will leave the cable if the angle is too great (this is a scientific fact... want to mess up data going to a server? bend the optical cable, if there is one). Once we overcome this, which may be very distant from now, we can start wiring our motherboards, and start connecting to online sources through optical cabling, thus enabling very high speed connections.

These 5 things together will move the industry into the next tier of computer performance. Small changes in one area or another aren't likely to affect much. This is my opinion, at least.

Quote:

---

Originally posted by Arcadian:


1) Moving to IA64, or other non-x86 architecture. This will undoubtably be IA64, but I am opening myself to the possibility that IA64 might fail, and another architecture comes to fill its shoes. On this same topic, we'll call it 1b) Paralellize data. In other words, SMP configurations are good for now, but I see symmetric multiprocessing on the core level in the future. Read another post on this forum for more information, but I believe SMT and CMP to be the future. More paralellized code will also be necessary so that each of the processor cores and threads will be given data 'a plenty to sort through.

---

I am not so sure about IA-64 at this point. When I first heard about it I was excited but I am beginning to have a lot of doubts. The premise of IA-64 is to make use of VLIW/Explicit Parallelism to avoid the complexities of out of order execution and hopefully get more parallelism then OOOE can achieve.

OOOE finds parallelism at run time using hardware; VLIW/EPIC finds it at compile time using software. In theory this should make your hardware simple.

In other words it is supposed to be small simple and effective. Somewhere along the way IA-64 became very very complicated. The die size is huge and it is too complicated to run at high speed. This is a very bad way to start for a processor whose primary advantage is supposed to be simplicity. This may change with future versions of IA-64 but while IA-64 was under development a few other things happened.

OOOE was developed and perfected. Improved manufacturing process made more transistors available to chip designers. This meant that deep OOO designs are now much more practical. In fact the OOO components of most processes take up less then 20 % of the die space, so it has become relatively cheep to implement OOOE.

On the other side VLIW/EPIC compilers have not advanced nearly as quickly. Memory latency has increased dramatically. This is worse for VLIW then OOOE because memory latency can't be predicted at compile time. Dependencies generated by memory latency can only be resolved at run time using some form of OOOE.

VLIW/EPIC can look much deeper for parallelism then OOOE provided the compiler is good, but OOOE can react to things like memory latency much better then VLIW/EPIC. Ultimately we will probably see a convergence and most ISA's will be similar

Quote:

---

Originally posted by Arcadian:


1) Moving to IA64, or other non-x86 architecture. This will undoubtably be IA64, but I am opening myself to the possibility that IA64 might fail, and another architecture comes to fill its shoes

---

Intel has done a very good job of eliminating the CISC penalty in x86. It is still there, but is quite small. They still have a lot of problems though. IMHO,I think X86 can be competitive for some time yet if it can make the following changes. (Not necessarily easy ones though)

Give the architecture some more registers. I don't know if they need 32 like most RISC machines but 16 are a minimum. Limited registers means more memory operations and a lot less parallelism.

Get rid of the accumulator configuration in the ALU. X86 ALU can only save the result of a calculation to 1 register (the Accumulator) and on top of that the Accumulator is always one of the original operands, so you always destroy one of your values unless you specifically save it to another register. The process of copying register contents, moving them to put them in the accumulator adds extra, unnecessary instructions to the program.

SSE can do most of this on the FPU side so that is a step forward, and now that we have SSE2 which is fully IEEE compliant and can completely replace X87 (SSE could not) a lot of the concerns on the FPU side have been addressed.

Get triadic instructions for both the ALU and FPU. X86 and SSE2 only support 2 operand instructions. They can do things like a=a+b, a=a+c etc (the result must be put into a). Most other ISA's support 3 operand instructions and can do a=b+c+d, a=a+b+c, c=a+b+d (result can go anywhere)

At some point 64 bit operation will be required (for memory access)

These changes, along with a trace cache to remove the CISC decode penalty would bring X86 a long way towards parity with more modern ISA's



[This message has been edited by Moridin (edited October 11, 2000).]

Quote:

---

Originally posted by Moridin:
Give the architecture some more registers. I don't know if they need 32 like most RISC machines but 16 are a minimum. Limited registers means more memory operations and a lot less parallelism.

Get rid of the accumulator configuration in the ALU. X86 ALU can only save the result of a calculation to 1 register (the Accumulator) and on top of that the Accumulator is always one of the original operands, so you always destroy one of your values unless you specifically save it to another register. The process of copying register contents, moving them to put them in the accumulator adds extra, unnecessary instructions to the program.

---

The Itanium is able to provide these things. It actually has 128 registers, all 64bit. It also has 128 more floating point registers, and 64 predicate registers. The instructions also accomodate you suggestion regarding the ALU. You say in a previous post that you are having some doubts about IA-64. You shouldn't because it is progressing quite well. Some people are displeased that it has taken so long, but there are the 5 9's of reliability it must attain. In other words, 99.999% uptime. Intel can't release it unless it is at least that stable. Plus, the successor to Itanium, the McKinley is supposed to be a much smaller die, and much faster, too. Intel has a lot in store for IA-64, so I would be very surprised if it doesn't do very well.

Moridin:
You're wrong on some points. The x86 ALU can save to results to all registers for many instruction, not just the accumulator (EAX). You can do stuff like
ADD EBX, ECX
AND EBX, ECX
OR EBX, ECX
SHL EBX, 1
You don't need to use the accumulator for those.
However, many instructions (such as MUL and IMUL (the single operand one)) can only work on the accumulator, but it's mainly the complex instructions (which should be avoided anyway).

And a = b + c + d is a 4 operand instruction. A 3 operand should read a = b + c.

... I would like to add that I have high hopes for IA-64 too. It really solves most of the problems that the x86 archetecture has. It removes much of the dependency of high speed memory, it removes the need for a branch prediction unit, it can do register indexing meaning you can put small arrays into registers instead of memory (I always wanted to be able to do that), and it's instruction set isn't so damn ugly! https://www.sharkyforums.com/images/.../2005/06/5.gif

Quote:

---

Originally posted by Humus:
Moridin:
You're wrong on some points. The x86 ALU can save to results to all registers for many instruction, not just the accumulator (EAX). You can do stuff like
ADD EBX, ECX
AND EBX, ECX
OR EBX, ECX
SHL EBX, 1
You don't need to use the accumulator for those.
However, many instructions (such as MUL and IMUL (the single operand one)) can only work on the accumulator, but it's mainly the complex instructions (which should be avoided anyway).

---

Thanks, I am not familiar with the full IA-32 instruction set. Most of my assembly programming was done in 68000, 6800, 8080 and the 8080 compatible Z80. I still think IA-32 is limited in this regard compared to newer ISA's and that this is a bottleneck in the ISA.

I also understand that the LEA instruction can extend some of these capabilities, but I am not entirely sure what it does.

Quote:

---

Originally posted by Arcadian:
The Itanium is able to provide these things. It actually has 128 registers, all 64bit. It also has 128 more floating point registers, and 64 predicate registers. The instructions also accomodate you suggestion regarding the ALU. You say in a previous post that you are having some doubts about IA-64. You shouldn't because it is progressing quite well. Some people are displeased that it has taken so long, but there are the 5 9's of reliability it must attain. In other words, 99.999% uptime. Intel can't release it unless it is at least that stable. Plus, the successor to Itanium, the McKinley is supposed to be a much smaller die, and much faster, too. Intel has a lot in store for IA-64, so I would be very surprised if it doesn't do very well.

---

The problem with adding more registers is that adds extra levels of logic to every register access. 16 registers require only 4 levels of logic while 128 require 7. If you look at the pipeline for Itanium register access is spread over 2 pipeline stages. Every other processor does this in a single stage.

IA-64 is an in order device so it needs many more registers for the compiler to use so it can find parallelism. An OOO device does not need nearly as many architectural registers to find parallelism. It does however need a set of rename registers for each pipeline stage prior to the execution stage.

I agree with you though, McKinley looks a lot better then Itanium, I still do not think it will be as fast as EV7 though.

ok, this just got way out my league https://www.sharkyforums.com/images/.../2005/06/6.gif

------------------
Compaq Armada E500
650MHz PIII 128MB RAM
8MB ATI rage mobility
11GB hard drive/DVD
dual booting win98/2k

who said you cant game on a notebook????

Quote:

---

Originally posted by Moridin:
The problem with adding more registers is that adds extra levels of logic to every register access. 16 registers require only 4 levels of logic while 128 require 7. If you look at the pipeline for Itanium register access is spread over 2 pipeline stages. Every other processor does this in a single stage.

---

I think you are misunderstanding some of the specifications. I don't know much more myself, but what you said probably doesn't have the impact that you think. At least, I haven't heard anyone else complain about this. Can anyone shed some light on this topic?

Quote:

---

Originally posted by Moridin:
IA-64 is an in order device so it needs many more registers for the compiler to use so it can find parallelism. An OOO device does not need nearly as many architectural registers to find parallelism. It does however need a set of rename registers for each pipeline stage prior to the execution stage.

---

For an in order device, Itanium can be much faster than many out of order devices. It is the architecture itself that makes in order operation work. The reason why in order affects performance in x86 is because there are too many dependancies, and even register renaming can't solve them all. In EPIC, these dependancies are resolved at compiler time, so that the CPU will not be stalled as often. In order actually raises the performance of the Itanium.

Quote:

---

Originally posted by Moridin:
I agree with you though, McKinley looks a lot better then Itanium, I still do not think it will be as fast as EV7 though.

---

There is nothing impressive about the EV7. Actually EV7 doesn't change the processor architecture at all. It simply allows new levels of SMP parallelism. It's a different protocol that will only raise performance on a system level, not a processor level. If you are talking about IA-64 vs. an EV7 single processor, Itanium will be much faster, let alone McKinley. Only in very large SMP systems will EV7 be faster. At least this is what I hear.