Overview Features Instructions Performance Forum Downloads Products Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireReleases
Performance and Benchmark Results!

QUALITY WARNING : Dissapointing Tools From AMINET!page  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 3163
02 Feb 2018 17:37


AMINET is a good idea.
 
A Database full of tools and programs for AMIGA.
Some of these programs are free software which people compiled for AMIGA.
Like for example the well known CPU benchmark BYTEMARK
 
Here is the matching AMIGA file in AMINET
EXTERNAL LINK 
 
The big problem with AMINET is that there is no quality control.
So it can happen that people have used very bad compile options and created huge and slow binaries - running 2, or 3 times slower than they should.
And that these "bad" binaries than were uploaded in AMINET.
 
 
 
What is Bytemark?
BYTEMARK is cross platfrom benchmark to measure CPU speed.
If you want to compare your 68K to an X86 - with this tool you can.
You would of course expect that such a benchmark is correctly compiled to run fast, right?
 
 
Lets take a look into BYTEMARK binary
 
OK lets pick one random function:

FABS:
  fmove.d $4(a7),fp0
  fmove.x fp7,-(a7)
  fmove.x fp0,fp7
  fabs.x fp7,fp0
  fmove.x (a7)+,fp7
  rts

 
Bytemark is also an FPU benchmark.
We see in this function 5 FPU instructions.
The code looks not optimal.
 

Lets see how the code will look with proper compile flags.


FABS:
  fabs.d $4(a7),fp0
  rts

 
Wow this makes a difference!
We have now 1 FPU instruction instead 5!
And we avoided 24 bytes of unneeded stack reads/writes.
So this functions got now many times faster!
 
In short this binary is badly compiled and could run several times faster if correctly compiled.
 

If you ever wondered why LAME is slow on AMIGA or why your 68060 runs worse CPU scores than an 80486 - now you know.
It might not your AMIGA - but badly compiled software.


Samuel Crow
(Apollo Team Member)
Posts 270
02 Feb 2018 20:39


Amen!  We need Bebbo's build of GCC 6.3 up to par ASAP!  Once that is done we can look at making it run on native hardware or a similar framework.  It's hard enough to get code working without having to check the code generation of the compiler.


Matthew Burroughs

Posts 8
02 Feb 2018 22:50


Feel somewhat embarrassed that i managed to read "disappearing Tools" and then wondered what Gunnar was banging on about.

Blame munching on toast while at keyboard.


Ronnie Beck

Posts 6
04 Feb 2018 13:52


Matthew Burroughs wrote:

Feel somewhat embarrassed that i managed to read "disappearing Tools" and then wondered what Gunnar was banging on about.
Blame munching on toast while at keyboard.

Why do we need to know this?  It isn't helpful to this thread to know that you miss-read a topic.


Ronnie Beck

Posts 6
04 Feb 2018 14:17


Samuel Crow wrote:

Amen!  We need Bebbo's build of GCC 6.3 up to par ASAP!  Once that is done we can look at making it run on native hardware or a similar framework.  It's hard enough to get code working without having to check the code generation of the compiler.

So I am interested to know what the benefits would be of GCC 6.3.  Modern C++11/14 support would be awesome for those of use who like C++.  But I am also wondering about those who would prefer a compiler that would run natively on Amiga.  Or am I wrong in the assumption that Bebbo's work would only result in a cross compiler running on Linux?  For initial development work I can see the advantage of using well featured tools like Eclipse for compiling projects.  But at some point, you will need to debug and profile that code. 

GCC generates a couple of different debugging symbol types as well as profiling but are any of them workable on OS3?

As a linux developer, the idea of using GCC to code for the Amiga is very attractive but I do wonder about the optimisation and debuggability of such code.


Gunnar von Boehn
(Apollo Team Member)
Posts 3163
04 Feb 2018 15:56


Ronnie Beck wrote:

But I am also wondering about those who would prefer a compiler that would run natively on Amiga.

Why should it not run on AMIGA OS?


Marlon Beijer

Posts 81
04 Feb 2018 17:33


