You are here

Yoshimi coding improvement

For all other computers and operating systems, including Atari, Linux and mobile apps.

Moderator: Moderators

Yoshimi coding improvement

Postby Folderol » Sun Jan 10, 2021 11:34 pm

For a quite a long time I’ve been aware our performance with LV2 is not as good as when running stand-alone, but could find no explanation, so more-or-less just accepted it.

More recently with the Raspberry Pi, I had a seemingly unrelated problem in that some CPU specific calls we made were not supported. While looking into that, I started to investigate the whole issue of denormal behaviour. In brief, this is where a gradually reducing floating point number can never actually reach zero, and ends up wasting a lot of CPU time.

It was at this point I noticed the CPU specific anti-denormal code was not called at all for LV2, on the assumption the host would manage it. This might have been true at one point, but with the advent of ARM and other CPU types, they all moved to developing specific correction within their own code instead.

Therefore I decided the best way to resolve both these problems was to do the same. The result is there is a new branch called simply ‘denormal’ for testing this. On test here, I’m finding the performance is very slightly poorer when working stand-alone, but significantly better on LV2. I haven’t checked the Raspberry Pi yet, but I’m again expecting improved performance.

I’m still trying to refine this. I want to make sure the correction is applied as efficiently as possible exactly where it’s needed, but only where it is needed. While researching this, I discovered that some developers just take a blanket approach and put it everywhere.
User avatar
Folderol
Jedi Poster
Posts: 12089
Joined: Sat Nov 15, 2008 1:00 am
Location: The Mudway Towns, UK
Yes. I am that Linux nut.
Onwards and... err... sideways!

Re: Yoshimi coding improvement

Postby Martin Walker » Mon Jan 11, 2021 12:06 am

Well done Will :thumbup:

Denormals have accounted for a host of long-term problems for ahost of developers over the years, from outright crashes to increases in CPU overheads.


Martin
User avatar
Martin Walker
Moderator
Posts: 16964
Joined: Wed Jan 13, 2010 9:44 am
Location: Cornwall, UK

Re: Yoshimi coding improvement

Postby Eddy Deegan » Mon Jan 11, 2021 12:14 am

A good bit of detective work there Will :clap: :thumbup:
User avatar
Eddy Deegan
Moderator
Posts: 5347
Joined: Wed Sep 01, 2004 12:00 am
Location: Brighton & Hove, UK
Some of my works
The SOS Forum Album projects
 

Re: Yoshimi coding improvement

Postby N i g e l » Mon Jan 11, 2021 12:59 am

Folderol wrote: the whole issue of denormal behaviour.

I gotta 400 keyboard for xmas, my 1st thought was about denormals, so Im following this thread to see what happens.

;)
N i g e l
Frequent Poster
Posts: 1300
Joined: Sun Aug 12, 2018 2:40 pm
Location: British Isles

Re: Yoshimi coding improvement

Postby Martin Walker » Mon Jan 11, 2021 8:14 pm

Martin Walker wrote:Well done Will :thumbup:

Denormals have accounted for a host of long-term problems for ahost of developers over the years, from outright crashes to increases in CPU overheads.

And just to reinforce my point, here's yet another developer (Chris from Airwindows) having to deal with 'tricky to track down' denormal problems with Logic users on Catalina:

https://www.kvraudio.com/forum/viewtopi ... 6&t=558730

"If people get crashes during playback before, and that one change fixes it, it establishes that on normal versions of MacOS long double variables use the math library fabs() and correctly return the right number, or zero. And under Catalina, ANY USE of the math library fabs() on a long double can convert it to a double or maybe a float, where it becomes a zero if it's small enough, and then dividing by it crashes Logic or blows up the CPU."


Martin
User avatar
Martin Walker
Moderator
Posts: 16964
Joined: Wed Jan 13, 2010 9:44 am
Location: Cornwall, UK

Re: Yoshimi coding improvement

Postby wireman » Mon Jan 11, 2021 8:20 pm

Folderol wrote: While looking into that, I started to investigate the whole issue of denormal behaviour. In brief, this is where a gradually reducing floating point number can never actually reach zero,

Yes it can.
wireman
Frequent Poster
Posts: 649
Joined: Fri Dec 17, 2004 1:00 am

Re: Yoshimi coding improvement

Postby Folderol » Mon Jan 11, 2021 9:50 pm

Indeed, you have the two extremes - never zero, or zero when it shouldn't be possible. I was simplifying for the specific case of a decaying signal.
A not too contrived example (I made sure it would terminate):

// g++ -Wall nozero.cpp -o nozero

#include <iostream>

int main(void)
{
float num = 1.0f;
int count = 0;
int end = 0x7fff;
while (count < end)
{
num *= 0.7f;
if (count < 50 || (end - count < 10))
std::cout << "size " << num << std::endl;
++ count;
}
return (0);
}

P.S.
Guess what?
I've found a corner case where a term still never reaches zero, unless forced with a panic stop :(
User avatar
Folderol
Jedi Poster
Posts: 12089
Joined: Sat Nov 15, 2008 1:00 am
Location: The Mudway Towns, UK
Yes. I am that Linux nut.
Onwards and... err... sideways!

