Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: ami_stuff on June 13, 2009, 04:51:13 PM
-
I found out that in some cases GCC 4.4 generates a slower binaries compared to GCC 3.4. PNGCrush compiled with GCC 4.4 seems to be about 20% slower.
I need someone who have a real Amiga with 68040/68060 CPU.
Here is a link to archive with PNGCrush optimized for 040/060 CPUs:
http://www.filejumbo.com/Download/D7FEA95B5375BE18/
Please download it, unpack, copy all files to RAM: and run PNGCrush like this:
1. When your Amiga have 68040 CPU:
PNGCrushGCC34_040 pngtest.png out.png
delete out.png
PNGCrushGCC44_040 pngtest.png out.png
2. When your Amiga have 68060 CPU:
PNGCrushGCC34_060 pngtest.png out.png
delete out.png
PNGCrushGCC44_060 pngtest.png out.png
Please post here "CPU time used" results generated by GCC 3.4/GCC 4.4 builds, optimized for your processor.
-
Ok, running it now on a Bliz 1260.
GNU nano 2.0.9 File: ../Download/result
gcc34 68060 50mhz
CPU time used = 267.340 seconds (decoding 16.940,
encoding 247.800, other 2.600 seconds)
gcc44
CPU time used = 328.360 seconds (decoding 16.800,
encoding 309.260, other 2.300 seconds)
-
Hi,
First of all, I couldn't run because i only had Version 48.5 of ixemul library and I needed V61. had to track that down before it would run.
Blizzard 060, 196mb ram:
PNGCrushGCC34_060
CPU time used = 338.000 seconds (decoding 22.380,
encoding 310.940, other 4.680 seconds)
PNGCrushGCC44_060
CPU time used = 411.220 seconds (decoding 21.660,
encoding 384.900, other 4.660 seconds)
Hope that helps!
-
Thanks for the results. It looks like a speed regression. Hmm, maybe someone can compile PNGCrush with GCC 3.x and 4.x for PPC, so we will know if this is only m68k problem or maybe this regression happens on all platforms.
-
Where do we get 440 in the first place ?
Have you also recompiled libpng with gcc 440 or just pngcrush ?
And what if you tried it with the options -m68020-60 -m68881 -ffast-math turned on ?!
Oh yeah, the output:
gcc 340 - 040 CPU time used = 38.220 seconds (decoding 4.280, encoding 32.840, other 1.100 seconds)
gcc 440 - 040 CPU time used = 47.080 seconds (decoding 3.560, encoding 42.160, other 1.360 seconds)
gcc 340 - 060 CPU time used = 38.540 seconds (decoding 4.600, encoding 32.740, other 1.200 seconds)
gcc 440 - 060 CPU time used = 47.360 seconds (decoding 3.520, encoding 42.440, other 1.400 seconds)
x303 :D :D :D
-
Where do we get 440 in the first place ?
As always, Bernd :)
Have you also recompiled libpng with gcc 440 or just pngcrush ?
Yes, PNGCrush is distributed with libz and libpng sourcecode in the archive. There is no need for external link libraries.
And what if you tried it with the options -m68020-60 -m68881 -ffast-math turned on ?!
I think "-m68020-60" shouldn't make any different, maybe slowdown a bit 68040/68060 builds. I strongly suggest to not use "-ffast-math" when this option is not enabled by default by software's developer in the makefile. It may create a lot of problems. For example, FFmpeg compiled with "-ffast-math" generates broken output while converting MP2 to WAV.
gcc 340 - 040 CPU time used = 38.220 seconds (decoding 4.280, encoding 32.840, other 1.100 seconds)
gcc 440 - 040 CPU time used = 47.080 seconds (decoding 3.560, encoding 42.160, other 1.360 seconds)
gcc 340 - 060 CPU time used = 38.540 seconds (decoding 4.600, encoding 32.740, other 1.200 seconds)
gcc 440 - 060 CPU time used = 47.360 seconds (decoding 3.520, encoding 42.440, other 1.400 seconds)
Thanks for the results!
-
As always, Bernd :)
You mean the amidevcpp package ?
I think "-m68020-60" shouldn't make any different, maybe a slowdown a bit 68040/68060 builds.
I never noticed that with my ports. And you need just 1 file for 4 systems (020/030/040/060)
I strongly sugges to not use "-ffast-math" when this option is not enable by default by software developer in the makefile. It may make a lot of problems. For example, FFmpeg compiled with "-ffast-math" generates broken output while converting MP2 to WAV.
I also never noticed that, ever. Even on my ffmpeg wos port it shouldn't be a problem. If ffmpeg gives broken output files, ffmpeg is broken.
x303 :D :D :D
-
You mean the amidevcpp package ?
No. You can get compiler from Bernd (bernd_afa). It's not included in the AmiDevCPP package.
I strongly suggest to not use "-ffast-math" when this option is not enabled by default by software's developer in the makefile. It may create a lot of problems. For example, FFmpeg compiled with "-ffast-math" generates broken output while converting MP2 to WAV.
I also never noticed that, ever. Even on my ffmpeg wos port it shouldn't be a problem. If ffmpeg gives broken output files, ffmpeg is broken.
-ffast-math
Sets -fno-math-errno, -funsafe-math-optimizations,
-fno-trapping-math, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-limited-range.
This option causes the preprocessor macro __FAST_MATH__ to be defined.
This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.
Be careful with this option ;)
-
Here is a quick release of FFplay.
Changes:
SVN-r18880a:
- added selectable hicolor/trucolor dither modes (-dither gray/hicolor/truecolor)
- added "-autoexit" option (playback will end a few secs before actual end of the video)
- when Workbench's bit depth is 8bit and no "-dither" option is specified,
FFplay will use fullscreen gray mode
- fixed some audio/video out of sync problems while switching between fullscreen/windowed modes
- fixed problem with display of images bigger than Workbench's screen resolution
in windowed mode (only a part of the image was displayed)
- fixed crash with images bigger than 2048 pixels
- 16bit display should work now correctly on the Spectrum gfx card (thanks to updated libSDL)
- added about requester :)
-
SVN-r18880b:
- fixed audio/video out of sync problems while resizing FFplay's window without LMB release
(not decoded video track will be skipped now)
- some not so important changes here and there
-
FFplay worx pretty good. Still some problems with the timing / frame skipping while not doing anything. But this might be also have something to do with my underpowered machine, running winuae 1.6.1. with a 32bit screen.
idea for next release: press 'L' for loading next file.
x303 :D :D :D
-
SVN-r18880c:
- fixed a bug which I intruduced in the previous release (sometimes resize skipped too much of video track)
This is the last release of SVN-r18880 - new SVN after ~2 months.
http://www.filejumbo.com/Download/7CF785BDF093CAAE/
@x303:
I tryed to add file requester with "o" key to load another video, but when I close old video and open another one, I get "unknown codec type" error.
-
Please someone run this benchmark on the 68040:
http://www.filejumbo.com/Download/1A7322C3ADB24B74/
Thanks
-
I've run your test program on my 060 setup and the new routine is about 10x faster than the old one.
x303 :D :D :D
-
I've run your test program on my 060 setup and the new routine is about 10x faster than the old one.
x303 :D :D :D
Thanks, maybe someone will post results from 68040 :afro:
-
@x303
Speaking of FFMPEG and FFPlay, could you compile an up-to-date WarpOS version? 68k version is so sluggish. If it requires too much work, then forget my request. No problem.
(sorry for diverting the topic, but i just couldn't resist.. :D)
-
Thanks, maybe someone will post results from 68040 :afro:
Nevermind, I have the results already.
-
@x303
Speaking of FFMPEG and FFPlay, could you compile an up-to-date WarpOS version? 68k version is so sluggish. If it requires too much work, then forget my request. No problem.
(sorry for diverting the topic, but i just couldn't resist.. :D)
I can only do this if I have a compiled 68k version, so I know which file to include and which not.
x303 :D :D :D