Error with `-vec` Option

[ryukau]

Compiling DigiFaustMidi.dsp with -vec option outputs following error.

$ faust2jaqt -t 0 -time -vec DigiFaustMidi.dsp

# ...

    end prepare2 (duration : 0.0004251)
ERROR : 'control/enable' can only be used in scalar mode

When targeting DigiDrie.dsp, compilation stuck at end prepare. I waited around 30 minutes, and it didn't progress.

$ faust2jaqt -t 0 -time -vec DigiDrie.dsp

# ...

    end prepare (duration : 5.96513) # Stuck at here.

-vec option is likely crucial to speed up on x86 platforms. Is it possible to change the code not to use control?

Also there was a discussion that control will be removed in future.

• Faust : signal processing language / Thread: [Faudiostream-users] demand-rate in faust?

[magnetophon]

I have the same problem with DigiDrie.dsp and -vec. I hadn't tried out 'DigiFaustMidi.dspwith-vecyet, so I hadn't run into thecontrol` issue.

To remove control, just toggle these lines.

You can then compile with: faust2jack -t 0 -time -midi -nvoices 1 -vec DigiFaustMidi.dsp && ./DigiFaustMidi.

The resulting binary still takes 45% CPU on my HW. If I compile the same thing without -vec, it takes about 52% time faust2jack -t 0 -time -midi -nvoices 1 -vec -dfs DigiFaustMidi.dsp && ./DigiFaustMidi takes 45% as well.

I'm currently checking out other compile options that are now possible, since we have -vec working, like -omp and -sch.

[ryukau]

Thanks for the workaround! I'll try it.

For benchmark, I added a small document about faustbench. If you take benchmarks, feel free to add result to it.

Also, here is the faust options faustbench is using.

[magnetophon]

Thanks for making those!

If you take benchmarks, feel free to add result to it.

I'll wait for you to add some examples. I'm not sure what a sensible way to do it would be. I guess we need a table with:

• source commit hash
• compile options
• result

The result of component level benchmark may not be reliable, because C++ compiler optimization may work differently on merged code. Still, it's better than nothing.

In my experience, testing parts of faust code does not tell us too much about the total. Not sure what the solution is though.

[magnetophon]

-omp uses 42% CPU.

So far all the options have used about the same amount of CPU, (reported by htop) as they use DSP (reported by qjackctl).

-sch uses 38% DSP, but 160% CPU!!!

So a quick test makes it look like we can win some CPU with compiler options, but not that much. I'm still hoping for -fm def to help a lot, but that doesn't compile for me. Sletz mentioned on slack that: Then I guess https://raw.githubusercontent.com/grame-cncm/faust/master-dev/architecture/faust/dsp/fastmath.cpp line 37 does not work with GCC? You may have to tweak it a bit to make it work?

But I have no idea how to do that. Maybe you can help?

[ryukau]

I'm currently running faustbench on DigiFaustMidi.dsp. I'll update the markdown when I get result.

DigiDrie.dsp still stucks on my environment with -vec. Faust version is 2.28.0 here. Probably this one is not related to control primitive.

In my experience, testing parts of faust code does not tell us too much about the total. Not sure what the solution is though.

That's true. I'd like to have function call count. It would be nice if there's Callgrind equivalent for Faust. I tried interp-tracer -output -trace 5, but it doesn't look like correcting function calls on Faust code. dynamic-* may outputs function call info, but I couldn't get them working.

---

52% to 38-42% is very good I would say. Did you try -vs optioin?

I can't help much on -fm issue. I haven't used __attribute__. The problem is on this line:

#define EXPORT __attribute__ ((visibility("default"))) __attribute__((always_inline))

Dirtiest solution might be just remove __attribute__((always_inline)) and rebuild Faust.

[magnetophon]

The latest commit, when compiled with faust2jack -t 0 -time -midi -nvoices 1 DigiFaustMidi.dsp, uses just 20-25% cpu.

I used the control primitive in a few places so the synth can not be compiled with any of the options that need -vec, only scalar mode.

It uses 20% without the filters running, and 25% with all 3 mixed in. Let me know if you can get it to use more with another setting, I think I tried everything.

The no_control branch uses 35%.

I know that control is not really supported, and might be dropped, but this might be worth it, especially because you said:

A tendency I found is that approximated versions are slightly faster in -scal case. If we decide to use -scal only, these approximation might be used.

What do you think, to control or not to control? :wink:

[ryukau]

One of the reason I started writing audio programs is that the support was terminated for one of the synth I extensively used. It broke many of my project files, and I didn't like it. This is also the reason I use GPL for my plugins. I might be able to fix the problem if that synth was open sourced.

Because of this, I care about long term support. And in this sense, I disagree to use the functionality that is announced to dropped.

That said, I think it's OK to keep control for now. But I'm against adding more. The discussion I linked indicates that Faust will likely provides a replacement of control. So in worst case, we just fix the 2 lines that uses control (1, 2).

[magnetophon]

Because of this, I care about long term support.

Agreed, I exclusively use open software because of this reason.

So in worst case, we just fix the 2 lines that uses control (1, 2).

That's what I thought as well.

I think this issue is done then, agreed?

[ryukau]

Yes, this is done.

I think keep opening this issues is better, with wontfix label. On web browser, GitHub issue search bar has default options is:issue is:open. So it makes easier to find, if someone faces the same issue.

What do you think?

[magnetophon]

Done.