OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Dave Yeo on March 06, 2022, 07:56:47 am

Title: i686 vs Pentium 4
Post by: Dave Yeo on March 06, 2022, 07:56:47 am
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. 
Title: Re: i686 vs Pentium 4
Post by: Ibrahim Hakeem on March 06, 2022, 08:57:29 am
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.
Title: Re: i686 vs Pentium 4
Post by: Eugene Tucker on March 06, 2022, 03:00:47 pm
I agree with both of you on this. and have no further comment.
Title: Re: i686 vs Pentium 4
Post by: Neil Waldhauer on March 06, 2022, 03:23:53 pm
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.
Title: Re: i686 vs Pentium 4
Post by: ivan on March 06, 2022, 04:37:42 pm
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. 
Title: Re: i686 vs Pentium 4
Post by: Silvan Scherrer on March 06, 2022, 05:35:17 pm
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.
Quote
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.
Title: Re: i686 vs Pentium 4
Post by: Silvan Scherrer on March 06, 2022, 05:38:32 pm
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.
Title: Re: i686 vs Pentium 4
Post by: Martin Iturbide on March 07, 2022, 03:12:49 am
Quote
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 (https://www.os2world.com/forum/index.php?topic=3012.msg33977#msg33977"), 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
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 08, 2022, 02:55:11 am
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.
 
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 08, 2022, 03:22:50 am
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.
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 08, 2022, 03:28:46 am
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 (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
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 08, 2022, 02:04:27 pm
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 (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
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 08, 2022, 06:08:56 pm
So for testing floating point, I found this, https://github.com/shaswata56/BenchUtil (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.
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 09, 2022, 04:37:16 am
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).
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 09, 2022, 07:47:15 am
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
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 09, 2022, 04:31:58 pm
Hi Dave!

That is strange, is it repeatable?

Hmm, maybe the approach I took to implementing the various -march and -mtune settings was incorrect: I included those in the main makefile as part of the CFLAGS line.

So now I've re-ran, having cleaned-up the CFLAGS and used the CLI make call with the XCFLAGS instead.

1) AMD optimized
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14098
Total time (secs): 14.098000
Iterations/Sec   : 85118.456519
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=amdfam10 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

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

2) AMD generic
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 18324
Total time (secs): 18.324000
Iterations/Sec   : 98231.827112
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=generic -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

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

3) PENTIUM4 optimized
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14391
Total time (secs): 14.391000
Iterations/Sec   : 83385.449239
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -mtune=pentium4 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

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

4) PENTIUM4 generic
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 19648
Total time (secs): 19.648000
Iterations/Sec   : 91612.377850
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -mtune=generic -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

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

In both architecture cases, the "generic" option produces a better results as compared to CPU specific tune, this is not a good outcome, as you said, maybe a compiler bug?

On my AMD CPU, the AMD -march gives a better result than P4 (which is to be expected).
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 09, 2022, 05:57:30 pm
Does seem like a compiler bug. Try with only -march=amdfam10 as the -mtune=amdfam10 is redundant and might be the problem, -mtune is implied to be the same as -march if it is not stated.
Also try -march=native.
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 09, 2022, 08:27:54 pm
Try with only -march=amdfam10 as the -mtune=amdfam10 is redundant and might be the problem, -mtune is implied to be the same as -march if it is not stated.
Also try -march=native.

1) amdfam10
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14149
Total time (secs): 14.149000
Iterations/Sec   : 84811.647466
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

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

2) pentium4
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14515
Total time (secs): 14.515000
Iterations/Sec   : 82673.096796
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

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

3) native
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 15119
Total time (secs): 15.119000
Iterations/Sec   : 79370.328725
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=native -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

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

Looks to me like -mtune is still doing something...
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 10, 2022, 03:13:31 pm
I hit the GCC bug forum in an attempt to find any known issues with mtune optimization logic for the amdfma10 processors. While nothing obvious jumped out, I did do some pretty extensive reading on a couple of general "optimization logic" bug threads:

