Exciting news, RE's can now be as heavily optimised as vst and use streaming simd instructions

[Theo.M]

Kvr link:

viewtopic.php

i honestly just about wet myself reading this. So the 2.1 SDK is a huge improvement and I guess in beta means it will be out soon.

disco dsp couldn't port their stuff thus far due to optimisation issues (George has said this himself, I am not just making it up or anything), so hopefully this means we will see discovery pro/corona at some stage now.

Finally!!!.. this will be a complete game changer if the info is correct.. 

Just add some pdc in there too props, and I might just be in heaven. Oh, and a working authoriser.

[Kategra]

I hope that devs update their existing RE with the new optimizations, though I doubt many will actually do it.

IMHO, RE tech is still worse than "old crappy tech" (Ernest trashing AAX, AU, RTAS & VST)

[normen]

SIMD instructions only work with 32bit values and most audio developers use 64bit internally so this will only help for a handful of algorithms (e.g. U-He's offerings). For normal code, the compiler already uses SIMD instructions if the code can be translated to these. I am happy though that the Props found a platform-independent way to add vectoring support so that this bit of RE criticism can be laid to rest.

[Theo.M]

SIMD instructions only work with 32bit values and most audio developers use 64bit internally so this will only help for a handful of algorithms (e.g. U-He's offerings). For normal code, the compiler already uses SIMD instructions if the code can be translated to these. I am happy though that the Props found a platform-independent way to add vectoring support so that this bit of RE criticism can be laid to rest.

Ok thanks for further clarification.. Interesting and just as I suspected that it was probably improved in tandem with U-HE

By the way, do SIMD only work for 32 bit instructions in RE, or do you mean even in vst?

[normen]

Ok thanks for further clarification.. Interesting and just as I suspected that it was probably improved in tandem with U-HE

By the way, do SIMD only work for 32 bit instructions in RE, or do you mean even in vst?

SSE etc. basically just allow you to do computations with tuples containing 4 values at once, so you can use quaternions and vectors and do computations with these directly in one CPU cycle instead of computing the single values in the tuples in 4 (or more) cycles. These tuples have a width of 128bit in the hardware, meaning 32bit for each single value. So yes, this is a general limitation of SSE, MMX, Altivec etc. Back when the G4/G5 came out the eMagic developers have been asked why the new CPUs don't boost their DSP code performance to the levels expected from the marketing hype. Their answer was exactly this, they do computations in 64bit and they don't translate well to these instruction sets.

So this means that a) you need to have your algorithms based on vectors / quaternions or in general tuples and b) you can only process 32bit values for the single numbers in the tuples when you want to use SIMD instructions directly. Anyway, if a modern compiler sees a chance to process your (even non-vectorized) 32bit computations with a SIMD instruction it will take your (normal, non-optimized) code and convert it to SIMD machine code, this is already true for current REs which are compiled by llvm.

Urs from U-He called the 64bit processing "64bit bullshittery" and said he was "proud to say that their offerings process at 32bit" because they use "modern algorithms that don't cause issues at 32bit precision". He's certainly a way better programmer and mathematician than I am so I tend to believe him. Still theres few others that I heard this from and most audio developers still underline the fact that their algorithms work at 64bit precision.

[esselfortium]

Great news! Hopefully this will mean some activity from U-he and friends again.

[avasopht]

Great news! Hopefully this will mean some activity from U-he and friends again.

Well  he had many requests, including access to static data. Adding access to static data has a problem in that it puts limitations on the Rack Extension system as a whole.

So you never know, there may be a bit of a stalemate.

[Theo.M]

Great news! Hopefully this will mean some activity from U-he and friends again.

Well  he had many requests, including access to static data. Adding access to static data has a problem in that it puts limitations on the Rack Extension system as a whole.

So you never know, there may be a bit of a stalemate.

Let's think nice and positive. And whilst we are thinking positive, let's think that awesome  scripted IDT stuff is on it's way too

[joeyluck]

Can we have Satin now? =D

[avasopht]

Let's think nice and positive. And whilst we are thinking positive, let's think that awesome  scripted IDT stuff is on it's way too

Hey you know me. I'm all positive with a hint of caution

