Best processor for 32-bit [rd]OS - a.k.a RDOS-OS is best OS!

[rdos]

Moved this performance discussion to a new thread.

Source to test: http://rdos.net/vc/viewvc.cgi/trunk/tes ... iew=markup

Below "near" means the non-optimized code that does a C procedure call in 32-bit flat mode. It was compiled in debug mode, and contains 3 near calls, and some other junk. Gate is a call-gate that just does a 32-bit far return.

The "gate" figure pretty much predicts the performance of some of my test-programs that does many syscalls. For instance, it predicts that my AMD portable should use more processor power than the AMD Geode, even if it runs at a much higher frequency.

The "gate" figure also pretty much predicts interrupt performance. By scaling the below gate numbers by a factor 2/3, the maximum number of interrupts on the machine in 32-bit mode could be predicted.

Here are the results for my performance tests on various computer systems I have.

6-core AMD Phenom: (at 2.8 GHz)
near: 44.7 million calls per second
gate: 12.0 million calls per second

2-core AMD Athlon I: (at 1GHz)
near: 19.7 million calls per second.
gate: 7.0 million calls per second.

AMD Geode: (at 500MHz)
near: 5.9 million calls per second.
gate: 4.0 million calls per second.

2-core AMD E-300 (at 1.2GHz):
near: 20.0 million calls per second.
gate: 2.7 million calls per second.

2-core Intel Atom (at 3GHz)
near: 24.4 million calls per second
gate: 2.4 million calls per second

Intel Celeron (400MHz)
near: 5.8 million calls per second
gate: 1.8 million calls per second

If somebody else has some other suitable machines (especially some high-end Intel PCs), it would be interesting to test. If you have GRUB installed, I could provide a test image + the needed GRUB configuration in order to load & run the test.

[Nable]

I have smth like that:
Pentium III @ 600MHz
Pentium M 1.73GHz @ 1.3GHz (need pinmod to use native freq)
Core i3 @ <didn't remember>

Are interested in doing tests on it?

[Brendan]

Hi,

Below "near" means the non-optimized code that does a C procedure call in 32-bit flat mode. It was compiled in debug mode, and contains 3 near calls, and some other junk. Gate is a call-gate that just does a 32-bit far return.

Why are you testing call gates on modern CPUs?

About 15 years ago, Intel and AMD realised that call gates suck (due to multiple GDT lookups and protection checks) and created "less silly" alternatives. Unfortunately Intel's alternative (SYSENTER) wasn't the same as AMD's alternative (SYSCALL) and for a while each manufacturer wouldn't/didn't support the other's competing alternative. For modern CPUs this isn't a problem - all modern CPUs support SYSENTER in 32-bit code and SYSCALL in long mode.

To support old CPUs it's easy to emulate SYSENTER (and/or SYSCALL) within the invalid opcode handler, and to support old software it's easy to also support call gates; but legacy stuff like this isn't really important for performance tests.


Cheers,

Brendan

[Combuster]

Also, I see the same statistics from last thread which means your test code is still broken.

[rdos]

Why are you testing call gates on modern CPUs?

Because call gate performance is the best estimator of how fast RDOS (and any other older OS, like Windows XP), will perform on a particular processor. It is also the best estimator of interrupt latencies and interrupt performance, as using gates in IDT is the only way of handling interrupts in 32-bit mode.

About 15 years ago, Intel and AMD realised that call gates suck (due to multiple GDT lookups and protection checks) and created "less silly" alternatives. Unfortunately Intel's alternative (SYSENTER) wasn't the same as AMD's alternative (SYSCALL) and for a while each manufacturer wouldn't/didn't support the other's competing alternative. For modern CPUs this isn't a problem - all modern CPUs support SYSENTER in 32-bit code and SYSCALL in long mode.

SYSENTER/SYSCALL is not an alternative for me. While I haven't tested, I'm pretty sure that a SYSENTER followed by a far call in kernel is not faster than a call gate on a modern processor.

To support old CPUs it's easy to emulate SYSENTER (and/or SYSCALL) within the invalid opcode handler, and to support old software it's easy to also support call gates; but legacy stuff like this isn't really important for performance tests.

Why would anybody want to do such a bad thing? On older processors, at least up to AMD Geode, using call gates is the fastest method of calling kernel.

What I would want to do is to put up performance lists for people wanting to run legacy OSes (and RDOS), and warn them that some modern processors really suck at this and should be avoided.

