Poll: what OS do most people use for music production?

[Mayae]

Okay, well then disregard what I said before and just use your preferred settings AVX probably crashes because your CPU doesn't have it (over 4 years old?)

SSE and its relatives are the only supported platform on x64, and on processors today, doubles and floats generally run at the same speed (except for bandwidth, of course). The only speedup to be gained from floats is through SIMD which doesn't really happen unless you handcode it or the compile can easily vectorize your code - which rarely is the case for DSP code, often being serial and based on feedback.

[Ivan_C]

Wow, I didn't know it is possible to get such strange behaviour from fp:fast ! I haven't seen anything like that happening to me yet.

So, I have been looking for information about fp:fast, and I have found this article : http://blogs.msdn.com/b/vcblog/archive/ ... ecise.aspx

[Taron]

Ufff, it will take some heavy pondering to really take advantage of SIMD in audio code...running the danger of contriving situations, haha. I suppose if samples were involved, it might make more sense, but I don't have that at all, except for a tiny bit of post processing of the buffer...
But I have to do that heavy pondering before saying too much.
As for the doubles vs. floats, it's the bandwidth that I'm worried about, too. Again, I wonder, if processor cache could already matter for code such as mine. I've got one big loop for 3 curve envelopes running 2 oscillators and 1 noise through a formant filter, a phaser, a resonance filter and a saturator. Then I have 2 more small loops as experiments on post highpass, lowpass and limiter and a pretty tap delay, but those I'm not worried about.

The fp:fast article is interesting, but it feels a bit flimsy. I guess, that's just the thing...it's not clear.

[psmacmur]

Re SIMD... not that I actually know what I'm talking about, but your notion that refactoring your loops might help is corroborated in this Intel Compiler guide

You'll presumably also need to cache-optimize your data... which is where by 0% knowledge of DSP become apparent: maybe you don't have data. Maybe low-CPU plugins process samples in batches just to feed the SIMD units. All I really know is that, during the Hive OSC, only some of the code paths were vectorized (e.g. supersaw). The then-unvectorized code (ironically, simpler OSC waveforms, I believe) consumed noticeably more CPU. Hive is based on mipmaps or something though, quite unlike your synth, if I understand correctly, Taron.

[Taron]

Yup, you understood correctly. I'm using code to generate waveforms, not data.
However, I looked into processor cache on my cpus and found that it has 24Mb...ah...so, hm...but I wonder, if there's another layer of cache even closer to the operations, yet, a lot smaller... I'll look into that guide for sure!

Thanks!