1) Bug 81616 - Update -mtune=generic for the current Intel and AMD processors  (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616))

2) GCC buglist with "amdfam10" filter (https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=amdfam10 (https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=amdfam10))

Also came across this decent post on the relationship between march and mtune => https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/ (https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/), great info in the discussion section actually.

So here is the kicker, it would appear (juding by the performance tests these teams were running) that best performance results were obtained when using the mtune=K8 option on the amdfam10 architecture. Hmm....strange I thought, b/c K8 is an older architecture and the Phenom (in my case) really did not introduce new features, other than basically an updated memory controller and L3 cache (more than doubled – from 2MB to 6MB). Not sure if there are any actual instrution set differences.

Anyways, alright, so I'm already trying this out, why not give this new combo a whirl?

Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 18130
Total time (secs): 18.130000
Iterations/Sec   : 99282.956426
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=k8 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

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

Wow...so that's a pretty significant difference: 99282.956426 (mtune=k8) vs 84811.647466 (no mtune).

The differences narrow down significantly when looking at tuned results: 99282.956426 (mtune=k8) vs 98231.827112 (mtune=generic).
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 12, 2022, 05:02:20 am
Some interesting stuff there. Seems the GCC documentation is lacking. Playing more here, I found that -march=sandybridge crashes unless I add -mno-avx, which is not needed for -march=native and I also seem to get the best performance with -mtune=generic though it is only slightly better then native. The output of -Q --help=target is interesting too. Something like,
Code: [Select]
gcc -march=native -Q --help=target > march_native.txt
gcc -march=sandybridge -Q --help=target > march_sandybridge.txt
diff -u march_native.txt march_sandybridge.txt
shows the small differences.
At least we've established that on some (most?) CPU's, the -mtune=generic seems to result in a positive result.
You might want to try the latest Firefox I uploaded to Bitbucket, built with -march=pentium4 -mtune=generic. I have builds of SM and TB but Bitbucket stopped letting me upload. That Firefox has intree NSPR4 and NSS and seems stabler due to it. If you prefer the DLLs can be removed so the system installed ones are used.
Title: Re: i686 vs Pentium 4
Post by: Eugene Tucker on March 12, 2022, 03:21:05 pm
Bitbucket will not let one access your Seamonkey and Thunderbird builds as well, The seem to have shut down the page.
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 12, 2022, 05:00:18 pm
Did you try at https://bitbucket.org/dryeo/cc-os2/downloads/ (https://bitbucket.org/dryeo/), it is the page I created when Bitbucket deleted all the repositories using Mercurial.
Also Firefox is at [url]https://bitbucket.org/dryeo/mozilla-os2/downloads//url]
Seems our old builds don't work there anymore, I had to use the simplebrowser to access.
Title: Re: i686 vs Pentium 4
Post by: Dariusz Piatkowski on March 12, 2022, 06:25:42 pm
Dave,

...The output of -Q --help=target is interesting too. Something like,
Code: [Select]
gcc -march=native -Q --help=target > march_native.txt
gcc -march=sandybridge -Q --help=target > march_sandybridge.txt
diff -u march_native.txt march_sandybridge.txt

Hmm...OK, this simple gcc call does NOT work on my machine...which perhaps implies I have something else wrong? lol

Here is what I get (I won't post the whole thing, but it's about 200 lines of the same repeated error message until the very end):

