Author Topic: I need a tester with 040/060 Amiga (Read 2320 times)

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.

mike- · « **Reply #1 on:** June 13, 2009, 06:34:20 PM »

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)

wurzel · « **Reply #2 on:** June 13, 2009, 09:02:28 PM »

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!

ami_stuff · « **Reply #3 on:** June 13, 2009, 09:36:30 PM »

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.

x303 · « **Reply #4 on:** June 13, 2009, 10:44:10 PM »

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

ami_stuff · « **Reply #5 on:** June 13, 2009, 11:06:51 PM »

Quote from: x303;511037

Where do we get 440 in the first place ?

As always, Bernd

Quote

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.

Quote

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.

Quote

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!

x303 · « **Reply #6 on:** June 13, 2009, 11:16:49 PM »

Quote from: ami_stuff;511045

As always, Bernd

You mean the amidevcpp package ?

Quote

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)

Quote

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

ami_stuff · « **Reply #7 on:** June 13, 2009, 11:30:16 PM »

Quote from: x303;511047

You mean the amidevcpp package ?

No. You can get compiler from Bernd (bernd_afa). It's not included in the AmiDevCPP package.

Quote

Quote

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.

Quote

-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

ami_stuff · « **Reply #8 on:** June 21, 2009, 03:24:06 PM »

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

ami_stuff · « **Reply #9 on:** June 22, 2009, 09:22:58 PM »

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

x303 · « **Reply #10 on:** June 22, 2009, 10:32:08 PM »

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

ami_stuff · « **Reply #11 on:** June 23, 2009, 12:04:34 PM »

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.

ami_stuff · « **Reply #12 on:** August 15, 2009, 01:27:48 PM »

Please someone run this benchmark on the 68040:

http://www.filejumbo.com/Download/1A7322C3ADB24B74/

Thanks

x303 · « **Reply #13 on:** August 15, 2009, 04:45:38 PM »

I've run your test program on my 060 setup and the new routine is about 10x faster than the old one.

x303

ami_stuff · « **Reply #14 on:** August 15, 2009, 07:22:20 PM »

Quote from: x303;519337

I've run your test program on my 060 setup and the new routine is about 10x faster than the old one.

x303

Thanks, maybe someone will post results from 68040 :afro:

Author Topic: I need a tester with 040/060 Amiga (Read 2320 times)

ami_stuff

I need a tester with 040/060 Amiga

mike-

Re: I need a tester with 040/060 Amiga

wurzel

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

x303

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

x303

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

x303

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga

x303

Re: I need a tester with 040/060 Amiga

ami_stuff

Re: I need a tester with 040/060 Amiga