OS/2, eCS & ArcaOS - Technical > Programming
i686 vs Pentium 4
Dariusz Piatkowski:
Hi Dave!
--- Quote from: Dave Yeo on March 09, 2022, 07:47:15 am ---That is strange, is it repeatable?
--- End quote ---
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: ---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
--- End code ---
2) AMD generic
--- Code: ---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
--- End code ---
3) PENTIUM4 optimized
--- Code: ---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
--- End code ---
4) PENTIUM4 generic
--- Code: ---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
--- End code ---
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).
Dave Yeo:
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.
Dariusz Piatkowski:
--- Quote from: Dave Yeo on March 09, 2022, 05:57:30 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.
--- End quote ---
1) amdfam10
--- Code: ---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
--- End code ---
2) pentium4
--- Code: ---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
--- End code ---
3) native
--- Code: ---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
--- End code ---
Looks to me like -mtune is still doing something...
Dariusz Piatkowski:
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)
2) GCC buglist with "amdfam10" filter (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/, 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: ---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
--- End code ---
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).
Dave Yeo:
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: ---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
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version