Performance Discussion - The Biggest Bottleneck

Quote:

---

Originally posted by Humus:
Would you mind explaining a little better what you mean by "x86 architecture in general is segmented. When IA-64 becomes popular, you will start seeing flat memory ranges, which will give larger performance."?

In what way is IA-32 not flat? You address memory with a single 32bit address like MOV EAX, [EBX]. With EBX = 0 in this case you address the first byte of your program and with EBX = 0xFFFFFFFF you address the last byte in your virtual memory.

BTW, OS memory management is a very important factor for system performance. Every time you encounter a "new" or "delete" statement in C++ that's a call the OS. Same for malloc/calloc/realloc/free etc.
Those are not considered to be cheap operations.

[This message has been edited by Humus (edited October 20, 2000).]

---

Ever notice how the Pentium III, for example, has a 36bit address range? Yet registers such as EBX are 32bit. In order to access memory outside of that range, you need segment registers, which include CS and DS, for example. Each program running under Windows, for example, is allowed their own protected segment to run under. A flat memory address space, which could only be allowed with 64bit registers, is a preferable situation, and does not require extra instructions to compute effective addresses, for example.

I'd say the biggest bottleneck is the bus speed in general. Everything needs to be faster except the processor which would still be nice to see run at unreal frequencies. All periferals internal and external need to interact faster with each other.

------------------
I'm consistantly inconsistant!

Quote:

---

Originally posted by Arcadian:
Ever notice how the Pentium III, for example, has a 36bit address range? Yet registers such as EBX are 32bit. In order to access memory outside of that range, you need segment registers, which include CS and DS, for example. Each program running under Windows, for example, is allowed their own protected segment to run under.

---

I dunno about Win9x, but Windows NT operates with memory pages, where each page can be as small as 4KB or as big as (usually) 2GB. Segments are more or less a thing of the past (and has been - atleast using protected mode on the i386 and up).

--
Rune

Quote:

---

Originally posted by Arcadian:
Ever notice how the Pentium III, for example, has a 36bit address range? Yet registers such as EBX are 32bit. In order to access memory outside of that range, you need segment registers, which include CS and DS, for example. Each program running under Windows, for example, is allowed their own protected segment to run under. A flat memory address space, which could only be allowed with 64bit registers, is a preferable situation, and does not require extra instructions to compute effective addresses, for example.

---

But then we are talking about extensions, which are rarely used by standard applications. Any application using standard 32bit addresses will have a flat memory model and will not require any kind of extra instructions to compute the effective address.

Quote:

---

Originally posted by Humus:
But then we are talking about extensions, which are rarely used by standard applications. Any application using standard 32bit addresses will have a flat memory model and will not require any kind of extra instructions to compute the effective address.

---

Correct, but I was originally discussing processor architecture performance. In terms of x86, the operating system still has to treat the memory model as segmented, which adds overhead. Windows NT does a very good job of making the x86 memory model look flat, but it still takes processor time to do so. Thanks for making this clearer for everybody else, though, Humus. https://www.sharkyforums.com/images/.../2005/06/5.gif

Quote:

---

Originally posted by Arcadian:
[B]
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.

[B]

---

