OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Setup & Installation => Topic started by: Dariusz Piatkowski on February 10, 2018, 08:32:18 pm
-
Let me say the following right off the top: my original install of YUM, RPM and ANPM was using the i686 platform. In that configuration everything appeared to work fine, but I would occasionally run into problems with various installs (such as the Git package for example) where no explanation for the failure was available.
Given that I am running this on an AMD Phenom II X6 CPU, and the fact that big applications like Firefox are being released as 'pentium4' platform I decided to "do the prayer" and convert my platform. Yes, it is a well recognized fact that this is really more about luck then following a prescribed process.
However, having reached out to the ANPM guys I got some good hints on what MIGHT work. I accepted that and off I went to experiment.
Alright...so the end result now is that I appear to have a working pentium4 platform install. ANPM starts up fine and produces a listing of all my installed packages, however, I do not see any repositories. Worse yet, attempting to add a repository (such as netlabs-rel) simply does not work. Nothing shows up in ANPM, no file is created in the \etc\ym\repos.d directory, nuthin'!!!! Conversely, putting a file directly into the \etc\yum\repos.d directory is simply not recognized by ANPM or YUM for that matter.
So for example, here is what I get:
[G:\]yum repolist
Config time: 0.076
Yum Version: 3.2.27
COMMAND: yum repolist
Installroot: /@unixroot
Setting up Package Sacks
repolist: 0
I'm at a loss at this point in time. What are the variables that control where YUM stores the repo files? What else should I look at?
-
Hi Dariusz
Why change to pentium4 if i686 worked fine? - I doubt it makes any difference as to whether an app will install and run.
Are the packages arcanoae-rel and netlabs-rel showing in either Installed or Available?
Regards
Pete
-
Given that I am running this on an AMD Phenom II X6 CPU, and the fact that big applications like Firefox are being released as 'pentium4' platform I decided to "do the prayer" and convert my platform
But, i686 is the proper platform for that machine. Why would you want to change? Pentium 4 is for Intel Pentium 4 machines. Firefox is also available for i686 platform. Use the proper one, and it will all work better.
Hopefully, you have a backup that you can restore, because trying to fix the problem, that you have caused, will likely be difficult, at best.
-
Hi Doug!
Given that I am running this on an AMD Phenom II X6 CPU, and the fact that big applications like Firefox are being released as 'pentium4' platform I decided to "do the prayer" and convert my platform
But, i686 is the proper platform for that machine. Why would you want to change? Pentium 4 is for Intel Pentium 4 machines. Firefox is also available for i686 platform. Use the proper one, and it will all work better....
But that is actually not correct.
Here is a great link (https://myonlineusb.wordpress.com/2011/06/08/what-is-the-difference-between-i386-i486-i586-i686-i786/ (https://myonlineusb.wordpress.com/2011/06/08/what-is-the-difference-between-i386-i486-i586-i686-i786/)) that links the RPM architecture naming conventions to the CPU family releases.
To summarize:
i386 – Intel i386/80386 (in 1985) or AMD386 / AM386
i486 – Intel i486/80486 (Pentium 4 /Pentium Pro) or AMD486 / AM486
i586 – Intel Pentium 5 (ly) or AMD-K5
i686 – Intel Pentium 6 (ly) or AMD-K6
i786 – Intel Pentium 7 (ly) or AMD-K7
...and the Phenom processors are newer than the Athlon CPUs which were the K7 family, therefore, on my hardware I should be aiming to run the 'pentium4' platform, besides, I am already planning for the Ryzen deployment next...so why get stuck with the i686 stuff where vast majority of the multimedia instructions are not supported? (think of that pesky FF/YouTube video playback problem...)
-
Hi Dariusz, there's 2 main things to consider when trying to figure out the closest CPU choice to what you're actually using, features and instruction ordering.
Feature wise, the P4 (RPM is only targeting the first generation P4) is ahead of i686 as it supports MMX, SSE and I believe SSE2, which are known as simd instructions. For regular programs, these usually don't matter, except programs that do a lot of floating point math may use SSE2 instead of i387 instructions depending on compiler settings. Note most programs don't use much in the way of floating point math. Multimedia apps, including Firefox also benefit from the simd instructions but most all dynamically check what CPU you have and enable the instructions. They often also have hand rolled assembly code to use the simd instructions and even where simd instructions are used by other stuff such as intl support in Firefox, both paths are compiled including SSE2 (-msse2 is the GCC option) and a runtime check decides which path to take. Note newer versions of Firefox (53+) require SSE2 now with a minimum CPU requirement of a Pentium M.
Instruction ordering is more important. Most all CPU's are pipelined and do speculative execution. If the instructions are ordered correctly, the CPU can dispatch more instructions per cycle and have less chance of needing to flush the pipeline and refill it. Most all Intel CPU's are descended from the i686 while the Netburst architecture was a completely different beast which used very different preferred instruction ordering. It's one of the reasons that generally a P4 was so slow compared to a P3. At one point I had a P4D running at 2.8 MHz and swapped the CPU for a 1.86Mhz C2D and it was at least 50% faster (and used half the power).
AMD processors use instruction ordering much closer to the i686 and for this reason i686 is the better choice compared to P4 (Netburst) for most programs and most multimedia apps including Firefox playing youtube videos will still use most all simd instructions that your CPU supports.
You should be able to find an open source CPU benchmark and test by compiling with various CPU architectures.
Really it would be nice if RPM supported a few more architectures such as the Pentium M or newer and RPM was a bit smarter about realizing that they're all i386 variants and allowed more mix and match.
-
Hey Dave!
...You should be able to find an open source CPU benchmark and test by compiling with various CPU architectures...
Yeah, I understand that there are significant differences between something like the pentium4 and pre-CPUs. Heck, I would imagine that the massive pipeline depth on the p4 alone has a significant bearing on what optimizations the compiler can do. The P4 architecture was meant to enable very fast clock speeds, 4HGz and higher. The challenge with something like the AMD Phenom family is that they are not as deep, so certainly the code compiled for p4 will be sub-optimal...however, w/o measuring this, as you said, it is really hard to know.
Alright...so off to work I went...plugged away until I found some open source benchmarks, I pulled the Linux specific sources in hopes of this getting me a relatively closer migration path. I have a vanilla install of the OS/2 Toolkit along with the RPM gcc (4.9.2). The issue I've ran into is that various header files are missing in the OS/2 install.
For example: sysinfo.h, not present at all, not in the GCC, not the toolkit, nor even the IBMCPP environment.
In such cases (and I did spend a chunk of time looking at this prior to posting here), what is the correct approach to pursue? Meaning, do I simply find such a file and toss it onto my box here?
I had just plugging the holes without really understanding the bigger env/configuration picture.
As always, thanks for the insights!
EDIT: As best as I can tell this should be in the gnulib package...but I see nothing like that out there, closest is glib2-devel, but that does now show the sysinof.h file.
-
Searching for sysinfo.h results in
sysinfo struct in linux/kernel.h
so whatever code uses it won't compile on OS/2 without porting or may be unneeded. Better to search for a cross platform benchmark.
Quickly looking I found this, http://www.math.utah.edu/~mayer/linux/bmark.html (http://www.math.utah.edu/~mayer/linux/bmark.html) which compiles fine with a bit of makefile editing. Change the CFLAGS line to remove -static and add -Zomf for a quick compile. Should have the targets adjusted by adding .exe and the clean rule changed from /bin/rm to rm and possibly other changes.
Some of my results are low so possibly needs some code changes, perhaps something is overflowing. There's a more up to date port here, https://www.freshports.org/benchmarks/nbench/ (https://www.freshports.org/benchmarks/nbench/) if you can figure out how to download the source.
H:\tmp\nbench-byte-2.2.3>nbench.exe
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 652.56 : 16.74 : 5.50
STRING SORT : 69.906 : 31.24 : 4.83
BITFIELD : 3.7866e+08 : 64.95 : 13.57
FP EMULATION : 103.23 : 49.53 : 11.43
FOURIER : 13282 : 15.11 : 8.48
ASSIGNMENT : 23.981 : 91.25 : 23.67
IDEA : 3222.6 : 49.29 : 14.63
HUFFMAN : 1618.9 : 44.89 : 14.34
NEURAL NET : 24.707 : 39.69 : 16.70
LU DECOMPOSITION : 1091.8 : 56.56 : 40.84
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 44.389
FLOATING-POINT INDEX: 32.367
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : OS/2 1
C compiler : gcc version 4.9.2 (GCC)
libc :
MEMORY INDEX : 11.579
INTEGER INDEX : 10.714
FLOATING-POINT INDEX: 17.952
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.
-
...Quickly looking I found this, http://www.math.utah.edu/~mayer/linux/bmark.html (http://www.math.utah.edu/~mayer/linux/bmark.html) which compiles fine with a bit of makefile editing...
Ahhh...awesome, I found the various write-ups on nbench, but none of my searches led me to a source, but yeah, it seems like that benchmark has a reasonable mix of what it does.
Alrigh, so next questions: what are you using for make?
I see the following options available through YUM:
Available Packages
automake.noarch 1.14.1-3.oc00 netlabs-rel
cmake.pentium4 3.7.0-2.oc00 netlabs-rel
cmake-data.noarch 3.7.0-2.oc00 netlabs-rel
cmake-debuginfo.pentium4 3.7.0-2.oc00 netlabs-rel
cmake-doc.noarch 3.7.0-2.oc00 netlabs-rel
cmake-gui.pentium4 3.7.0-2.oc00 netlabs-rel
kbuild-make.pentium4 1:0.1.9998-9.oc00 netlabs-rel
What I know about cmake is that it's really not a make replacement but rather a project builder, which in effect creates the actual makefile that is then used.
So basically either the toolkit make or kbuild...advice as to which one I need to pursue?
-
kbuild-make is gnumake and the usual one to use.
-
I just now had a chance to view the Arca Noae Package Manager. I am impressed. It makes it so easy to update and install RPM. Great job to the developers. However, I encountered one problem. It was while I was messing with both DVD Tools and RSJ writer I encountered the problem. This is with the latest version of YUM.
I deleted the CDRTools 3.01.1-1 using YUM. After trying various thing, I went to reinstall the program. When accessing the DVD for the RPM, it was the one package it couldn't find even though it was still on the DVD. I then tried doing it with FM/2 through association. YUM would start, show the file, I would select it to install and it went through the motions like it was installed. However, when the depository reappeared, no CDTools.
Finally I went to Quick Install. Typed in "YUM install cdrtools 3.01.1-1"
It downloaded and installed without a problem and now appears in the package manager.
-
Alright...got some results to toss at you guys!
So first thing first, Dave, I see what you mean about possible overflow, the GCC warning is there, but as I know very little about OS/2 C/C++ coding I can not tell whether this declaration is a problem. Worse yet, the makefile is attempting to build pointer.h dynamically, but it is clearly missing some of the underlying OS/2 implementations:
During compilation I get the following back:
if [ "4" = `./pointer` ] ; then touch pointer.h ;\
else echo "#define LONG64" >pointer.h ; fi
./pointer: 1: ./pointer: Syntax error: word unexpected (expecting ")")
G:/usr/bin/sh.exe: 1: [: =: argument expected
That leads me to believe that the './pointer' is some sort of a linux/gnu? cl utility...but searching on this just brings up a mountain of results on the C/C++ pointer topic instead...LOL
Needless to say, pointer.h is created as:
#define LONG64
...and so AFAIK this is telling the code that the local compilar supports 64-bit long...does it in our case? I think not given that we are in a 32-bit OS...?
#ifdef LONG64
#define MAXPOSLONG 0x7FFFFFFFFFFFFFFFL
#else
#define MAXPOSLONG 0x7FFFFFFFL
#endif
Especially in light of the comment in the main code:
/* is this a 64 bit architecture? If so, this will define LONG64 */
#include "pointer.h"
...I actually think that pointer.h should be commented out. So that is what I'm working on now, the 32-bit version of this benchmark I suppose???
Once I finish that and have a decent set of results I'll post an update!
-
Hmm, here I get,
gcc -DLINUX -s -Zomf -Wall -O3\
-o pointer pointer.c
rm -f pointer.h
if [ "4" = `./pointer` ] ; then touch pointer.h ;\
else echo "#define LONG64" >pointer.h ; fi
with a correct empty pointer.h. The build system builds pointer.exe here which outputs 4.
I get one harmless warning,
gcc -DLINUX -s -Zomf -Wall -O3\
-c nbench1.c
nbench1.c: In function 'DoNNET':
nbench1.c:3149:7: warning: variable 'errorcontext' set but not used [-Wunused-but-set-variable]
char *errorcontext;
^
Here's my Makefile patch, and I created a repository, https://github.com/dryeo/nbench-byte (https://github.com/dryeo/nbench-byte). Here's a basic binary as well, seems to work with the attached NNET.DAT in the same directory.
-
Hi Dave,
i get:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT :
_fmutex operation failed: LIBC Heap request
Killed by SIGABRT
pid=0x0586 ppid=0x0061 tid=0x0001 slot=0x00ca pri=0x0200 mc=0x0002 ps=0x0017
C:\HOME\DOWNLOADS\NBENCH.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
_fmutex operation failed: LIBC Heap request
Killed by SIGABRT
pid=0x0586 ppid=0x0061 tid=0x0001 slot=0x00ca pri=0x0200 mc=0x0003 ps=0x0017
C:\HOME\DOWNLOADS\NBENCH.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
Will try to compile myself to...
-
Dave,
I think I see the root cause of my problem.
I took your makefile, executing it gets me the following:
===
[G:\CODE\SOURCE\BENCHMARKS\NBENCH]make
gcc -s -Zomf -Wall -O3 pointer.c -o pointer
ilink.exe: No such file or directory
make: *** [pointer] Error 1
===
'ilink.exe' does exist, just not anywhere in the PATH since it is part of the IBM C/C++ toolset I have installed on my machine, so I am not sure how this gets pulled in to the GCC process?
If on the other hand I remove the '-Zomf' from the 'CFLAGS = -s -Zomf -Wall -O3', then I can successfully compile and build the final nbench.exe, but the pointer EXE is never created, or rather, what is created can not be executed within an OS/2 session and subsequently I see how the makefile macro fails to build a proper pointer.h file.
HOWEVER
If I modify the makefile slightly and do the following (change in BOLD):
===
pointer.h: pointer Makefile
$(CC) $(MACHINE) $(DEFINES) $(CFLAGS)\
-o pointer.exe pointer.c
rm -f pointer.h
if [ "4" = `./pointer` ] ; then touch pointer.h ;\
else echo "#define LONG64" >pointer.h ; fi
===
..then pointer.exe is created successfully, it runs during the build process and puts a '4' into pointer.h file.
All of that begs the question: what the heck is that '-Zomf' switch???
Sorry, unless I am missing the obvious I am not finding the answer out there. I most often try the following GCC sites for info:
1) https://gcc.gnu.org/ (https://gcc.gnu.org/)
2) https://gcc.gnu.org/onlinedocs/ (https://gcc.gnu.org/onlinedocs/)
3) https://www.gnu.org/manual/manual.html (https://www.gnu.org/manual/manual.html)
-
Hi Dariusz, the -Zomf and all -Z* options are OS/2 specific, in the case of -Zomf, it converts the aout object files that GCC produces into OMF format which is OS/2's native format. With OMF object files we use the native linker to link, which works better then our ancient LD port, especially for DLL's. (and was originally the only way to build DLLs with GCC)
You're probably missing the wl package, gcc-wlink rpm, which I believe will add the correct environment variables to config.sys to use wl.exe (wlink with some fixes to handle our debug data). Run emxomfld.exe to see the variables needed.You can also add ilink to your path, might need some dpath additions as well as INCLUDE additions.
Without -Zomf, you can use the -Zexe switch will build a pointer binary and a pointer.exe binary which the pointer binary will point to.
Hi Tellie, interesting. Machine too quick? Perhaps try debugging or just link in libcx, add -g and -Zmap and see if it gives a trp file. All I did was adjust the Makefile quickly, probably wouldn't hurt to add -Zbin-files to the CFLAGS as well.
-
Hi Dave,
Well this is a I7
But i get same as i compile it here to
Alto it does notting if i start it, it just sits there, have to use cntrl c to stop it.
-
Dave's build works fine here. When you start it, it's not "doing nothing", it's running the first test which takes quite a while. Look at a CPU meter - one core should show 99.9% utilization.
However, this is just a test build whose results are substantially meaningless because it's not optimized for a specific processor. The origin of this thread was a desire to see if P4 optimization was better suited for a specific AMD processor than 686 optimization (highly doubtful, IMHO). As such, you'd need at least 2 builds, each optimized accordingly, so you can compare the results.
BTW... something's wrong with the Neural Net test. It seems highly unlikely that a Core2/Quad running at 2.5ghz can only achieve 90% of the performance of an AMD K5 @ 233mhz.
-
...Alto it does notting if i start it, it just sits there, have to use cntrl c to stop it...
How are you starting it? just nbench.exe, or have you tried giving it a command file?
In my case, I consistently have the benchmark stuck on the Assignment test, and if I do not run with the FULL STATS enabled the 'LU DECOMPOSITION' crashes. So I think there may be some bugs in there somewhere.
I've attached my com.txt file, which is what I use to drive nbench here with : 'nbench -ccom.txt'
The heavily optimized Phenom II X6 CPU family run gets me the following results:
=== START ===
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1957 : 50.19 : 16.48
STRING SORT : 351.12 : 156.89 : 24.28
BITFIELD : 6.8251e+08 : 117.07 : 24.45
FP EMULATION : 587.38 : 281.85 : 65.04
FOURIER : 27896 : 31.73 : 17.82
IDEA : 9381.9 : 143.49 : 42.60
HUFFMAN : 3661.6 : 101.54 : 32.42
NEURAL NET : 14.26 : 22.91 : 9.64
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 62.643
FLOATING-POINT INDEX: 8.991
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : OS/2 1
C compiler : gcc version 4.9.2 (GCC)
libc :
MEMORY INDEX : 8.405
INTEGER INDEX : 34.884
FLOATING-POINT INDEX: 5.558
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
=== STOP ===
-
Hi,
Ok after some time i get some info...
[E:\gcc\nbench-byte-2.2.3\nbench-byte-master]nbench
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1063 : 27.26 : 8.95
STRING SORT : 299.67 : 133.90 : 20.73
BITFIELD : 6.3214e+08 : 108.43 : 22.65
FP EMULATION : 341.2 : 163.73 : 37.78
FOURIER : 23266 : 26.46 : 14.86
ASSIGNMENT : 34.464 : 131.14 : 34.01
IDEA : 7585.4 : 116.02 : 34.45
HUFFMAN : 3641.9 : 100.99 : 32.25
NEURAL NET : 1.8775 : 3.02 : 1.27
LU DECOMPOSITION :ERROR CONDITION
Context: FPU:LU
Code: 1
-
For those getting crashes, it would be good to test with even less optimization, eg using -O2 or -O or even -Os instead of -O3 to see if it is a compiler optimization bug.
I haven't had any crashes with the native binary, trying to run a couple of DOS binaries resulted in the DJGPP build crashing right away and a Watcom 10 DOS/4G build crashing at the LU Composition test. These binaries are all linked from the page I first referenced as well as a bunch of results.
Both the neural net and ASSIGNMENT test results look questionable here with the neural net about a 1/3rd better then the K6 and the assignment just a bit better.
Quickly testing with various optimizations didn't show much differences with the expected results of i686 being generally better then the P4 but the P4 doing a hair better on FP. Best result was i686+-msse2 (and the needed -mstackrealign to work around a compiler bug). These tests need to be redone as I didn't disable the screensaver and close everything in all cases.
This is a very gutless Pentium (C2D) at 1.6Ghz
I'll also try using OpenWatcom at some point.
-
Alright you guys...druuummmm rolll please!!! 8)
So given this single synthetic benchmark, which I am guessing probably does not take the full advantage of various instruction set functionality, I spent sime time first looking at how to produce the optimal (fastest & correct results - all tests complete successfully) and then I applied the same compilar optimizations across the different architectures.
One thing I learned right off the top is that at least our 4.9.2 version seems to have a problem with the '-mfpmath=sse' flag. Using this consistently produced a crash in the code. While it was handled gracefuly - not a process dump, it still prevented the benchmark from completing. It did not matter what level of -O optimization I was attempting, even -O1 would cause a failure, therefore, I attributed the failure to the use of the -mfpmath=sse flag. I suppose it could also be due to interaction between these various flags.
Below are the results of each platform execution: i686, pentium4, AMD K10.
The final gcc compiler flags with produced the best result were: 'CFLAGS = -s -march=CPU -Ofast -pipe -msse2', where CPU can be: i686, pentium4, amdfam10.
1) AMD K10 - Phenom II X6 (my specific CPU)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1746.9 : 44.80 : 14.71
STRING SORT : 349.85 : 156.32 : 24.20
BITFIELD : 7.623e+08 : 130.76 : 27.31
FP EMULATION : 528.02 : 253.37 : 58.46
FOURIER : 27701 : 31.50 : 17.69
ASSIGNMENT : 49.893 : 189.85 : 49.24
IDEA : 8966.9 : 137.15 : 40.72
HUFFMAN : 3762.4 : 104.33 : 33.32
NEURAL NET : 13.633 : 21.90 : 9.21
LU DECOMPOSITION : 2294.8 : 118.88 : 85.84
====================ORIGINAL BYTEMARK RESULTS====================
INTEGER INDEX : 130.083
FLOATING-POINT INDEX: 43.447
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
=======================LINUX DATA BELOW=========================
MEMORY INDEX : 31.927
INTEGER INDEX : 32.867
FLOATING-POINT INDEX: 24.098
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
2) pentium4
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1570.6 : 40.28 : 13.23
STRING SORT : 336.59 : 150.40 : 23.28
BITFIELD : 7.2587e+08 : 124.51 : 26.01
FP EMULATION : 488.55 : 234.43 : 54.09
FOURIER : 27731 : 31.54 : 17.71
ASSIGNMENT : 47.027 : 178.95 : 46.41
IDEA : 8793.9 : 134.50 : 39.93
HUFFMAN : 3586.7 : 99.46 : 31.76
NEURAL NET : 11.808 : 18.97 : 7.98
LU DECOMPOSITION : 2284.7 : 118.36 : 85.47
====================ORIGINAL BYTEMARK RESULTS====================
INTEGER INDEX : 122.890
FLOATING-POINT INDEX: 41.370
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
=======================LINUX DATA BELOW=========================
MEMORY INDEX : 30.402
INTEGER INDEX : 30.866
FLOATING-POINT INDEX: 22.945
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
3) i686
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1252.1 : 32.11 : 10.55
STRING SORT : 349.32 : 156.09 : 24.16
BITFIELD : 8.5654e+08 : 146.93 : 30.69
FP EMULATION : 465.96 : 223.59 : 51.59
FOURIER : 27731 : 31.54 : 17.71
ASSIGNMENT : 51.986 : 197.81 : 51.31
IDEA : 10374 : 158.67 : 47.11
HUFFMAN : 4030.6 : 111.77 : 35.69
NEURAL NET : 11.511 : 18.49 : 7.78
LU DECOMPOSITION : 2312.3 : 119.79 : 86.50
====================ORIGINAL BYTEMARK RESULTS====================
INTEGER INDEX : 128.472
FLOATING-POINT INDEX: 41.184
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
=======================LINUX DATA BELOW=========================
MEMORY INDEX : 33.632
INTEGER INDEX : 30.927
FLOATING-POINT INDEX: 22.842
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
OK, so what's the verdict?
Well, on our platform, with this particular test, there is very little difference. i686 is a pretty viable choice for those who have older hardware in particular...not any slower than the pentium4, in fact, the memory access marks were higher. Not sure how memory bus speed settings imact this (if they do at all???), but clearly there is more to this.
Those of us who do have non-ancient hardware (OK, even my K10 is old news), or are thinking of moving up to newer hardware, should probably install the pentium4 stuff.
I for one am curious if the newer GCC releases (like Paul's 7.3.0 for example) are able to produce faster code? Worth a try...but can anyone point me to some reading on how to support multiple GCC installs on our platform??? I did some preliminary linux reading on this, seems to be all about the \usr\local\. setups, but is this even viable on OS/2?
Last, I've attached the full dump of all the testing results I capture...about 30 different runs, if anything it'll give you some ideas what were the different flags I tried.
-
Hi Dariusz, looking at your results, I'd say that i686 is your best choice due to faster memory (perhaps related to instruction ordering) and slightly faster integer, which is used much more then floating point. They're both close though. Be nice to have a Pentium M choice, basically i686 with MMX, SSE, and SSE2.
Did you try adding -mstackrealign with your -mfpmath=sse flag?
Using newer compilers isn't too hard. Paul uses /usr/localxxx (where xxx is the compiler version) as the target so you can unzip into your UNIXROOT tree. KOMH released a modified gccenv.cmd that makes switching fairly easy. I rename it to reflect the compiler version, eg gcc510env.cmd or gcc710env.cmd and it needs adjusting at about line 68 to point to the correct /usr/localxxx location, eg for gcc 5.10 I have
/*
* Do work.
*/
call GCC322plus sPath, 'gcc510', 0, sLinker;
exit 0;
Gotchas include that by default it resets to using ilink as the linker and Paul's ports sometimes find \usr\lib\stdc++.a or stdc++.lib or stdc++_s.a instead of the correct ones. Simplest is to temporarily move them aside if compiling C++ code.