Announcing the traditional bug splat update to SDL 0.6
Lots of little bugs fixed.
http://www.devolution.com/~slouken/SDL/develop.html
See ya!
Announcing the traditional bug splat update to SDL 0.6
Lots of little bugs fixed.
http://www.devolution.com/~slouken/SDL/develop.html
Can we start breaking the tarballs up, or run a cvs, or provide patches?
~1MB is getting big to download every few days
on a more interesting note, I’ve finally got a ‘good’ egcs installed, so I
should be able to leap on the development sharp bit(:)…
njhOn Fri, 17 Apr 1998, Sam Lantinga wrote:
on a more interesting note, I’ve finally got a ‘good’ egcs installed, so I
should be able to leap on the development sharp bit(:)…
WooHoo! it compiles!!!
njhOn Sat, 18 Apr 1998 @Nathan_J_Hurst wrote:
Can we start breaking the tarballs up, or run a cvs, or provide patches?
~1MB is getting big to download every few days
Sure. I’ll provide patches as well as tarballs.
CVS, well… we’ll see. 
See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
on a more interesting note, I’ve finally got a ‘good’ egcs installed, so I
should be able to leap on the development sharp bit(:)…
Just don’t impale yourself!
WooHoo! it compiles!!!
Does it work too?
See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
njh> ist und schreibt am Sat, 18 Apr 1998 12:11:26 +1000 (EST):
Hello Sam,
I would be happy to get smaller patches as context diffs for the different releases. During
my vacation my only modem is a GSM mobil phone. With ~9600 Baud is it not the fastest and
cheapes way to suck your distribution
So I agree with njh.
njh> On Fri, 17 Apr 1998, Sam Lantinga wrote:
Announcing the traditional bug splat update to SDL 0.6
Lots of little bugs fixed.
http://www.devolution.com/~slouken/SDL/develop.html
njh> Can we start breaking the tarballs up, or run a cvs, or provide patches?
njh> ~1MB is getting big to download every few days
njh> on a more interesting note, I’ve finally got a ‘good’ egcs installed, so I
njh> should be able to leap on the development sharp bit(:)…
njh> njh–
Freundliche Gr??e,
Best regards,
i.V. Michael H?hne
Sales Manager WorldCom
UUNET Sales Department
Mob.: [+49] 172/521-6104 UUNET Deutschland GmbH
Tel.: [+49] 231/972-1071 Emil-Figge-Stra?e 80
Fax.: [+49] 231/972-1122 44227 Dortmund, Germany
mailto:mich at de.uu.net http://www.uunet.de/
njh> ist und schreibt am Sat, 18 Apr 1998 15:46:59 +1000 (EST):
Dear SDL fan:
You can easily delete this E-mail if you are not interested in Linux Pentium optimized code.
njh> On Sat, 18 Apr 1998 njh at cs.monash.edu.au wrote:
on a more interesting note, I’ve finally got a ‘good’ egcs installed, so I
should be able to leap on the development sharp bit(:)…
njh> WooHoo! it compiles!!!
njh> njh
Hi njh,
have you ever tried the fast and stable pgcc-1.0.1 or new pgcc-1.0.2 ? This pentium
optimizing spin off from the egcs project complies nearly every C code very well for me. The
resulting binary will be in most cases a few percent faster, and with higher optimizations up
to 20 percent faster than the standard egcs or gcc.
IMHO: Efficient and optimized code is better than a optimizing compiler, but if you can not
change the code, an optimizing compiler is a good choice.
Some things I have compiled with pgcc-1.0.1:
Latest XFree
Latest XEmacs
Latest Emcas
Latest stable Linux kernel
Libc
Libg++
Libstd++
Latest bash
Latest gs
and … many things more
as well as:
SDL up to SDL-0.6e and sdldoom-1.10-0.5. It it always worth a try
Here is the URL:
Here is my cook book for compiling fast binaries:
And these are my often used flags
-malign-double -mstack-align-double # Might be critical: double alignment on word boundary
Breaks abi definition but speeds
up floating point related code a
lot. Try it on yor own risk.
-funroll-all-loop # Mostly an overall win. But some dynamic loop code
can't be unrolled. Again try it on your own risc.
CFLAGS= -O6 -mpentium -ffast-math -malign-loops=2 -malign-jumps=2 -malign-functions=2
These options are mostly save for me. 97 % of all code should compile and ran fast with this
options.
If you like to see an overall floating point speed up and you are using Linux libc5, install
this inline x87 math library inline-math-2.6.tar.gz.
To use this math library you need these options too:
CFLAGS += -D__USE_MISC -D__USE_ISOC9X
I am running successfully this inline asm code in my libc, kernel, X11R6, Emacs, Imagemagick
and most of my programs as well.
Here are a few compiler statistics:
Summary:
gcc-2.7.2.1> INTEGER INDEX : 1.773
gcc-2.7.2.1> FLOATING-POINT INDEX: 1.468
gcc-2.8.0> INTEGER INDEX : 1.792
gcc-2.8.0> FLOATING-POINT INDEX: 1.522
pgcc-1.0.1> INTEGER INDEX : 1.905 //=======> no ASM inline assembler
pgcc-1.0.1> FLOATING-POINT INDEX: 1.489 //=======> no ASM inline assembler
pgcc-1.0.1> INTEGER INDEX : 1.907 //=======> with ASM inline assembler
pgcc-1.0.1> FLOATING-POINT INDEX: 1.705 //=======> with ASM inline assembler
pgcc-1.0.1> INTEGER INDEX : 1.970 //=======> with ASM inline assembler in libc
pgcc-1.0.1> FLOATING-POINT INDEX: 1.826 //=======> with ASM inline assembler in libc
Here are the full test results:
gcc-2.7.2.1> BYTEmark* Native Mode Benchmark ver. 2 (10/95)
gcc-2.7.2.1> Index-split by Andrew D. Balsa (11/97)
gcc-2.7.2.1> Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
gcc-2.7.2.1>
gcc-2.7.2.1> TEST : Iterations/sec. : Old Index : New Index
gcc-2.7.2.1> : : Pentium 90* : AMD K6/233*
gcc-2.7.2.1> --------------------:------------------:-------------:------------
gcc-2.7.2.1> NUMERIC SORT : 71.429 : 1.83 : 0.60
gcc-2.7.2.1> STRING SORT : 6.3568 : 2.84 : 0.44
gcc-2.7.2.1> BITFIELD : 1.0222e+07 : 1.75 : 0.37
gcc-2.7.2.1> FP EMULATION : 3.3659 : 1.62 : 0.37
gcc-2.7.2.1> FOURIER : 1810.9 : 2.06 : 1.16
gcc-2.7.2.1> ASSIGNMENT : 0.51055 : 1.94 : 0.50
gcc-2.7.2.1> IDEA : 82.617 : 1.26 : 0.38
gcc-2.7.2.1> HUFFMAN : 54.845 : 1.52 : 0.49
gcc-2.7.2.1> NEURAL NET : 0.98775 : 1.59 : 0.67
gcc-2.7.2.1> LU DECOMPOSITION : 18.685 : 0.97 : 0.70
gcc-2.7.2.1> ==========================ORIGINAL BYTEMARK RESULTS==========================
gcc-2.7.2.1> INTEGER INDEX : 1.773
gcc-2.7.2.1> FLOATING-POINT INDEX: 1.468
gcc-2.7.2.1> Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
gcc-2.7.2.1> ==============================LINUX DATA BELOW===============================
gcc-2.7.2.1> C compiler : gcc version 2.7.2.1
gcc-2.7.2.1> libc : libc.so.5.4.39
gcc-2.7.2.1> MEMORY INDEX : 0.433
gcc-2.7.2.1> INTEGER INDEX : 0.450
gcc-2.7.2.1> FLOATING-POINT INDEX: 0.814
gcc-2.7.2.1> Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
gcc-2.7.2.1> * Trademarks are property of their respective holder.
gcc-2.8.0> BYTEmark* Native Mode Benchmark ver. 2 (10/95)
gcc-2.8.0> Index-split by Andrew D. Balsa (11/97)
gcc-2.8.0> Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
gcc-2.8.0>
gcc-2.8.0> TEST : Iterations/sec. : Old Index : New Index
gcc-2.8.0> : : Pentium 90* : AMD K6/233*
gcc-2.8.0> --------------------:------------------:-------------:------------
gcc-2.8.0> NUMERIC SORT : 72.105 : 1.85 : 0.61
gcc-2.8.0> STRING SORT : 6.3745 : 2.85 : 0.44
gcc-2.8.0> BITFIELD : 9.772e+06 : 1.68 : 0.35
gcc-2.8.0> FP EMULATION : 3.4662 : 1.66 : 0.38
gcc-2.8.0> FOURIER : 1790.6 : 2.04 : 1.14
gcc-2.8.0> ASSIGNMENT : 0.50067 : 1.91 : 0.49
gcc-2.8.0> IDEA : 88.684 : 1.36 : 0.40
gcc-2.8.0> HUFFMAN : 56.412 : 1.56 : 0.50
gcc-2.8.0> NEURAL NET : 1.0235 : 1.64 : 0.69
gcc-2.8.0> LU DECOMPOSITION : 20.345 : 1.05 : 0.76
gcc-2.8.0> ==========================ORIGINAL BYTEMARK RESULTS==========================
gcc-2.8.0> INTEGER INDEX : 1.792
gcc-2.8.0> FLOATING-POINT INDEX: 1.522
gcc-2.8.0> Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
gcc-2.8.0> ==============================LINUX DATA BELOW===============================
gcc-2.8.0> C compiler : gcc version 2.8.0
gcc-2.8.0> libc : libc.so.5.4.39
gcc-2.8.0> MEMORY INDEX : 0.424
gcc-2.8.0> INTEGER INDEX : 0.465
gcc-2.8.0> FLOATING-POINT INDEX: 0.844
gcc-2.8.0> Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
gcc-2.8.0> * Trademarks are property of their respective holder.
My currently used compile time options:
CFLAGS = -s -static -O6 -mpentium -ffast-math -D__USE_MISC -D__USE_ISOC9X
pgcc-1.0.1> BYTEmark* Native Mode Benchmark ver. 2 (10/95)
pgcc-1.0.1> Index-split by Andrew D. Balsa (11/97)
pgcc-1.0.1> Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
pgcc-1.0.1>
pgcc-1.0.1> TEST : Iterations/sec. : Old Index : New Index
pgcc-1.0.1> : : Pentium 90* : AMD K6/233*
pgcc-1.0.1> --------------------:------------------:-------------:------------
pgcc-1.0.1> NUMERIC SORT : 72.789 : 1.87 : 0.61
pgcc-1.0.1> STRING SORT : 6.6007 : 2.95 : 0.46
pgcc-1.0.1> BITFIELD : 1.0438e+07 : 1.79 : 0.37
pgcc-1.0.1> FP EMULATION : 3.7065 : 1.78 : 0.41
pgcc-1.0.1> FOURIER : 1250.4 : 1.42 : 0.80
pgcc-1.0.1> ASSIGNMENT : 0.5109 : 1.94 : 0.50
pgcc-1.0.1> IDEA : 93.11 : 1.42 : 0.42
pgcc-1.0.1> HUFFMAN : 67.568 : 1.87 : 0.60
pgcc-1.0.1> NEURAL NET : 1.232 : 1.98 : 0.83
pgcc-1.0.1> LU DECOMPOSITION : 22.621 : 1.17 : 0.85
pgcc-1.0.1> ==========================ORIGINAL BYTEMARK RESULTS==========================
pgcc-1.0.1>
pgcc-1.0.1> INTEGER INDEX : 1.905 //=======> no ASM inline assembler
pgcc-1.0.1> FLOATING-POINT INDEX: 1.489 //=======> no ASM inline assembler
pgcc-1.0.1>
pgcc-1.0.1> Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
pgcc-1.0.1> ==============================LINUX DATA BELOW===============================
pgcc-1.0.1> C compiler : gcc version pgcc-2.90.23 980102 (egcs-1.0.1 release)
pgcc-1.0.1> libc : libc.so.5.4.44
pgcc-1.0.1> MEMORY INDEX : 0.442
pgcc-1.0.1> INTEGER INDEX : 0.502
pgcc-1.0.1> FLOATING-POINT INDEX: 0.826
pgcc-1.0.1> Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
pgcc-1.0.1> * Trademarks are property of their respective holder.
pgcc-1.0.1> BYTEmark* Native Mode Benchmark ver. 2 (10/95)
pgcc-1.0.1> Index-split by Andrew D. Balsa (11/97)
pgcc-1.0.1> Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
pgcc-1.0.1>
pgcc-1.0.1> TEST : Iterations/sec. : Old Index : New Index
pgcc-1.0.1> : : Pentium 90* : AMD K6/233*
pgcc-1.0.1> --------------------:------------------:-------------:------------
pgcc-1.0.1> NUMERIC SORT : 73.316 : 1.88 : 0.62
pgcc-1.0.1> STRING SORT : 6.5958 : 2.95 : 0.46
pgcc-1.0.1> BITFIELD : 1.0438e+07 : 1.79 : 0.37
pgcc-1.0.1> FP EMULATION : 3.7065 : 1.78 : 0.41
pgcc-1.0.1> FOURIER : 1831.2 : 2.08 : 1.17
pgcc-1.0.1> ASSIGNMENT : 0.51282 : 1.95 : 0.51
pgcc-1.0.1> IDEA : 93.075 : 1.42 : 0.42
pgcc-1.0.1> HUFFMAN : 67.454 : 1.87 : 0.60
pgcc-1.0.1> NEURAL NET : 1.2654 : 2.03 : 0.86
pgcc-1.0.1> LU DECOMPOSITION : 22.597 : 1.17 : 0.85
pgcc-1.0.1> ==========================ORIGINAL BYTEMARK RESULTS==========================
pgcc-1.0.1>
pgcc-1.0.1> INTEGER INDEX : 1.907 //=======> with ASM inline assembler
pgcc-1.0.1> FLOATING-POINT INDEX: 1.705 //=======> with ASM inline assembler
pgcc-1.0.1>
pgcc-1.0.1> Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
pgcc-1.0.1> ==============================LINUX DATA BELOW===============================
pgcc-1.0.1> C compiler : gcc version pgcc-2.90.23 980102 (egcs-1.0.1 release)
pgcc-1.0.1> libc : libc.so.5.4.44
pgcc-1.0.1> MEMORY INDEX : 0.442
pgcc-1.0.1> INTEGER INDEX : 0.503
pgcc-1.0.1> FLOATING-POINT INDEX: 0.946
pgcc-1.0.1> Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
pgcc-1.0.1> * Trademarks are property of their respective holder.
pgcc-1.0.1> BYTEmark* Native Mode Benchmark ver. 2 (10/95)
pgcc-1.0.1> Index-split by Andrew D. Balsa (11/97)
pgcc-1.0.1> Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
pgcc-1.0.1>
pgcc-1.0.1> TEST : Iterations/sec. : Old Index : New Index
pgcc-1.0.1> : : Pentium 90* : AMD K6/233*
pgcc-1.0.1> --------------------:------------------:-------------:------------
pgcc-1.0.1> NUMERIC SORT : 81.316 : 2.09 : 0.68
pgcc-1.0.1> STRING SORT : 6.6038 : 2.95 : 0.46
pgcc-1.0.1> BITFIELD : 1.0469e+07 : 1.80 : 0.38
pgcc-1.0.1> FP EMULATION : 3.7106 : 1.78 : 0.41
pgcc-1.0.1> FOURIER : 1830.5 : 2.08 : 1.17
pgcc-1.0.1> ASSIGNMENT : 0.57715 : 2.20 : 0.57
pgcc-1.0.1> IDEA : 92.971 : 1.42 : 0.42
pgcc-1.0.1> HUFFMAN : 67.613 : 1.87 : 0.60
pgcc-1.0.1> NEURAL NET : 1.2737 : 2.05 : 0.86
pgcc-1.0.1> LU DECOMPOSITION : 27.578 : 1.43 : 1.03
pgcc-1.0.1> ==========================ORIGINAL BYTEMARK RESULTS==========================
pgcc-1.0.1> Computer : Tecra 740CDT / MMX-166 256 kb Cache Im Dock
pgcc-1.0.1>
pgcc-1.0.1> INTEGER INDEX : 1.970 //=======> with ASM inline assembler in libc
pgcc-1.0.1> FLOATING-POINT INDEX: 1.826 //=======> with ASM inline assembler in libc
pgcc-1.0.1>
pgcc-1.0.1> Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
pgcc-1.0.1> ==============================LINUX DATA BELOW===============================
pgcc-1.0.1> C compiler : gcc version pgcc-2.90.23 980102 (egcs-1.0.1 release)
pgcc-1.0.1> libc : libc.so.5.4.44
pgcc-1.0.1> MEMORY INDEX : 0.460
pgcc-1.0.1> INTEGER INDEX : 0.516
pgcc-1.0.1> FLOATING-POINT INDEX: 1.013
pgcc-1.0.1> Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
pgcc-1.0.1> * Trademarks are property of their respective holder.–
Freundliche Gr??e,
Best regards,
i.V. Michael H?hne
Sales Manager WorldCom
UUNET Sales Department
Mob.: [+49] 172/521-6104 UUNET Deutschland GmbH
Tel.: [+49] 231/972-1071 Emil-Figge-Stra?e 80
Fax.: [+49] 231/972-1122 44227 Dortmund, Germany
mailto:mich at de.uu.net http://www.uunet.de/
have you ever tried the fast and stable pgcc-1.0.1 or new pgcc-1.0.2 ? This pentium
optimizing spin off from the egcs project complies nearly every C code very well for me. The
resulting binary will be in most cases a few percent faster, and with higher optimizations up
to 20 percent faster than the standard egcs or gcc.
The problem njh is, that he’s a LinuxPPC user (like me), and gcc on the
LinuxPPC is (very) broken.
Egcs is what I use, and at this point in time, is the stablest known
working compiler for PPC
IMHO: Efficient and optimized code is better than a optimizing compiler,
but if you can not
change the code, an optimizing compiler is a good choice.
Hehehe… well… good efficient code, needs a working complier
(As memory serves (correct me if I’m wrong, Nathan) he couldn’t even
compile egcs, and had to download an rpm from ftp.linuxppc.org)
Michael Samuel,
Surf-Net City - Internet Cafe and Internet Service Providers
Phone: +61 3 9593-9977
E-Mail:
WWW: http://www.surfnetcity.com.au/~michael/On 18 Apr 1998, Michael Huehne wrote:
The problem njh is, that he’s a LinuxPPC user (like me), and gcc on the
LinuxPPC is (very) broken.
Whose says I’m a problem???
Oh yeah, and egcs isn’t too bad, you only got the ‘good versions’ of
egcs/gcc, back in the good ol’ days you had to run things through gcc 10
times or so to get it to compile(I actually had a script which
ran the gcc -c parts of a makefile upto 20 times…)
(As memory serves (correct me if I’m wrong, Nathan) he couldn’t even
compile egcs, and had to download an rpm from ftp.linuxppc.org)
Not Quite, I could compile and older version of egcs… I’ll download the
latest sources and try them out using my new egcs rpms
njhOn Sat, 18 Apr 1998, Michael Samuel wrote:
On 18 Apr 1998, Michael Huehne wrote:
Just don’t impale yourself!
Euwww! I’m going pale just thinking about it.
WooHoo! it compiles!!!
Does it work too?
YES! All the test apps work, and my loopwave1-reverb works, almost; I’m
getting an interesting bug though.
In my inner(test) loop I’m doing something like this:
for each sample{
S = 0;
S += sample[i+0]*0.3; // modified coz I don’t have the exact
// source on hand
S += sample[i+128]*0.3;
outputbuff[i] = S;
}
If I do one of the sample[ lines it works fine. If I do the other sample[
line it works. If I do both the system hangs when it tried to open the
outputbuff for playing.
ideas?
njhOn Sat, 18 Apr 1998, Sam Lantinga wrote:
In my inner(test) loop I’m doing something like this:
for each sample{
S = 0;
S += sample[i+0]*0.3; // modified coz I don’t have the exact
// source on hand
S += sample[i+128]*0.3;
outputbuff[i] = S;
}
If I do one of the sample[ lines it works fine. If I do the other sample[
line it works. If I do both the system hangs when it tried to open the
outputbuff for playing.
ideas?
Do you have optimizing turned on? What datatype is S?
What do you mean by open outputbuff? Read from it?
Can you step with gdb and see exactly where it hangs?
See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
In my inner(test) loop I’m doing something like this:
for each sample{
S = 0;
S += sample[i+0]*0.3; // modified coz I don’t have the exact
// source on hand
S += sample[i+128]*0.3;
outputbuff[i] = S;
}If I do one of the sample[ lines it works fine. If I do the other sample[
line it works. If I do both the system hangs when it tried to open the
outputbuff for playing.ideas?
Do you have optimizing turned on?
Hmmm, don’t think so.
What datatype is S? float.
What do you mean by open outputbuff? Read from it?
Well, I just passed it as the buffer param to SDL_AudioPlay.
Can you step with gdb and see exactly where it hangs?
Later… breakfast first…
njhOn Sat, 18 Apr 1998, Sam Lantinga wrote: