How to get the most speed out your program?

[TerryRitchie]

yeah and do that before you start running up recent files ;-))

Update: yep, just lost the couple of Recent files I had accumulated when I checked that box and unchecked the 2nd.

AGAIN WARNING!!!

I just checked and unchecked this option a few few times, compiling some code with the setting enabled and disabled. My recent file list is still intact and untouched. I wonder why yours was affected?

[bplus]

Guess we all have our own private little rain clouds...

you know you have to restart qb64pe to see the missing recent files?

BTW just tested again because checking first box and all other off plus 3 at bottom really S L O W S the compile time down for me and lost the one recent file I had stored in there: Daves Not Here, yeah its not there anymore either. Daves not... was taking like 30 secs to compile, too slow for me.

Plus the first time yesterday, i didn't even change anything, I just looked in Compile Options and got a snapshot of the default compile options.

Just another life mystery.

[Gets]

It's been happening to me forever and I had no idea why until I saw this topic, but changing the compiler settings did clear my recent file list too.

[TerryRitchie]

It's been happening to me forever and I had no idea why until I saw this topic, but changing the compiler settings did clear my recent file list too.

Well this is odd, not happening to me ?? Could it be the OS version? I program on a Windows 7 Pro 64bit machine.

[Stuart]

@bplus
@Gets
I have changed the compiler settings many times (just experimenting with program execution speed) and I haven't ever noticed the "recent files list" being erased like you described earlier; but, I have noticed that whenever the compiler options are changed the user is informed that the loaded file has been changed (even when no file is loaded).

The compiler settings are actually saved (somewhere) as soon as the <OK> button is clicked on in the compiler settings window so there's really no need to display an asterisk beside the filename and prompt to resave it before closing the IDE.


@justsomeguy
@Pete
and anyone else that might be interested --
In addition to the optimizations already suggested by a740g which are :

1) Compile program with C++ optimization flag.
2) Strip C++ symbols from executable.

--->>
You might want to give this a try and see how it works for you :

First, make sure that all 3 of the options at the top are _NOT_ checked.
Next, enter this in the C++ Compiler Flags box :

-O3 -s -mtune=native
---or---
-O3 -s -DNDEBUG -mtune=native -- This makes the executable a little smaller by removing more DEBUG info.
(Either of the options above currently work best for me.)


-O3 -s -mcpu=native -march=native -mtune=native
(This could also be used, but read more about why I avoid using -march= below...)



Note : When the top 2 options are selected it's basically the same as :
-O2 -s
being entered into the C++ Compiler Flags box.

Also, please note that all of the examples above use a CAPITAL "O" followed by a number or a lowercase letter.
When I was using an older Windows Vista computer -Os would work better than -O2 but now that I'm using a newer Windows 11 computer, -O3 works better than -O2 or -Os.
-----------------------------


Even more info for further reading :

This info (and more) is from :
https://maskray.me/blog/2022-08-28-march-mcpu-mtune

-march=, -mcpu=, and -mtune=
In GCC and Clang, there are three major options specifying the architecture and microarchitecture the generated code can run on. The general semantics are described below, but each target machine may assign different semantics.

-march=X: (execution domain) Generate code that can use instructions available in the architecture X
-mtune=X: (optimization domain) Optimize for the microarchitecture X, but does not change the ABI or make assumptions about available instructions
-mcpu=X: Specify both -march= and -mtune= but can be overridden by the two options. The supported values are generally the same as -mtune=. The architecture name is inferred from X
-----------------------------------------

This ( and more) is from :
https://stackoverflow.com/questions/1055...from-mtune

If you use -march then GCC will be free to generate instructions that work on the specified CPU, but (typically) not on earlier CPUs in the architecture family.

If you just use -mtune, then the compiler will generate code that works on any of them, but will favour instruction sequences that run fastest on the specific CPU you indicated. e.g. setting loop-unrolling heuristics appropriately for that CPU.