[rdos]

Also, I see the same statistics from last thread which means your test code is still broken.

The test was not written in order to test the speed of call/ret, but to calculate the speed of typical syscalls and local calls. As such, it is not broken.

[rdos]

One more entry to the list:

Intel i5, 2.9GHz:
near: 56.2 million calls per second
gate: 7.2 million calls per second

This processor makes a tie with the initial AMD Athlon. However, Athlon delivers the same performance at 1GHz as this processor does at 2.9GHz!

OTOH, it is not as bad as the Intel Atom.

[rdos]

I have smth like that:
Pentium III @ 600MHz
Pentium M 1.73GHz @ 1.3GHz (need pinmod to use native freq)
Core i3 @ <didn't remember>

Are interested in doing tests on it?

Sure, that would be interesting.

Required files:
grubload.bin http://www.rdos.net/rdos/grubload.bin
rdos.bin http://www.rdos.net/rdos/rdos.bin

Instruction for loading with grub: (provided the files are in the \rdos directory on the first partition, change if not)

Code: Select all

rootnoverify (hd0,0)
kernel /rdos/grubload.bin
modulenounzip /rdos/rdos.bin

The image contains no storage or network device drivers, so should not do anything dangerous. It requires a PIC. If a PS/2 keyboard is available and working, it might be possible to use CTRL-F1 to get to the command line.

The exact configuration is here: http://rdos.net/vc/viewvc.cgi/trunk/boa ... iew=markup

[Rudster816]

One more entry to the list:

Intel i5, 2.9GHz:
near: 56.2 million calls per second
gate: 7.2 million calls per second

This processor makes a tie with the initial AMD Athlon. However, Athlon delivers the same performance at 1GHz as this processor does at 2.9GHz!

Which more\less proves that call gates are slow, and Intel\AMD haven't bothered doing any optimizations to them because they've been superseded by SYSCALL\SYSENTER.

Comparing an AMD Athlon to a Core i5 is like comparing a kitten to a puma. Yeah sure, they're both cats, but besides that, the latter is better in every which way that has any practical applications.

[rdos]

Which more\less proves that call gates are slow, and Intel\AMD haven't bothered doing any optimizations to them because they've been superseded by SYSCALL\SYSENTER.

Not entirely true. AMD's Phenom does outclass the Athlon. And it runs at similar speed as the Intel i5.

It is also notable that we see little improvement in the near call performance as well. The Intel i5 does lead here, but the Athlon (which now is many years old), is not far behind.

Comparing an AMD Athlon to a Core i5 is like comparing a kitten to a puma. Yeah sure, they're both cats, but besides that, the latter is better in every which way that has any practical applications.

For running anything legacy, you would want to chose Athlon over i5 every time.

Also, it does have practical implications. If a processor cannot handle call gates fast, it cannot handle interrupt gates fast either, and would not be able to cope with high interrupt loads.

[Combuster]

to calculate the speed of typical syscalls and local calls. As such, it is not broken.

It is broken because we:
1. Stay well away from Watcom's unoptimized compiler. A competing demonstration shows that 90% of that time is overhead induced by that compiler.
2. Don't use a segmented memory model.

[VolTeK]

1. Stay well away from Watcom's unoptimized compiler.

[rdos]

1. Stay well away from Watcom's unoptimized compiler. A competing demonstration shows that 90% of that time is overhead induced by that compiler.

More unsupported number-fiddling. We don't know the RDOS scores on the processor that had 500 million calls per second, so how could you calculate the 90% number? We also don't know the score for Watcom generated code with aggressive optimization, as I haven't tested that.

[brain]

This is all well and good, but compiler wars aside benchmarks are not a good indicator of real-world performance. in real code the syscalls should be few and far between, meaning any performance issues you note through these tests should be pretty much a non issue for all but corner cases.

[bubach]

to calculate the speed of typical syscalls and local calls. As such, it is not broken.

It is broken because we:
1. Stay well away from Watcom's unoptimized compiler. A competing demonstration shows that 90% of that time is overhead induced by that compiler.
2. Don't use a segmented memory model.

First of all, he did admit to using this test for "RDOS and any other older OS". Thats not trying to push segmentation down anybodys throat.
In its earlier commercial version Watcom was famously one of the best optimising compilers available. I'm not saying it's kept up with everything new - but I still doubt it's as bad as you make it sound.