FloatVectorOperations

Someone else said the same thing, which is bizarre… Are you perhaps using an old MS compiler? The only possible thing I can think of is that the const-ness of the “num” parameter in the cpp file is triggering a compiler bug where it incorrectly differentiates const/non-const parameters. Does it work if you change the cpp like this?

void FloatVectorOperations::clear (float* dest, int num) noexcept {

Someone else said the same thing, which is bizarre… Are you perhaps using an old MS compiler? The only possible thing I can think of is that the const-ness of the “num” parameter in the cpp file is triggering a compiler bug where it incorrectly differentiates const/non-const parameters. Does it work if you change the cpp like this?

void FloatVectorOperations::clear (float* dest, int num) noexcept { [/quote]
I’m using VS2008 (not that gives me any joy–I’m stuck with it because of another tool I have to use). Removing the const didn’t accomplish anything. Could this be related to the fact that a number of the RTAS wrapper files must be declared stdcall instead of cdecl?

I don’t think this problem is specific to VS2008. I’m having the same woes with Visual Studio 2010.

I also ran into a link issue with the call to the static method ‘AudioProcessor::setTypeOfNextNewPlugin’ in juce_PluginUtilities.cpp , turned to be caused by the ‘/Gz’ visual c++ flag that I was using for compiling the rtas wrapper code, and not using this flag for the rest of the code. Adding a JUCE_CALLTYPE in the declaration of setTypeOfNextNewPlugin solved it. Maybe this is the same issue ?

Ah, of course, it’ll be the damned __stdcall nonsense… Should have thought of that before! Thanks, I’ll sort that out asap…

Nice one, jules - that last update has fixed RTAS builds under VS2010. Thanks!

Regarding vDSP on the Mac, take care if you implement vector subtraction i.e., vDSP_vsub
https://developer.apple.com/hardwaredrivers/ve/errata.html

Works as expected on current systems but will break AT RUNTIME (!) on old OSs.

[quote=“martinrobinson”]Regarding vDSP on the Mac, take care if you implement vector subtraction i.e., vDSP_vsub
https://developer.apple.com/hardwaredrivers/ve/errata.html

Works as expected on current systems but will break AT RUNTIME (!) on old OSs.[/quote]

Yikes! Thanks, will avoid that!

I have a question : what is the best/most elegant way to declare a float vector with JUCE, to be sure it has its contents aligned, and to use it with the class FloatVectorOperations ? I have used a few times the aligned_malloc and the __m128 type before, but I imagine there is another way to do that in JUCE, if we want to use this new class, the parameters of the functions being simple float types…

Thanks in advance !

1 Like

Hey guys, lovely stuff, will try this soon as I always wanted such thing…

Quick question: is this cross-platform safe? (intel based computers, of course)

Jules! Great work as always, THANK YOU! 8)

It should be cross-platform seeing that it’s just an instruction set; AMD have supported SSE for some time iirc, and afaik ARM and Itanium support SSE, too.

Edit: Though I wouldn’t count on every manufacturer other than Intel supporting >SSE2!

[quote=“williamk”]Hey guys, lovely stuff, will try this soon as I always wanted such thing…

Quick question: is this cross-platform safe? (intel based computers, of course)

Jules! Great work as always, THANK YOU! 8)[/quote]

Yes, should all be nicely cross-platform!

Guys, how do I create a dynamic allocation that is aligned? Like float *data = new float[199] …

Thanks!

1 Like

I’m messing around with a profiling app trying to get a feel for the potential benefits of these functions, but I’m not sure if I should be setting a flag or something, because in my code, the following . . .

#if JUCE_IOS || JUCE_MAC
        Logger::writeToLog ("Using Apple gear");
#endif
        
#if JUCE_USE_VDSP_FRAMEWORK
        Logger::writeToLog ("vDSP enabled");
#endif

Only reports that I’m using apple equipment, and not vDSP (unless I’m fundamentally misunderstanding something). I’ve also been messing about with posix_memalign, using wacky alignments to see if I get a drop in performance, which I would expect, but do not see. Do I have to do anything special to enable the vector ops?

@Williamk (on POSIX)
posix_memalign( (void**)&heapData, 16, sizeof(float)numel);
…where heapData is a float

JUCE_USE_VDSP_FRAMEWORK is used internally. You can set it yourself if you need to override the default behaviour, but there’s no point in checking it in your own code.

@williamk

If you use any mainstream new or malloc function to allocate a block whose size is a multiple of 8, then you can be pretty damn confident that what you get back will be aligned to at least 8 bytes. Any allocator that didn’t do that would be very unusual.

Jules, if I use AudioSampleBuffer, I´m safe them?

Thanks again!

Best Regards, WilliamK

Safe from what? I think the only danger you’re in is the danger of worrying too much about problems before they happen!

SSE aligned load store required 16 byte alignment AFAIK.
You’re safe on mac not on windows though where you need to use _aligned_malloc and _aligned_free

FloatVectorOperations works on non-aligned blocks too, so he’s “safe” anyway.

William, you need to learn the 3 rules of optimisation! http://c2.com/cgi/wiki?RulesOfOptimization

Can I request a convertFloatToFixed() (_mm_cvtps_epi32) and maybe a floor() function? 

The floor function isn't a requirement since it can be approximated by simply casting to int and back again once I have the float to fixed conversion at hand, but could be nice to see in there :)