Phoenix Edition v3.1 released!

[Coolman]

thank you for your answers. i confirm that the version corrected by @a740g works with both versions of qb64. but i have the impression that the quality is better with version 3.0.0 of qb64. i could be wrong. it would be necessary to check at this level.

[SMcNeill]

thank you for your answers. i confirm that the version corrected by @a740g works with both versions of qb64. but i have the impression that the quality is better with version 3.0.0 of qb64. i could be wrong. it would be necessary to check at this level.

Kindly check and point out any sample code which you have that performs worse under the newest version.  From all my testing, sound and images both are much faster than before (particularly in the case where I was loading mp3 files about 100x faster in the new version).  If there's some case where the old is better than the new, we'd love to see it so we can see what's going on and if we can improve the performance any.

[Kernelpanic]

Good job again! Nullo problemo!

The bit rotations are similar to the shift operators, where is the concrete difference?

Code: (Select All)

'Uebung mit Bitrotation - 5. Sept. 2022
'Aehnelt den Schiebeoperatoren

Dim As Long a, b

Print
Input "a: ", a
Input "b: ", b

'Verschiebt 1 Bit nach rechts. Entspricht: Zahl / 2
a = _RoR(a, 1)
Print
Print a

'Verschiebt nach links. Entspricht: Zahl * 2
b = _RoL(b, 1)
Print
Print b

'Vierfach des letzten Wertes (b X 4)
b = _RoL(b, 2)
Print
Print b

End

[bert22306]

Installed v3.1.0 in the wee hours last night. In my three speed test programs, if anything, I see a very slight increase in speed in the number crunching test. The others are unchanged, as far as I can tell. Looks good!

[SMcNeill]

Good job again! Nullo problemo!

The bit rotations are similar to the shift operators, where is the concrete difference?

Rotate vs Shift (qb64phoenix.com) -- See if this helps explain the difference. 

[Stuart]

I hope that this slow down can be fixed somehow because the program I have uses very short sounds for sound events, but if it ends up costing me 5% of speed loss then the sounds will have to go and not even be available as an option...

Would you be able to give examples of the code that you find to be slower? I'm mostly interested in things like what you do with the sound handles and such. If we can pinpoint what exactly is slower then we could look at making some optimizations to those areas.

There are only 3 sound handles used, and they are all defined once, near the beginning of the program : 

  _DELAY .001: s1& = _SNDOPEN("HIGH.WAV")
  _DELAY .001: s2& = _SNDOPEN("LOW.WAV")
  _DELAY .001: s3& = _SNDOPEN("BAD.WAV")


Throughout the program sounds are called with a command like the following : 

  Hz = 900: GOSUB 5555


The only other place that the older "SOUND" command or the sound handles are used is in the sound subroutine : 

    REM -- (SUBROUTINE) -- Play a sound.
5555 IF snd AND D! > 0 THEN
5556    IF QB64 THEN
          IF Hz = 1000 THEN
              _DELAY .001: IF s1& THEN _SNDPLAY s1&: RETURN

          ELSEIF Hz = 900 THEN
              _DELAY .001: IF s2& THEN _SNDPLAY s2&: RETURN

          ELSEIF Hz = 500 THEN
              _DELAY .001: IF s3& THEN _SNDPLAY s3&: RETURN

          END IF
        END IF
        SOUND Hz, D! + .4 * -(D! = 0)
    END IF
    RETURN


NOTE :  This is an "old style", single module .BAS file which will work in QB64 or QB4.5; that's why the "_DELAY .001" commands are present -- QB4.5 will automatically remove the entire line, and the delays don't really affect QB64 at all.

MORE :  There are NO "_DELAY" commands in any critical program loops -- specifically the MAIN LOOP where all of the math calculations and string comparisons are done.



The rest of the program is rather long -- currently about 90.6 KB in total, and I plan to upload it as soon as I finish adding/changing some REM lines, etc.



Now, with all that being said : 

I could be wrong, but I'm starting to think that the main problem causing the speed reduction is when the program gets to a certain length in size : 

The info below is what I get when compiling with the _older_, v0.8.2 : 

When I compile using -Os the size is 2165 KB -- the run time is  9.8 seconds.
When I compile using -02 the size is 2311 KB -- the run time is 11.1 seconds.


According to the compiler options I found here : 
https://gcc.gnu.org/onlinedocs/gcc/Optim...tions.html

It eventually says this : 

Optimize for size. -Os enables all -O2 optimizations except those that often increase code size:

-falign-functions  -falign-jumps
-falign-labels  -falign-loops
-fprefetch-loop-arrays  -freorder-blocks-algorithm=stc

It also enables -finline-functions, causes the compiler to tune for code size rather than execution speed, and performs further optimizations designed to reduce code size.

---

So, since the older v0.8.2 _also_ runs a little slower when the code size increases, I'm assuming that v3.1.0 is slower simply because of the extra code used to add the new audio backend (which I do like better -- mainly because of the less restrictive license agreement).  It also seems to work just as good, and it does support more file types.

Anyway, I hope that some sort of optimization(s) will still be possible so that just having sounds available won't cause too much of a decrease in program speed.


Thanks for your response @DSMan195276 and in advance for checking into it.

[SMcNeill]

@Stuart It appears as if the culprit to your code being slower is because of the SOUND command -- and it seems as if the reason why it runs faster is because it's glitched in the old OpenAL backend!

Try this code for example:

Code: (Select All)

t# = Timer + 3
Do
    Sound 1000, 1
    Print ".";
    count = count + 1
Loop While Timer < t#

Print count; "runs in 3 seconds"

Now here we're just printing a few dots onto the screen, while playing a sound.  Our call to sound has it playing a C6 note for about 1/18th of a second.  (SOUND's parameters are frequency, duration, and the duration is counted in 1/18th of seconds.)  The result we would expect to see her should be 18 * 3 = 54 runs in 3 seconds.

On my PC, I'm seeing around 60 runs in 3 seconds with the new audio backend.  We're actually running a little faster than we should, but it's not that much faster.

As for the old backend?  This is running for 72,000+ times in 3 seconds, and our tone continues to play long after the program ends!  It's definitely tossing out these sounds -- which should be a program pause in execution -- at an insane rate!!

The old audio backend is glitched rather badly, and it's just something which nobody ever noticed before.  (Much like the issue with Ken's dancing line program -- all we ever got was mono-speaker sound, which worked for his program, and it wasn't until the new backend started producing stereo sound that the glitches in his code became apparent.)

The old version was indeed faster -- but it was insanely faster and broken.  The new one fixes the issue the old one had, and that's where you're seeing the slowdown in your code from.

[SMcNeill]

IF snd AND D! > 0 THEN
        SOUND Hz, D! + .4 * -(D! = 0)

 You may want to rework your duration for your SOUND statement.  D is greater than 0, so D can never BE zero in your formula, making the D = 0 FALSE

SOUND Hz, D + .4 * -(D = 0)
SOUND Hz, D + .4 * -0
SOUND Hz, D

I don't know what D is in your program, but you may want to tweak it for the new backend where our timing is much closer to what's expected.  Maybe try SOUND Hz, D / 10

[Stuart]

@Stuart It appears as if the culprit to your code being slower is because of the SOUND command -- and it seems as if the reason why it runs faster is because it's glitched in the old OpenAL backend!

Try this code for example:

Code: (Select All)

t# = Timer + 3
Do
    Sound 1000, 1
    Print ".";
    count = count + 1
Loop While Timer < t#

Print count; "runs in 3 seconds"

Now here we're just printing a few dots onto the screen, while playing a sound.  Our call to sound has it playing a C6 note for about 1/18th of a second.  (SOUND's parameters are frequency, duration, and the duration is counted in 1/18th of seconds.)  The result we would expect to see her should be 18 * 3 = 54 runs in 3 seconds.

On my PC, I'm seeing around 60 runs in 3 seconds with the new audio backend.  We're actually running a little faster than we should, but it's not that much faster.

As for the old backend?  This is running for 72,000+ times in 3 seconds, and our tone continues to play long after the program ends!  It's definitely tossing out these sounds -- which should be a program pause in execution -- at an insane rate!!

The old audio backend is glitched rather badly, and it's just something which nobody ever noticed before.  (Much like the issue with Ken's dancing line program -- all we ever got was mono-speaker sound, which worked for his program, and it wasn't until the new backend started producing stereo sound that the glitches in his code became apparent.)

The old version was indeed faster -- but it was insanely faster and broken.  The new one fixes the issue the old one had, and that's where you're seeing the slowdown in your code from.

Thanks for the detailed explanation and the example code.


when I ran your example using v3.1.0, I got these results : 

With the old audio backend it runs about 7,200 times in 3 seconds.
-->  (Not surprised it's 10x slower than your computer since I'm on Windows Vista SP2)
With the new audio backend it runs about    59 times in 3 seconds.


When I ran your example using QB4.5, I got these results :

55 to 56 times in 3 seconds.



Thanks again @SMcNeill for the detailed explanation and example code.

[Stuart]

IF snd AND D! > 0 THEN
        SOUND Hz, D! + .4 * -(D! = 0)

 You may want to rework your duration for your SOUND statement.  D is greater than 0, so D can never BE zero in your formula, making the D = 0 FALSE

SOUND Hz, D + .4 * -(D = 0)
SOUND Hz, D + .4 * -0
SOUND Hz, D

I don't know what D is in your program, but you may want to tweak it for the new backend where our timing is much closer to what's expected.  Maybe try SOUND Hz, D / 10

Okay, D! is used to denote the duration of the sound.

Although the help files for QB64 _and_ QB4.5 say that "DURATION" should be an INTEGER value, I've found that it also seems to work properly with a duration as small as .1 for QB64 and .4 for QB4.5 and the sounds do seem to be shorter than with a duration of 1.

Now, D! will be equal to zero when sound events are turned off, so in order to make a sound when the sound events are turned back on I added the " + .4 * -(D! = 0) ", and I also enter the subroutine at 5556 instead of 5555 when turning sound events on or off in order to avoid the test for D! > 0.

As far as the "DURATION" value goes, I plan to recheck everything in QB64 and QB4.5 and make any adjustments needed for the best results.

QB4.5 always uses the "SOUND" command; QB64 uses the "SOUND" command _only_ if the .wav files aren't present when the program is compiled.


Thanks again @SMcNeill for all your help and advice.