There are a deluge of open sourced vectorised algorithms that can benefit from this.

[ScuzzyEye]

Do that many developers really write their DSP routines to use 64-bit math? That's incredibly wasteful, even without Uhe's saying so, all the audio handling code I write has used 32-bit floats, instead of needlessly promoting it to 64-bit.

Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.

For those of you following along. SIMD (Single Instruction, Multiple Data) instructions in modern CPUs allow one instruction to process more than one value. Before this if you wanted to process four 32-bit values, you'd write a loop and run through it four times. So not only was the CPU doing four floating point calculations, but it was also keeping track of where it was in the loop, and fetching the values to be worked on, with each time through the loop. SIMD allows multiple values to be pre-loaded before the calculation starts, reducing the number of times the CPU has to stop to wait for data to load, and does its calculation on them all at the same time. Also because of requirements places on the programmer, when using SIMD instructions the values have to be aligned on special bounders in RAM. Because of this requirement, the CPU can make additional optimizations when doing the fetching that saves a lot of time too. (Non-SIMD instructions can perform better with aligned data, but checks have to be done to make sure it is aligned, because there's no requirement for it to be.)

[Exowildebeest]

Whatever those quaternions, leptons and bosons do, I'll have some of 'm.

[avasopht]

Do that many developers really write their DSP routines to use 64-bit math? That's incredibly wasteful, even without Uhe's saying so, all the audio handling code I write has used 32-bit floats, instead of needlessly promoting it to 64-bit.

Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.

For those of you following along. SIMD (Single Instruction, Multiple Data) instructions in modern CPUs allow one instruction to process more than one value. Before this if you wanted to process four 32-bit values, you'd write a loop and run through it four times. So not only was the CPU doing four floating point calculations, but it was also keeping track of where it was in the loop, and fetching the values to be worked on, with each time through the loop. SIMD allows multiple values to be pre-loaded before the calculation starts, reducing the number of times the CPU has to stop to wait for data to load, and does its calculation on them all at the same time. Also because of requirements places on the programmer, when using SIMD instructions the values have to be aligned on special bounders in RAM. Because of this requirement, the CPU can make additional optimizations when doing the fetching that saves a lot of time too. (Non-SIMD instructions can perform better with aligned data, but checks have to be done to make sure it is aligned, because there's no requirement for it to be.)

Some filter designs are unstable with 32-bit precision. 

[X1Lo]

Anytime UHE Satin is brought up, I can help but to think of this video.  Mostly because the first time I saw Satin I misread it Satan. 
https://www.youtube.com/watch?v=liSseCH6_p8

[ScuzzyEye]

Some filter designs are unstable with 32-bit precision. 

True, if you take code that's using doubles, and just change them to floats, you can break the filter. But it is also possible to make a few other small changes to keep the errors due to the loss of precision from piling up.

[normen]

Some filter designs are unstable with 32-bit precision. 

True, if you take code that's using doubles, and just change them to floats, you can break the filter. But it is also possible to make a few other small changes to keep the errors due to the loss of precision from piling up.

The thing is mainly transients during processing, yeah. While 32bit is way enough in terms of headroom and noise floor, when you do processing (especially physical/analog modeling) the values you get in between might get very small / big and thus start to scratch the resolution boundaries of 32bit.

[SynapseAudio]

Do that many developers really write their DSP routines to use 64-bit math? That's incredibly wasteful, even without Uhe's saying so, all the audio handling code I write has used 32-bit floats, instead of needlessly promoting it to 64-bit.

Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.

For stereo processing SSE2 is very useful, and whenever high numerical precision is required.

Richard