-march=foo implies -mtune=foo unless you also specify a different -mtune. This is one reason why using -march is better than just enabling options like -mavx without doing anything about tuning.

Caveat: -march=native on a CPU that GCC doesn't specifically recognize will still enable new instruction sets that GCC can detect, but will leave -mtune=generic. Use a new enough GCC that knows about your CPU if you want it to make good code.
------------------------------------------------------------------------------------------------------

This (and more) is from :
https://stackoverflow.com/questions/4449...ually-work


There's this related question: GCC: how is march different from mtune?

However, the existing answers don't go much further than the GCC manual itself. At most, we get:

If you use -mtune, then the compiler will generate code that works on any of them, but will favour instruction sequences that run fastest on the specific CPU you indicated.

and

The -mtune=Y option tunes the generated code to run faster on Y than on other CPUs it might run on.
---------------------------------------------------------------------------------------------------

[bplus]

+ thanks for the additional info for compiling

@RhoSigma Is there anything in our Wiki on this?

[RhoSigma]

In short, this compiler options stuff affects the C/C++ side of things. It's not what changes your QB64 code to be translated differently into C/C++, but only how that translated code is compiled into the final EXE. From that POV I don't think it's something for the Wiki, but rather a dedicated forum thread like this or maybe a new tutorial somebody might write about it.

As for the disappearance of the recent files list (and probably the search history too), that is true for the current public releases of QB64PE. When you change C/C++ Compiler settings, then internal/temp is purged and needs to be rebuild using the new settings.

That's btw the reason why your code is marked as "changed", because it's the only way to force that re-build, the IDE must think "Oh change, let's recompile", otherwise you could just change the settings then press F5 and the IDE would answer you "Already compiled that EXE", it simply wouldn't know you wanna recompile with that changed settings. Remember pre-v3.12.0, before we had automatic "external dependency" checks, when you edited an include file in a 2nd IDE instance and after save and return to the 1st instance you had to do a fake change (insert/remove a space/line etc.) there, because the 1st instance didn't knew about the change you made and refused to recompile it without that fake change? Same with the compiler settings, just those are so to say an "internal dependency" we can trigger by simply setting the "change state".

Now back to the recent list, the purge of internal/temp for whatever reason also killed the recent.bin file there and that's it. However, a couple days ago I've changed the handling of the recent file and search history to use internal buffers and only save that buffers when exiting the IDE, hence whatever happens to these files in internal/temp when changing settings, recompiling etc., it doesn't affect the internal buffers and at exit the disk based files are always cleanly restored with the current buffer contents. So the problem of disappearing recent/search histories is solved with the next release of QB64PE.

[bplus]

Thanks for update and learning recent files is fixed for future versions @RhoSigma

[Pete]

I have changed the compiler settings many times (just experimenting with program execution speed) and I haven't ever noticed the "recent files list" being erased like you described earlier; but, I have noticed that whenever the compiler options are changed the user is informed that the loaded file has been changed (even when no file is loaded).

The compiler settings are actually saved (somewhere) as soon as the <OK> button is clicked on in the compiler settings window so there's really no need to display an asterisk beside the filename and prompt to resave it before closing the IDE...

>You might want to give this a try and see how it works for you : 

Note :  When the top 2 options are selected it's basically the same as : 
-O2 -s

...

As a former chem major, what the hell does removing ozone (O2) and sulfur (S) from the compiler have to do with speed issues? Wait, I could see Steve using the -S switch so his programs wouldn't stink so much, but removing O2 would deplete the overall effectiveness of that outcome.

This is cool old school stuff. Takes me back to the QuickBASIC switches. 

+2 to you for taking the time to post!

Pete

- Bill Gates stores all his great ideas on the Sulfur Cloud, H2S

[SpriggsySpriggs]

I get the most speed out of my programs by simply running them on hardware that is insane. I care not for optimizations.