Author Topic: YUM and RPM repositories - unable to add and save, why?  (Read 16099 times)

TeLLie

  • Full Member
  • ***
  • Posts: 226
  • Karma: +11/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #15 on: February 17, 2018, 06:37:09 pm »
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.

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +23/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #16 on: February 17, 2018, 07:16:25 pm »
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.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #17 on: February 17, 2018, 07:19:22 pm »
...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 ===

TeLLie

  • Full Member
  • ***
  • Posts: 226
  • Karma: +11/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #18 on: February 17, 2018, 09:07:40 pm »
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

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #19 on: February 17, 2018, 10:18:32 pm »
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.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #20 on: February 19, 2018, 07:14:22 pm »
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.
« Last Edit: February 19, 2018, 07:16:13 pm by Dariusz Piatkowski »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #21 on: February 19, 2018, 07:46:07 pm »
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
Code: [Select]
/*
 * 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.