Tools>optimize> ??

Status
Not open for further replies.

dewoof

Member
Hello,

Does one of the choices to 'optimize' just leave the code as it is - i.e. not optimize at all?
I get different results depending on what optimize tool I choose, so I'd like to turn 'optimize' off…

Thanks!
 
"get different results"?

Code behaves differently, wrongly, unexpected results? What Teensy is in use and what libraries and code?

Except in few aberrant cases the code will most always compile to the same functionally working state if it is properly written for the intended task, and not misusing or abusing odd procedures in completing the task, which the compiler misinterprets.

On Teensy_LC the default is for size to maximize the available RAM/FLASH space. On the others it seems 'FAST' is the default. Across the standard use cases of the libraries they have likely been most tested to work with these defaults.

Writing in a 'higher level' language not native to the processor - i.e. C/C++ versus Assembler that maps 1 to 1 to the machine instructions takes "Interpretation" by the compiler.

Following the language rules the indicated intent and process is mapped to processor instructions and data space.

This is always done in some 'optimal' fashion to express the intent - there is no 'Optimize Off', in some ways perhaps that would be DEBUG, which will attempt in some fashion to do a linear and literal expression that allows walking through the resultant machine code and having the highest match of related code following line by line from the source code.

The same idea can be expressed/mapped various ways. There is a trade off between code size and code speed.

Making the code small takes effort in one direction, making the code for 'debug' goes another direction, and making it fast has a series of steps as indicated by the menu where increasingly 'risky' or far reaching attempts are made to minimize the code overall. When it works as desired - it wasn't risky, but efficient with the provided settings. And of note these increasingly FASTER steps may or may not build faster code depending on how the code actually runs across selected small or large areas of active code.

Then after the compiler is done - the linker puts the pieces together into a working whole. It makes some assumptions based on the objects presented after compiling and orders the code that it sees as used. The LTO (Link Time Optimizer) option goes a step farther in what is really used and perhaps re-used when it decides what gets placed where in the resultant executable.
 
It is traditional that "Debug" is the not-optimized version of the code.

When you say "different results," what do you mean? Unless you're measuring timing, if the result of your code changes based on optimizations, it's likely you have a bug in your code that the compiler is "exploiting" when turning on optimizations.
 
Ok.

Now I understand a bit more about what is going on - I thought Debug might be the closest to non-optimized as it ran my code the best.
I think because I hadn't seen the optimize options before (because I was using older versions of Arduino and Teensyduino?) I suspected them of changing the code - which I guess they actually are.

more details:
T32.
#include <Wire.h>
#include <SPI.h>
#include <EEPROM.h>
#include <Encoder.h>
#include <ILI9341_t3.h>
#include <XPT2046_Touchscreen.h>

Using the 2.8" TFT touchscreen

The problems I'm having are all in the graphics.
But they manifest differently depending on which optimize setting I use.
Rectangles don't draw, they don't fill, or they are the wrong size.
So maybe the ILI9341_t3.h is where things get weird or (more likely) the problems are entirely in my code.

I was just trying to find out which optimize setting I should use to track down those bugs - I guess I'll keep using Debug.

Interestingly, every optimize setting produces better results when LTO is on.

Thanks for the quick help!
 
LTO is the newest and oddest way to get optimization, great when it works.

I suspect there may be some issue in your code, maybe not directly in sketch code - but the library interaction. It is possible running faster with optimizations is bringing that out. May be caused by conflicts among the various hardware - that exact combination may not have been used, and if so with alternate libraries.

What speed is the T_3.2 running at? 96 MHz or faster is great at times - but that is overclocked. Trying 72 MHz may show changes (better or worse) if it is timing related.

You might look to use the Teensy replacement for wire : #include <i2c_t3.h>.
 
Interestingly, every optimize setting produces better results when LTO is on.

Yes, but LTO also exposed several subtle, long-standing bugs in some libraries (many of them my fault). Several places were missing "volatile" on certain variables. Most have been fixed in the last several versions. Someday LTO will become the default.
 
If you say "graphics changes," then it sounds like you're driving the graphics display faster than it can keep up -- i e, a timing problem.
If you're using software SPI, then the timing of toggling the bits / clock / bus may change with optimization levels.
Exactly where this change happens needs debugging in the code using either changes-and-deduction, or a logic analyzer, or both.
 
So,

I have switched to a T35 since that's where I'm headed with this anyways.
I got the most distracting bugs out of my code.
I set the clock speed at 168 MHz - just to see what would happen...
Then I compiled with all the different optimize settings/choices:

Debug -----------------------------> Ok
Debug with LTO ------------------> Ok
Fast -------------------------------> NOT Ok
Fast with LTO ---------------------> Ok
Faster -----------------------------> NOT Ok
Faster with LTO ------------------> Ok
Fastest ----------------------------> NOT Ok
Fastest + pure-code -------------> NOT Ok
Fastest with LTO ------------------> Ok
Fastest + pure-code with LTO ---> Ok
Smallest code --------------------> NOT Ok
Smallest code with LTO ----------> Ok

The graphics are pretty basic. 4 filled white rectangles with black borders (sometimes changing to red).
2 soft buttons on the bottom to inc/dec the 4 parameters in the 4 rectangles and 2 soft buttons to move between pages of parameters.
3 pages w/4 parameters per = 12 adjustable parameters.
Here's some pictures of Ok vs NOT Ok.
The 3rd picture just shows that when you touch one of the parameters it's rectangle border changes to red so that you know where the inc/dec focus is.

Ok.jpgNOT Ok.jpgOk wRed.jpg
 
Interesting, but without a minimal set of code that others could use to reproduce and observe the behavior you'll get conjecture or crickets.

Remove any hardware or libraries you can and still see the behavior. If taking out a library not needed for display of the issue allows it to work that would suggest the source of the conflict. Document the hardware in use and show the code used.

Much work has been done with that screen in various cases, simple to complex, maybe not as much with t_3.5 as the 3.2 and 3.6

Did you rework the code to use the i2c_t3 replacement for wire?

As Paul and I noted LTO usually causes trouble,, not relieves it.
 
I guess my question now is:
If I have to use a "with LTO" optimize setting for my code to compile in a useable form does it matter?
Is it going to bite me in the butt down the road somewhere?

btw, I removed Wire and saw no difference.
 
If I have to use a "with LTO" optimize setting for my code to compile in a useable form does it matter?

I would give it a 65% likelihood that your problem is timing in the communications to the display.
When it's "not OK," versus when it's "OK," what does a logic analyzer or scope look like for the communications? Are there clock or timing differences?

Also, reduce the problem to a clear screen with a single rectangle on it, in a single sketch, and see if it reproduces.
 
If this is a problem with the display (ili9341_t3), you might try editing the source of it and lower the MAX SPI speed.
in the library .cpp file you see:
#define SPICLOCK 30000000

Try it with SPICLOCK 8000000

And see if it works...

You might also try it with my version ili9341_t3n (up on github/kurte... requires my SPIN library up there as well). Doubt it would make difference, but...
 
I've never seen a ILI9341 that does not work with high speed !
More likely, the connections are not good. Or too long.

LTO: With my tests (a year or more ago - maybe this has changed?) LTO was slower on teensy - in almost all cases. Dunno why.
 
Status
Not open for further replies.
Back
Top