Ronnie Beck wrote:
So I am interested to know what the benefits would be of GCC 6.3.  Modern C++11/14 support would be awesome for those of use who like C++.  But I am also wondering about those who would prefer a compiler that would run natively on Amiga.  Or am I wrong in the assumption that Bebbo's work would only result in a cross compiler running on Linux?  For initial development work I can see the advantage of using well featured tools like Eclipse for compiling projects.  But at some point, you will need to debug and profile that code. 
 
  GCC generates a couple of different debugging symbol types as well as profiling but are any of them workable on OS3?
 
  As a linux developer, the idea of using GCC to code for the Amiga is very attractive but I do wonder about the optimisation and debuggability of such code.

GDB used to work on aros-m68k so I definitely think debugging would be doable, remotely. You don't need to compile on the actual machine to be able to debug, you know. By setting up a gdbserver in AmigaOS and feeding it with the binary you want to debug, you can then connect with your IDE of choice that has GDB support and step through the code.

There's also this guy that has started to make gdbserver built-in to FS-UAE and WinUAE, to be able to debug programs directly in an UAE environment.

Compiling and doing all that stuff directly on a classic Amiga would be as much fun as watching paint dry. But to each their own.


Gunnar von Boehn
(Apollo Team Member)
Posts 3163
04 Feb 2018 18:03


Marlon Beijer wrote:

  By setting up a gdbserver in AmigaOS and feeding it with the binary you want to debug, you can then connect with your IDE of choice that has GDB support and step through the code.
 

 
You can connect to APOLLO using JTAG cable and a GDBserver running on Linux and can remote debug it with GDB.
APOLLO has advanced debugging features build in - some of the team did already do this.
 


Marlon Beijer

Posts 81
04 Feb 2018 18:54


Gunnar von Boehn wrote:

Marlon Beijer wrote:

  By setting up a gdbserver in AmigaOS and feeding it with the binary you want to debug, you can then connect with your IDE of choice that has GDB support and step through the code.
 

 
  You can connect to APOLLO using JTAG cable and a GDBserver running on Linux and can remote debug it with GDB.
  APOLLO has advanced debugging features build in - some of the team did already do this.
 

Sweet, didn't know this. :)


Ronnie Beck

Posts 6
04 Feb 2018 19:32


Gunnar von Boehn wrote:

Why should it not run on AMIGA OS?

Good question.  I guess the the author is the best person to answer that.  The first line of the project page's overview says "this fork of amigaos-cross-toolchain project provides an easy way to build AmigaOS 3.x (m68k) target toolchain in a Unix-like environment."

I don't personally see why it shouldn't be ported to run on AmigaOS as well.  Or at least the debugger. but I am not doing the porting.  And I don't really know enough to know the difficulty of porting gdb to OS3.  Or maybe it is ported.  But any mention of it is glaring omission of the listed goals and the documentation I read.  But I will be very happy to be wrong.  :-)


Ronnie Beck

Posts 6
04 Feb 2018 19:44


Marlon Beijer wrote:

You don't need to compile on the actual machine to be able to debug, you know. By setting up a gdbserver.......

Yes......I know.  But What gdbserver/debugger works with this compiler????  That is the question.  Maybe it is too early in the projects life to answer this question.  I leafed through the downloads and the documentation.  I don't see any mention of a debugger nor any gdb/gdbserver compiled for Amiga OS.  I guess we just have to see how the project progresses.


Marlon Beijer

Posts 81
04 Feb 2018 20:11


Ronnie Beck wrote:

Marlon Beijer wrote:

  You don't need to compile on the actual machine to be able to debug, you know. By setting up a gdbserver.......
 

 
  Yes......I know.  But What gdbserver/debugger works with this compiler????  That is the question.  Maybe it is too early in the projects life to answer this question.  I leafed through the downloads and the documentation.  I don't see any mention of a debugger nor any gdb/gdbserver compiled for Amiga OS.  I guess we just have to see how the project progresses.

It's been discussed in the EAB thread. The focus is on getting the compiler to produce good code specific for AmigaOS 3.x. GDB stuff will come later on. Treat it like a beta, as it's under heavy development.