Re: Yoshimi coding improvement

Postby wireman » Mon Jan 11, 2021 10:21 pm

Interesting.

I wrote a program before my reply to decay from 1.0 multiplying by 0.4 each time.

Output looks like this...

Code: Select all
 1.000000000e+00 3f800000 0 01111111 00000000000000000000000
 4.000000060e-01 3ecccccd 0 01111101 10011001100110011001101
 1.600000113e-01 3e23d70b 0 01111100 01000111101011100001011
 6.400000304e-02 3d83126f 0 01111011 00000110001001001101111
 2.560000122e-02 3cd1b718 0 01111001 10100011011011100011000
 1.024000067e-02 3c27c5ad 0 01111000 01001111100010110101101
 4.096000455e-03 3b8637be 0 01110111 00001100011011110111110
 1.638400252e-03 3ad6bf97 0 01110101 10101101011111110010111
 6.553601124e-04 3a2bcc79 0 01110100 01010111100110001111001
 2.621440508e-04 39897061 0 01110011 00010010111000001100001
 1.048576232e-04 38dbe702 0 01110001 10110111110011100000010
...
 3.831245604e-36 04a2f692 0 00001001 01000101111011010010010
 1.532498206e-36 04025edb 0 00001000 00000100101111011011011
 6.129992912e-37 035097c5 0 00000110 10100001001011111000101
 2.451997210e-37 02a6dfd1 0 00000101 01001101101111111010001
 9.807989511e-38 02057fdb 0 00000100 00001010111111111011011
 3.923195973e-38 0155995f 0 00000010 10101011001100101011111
 1.569278417e-38 00aae119 0 00000001 01010101110000100011001
 0.000000000e+00 00000000 0 00000000 00000000000000000000000


Columns are value, value representation in Hex, value representation in binary in 3 columns, sign,exponent,mantissa for 32-bit IEEE float.

Note that we flush to zero in this sequence at the last value 0.0.

Now if we allow denormals the end of the sequence looks like this...

Code: Select all
 
...
 3.923195973e-38 0155995f 0 00000010 10101011001100101011111
 1.569278417e-38 00aae119 0 00000001 01010101110000100011001
 6.277113668e-39 00445a0a 0 00000000 10001000101101000001010
 2.510845187e-39 001b5737 0 00000000 00110110101011100110111
 1.004338635e-39 000aefb0 0 00000000 00010101110111110110000
 4.017354541e-40 00045fe0 0 00000000 00001000101111111100000
 1.606939014e-40 0001bff3 0 00000000 00000011011111111110011
 6.427756056e-41 0000b32e 0 00000000 00000001011001100101110
 2.571102422e-41 000047ac 0 00000000 00000000100011110101100
 1.028412943e-41 00001cab 0 00000000 00000000001110010101011
 4.114212291e-42 00000b78 0 00000000 00000000000101101111000
 1.645124397e-42 00000496 0 00000000 00000000000010010010110
 6.586102782e-43 000001d6 0 00000000 00000000000000111010110
 2.634441113e-43 000000bc 0 00000000 00000000000000010111100
 1.050973848e-43 0000004b 0 00000000 00000000000000001001011
 4.203895393e-44 0000001e 0 00000000 00000000000000000011110
 1.681558157e-44 0000000c 0 00000000 00000000000000000001100
 7.006492322e-45 00000005 0 00000000 00000000000000000000101
 2.802596929e-45 00000002 0 00000000 00000000000000000000010
 1.401298464e-45 00000001 0 00000000 00000000000000000000001
 0.000000000e+00 00000000 0 00000000 00000000000000000000000


The denormals have an exponent with all zero bits.

Of course an issue with denormals is that we have hardly any bits to represent a number so any calculations are pretty doubtful, I assume that since you decay by 0.7x then the result is being rounded to the same number.
wireman
Frequent Poster
Posts: 649
Joined: Fri Dec 17, 2004 1:00 am

Re: Yoshimi coding improvement

Postby Folderol » Tue Jan 12, 2021 7:29 pm

Hey! Wanna job?
The pay is peanuts, but these aren't just any old type. No, these are virtual peanuts.
The documentation is also rather special too. It's sparse docs.
Oh, and the code style is interesting.
User avatar
Folderol
Jedi Poster
Posts: 12089
Joined: Sat Nov 15, 2008 1:00 am
Location: The Mudway Towns, UK
Yes. I am that Linux nut.
Onwards and... err... sideways!

Re: Yoshimi coding improvement

Postby Martin Walker » Thu Jan 14, 2021 3:43 pm

Hasn't this thread gone quiet? :smirk:


Martin
User avatar
Martin Walker
Moderator
Posts: 16964
Joined: Wed Jan 13, 2010 9:44 am
Location: Cornwall, UK

Re: Yoshimi coding improvement

Postby wireman » Thu Jan 14, 2021 8:29 pm

I feel it is not a topic for a general audience.

And I'm too busy with my day job at the moment to spend much time on hobbies but am intrigued by Arm (Pi) as a platform for music-related projects, I see you can get add on hardware to help (Audio Injector for example).
wireman
Frequent Poster
Posts: 649
Joined: Fri Dec 17, 2004 1:00 am