GCC version VS performance

SGDK only sub forum

Moderator: Stef

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: GCC version VS performance

Post by Stef » Sun Jun 11, 2017 9:53 pm

Ok, i think i got it working right now, with a single bin folder :)
After some tests i can say the new GCC 6.3 can perform much better in some case (when you are calling many time a small method for instance where the previous GCC 3.4.6 was not able to inline it) and generally perform better than GCC 3.4.6.
On the SGDK benchmark tests i observed a score increase from ~18000 to ~21000 in total score. But i was using -O1 with GCC 3.4.6 while i'm using -03 and others extra optimization flags with GCC 6.3 so at the end, the difference is not that important. I even observed some cases where GCC 3.4.6 was a bit faster (with -O1) but only by a very small margin... SGDK is also already using assembly for some critical parts and i always tried to profile slow parts of the library and tried to help the compiler to produce the best code so this result is not that surprising.
I still believe that for a full C project the performance difference can be much more important (20% up to 50% faster in best case), I am confident it will help for the sprite engine which is still done in 100% C code :)

I had to fix some stuff in the lib to get it working correctly :
- put vtimer as 'volatile' (this is expected, it should have been volatile from beginning)
- increasing the default Stack size from 0x400 to 0x800 as newer optimizations tend to consume much more stack memory...
this one was tricky to figure (stack overwriting part of heap memory which create all sort of weird bugs).

So the next SGDK will definitely use the new GCC 6.3 ! Thanks again Gligli for your big contribution here =) I was even able to reduce a bit the size of required files so the bin folder size is about 43 MB for GCC 6.3 compared to previous 26 MB for GCC 3.4.6, definitely not as much as i was expecting :)
One minor bad news is that despite my efforts i couldn't get GDB working with BlastEm nor GensKmod, i obtains different errors on both emulators... I think the problem is on emulator side, probably not compatible with GDB 7.12

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: GCC version VS performance

Post by cero » Mon Jun 12, 2017 9:13 am

vtimer should not be volatile. If that helps anything, that's an optimization bug.

gligli
Newbie
Posts: 8
Joined: Thu Jun 08, 2017 7:46 am
Location: Lyon / France
Contact:

Re: GCC version VS performance

Post by gligli » Mon Jun 12, 2017 9:23 am

Stef:
Great :) The integrated benchmark doesn't even benefit much from the new optimisations, benchmarking mainly ASM code.
About GDB, I didn't have anything to test it, so it may just be compiled wrong...

cero:
vtimer is written by an interrupt and red by the main loop, that seems like a pretty standard case of needing volatile (being updated "behind the back" of the main loop).

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: GCC version VS performance

Post by Stef » Mon Jun 12, 2017 9:54 am

@cero>vtimer should be volatile as it's modified externally by the vint : the waitTick(..) call the getSubTick() and if vtimer is not volatile then the compiler can try to optimize the whole...

@gligli> I'm almost certain the problem is on emulator side about GDB don't worry. For the benchmark, yeah, lot of ASM code (for firsts tests) but not only :) Anyway we can still see the nice improvement :)

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: GCC version VS performance

Post by cero » Mon Jun 12, 2017 6:25 pm

Being updated via an interrupt is no different to being updated by a function called by the main loop. It's a global variable, any function can update it.

edit: But of course, LTO knows what the other functions do. So in the LTO case, making it volatile is correct.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: GCC version VS performance

Post by Stef » Mon Jun 12, 2017 7:00 pm

No, it's different as it can be updated while you're "reading" it :
While you are in the waitMs(..) method for instance, vint can happen and modify vtimer variable... no way to have this happening in classical single threaded environment.

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: GCC version VS performance

Post by Miquel » Mon Jun 12, 2017 7:48 pm

If vtimer is not volatile main function could have it in one register while testing it endlessly, while the interruption is updating it in memory.
Stef wrote:After some tests i can say the new GCC 6.3 can perform much better in some case (when you are calling many time a small method for instance where the previous GCC 3.4.6 was not able to inline it) and generally perform better than GCC 3.4.6.
The oldest version of GCC simply doesn't do any optimization between object files (*.o, *.obj), not a single inline expansion. That means that all optimization performed are done inside the c files, there is never a whole program optimization.
A think full way to overcome this limitation is to do what is called an amalgation, append all *.c files in to single one (not my idea) on compile time, using a makefile for example.
Talking about MD programs: Binary file grows, let's say about 20% more, but if you have your code distributed between several/lots of files is way faster, perhaps measures like twice as fast (obviously all depends on the code itself).
HELP. Spanish TVs are brain washing people to be hostile to me.

themrcul
Very interested
Posts: 116
Joined: Fri Apr 15, 2016 2:21 pm

Re: GCC version VS performance

Post by themrcul » Tue Jun 13, 2017 12:26 am

This is all exciting news, thanks all for your efforts in getting this going!

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: GCC version VS performance

Post by Sik » Tue Jun 13, 2017 1:17 am

Pretty much repeating what everybody is saying but:
cero wrote:Being updated via an interrupt is no different to being updated by a function called by the main loop. It's a global variable, any function can update it.
The change can literally happen in the middle of a sentence (let alone a whole function), so yes it needs to be volatile. Technically, it actually should be atomic, but a 68000 is only ever going to run one "thread" at a time (either main code or interrupt code), so it's good enough here.

It still won't work with values longer than 32-bit (in which case you should consider implementing mutexes or one-way queues). Not the case here, but something to take into account if the interrupt is meant to update multiple values or a struct or whatever else.
Sik is pronounced as "seek", not as "sick".

Manveru
Very interested
Posts: 85
Joined: Wed Sep 05, 2012 3:30 pm

Re: GCC version VS performance

Post by Manveru » Wed Jun 14, 2017 9:23 am

You can try the new GCC 7.1. It seems good.
The man who moves a mountain begins by carrying away small stones. Confucius, 551-479 BC

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: GCC version VS performance

Post by cero » Wed Jun 14, 2017 9:41 am

In the new version numbering, .1 is the old .0. I don't recommend .0 releases in general, especially for the compiler.

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: GCC version VS performance

Post by cero » Sat Jun 17, 2017 7:12 am

FYI, gcc 6.4 is going to be released in about three weeks.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: GCC version VS performance

Post by Stef » Sat Jun 17, 2017 10:05 pm

To be honest GCC 6.3 is "good enough" :) I think i will stick with it for sometime as long i don't meet any issues..

Post Reply