I need a tester with 040/060 Amiga

[ami_stuff]

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.

[ami_stuff]

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.

[ami_stuff]

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!

[ami_stuff]

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

[ami_stuff]

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]

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

[ami_stuff]

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]

Please someone run this benchmark on the 68040:

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

Thanks

[ami_stuff]

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:

[ami_stuff]

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

Nevermind, I have the results already.