Monkey C compiler optimization settings?

I am just looking at these compiler options as well.

Any reason why you are using 3z and not 3pz? According to the manual, p and z can be combined, so it would not hurt, would it?

I don't remember. Maybe when it started then it wasn't possible, or it wasn't documented this way. Not sure.

I don't know how it works (if at all) and if there's a difference between 3z vs 3p vs 3pz or actually even 3zp (if these really do something then it would make sense that 3pz and 3zp would generate different output)

It might even be that with a newer version of the SDK or a newer version of your app it changes which one is the best for you. Back then I played quiet a lot with it, and I even retested things with newer versions of the SDK, but I don't do it any more (though probably should do)

the-ninth said:

Any reason why you are using 3z and not 3pz? According to the manual, p and z can be combined, so it would not hurt, would it?

I do find it interesting that the dropdown at command palette > User Settings > Monkey C > Monkey C: Optimization Level only has the following options:

- default

- None (0)

- Basic (1)

- Fast (2)

- Slow (3)

There's no way to specify the p and z suffixes via the UI.

Obviously it would be clunky to have all possible combos of numerical optimization level and suffixes in one drop down, but maybe they could've added a couple of checkboxes for the suffixes (which would also be clunky).

I'm just wondering if the reason p and z aren't in the settings UI is because it's too clunky, because Garmin sees no value (maybe those options don't really do anything), or because Garmin thinks those are advanced options that the average dev doesn't need to use.

I"m also wondering whether it's truly possible to aggressively optimize for both speed and size at the same time.

At least in gcc, if you optimize for size, the program might get slower, and if you optimize for speed at the most aggressive level, the size of the output might get bigger.

If you specify pz in Monkey C, does the compiler take a balanced approach?

e.g. assuming p and z are fully functional, maybe:

- p alone aggressively optimizes for performance

- z alone aggressively optimizes for size

- pz is a balance between performance and size optimization

Ofc I'm just guessing, I have no idea how it actually works (or whether those options are fully functional.)

Also, if pz is always superior to either p or z, then why would Garmin have the suffixes in the first place? Couldn't it just run in pz mode all the time [assuming optimization is enabled]? [I'm assuming that any considerations regarding build time would be addressed by choosing the appropriate numerical optimization level]

I have been running some tests today, trying 3pz, 3p, 2p, 2p, 2z, 2.

The results are kind of all over the place. On a Fenix6Pro, 2p (=performance) gives me the most memory savings (1.9%), while 2 delivers the best performance (2.8%). On a Epix2Pro, all parameters deliver the same memory savings (1.3%), and 2z the best performance (1.6%).

Generally I get the feeling that the "slow" 3 maybe even refer to the actual performance of the code. Especially on the Fenix6Pro results seem worse with 3 than without optimization when it comes to performance.

Though the performance testing is kind of sketchy, especially on the Epix2Pro. I let the profiler run for 5 minutes, with onUpdate being called every 10 seconds, and take the average execution time. The parameters under which onUpdate works are always the same. Still one run for a certain device can deviate about 1% from the next. So basically all results are within that margin of error

my guess is that p and z still don't change anything

the-ninth said:

Generally I get the feeling that the "slow" 3 maybe even refer to the actual performance of the code. Especially on the Fenix6Pro results seem worse with 3 than without optimization when it comes to performance.

That would be hilarious but the settings UI help does suggest that "fast" and "slow" refer to compile time (at least supposedly)

What's even more funny is that that's exactly what we're promised, that the compilation will be slower. No word regarding whether it tries to optimize the code size or code performance. So maybe really what they do is just to add less or more empty loops to fulfill the promise :) 

flocsy🤠 said:

my guess is that p and z still don't change anything

For memory, the results are quite reproducible, and I do get different results when I add p or z.

Edit: I have to withdraw that statement. I run the whole test suit again, and now the results are the same for 2, 2p, 2z, 2pz, 3, 3p, 3z, and 3pz. Not sure what I did differently in my initial test.

The best optimizer is located between the chair and the keyboard, and things depend on how well the the original code was written.  If the code isn't that great, the optimizer could really help, but well written, maybe not as much.

Also new byte codes were added to newer device to reduce the size of the prg, which could impact the size between different devices.  See the --disable-v2-opcodes compiler flag

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/welcome-to-system-7

More with Less

System 7 helps you do more with less in a number of different ways. Devices supporting API 5.0.0 have new updates to the system opcodes designed to reduce the code space for common operations. Developers should expect an improvement of 20%– 30% when compiling on new devices.