[-008']

I don't understand any of it really, but I do know it means that SDK is making some progress.

I'm with you theo, bring on the big: drums, brass and strings IDT stuff! Thought for sure we'd have some of those by now. :/

[JiggeryPokery]

Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.

I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.

[Theo.M]

Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.

I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.

My apologies i had NO idea, now I feel really bad.

Obviously if i was an RE dev and had known there was a beta and it was breaking NDA to leak this feature, i would never do it myself. My apologies.

[JiggeryPokery]

Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.

I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.

My apologies i had NO idea, now I feel really bad.

Obviously if i was an RE dev and had known there was a beta and it was breaking NDA to leak this feature, i would never do it myself. My apologies.

Comments in this thread have been fairly general, about SSE use and limitations, rather than the RE SDK specifically, unlike another thread I did close today. So I don't feel there has been an NDA violation caused by this thread, as you were just reposting something you had publicly heard from elsewhere.

Really I was just warning other Devs of their obligations not to discuss the SDK in this thread before they did, accidentally or not

If people want to continue to discuss the ins and outs of SIMD instructions on a general level, knock yourselves out. But SDK specifics are most definitely banned and I will wield the hammer 'o bans. RE Devs know where they can discuss SDK stuff freely.

[Kategra]

Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.

I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.

Come on, this is not PUF.
They aren't discussing anything illegal, political, religion or hate speech. If A developer wants to tell everything he wants to tell about RE SDK he shouldn't be censored by Admins, it's PH business to enforce their NDA.


I presume that you admins who signed the NDA are responsible for yourself, not what other dev disclose.
IMHO, this kind of censorship will give bad vibes of the forum, with posts and topics being so slow. You guys should encourage discussions about Reason and all related, not oppose it.

Otherwise, you could drive this forum into a "Discover" forum, and leave the real Reason discussions to other forums like KVR, gearslutz etc.

[motuscott]

 I will wield the hammer 'o bans.

Why do I feel oddly comforted by this after PUF?

[JiggeryPokery]

Come on, this is not PUF.
They aren't discussing anything illegal, political, religion or hate speech. If A developer wants to tell everything he wants to tell about RE SDK he shouldn't be censored by Admins, it's PH business to enforce their NDA.


I presume that you admins who signed the NDA are responsible for yourself, not what other dev disclose.
IMHO, this kind of censorship will give bad vibes of the forum, with posts and topics being so slow. You guys should encourage discussions about Reason and all related, not oppose it.

Otherwise, you could drive this forum into a "Discover" forum, and leave the real Reason discussions to other forums like KVR, gearslutz etc.

If it's being censored how come you've posted a reply!?

I clearly stated in my follow-up response I don't consider this thread to be NDA breaking, it's fair to say my first post you've quoted didn't make that clear, hence the follow-up reply to Theo, who was unnecessarily concerned. I was merely reminding Devs that specific SDK discussion stuff is off-limits per their agreement with PH, as someone else happened to post such a request on a different thread.

So please reread my other response:

"If people want to continue to discuss the ins and outs of SIMD instructions on a general level, knock yourselves out. But SDK specifics are most definitely banned and I will wield the hammer 'o bans. RE Devs know where they can discuss SDK stuff freely."

So I'm not sure which bits of that are unclear, so I'll repeat: this thread was not locked because it is a general coding discussion and so everyone here free to carry on in the same manner, and afaiac the same goes for any other general coding thread, or job requests. But discussion of how to use the SDK is not allowed: we signed an NDA, we need a working relationship with Propellerhead, so I won't allow that, and I'm sure Richard, avasopht and Scuzzy above appreciate that view. There is an official PH forum for developers, that, more importantly, PH staff can offer valuable assistance, that won't be the case here. We're being practical and pragmatic.

No, this is not PUF, but we have to try our best to use a bit more common sense.

[avasopht]

Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.

I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.

Come on, this is not PUF.
They aren't discussing anything illegal, political, religion or hate speech. If A developer wants to tell everything he wants to tell about RE SDK he shouldn't be censored by Admins, it's PH business to enforce their NDA.


I presume that you admins who signed the NDA are responsible for yourself, not what other dev disclose.
IMHO, this kind of censorship will give bad vibes of the forum, with posts and topics being so slow. You guys should encourage discussions about Reason and all related, not oppose it.

Otherwise, you could drive this forum into a "Discover" forum, and leave the real Reason discussions to other forums like KVR, gearslutz etc.

Nothing unreasonable about that rule. Plenty of forums have that.

Some do it so they don't receive a cease and desist, for example, forum.gbadev.org had many licensed developers as active users while at the same time never came into legal issues.

It's a simple policy that any mature developer would have no problem with.