i686 vs Pentium 4

[Dave Yeo]

I know this has been discussed before, but I think we should revisit as Bitwise has decided to force us to the Netburst (Pentium 4) architecture and it is easier to make an argument here rather then at Github which no longer works well on out old browsers. ideally would be to make arguments here and then reference this thread on Github.
The main difference between the various i386 architectures is how things are optimized and whether simd (MMX, SSE, SSE2) intrinsic's are used. 

[Ibrahim Hakeem]

Hi Dave.

Like a lot of us here, I daily OS/2 on modern hardware for whatever tasks are still possible, so I am in complete agreement with you. In BitWise's defence, switching to a more modern infrastructure would likely be at a cost of much more labour in the short-run.

In spite of that, I'm sure the majority of us can agree it's still a serious necessity given that we're stuck to operating within 32bit memory limitations in a browser-oriented 64bit world. It's just impractical for us to be giving up precious memory in favour of sticking with an outdated and inefficient architecture. 32bit x86 consumer processors (primarily in netbooks) still exist and sell despite increasing resource demands from web browsers and other programs, simply because of how CPU instruction sets can cut down on processing overhead, it feels foolish for us to not take advantage of it.

Despite the possibility of our much loved and anticipated browser releasing sooner as a result of sticking to Netburst, it won't be a lasting success by any stretch if we cannot keep up with these demands in whatever ways we can/should.

[Eugene Tucker]

I agree with both of you on this. and have no further comment.

[Neil Waldhauer]

As an end user, I don't care what instruction set is used. But if I change my settings from i686 to pentium4 with rpm/yum, everything should still work afterward. For me it's not the instruction set, but the quality of the rpm specs.

Martin had to remove rpm/yum entirely and start over to change from i686 to pentium4. If that is what is needed, then please supply a tool to do it in one quick operation.

[ivan]

While all the above may be true it also underscores the reason I will not use RPM/YUM on any of my OS/2 based computers.  If I absolutely have to use one of the RPM offerings, I will download from the repository and unpack it on my test computer transferring what is needed to my work computer.

In my opinion all this can/could be avoided by using what we had befor someone decided to follow SUSE linux route - in other words WARPIN. 

[Silvan Scherrer]

As an end user, I don't care what instruction set is used. But if I change my settings from i686 to pentium4 with rpm/yum, everything should still work afterward. For me it's not the instruction set, but the quality of the rpm specs.

It does still work. Just let the update do its work.

Martin had to remove rpm/yum entirely and start over to change from i686 to pentium4. If that is what is needed, then please supply a tool to do it in one quick operation.

I dont know what he tried exactly.but he did it wrong for sure. As the update process works. And its not necessary to change arch for all. Just use yum update to update to later versions when available. And as said this works. If not open a ticket and we will solve it.

[Silvan Scherrer]

While all the above may be true it also underscores the reason I will not use RPM/YUM on any of my OS/2 based computers.  If I absolutely have to use one of the RPM offerings, I will download from the repository and unpack it on my test computer transferring what is needed to my work computer.

In my opinion all this can/could be avoided by using what we had befor someone decided to follow SUSE linux route - in other words WARPIN.

Feel free to solve all dependencies by hand. And configure then right.  And go ahead and create wpi packages for all rpm. We certainly will not do it.

[Martin Iturbide]

Martin had to remove rpm/yum entirely and start over to change from i686 to pentium4. If that is what is needed, then please supply a tool to do it in one quick operation.

I dont know what he tried exactly.but he did it wrong for sure.

Hi

I was suggested the reinstall of RPM as an alternative to change everything to pentium4, and that is what I had tried.

