• Replies 46 replies
  • Subscribers 22 subscribers
  • Views 6237 views
  • Users 0 members are here
Options
Related

4.1.4 Compiler 2 Beta code size comparsion

flocsy🤠
over 2 years ago
I compared the old compiler (4.1.4) with the new compiler (4.1.4 Compiler 2 Beta - https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/optimal-monkey-c)
                                    curr,peak,global,code,data,entry,settings,
old compiler, old sim:   26.0,27.2,1926,10960,4597,4094,1152
old compiler, new sim: 26.2,27.4,1614,10960,4597,4094,1023
new without params:   26.1,27.3,1614,10932,4600,3998,1023
new with -O 0:             26.2,27.4,1614,10960,4597,4094,1023
new with -O 1:             26.1,27.3,1614,10932,4600,3998,1023
new with -O 2:             24.8,26.1,1553,9988,4384,3963,1023

Some things to note:
- I was using -l 3 in all cases
- I had to "fix" or maybe "hack" some errors that appeared with the new compiler
- I'm not sure about the differences between old compiler old sim, new compiler new sim (it was probably a mistake, it happened because I tried the new compiler, new sdk, and it opened the sim, but later I switched back to 4.1.4 and forgot to close the sim)
- the default for the new compiler is -O 1 (not -O 0 !!!)
- I can hardly imagine any reason (unless we find some bug in the compiler that happens only in -O 2) why anyone would not use always -O 2
  • over 2 years ago in reply to flocsy🤠
    flocsy🤠 said:
    BTW previously (maybe in another thread) Jim wrote that if-s are faster than switch cases.

    Yeah, if statements save memory compared to switch statements. I think switch statements utilize a jump table which results in bigger code. As far as speed goes, I'd guess that switch statements with lots of cases are faster than the equivalent if..else statements -- O(1) vs O(n) where n is the number of cases -- but for practical purposes nobody is going to notice the speed difference, unless you have 10,000 cases or something.

    But in a perfect world, a good optimizing compiler should be able to generate equivalent code for both if you're optimizing for space.

  • over 2 years ago in reply to flocsy🤠
    flocsy🤠 said:
    Yeah, but really if you have or want to have enums just try it out and compare in view Memory.

    This was just an example.  Just would be nice for Garmin to be more clear on what optimizations that make our code harder to read can be stopped without hurting the compiled app.  (And also help testing the beta if we find it doesn't do as expected)  I expect some optimizations are specific cases so not something we should try to aim our code for, but some may be able to make it so our code can be more readable

  • over 2 years ago

    I've optimised my code myself so need optimization only for one things that is out of me: putting into code const/enums and not treat them as var (memory/code). When I see the generated code to initialise array with const - shivers go through me :-).

    So the most important thing is to explain (it can't be a secret) by example what does it mean (without description I'll spend hours to changing, building and watching into memory monitor):

    This optimization pass will perform constant folding, constant substitution, branch elimination and a few other optimizations before generating your executable.

    is 'constant substitution' 'inliniing' values of enums/const?

  • over 2 years ago

    I've recompiled my WF with beta 4.1.4 and  -O 3

    1. no const in vars Slight smile

    2. mem usage -2.4kB Slight smile

    3. globals -0,4kB Slight smile

    4. code -1.2kB Slight smile

    5. data -0,5kB Slight smile

    6. entry -0,4kB Slight smile

    7. settings 0kB

    Not much (~2% for 92kB devices) but it can save app if you are under the cap Slight smile

    Good work GARMIN!!!!!!!

  • over 2 years ago in reply to _psx_

    Do you see any difference between -O2 and -O3?

  • over 2 years ago in reply to flocsy🤠

    no, everything the same