I remember what my architecture professor asked the class: "how many of you have done multi-processor programming?", 2-3 hands raised. "how many of you actually like multi-processing programming?", none raised. judging by that, he made a prediction that by at least 5-10 more years, SMP is not going happen to the mainstream. He said that ever since the 70s people have been saying that SMP (or RISC for that matter) is the way but still here we are. of course physics will not be defeated and we will get there (unless that chemical/biological/dna based processings really take of). Also a note on compilers: one can argue that compilers should really bridge that gap from hardware architecture and programmers. However keep in minds that architecture and compiler designs are not develop in-sync (and that compiler people are programmers too https://www.sharkyforums.com/images/.../2005/06/5.gif). architectures have a very long time span considerations (including backward compatibility and roadmaps) so compilers will have to follow the architecture. Somehow it's hard for the big processor maker to built that real new and nice architecture. Once they've built it, they'd keep it for as long as possible. It would be very nice if the designs are developed together cleanly.
integrated memory and logic is actually pretty hard to manufacture although there are several products already (usually with small amount of memory). memory and logic actually have different manufacturing process. Manufacturers don't even sure which process is better, to integrate logic to memory or memory to logic.
One aspect that can be optimized is the OS. In a way the OS developments have fallen victim to architectural design paradigm much like the compilers (and no, it's not entirely microsoft's fault either https://www.sharkyforums.com/images/.../2005/06/5.gif). There are/were many many OS designs (and implementations) that are very efficient in terms of bus or disk or memory utilizations or filesystems for example. As someone already mentioned, OS system calls are very expensive and can be made a lot more efficient. A specialized network hardware company has special NICs & drivers that are very fast and bypass the OS so data can be copied (and used) without a lot of context switching by the OS. My other professor believes that in the not too distant future, in a LAN situation, a server with a lot of RAM actually can serve data (a lot) faster than local drives (he also predicts that ubiquitous wireless networking will happen as soon as we aliminated all those nasty road tunnels).


[This message has been edited by darkamage (edited October 21, 2000).]

[This message has been edited by darkamage (edited October 21, 2000).]

Intel's original 8-bit processor the 8080 used a 16-bit register for storing the memory address to be accessed. This gave it access to a maximum of 64 KB of memory. This was similar to most of the processors of that generation, like the Z80, and the 6800. This is a hidden register, not a user register.

When Intel developed the 8088 and 8086 they it as quickly as possible due to threats from the 68000 and Z8000 which were also under development at the time. To maintain backward compatibility and get the processor out fast the memory address register was left at 16 bits. To allow access to more then 64 KB of memory Intel came up with a segmented model that allowed the processor to access 16 of these segments for a total of 1 MB of memory.

This was the environment that DOS, and therefore all DOS programs were written for. DOS assigned the first 10 of these segments for use by programs thus the 640-KB limit in DOS. DOS could also use the other 6 pages for some, but not all, system-related stuff. Later versions of DOS allowed swapping the one of these pages (the 11th???) with another page above 1 MB allowing some programs to use memory above 1 MB if they were written for it.

When Intel introduced the 386 they expanded the memory address register to 32 bits or 4 GB addressable memory. The 4 bits used in the 8088 were still present allowing you to address 16 x 4GB = 64 GB. Of course DOS and all DOS apps still thought that this register was only 16 bits and treated it accordingly, thus the difference between 16 bit "Real" mode and 386 enhanced mode. (Of course there are other differences as well like memory protection)

Quote:

---

Originally posted by Arcadian:
In terms of x86, the operating system still has to treat the memory model as segmented, which adds overhead.

---

The OS only needs to create one huge 4GB page and then this wouldn't be an issue. This was one of the possibilities described in many a book covering the 80386 CPU years ago.

However... If you have an OS that caters to more than one application, and each application fancies a flat address space (and perhaps more memory then what's currently physically available), then I ask you this: Why not introduce the concept of paging?

NT btw was initially developed on workstations running on the MIPS R3000 (or R4000?) CPU. Ironically that's one of the first CPUs MS dropped support for (NT 3.51 still supported it?).

--
Rune

Seems to me that we haven't even begun to exploit the advantages of parallel processing. As for as consumer software goes, I can't think of a single product that attempts to harness more than one processor. Thus, I'd say software is the real bottleneck right now.

------------------
-warpoet

It's gotta be da bus speed!
I run a BX chipset @ 144MHz while my wife runs her BX @ 100MHz. My PIII/720(667) will walk away from her PIII/800 on any benchmark that we would run(BTW, her PIII/800 is the 256kb ATC variety).
I don't own or use any AMD products but I have read enough about the T-Bird to know that it is a very, very fast processor and it
runs a high FSB.
Secondly, I do strongly believe that all memory is not created equal. I noted a marked improvement in performance and benchmarks, not to mention overclocking capacity, when I replaced my Micron PC133 with Mushkin High-Perf. Rev.2 222.

Bobby

Bottlenecks depend on the application:
- Windows office applications are usually disk IO-bound, so faster disk subsystems help (and more RAM to avoid paging)
- Browsers are typically network IO-bound, so fatter pipes help
- Transaction-processing systems are typically disk IO-bound, so more spindles help
- 3D Max is typically floating-point compute-bound, so getting an Athlon helps
- Quake III at 1280x1024 High quality is typically bound by the memory bandwidth of the graphics card, so a Geforce DDR works better than an SDR
- The Java-based web application I'm working right now is disk-write bound (because it's logging a stupid amount of debugging info to disk)
- Server-based applications are often limited in the number of simultaneous users they can support by the size of their level two processor cache, so a Xeon or Sun processor helps

It is the stupid Microsoft OSs. The computer has so much power but it is all wasted with Microsofts add on crap. For example with the new media player you can't even play an MP3 without the stupid processor time wasting visulation going.

Quote:

---

Originally posted by Abit400:
It is the stupid Microsoft OSs. The computer has so much power but it is all wasted with Microsofts add on crap. For example with the new media player you can't even play an MP3 without the stupid processor time wasting visulation going.

---

Media Player has exactly nothing to do with the OS. Please pick something tangible to ***** about. (If I created my own Linux distro and bundled "BikeDude's Fantastic MP3 Player" with it which sucked CPU like there was no tomorrow, does this make Linux a "stupid OS"?)

--
Rune

WAIT.....WAIT.....HOLD ON

we're all looking at this the wrong way the biggest bottle neck isn't the hard ware its the software. We're all using a os that was based on a 20 year old coding (dos) un till we go to 32 bit coding our systems will be slowed down.....

but its not just our os its software in general.....It takes 6 months to 2 years to write a game or product in that time we will see massive improvements in speed.....I mean come on some people are still benchmarking quake2 and its already 3 years old which means that by moores law by now everyone should have replaced our computers.....

Software can only go so fast why do you think theres no new video cards coming out for a while there all waiting for dx8....theres no point making a card that will run current products 5% faster......

hard ware can be created and produced much faster than software due to error checking and such and there will always be this problem,when we had the pentium 100's (hey i still use my pentium 75 play civilisation on it https://www.sharkyforums.com/images/.../2005/06/5.gif ) we were working with smaller multiples in the numbers we were working with.....now we are using the same speed increases with smaller multiples on the same operating system (win me is really just win 95 which is really just 3.1 with a different gui which is really just a different win 1 and 2 which is really just a dos with a gui period) we are increasing our clock speeds in the same 33mhz jumps (900-933) which isn't as big a jump as 100 to 133......


------------------
'From now on I'm thinking only of me.'

Major Danby replied indugently with a superior smile: 'But, Yossarian, suppose everyone felt that way.'
'Then,' said Yossarian, 'I'd certainly be a damned fool to feel any othe way wouldn't I?'

If that's true, than how come Windows 2000, which is pure 32bit and 0% DOS, doesn't go that much faster than Windows 98 or ME?

I think the software tries to scale with the hardware, and development times aren't likely to get any shorter. There is still a lot that can be improved in the hardware, so I believe that is still the bottleneck in performance.