According to what I had read between lines on some posts (haven't found any official post, instruction or suggestion), the "right" procedure is to change os2-base to pentium4, do not worry about mixing i686 with pentium4 packages and that's all. If someone is experiencing some problems please post the error.

Regards

[Dave Yeo]

As I stated at the top, the conversation should be about the architecture, not the benefits/drawbacks of RPM, that ship has sailed. Our volunteers are comfortable with RPM and we get RPM and we do need a package manager, which Warpin is not.
Likewise about the process of changing architectures, which generally works fine and with a little bit of work in ANPM updating the odd individual package has been mostly fine with any problems likely in the spec file.
The question is how to easily fix the performance hit from using Netburst on most anything that isn't on Netburst.
I was going to write a long comment on hello world and differences in the compiler output, and then realized that Hello World isn't a good example. The difference was one directive in the source code that aligns memory to 4 byte boundaries. Surprisingly using -march=pentium4 didn't have that directive, neither did using the -Os (small memory footprint) optimization flag.
Most all computers load memory in 4 byte or multiples of 4 byte chunks and have since the i686, likewise the cache uses 4 byte or 16 byte chunks so there should be a performance increase, along with a slight hit on memory aligning the instructions to 4 byte boundaries. SSE[2,3] also requires that alignment.
 

[Dariusz Piatkowski]

As I stated at the top, the conversation should be about the architecture, not the benefits/drawbacks of RPM, that ship has sailed. Our volunteers are comfortable with RPM and we get RPM and we do need a package manager, which Warpin is not...

Thanks Dave fore re-focusing this discussion on the main topic.

...The question is how to easily fix the performance hit from using Netburst on most anything that isn't on Netburst...

So what do we actually know, as opposed to believe, this performance penalty to be?

As you know I'm happily chugging away using my AMD Phenom II CPU, old tech by today's standards, but it does support some of the instructions that have the potential to improve system performance, that being: SSE, SSE2, SSE4a. So from that perspective I do not see anything wrong with the move towards pentium4 releases.

If anything, I wish we actually had a more real choice, that being CPU specific package builds, basically along the lines of what you did for me building my Phenom specific FF release. In that case, I did genuinely see an improved performance and could benchmark enough to actually put a real metric on the results.

[Dave Yeo]

So anyways, my next idea is to benchmark the differences in optimizing for different CPU architectures. I found this, https://www.eembc.org/coremark/index.php a benchmark designed to test integer and pipeline speed on various CPU's see the Details part of the above page.
So I downloaded the source and built it and now share it, it is attached and includes the logs I generated.
Ideally to test, it needs to be rebuilt with different flags, make clean and then make, or make XCFLAGS="options" such as -march=pentium4. The -march targets an architecture. I tested no flags, seems our GCC now targets i686, Pentium 4, and native, in my case I5 as well as -march=pentium4 -mtune=generic. The -mtune parameter affects the instruction ordering with generic being for the common CPU's available and used when GCC was released.
The results showed most tests resulting in about 16200 Iterations/Sec with the best results actually for -march=pentium4 -mtune=generic, 16241 Iterations/Sec with most of the others being close enough that it may be background processes affecting the results (should really run 3-5 times and average). The exception being plain old -march=pentium4 which gave 13162 Iterations/Sec, bigger numbers are better and it seems P4 has close to a 20% performance hit on my CPU and likely on all Intel CPU's besides Netburst and likely similar on AMD. AMD should be tested.
By uncommenting the LFLAGS_END line in os2/core_portme.mak and using make XCFLAGS="-DMULTITHREAD=4 -DUSE_PTHREAD" can test 4 threads, where my results were Iterations/Sec   : 59947.545897 with no flags and for P4, Iterations/Sec   : 50128.454164, once again a performance hit of about 15%.

My idea is for the RPM packagers to simply add CFLAGS+= -mtune=generic to their future P4 builds which should result in a performance boost in most cases for everyone except the few P4 users left without having to switch architectures and rebuild everything.

Anyways source is included, requirements to build are simply GCC and make, pthread-dev for multi-threading.  "make XCFLAGS="-march=amdfam10" for newer AMD chips if others want to check out the differences. Don't forget to make clean in between compilations.
Now I should find a floating point benchmark and test that.
Edit: XCFLAGS="-march=native" is a simple way to test on your CPU

[Dariusz Piatkowski]

Dave, everyone...

So anyways, my next idea is to benchmark the differences in optimizing for different CPU architectures. I found this, https://www.eembc.org/coremark/index.php a benchmark designed to test integer and pipeline speed on various CPU's see the Details part of the above page.
So I downloaded the source and built it and now share it, it is attached and includes the logs I generated...

Nice!!! Thank you...

Here are the results for my Phenom II X6 running at 3.8GHz:

Code: [Select]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 17587
Total time (secs): 17.587000
Iterations/Sec   : 17058.054245
Iterations       : 300000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DPERFORMANCE_RUN=1
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0xcc42
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 17058.054245 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O
2 -DPERFORMANCE_RUN=1   / Heap

I'll play around with the different optimization flags Dave which you discussed in your post next. Also, the above is a result when executed on my system in as-is state, so various CPU spikes, etc...not quieted by any means! lol

[Dave Yeo]

So for testing floating point, I found this, https://github.com/shaswata56/BenchUtil simple programs to test 32 bit and 64 bit Gigaflops.
Testing by editing the makefile's CFLAG's, surprisingly using -march=pentium4 produced slightly better numbers then anything else I tried.

Code: [Select]

K:\work\BenchUtil>flops32.exe
Number of CPU cores to run Benchmark: 4
Benchmarking for 32 Bit Floating point operations per second
1| Tr 1: 166771296 Tr 2: 171153429 Tr 3: 180760710 Tr 4: 168050527 FLOPS = 686735962
Maximum CPU Throughput: 0.686736 Gigaflops.
Maximum Single Core Throughput: 0.180761 Gigaflops.

K:\work\BenchUtil>flops64.exe
Number of CPU cores to run Benchmark: 4
Benchmarking for 64 Bit Floating point operations per second
1| Tr 1: 177902634 Tr 2: 168180220 Tr 3: 182884650 Tr 4: 173335942 FLOPS = 702303446
Maximum CPU Throughput: 0.702303 Gigaflops.
Maximum Single Core Throughput: 0.182885 Gigaflops.

Then I realized there was no optimization happening, so I added -O2 (and others) which surprisingly resulted in 0 Gigaflops, seemed the compiler had optimized the floating point math away .
Then it occurred to me to test SSE, so I added "-msse2 -mfpmath=sse" to the CFLAGS and got a huge speedup,

Code: [Select]

K:\work\BenchUtil>flops32.exe
Number of CPU cores to run Benchmark: 4
Benchmarking for 32 Bit Floating point operations per second
1| Tr 1: 1456272991 Tr 2: 1465967192 Tr 3: 1418616653 Tr 4: 3770445355 FLOPS = 8111302191
Maximum CPU Throughput: 8.111302 Gigaflops.
Maximum Single Core Throughput: 3.770445 Gigaflops.

K:\work\BenchUtil>flops64.exe
Number of CPU cores to run Benchmark: 4
Benchmarking for 64 Bit Floating point operations per second
1| Tr 1: 4119103170 Tr 2: 4128738432 Tr 3: 4097239406 Tr 4: 4144496382 FLOPS = 16489577390
Maximum CPU Throughput: 16.489578 Gigaflops.
Maximum Single Core Throughput: 4.144496 Gigaflops.

Then also adding -march=pentium4, the speedup was smaller,

Code: [Select]

K:\work\BenchUtil>flops32.exe
Number of CPU cores to run Benchmark: 4
Benchmarking for 32 Bit Floating point operations per second
1| Tr 1: 1373982585 Tr 2: 1404198986 Tr 3: 1382572280 Tr 4: 3279735363 FLOPS = 7440489214
Maximum CPU Throughput: 7.440489 Gigaflops.
Maximum Single Core Throughput: 3.279735 Gigaflops.

K:\work\BenchUtil>flops64.exe
Number of CPU cores to run Benchmark: 4
Benchmarking for 64 Bit Floating point operations per second
1| Tr 1: 4136387606 Tr 2: 4130490416 Tr 3: 4147691444 Tr 4: 4125981262 FLOPS = 16540550728
Maximum CPU Throughput: 16.540550 Gigaflops.
Maximum Single Core Throughput: 4.147692 Gigaflops.

So you can see why to use SSE for floating point math. Seems the 32 bit math was slower compiled for a P4 and the 64 bit math was about the same. Once again really should have done the measurements 3-5 times and averaged.

[Dariusz Piatkowski]

I'll play around with the different optimization flags Dave which you discussed in your post next...

Hmm...so a bit of a surprise actually, I did not anticipate this.

1) tune & arch = amdfam10