Code: [Select]
{standard input}: Assembler messages:
{standard input}:1: Error: no such instruction: `the following options are target specific:'
{standard input}:2: Error: junk at end of line, first unrecognized character is `-'
{standard input}:3: Error: junk at end of line, first unrecognized character is `-'
...
{standard input}:183: Error: no such instruction: `known assembler dialects (for use with the -masm=option):'
{standard input}:184: Error: no such instruction: `att intel'
{standard input}:186: Error: no such instruction: `known ABIs (for use with the -mabi=option):'
{standard input}:187: Error: no such instruction: `ms sysv'
{standard input}:189: Error: no such instruction: `known code models (for use with the -mcmodel=option):'
{standard input}:190: Error: junk at end of line, first unrecognized character is `3'
{standard input}:192: Error: no such instruction: `valid arguments to -mfpmath=:'
{standard input}:193: Error: junk at end of line, first unrecognized character is `3'
{standard input}:195: Error: no such instruction: `known indirect branch choices (for use with the -mindirect-branch=/-mfunction-return=options):'
{standard input}:196: Error: no such instruction: `keep thunk thunk-extern thunk-inline'
{standard input}:198: Error: no such instruction: `known choices for return instrumentation with -minstrument-return=:'
{standard input}:199: Error: junk `nop5' after expression
{standard input}:201: Error: no such instruction: `known data alignment choices (for use with the -malign-data=option):'
{standard input}:202: Error: no such instruction: `abi cacheline compat'
{standard input}:204: Error: no such instruction: `known vectorization library ABIs (for use with the -mveclibabi=option):'
{standard input}:205: Error: no such instruction: `acml svml'
{standard input}:207: Error: no such instruction: `known address mode (for use with the -maddress-mode=option):'
{standard input}:208: Error: no such instruction: `long short'
{standard input}:210: Error: no such instruction: `known preferred register vector length (to use with the -mprefer-vector-width=option):'
{standard input}:211: Error: junk at end of line, first unrecognized character is `1'
{standard input}:213: Error: no such instruction: `known stack protector guard (for use with the -mstack-protector-guard=option):'
{standard input}:214: Error: no such instruction: `global tls'
{standard input}:216: Error: no such instruction: `valid arguments to -mstringop-strategy=:'
{standard input}:217: Error: no such instruction: `byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop'
{standard input}:218: Error: no such instruction: `vector_loop'
{standard input}:220: Error: no such instruction: `known TLS dialects (for use with the -mtls-dialect=option):'
{standard input}:221: Error: no such instruction: `gnu gnu2'
{standard input}:223: Error: no such instruction: `known valid arguments for -march=option:'
{standard input}:224: Error: no such instruction: `i386 i486 i586 pentium lakemont pentium-mmx winchip-c6 winchip2 c3 samuel-2 c3-2 nehemiah c7 esther i686 pentiumpro pentium2 pentium3 pentium3m pentium-m pentium4 pentium4m prescott nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel geode k6 k6-2 k6-3 athlon athlon-tbird athlon-4 athlon-xp athlon-mp x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native'
{standard input}:226: Error: no such instruction: `known valid arguments for -mtune=option:'
{standard input}:227: Error: no such instruction: `generic i386 i486 pentium lakemont pentiumpro pentium4 nocona core2 nehalem sandybridge haswell bonnell silvermont goldmont goldmont-plus tremont knl knm skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake intel geode k6 athlon k8 amdfam10 bdver1 bdver2 bdver3 bdver4 btver1 btver2 znver1 znver2'

At first I thought maybe this was a session related thing...so I even tried bash, but same result.

Any idea what my gcc is choking on here???
Title: Re: i686 vs Pentium 4
Post by: Dave Yeo on March 12, 2022, 07:27:09 pm
Perhaps picking up an OS/2 command instead of a *nix command? My PATH starts with (W: is UNIXROOT) W:\usr\libexec\bin and I also had to move \os2\print.com out of the way. Look in popuplog.os2 for print.com or similar crashes. My output starts with,
Code: [Select]
The following options are target specific:
  -m128bit-long-double                  [disabled]
  -m16                                  [disabled]
  -m32                                  [enabled]
  -m3dnow                               [disabled]
  -m3dnowa                              [disabled]
  -m64                                  [disabled]
  -m80387                               [enabled]
  -m8bit-idiv                           [disabled]
  -m96bit-long-double                   [enabled]
  -mabi=                                sysv
and is about 228 lines, 10095 bytes.