Roman S.

Posts 127
04 Feb 2018 20:37


Ronnie Beck wrote:

I don't personally see why it shouldn't be ported to run on AmigaOS as well.

I can think of two possible reasons:

- I bet there is no compiler being able to produce Amiga m68k output, with C++ support advanced enough to compile GCC 6.2... bebbo is working on this, but his port is not stable enough yet
- GCC 6.2 might have dependencies, which are not yet ported to AmigaOS



Mr Niding

Posts 226
04 Feb 2018 21:14


Daniel/Daytona highlighted crappy optimization in the original Tower57 code. His code runs 13-17 times faster

EXTERNAL LINK


Matthew Burroughs

Posts 8
06 Feb 2018 18:32


Tad Harsh, not one for jokes eh?


Daytona 675x

Posts 17
06 Feb 2018 20:37


@Mr Niding
Yes, but in case of T57 that's not the fault of a crappy compiler... ;)

But anyway, somewhere here some months ago I brought up the issue with benchmark-comparisons based on poor builds with antique compilers already. IIRC it was sth. about PPC scoring far less than it was actually capable of.
Good that people get reminded that benchmarks are always to be enjoyed with caution (not just because of this problem).


Gregthe Canuck

Posts 216
06 Feb 2018 23:41


Hey Daytona -

Do you think a T57 port to Vampire is feasible on the V4?


Gunnar von Boehn
(Apollo Team Member)
Posts 3163
07 Feb 2018 08:31


I think we have 3 separate problems.

A) Program written in a very slow way by design.
Those are coding design question and sometimes
also bad programming like passing variables by value instead by reference. Tower 57 might be an example here.

B) People doing mistake during compile.
This means the person compiling the executable for AMIGA, did accidentally make a compile with disabled compile optimizations.
We can see on AMINET many examples of normally good programs
bad badly compiled. A good example would be LAME here.

C) Quality of C compilers.
GCC and other C compiler sometimes create relative bad results.

Lets give an example:

Below is part of the main render function in NEO-GEO emulator.


L73:
        bfextu d1{#4:#4},d0
        tst.b d0
        jeq L74
        and.l #255,d0
        move.w 2(a2,d0.l*4),18(a0)
L74:
        bfextu d1{#8:#4},d0
        tst.b d0
        jeq L75
        and.l #255,d0
        move.w 2(a2,d0.l*4),20(a0)
L75:
        bfextu d1{#12:#4},d0
        tst.b d0
        jeq L76
        and.l #255,d0
        move.w 2(a2,d0.l*4),22(a0)

This code uses 5 instructions per pixel.
The BFEXTU does set the flags correctly.
GCC is nor aware if this - and put there an extra TST instruction to create the flags. This instruction is NOT needed and useless.
Then GCC puts there a AND.L #$FF,D0 to limit the result to BYTE range. The extracted value of BFEXTU is by the parameter already limited to Byte range. This means this AND is totally unneeded.

In short: of the 5 instruction - 2 are useless.

That GCC throws on 68K huge number of unneeded TST instructions is a known bug in GCC - which is caused by the laziness of the GCC developers - they simply did not care to implement a tracking of the flags created by instructions.

With a little better C-Compiler we can assume that many programs can run 10% faster easily.

More can be gained by people hand tuning important functions.
Its obvious that by re-designing this main NEO-GEO draw function we can make it easily 5 times faster with AMMX.




Roman S.

Posts 127
07 Feb 2018 08:48


One more problem is software which reinvents the wheel - these are usually quick&dirty ports from Linux. Example: ImageMagick and NetPBM, which do not use datatypes to load/store images (they have own routines), ImageMagick does not use diskfont.library to load system fonts (has own routines, able to load XWindow fonts, but not Amiga-format fonts), etc.


Gregthe Canuck

Posts 216
07 Feb 2018 08:59


Gunnar -

I have asked 'bebbo' if his current gcc port has the same issue with the tst instruction.

posts 24page  1 2