Code: [Select]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 13914
Total time (secs): 13.914000
Iterations/Sec   : 57496.047147
Iterations       : 800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 4

2) arch=amdfam10, tune=generic

Code: [Select]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 17822
Total time (secs): 17.822000
Iterations/Sec   : 67332.510380
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 4

3) same config as #2 above, but running the full 6 cores

Code: [Select]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 21224
Total time (secs): 21.224000
Iterations/Sec   : 84809.649453
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

4) same #3 above, but with arch=pentium4, tune=generic

Code: [Select]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 21252
Total time (secs): 21.252000
Iterations/Sec   : 84697.910785
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

The GCC architecture specific tune option produced WORSE performance than the GENERIC option, which at least to me is not intuitive, quite the opposit actually.

..and while I focused in the above tests on multi-threaded performance, the single-threaded runs matched the tune results that I saw here (same conclusion).

[Dave Yeo]

That is strange, is it repeatable? I also notice the 2nd run had more Iterations for some reason as well as your log not showing all the compiler flags. I get this,

Code: [Select]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 13073
Total time (secs): 13.073000
Iterations/Sec   : 61194.829037
Iterations       : 800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -march=native -mtune=generic -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 4
some crc's

Code: [Select]

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 61194.829037 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -march=native -mtune=generic -DPERFORMANCE_RUN=1
  -lpthread / Heap / 4:PThreads

Looking at [url]https://www.eembc.org/coremark/scores.php[/code] and filtering for AMD Phenom II X6 1090T I see someone else got 73233.25
Always a possibility of a compiler bug. Also if you don't specify -mtune, you get it tuned for -march