Announcing QB64 Phoenix Edition v0.8.0 Release!

[DSMan195276]

QB64 Phoenix Edition v0.8.0!

New Features
  - A new 'C++ Compiler Settings' dialog, under the 'Options' menu. It allows setting:
    - Compiling program with C++ optimizations using `-O2` (off by default).
    - Strip symbols from executable (on by default)
    - Add C++ debug information to executable (off by default)
    - Textbox for supplying extra compiler flags
    - Textbox for supplying extra linker flags
    - Entry to modify the maximum number of C++ compiler processes to run (setting this higher can speed up compilation).

Bug fixes
  - Many improvements to the rendering of the Wiki in the QB64 IDE.
  - Improved dialog text around missing `curl.exe`
  - The IDE will not attempt to keep downloading help pages if `curl.exe` is missing.

Full Changelog: https://github.com/QB64-Phoenix-Edition/...1...v0.8.0

[bplus]

Nice! I tried a -O3 compile and got a much faster time for processing 1,000,000 integers to find 78498 primes and check 104743 is prime. .03+ secs down from .046 secs. It might have been already faster at .042 secs before compile flag change at new? default -O2.

Thumbs up for this, @DSMan195276 are you going by different avatar name or were you at .org?

So finally got the debug stuff to quit bugging me when I click too close to left border going from v2.0 to .8 which I labeled _8 in folder. Next move a bunch of files in, rewrite the shortcut key and reset the default exe to handle .bas files.

[DSMan195276]

>  It might have been already faster at .042 secs before compile flag change at new? default -O2.

To clarify on this change, the default was and is still no optimization. If you check the box in the new dialog you'll use `-O2`, or you can just write `-O3` into the compiler flags dialog to use that instead.

> Thumbs up for this, @DSMan195276 are you going by different avatar name or were you at .org?

This is the same username I've kept, but I was around more in the .net days, I'm not sure I ever registered on the .org site. On Discord I'm 'offbyone', and on GitHub I'm just 'mkilgore'.

[JRace]

Sweet!
I''ve been tinkering with the flags on Yet Another Sieve Program.  Using -Os I'm seeing a smaller EXE (1.72M using -Os vs 2.01M unoptimized), AND a roughly 25% speed increase.

Question: Looks like the IDE Colors and C++ Compiler Settings menu options both use "o" as the shortcut key.  Is this supposed to be, because when I type "<ALT>o o" I get the colors dialog?

[DSMan195276]

I''ve been tinkering with the flags on Yet Another Sieve Program.  Using -Os I'm seeing a smaller EXE (1.72M using -Os vs 2.01M unoptimized), AND a roughly 25% speed increase.

Yep, even with regular `-O2` the program should be smaller.

Question: Looks like the IDE Colors and C++ Compiler Settings menu options both use "o" as the shortcut key.  Is this supposed to be, because when I type "<ALT>o o" I get the colors dialog?

Nope, that was an oversight Easy enough to fix though.

[Coolman]

i compiled qb64.bas with the optimized version O3. i moved the executable to the root of version 0.8.0. the strip function works, the size of the generated executables is smaller (i used the linux strip -s executable name command to do the same thing). same for the optimization flag, it was an essential and expected function, I put O3 and tested it quickly. the generated programs are faster. the qb64 source code is a real mess. cleaning it up and structuring it better is a risk to break something. thanks for your efforts. you did a great job @DSMan195276.

[James D Jarvis]

Well darn the executable files produced with the optimization flags are indeed smaller. I had one program coming out with a 2.78 MB exe now coming out at 2.3. It may indeed run quicker too but I didn't run any real diagnostics to check but I can't help but feel like it compiles a little bit slower. Is that due to using the optimization flag? (I know that sounds like a ridiculous question but just wondering if that's consistent with other folk's expectations and experiences).

[DSMan195276]

Yes, you should expect longer compilation times when enabling optimization. For larger QB64 programs this can be quite a bit longer. It is possible to improve the compilation times but I wouldn't expect that any time soon since it would require some fairly fundamental changes to how QB64 generates the C++ program.

[James D Jarvis]

I know that sounded silly I just don't recall actually noticing it when compiling in C/C++ unless the program was a monster. Of course, everything was insanely slower when I programmed in C/CC++ (amazing what a difference 15 years makes).

[bert22306]

Yes, you should expect longer compilation times when enabling optimization. For larger QB64 programs this can be quite a bit longer. It is possible to improve the compilation times but I wouldn't expect that any time soon since it would require some fairly fundamental changes to how QB64 generates the C++ program.

Cool, that explains it. I tried the optimization enabled, and it made a significant difference in number crunching speed. Compilation times are extended somewhat, but depend on how long the program is. In shorter programs, I don't notice much difference. Maybe those with gymongous programs will notice more.

I have a number crunching test I wrote, which spits out prime numbers, starting with 3. It does so in groups of five trials each, 3 to 100,003, 3 to 150,001, 3 to 200,003, 3 to 300,007, and 3 to 400,009.

For the speed test, of course, it doesn't display all the primes, only displays the last one.

Oddly, with version 0.8.0, without optimization, it seemed slightly slower than version 0.7.0. In my PC, to reach 400,009 took about 0.87 to 0.93 seconds at most, with version 0.7.0. But with version 0.8.0 without optimization, a couple of times it took just over 1.0 sec.

With optimization enabled, instead, we're down to a range of 0.61 to 0.66 seconds, shortest to longest time required of the five trials, to reach 400,009. A real improvement.

Roughly what has happened is, each of those groups of results, with optimization enabled, show about the same time required as the shorter group of tests did before. So, the time it takes to reach 400,009 is about the same as it required previously to reach 300,007. Similarly, the times required to reach 200,003 are about the same as it took previously to reach 150,001. Slick! Thanks!

(Parenthetically, a BIOS update maybe 2 years ago improved this particular test quite a bit too. In my own 6th gen Intel Core i7, performance went down when they did the first BIOS change to mitigate the specter/meltdown threat. But then they more than compensated for that performance loss with a BIOS update some time ago, maybe at most 2 years ago. Saying this for those guys who refuse to update their BIOS!)