• SoftwareC/C++

  • Using functions from <cmath> take much longer to compile.

Hi, in my current project, I have been experimenting using <cmath> funtions and <math_neon.h> functions. Since I am running this code at initialization, I would like to use the higher precision functions from <cmath>. However, when using them, my project takes a very long time to compile (about a minute or so). Specifically, I am using sinf(). When using sinf_neon(), the compile time reverts back to normal, and I only have to wait a few seconds or so before my project begins to run.

If you need any further information from me about this, I am more than willing to provide anything necessary.

I expect different compile times when you have

#include <cmath>

versus when you don't have it, but once it is in place it should not take longer to compile regardless of whether you use sinf or you don't.

Still, in my experience having cmath does not make a huge difference in compile time. A simple render.cpp file with #include <cmath> takes less than 3 seconds to compile for me.

I have both

#include <cmath>
#include<math_neon.h>

in a separate class file. They are not included directly in my render file, as I only need them in my class functions. The class is then included in render.cpp.

I should have phrased it differently. It builds and "runs" in the same amount of time, but my audio does not begin to play until about a minute or two after the console says "project running". Actually, in my most recent experiment using the <cmath> functions, it took about 3 minutes before I started hearing anything from my project. When using sinf_neon(), there is no time delay between "project running" and my project actually running. I am changing nothing in my code between experiments except for which sin function I am choosing to run.

It's not a negligible difference. It's a huge, noticeable difference that is very annoying. Also, clicking the stop button in the IDE does nothing until the the project actually begins (I can hear my audio), so I have to wait until it runs to make changes.

I see. Shared libraries (like libmath) are a bit slower to load than statically linked ones (like libmath-neon), yet a "few minutes" sounds way too long.

In the case of this SO question they experience a noticeable longer startup time for the dynamic library, but that is a 180MHz CPU, whereas the one on Bela is much faster. Maybe your program is particularly complex and you are already using plenty if I/O and CPU for something else at startup, so that the small dynamic loader overhead translates in longer waits?
I never noticed any significantly longer boot time on Bela.

You could try to pass some options to the linker to use a static version of libmath, e.g.: set LDFLAGS=/usr/lib/arm-linux-gnueabihf/libm.a in Project settings -> Make parameters

Passing that flag did nothing noticeable. All I need to do is copy and past into that make parameters text box, correct? Didn't seem like hitting enter did anything.

As far as what I'm doing in initialization, I'm just generating wavetable oscillators, and filling them with float values. In my current project, it's 4 objects, each with 11 float arrays of size 4096. I'm generating the tables based off harmonics per octave, which is where my my use of the sin function comes into play. The fact that it works in a few seconds with sinf_neon and a few minutes with sinf is extremely strange, and its leading me to believe that I have done something stupid, but cannot figure out the issue. My project is not very complex (yet), so I'm not really sure where the mistake is happening.

After doing some testing, I see that the problem is within the object initialization. If I create one object, it takes less time. If I create 4 objects, it takes much more time (as expected). This time difference in unnoticeable using neon, but multiplied while using cmath.

I apologize for my lack of testing before posting...

It seems to be narrowed down to one member function that uses sinf(), and not every function that calls sinf() in my class. I narrowed it down to a single member function that calls sinf() that's causing the problem. If I change it to sinf_neon(), and leave the rest of my member functions using sinf(), it compiles and runs as normal.

I'm going to look at it a bit more, but I still find it extremely strange as to how long the difference is between the usage of the two functions.