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

This forum is for discussing Rack Extensions. Devs are all welcome to show off their goods.
User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

21 Jan 2015

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.


User avatar
Kategra
Posts: 327
Joined: 18 Jan 2015

21 Jan 2015

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)

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Jan 2015

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.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

21 Jan 2015

normen wrote: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?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Jan 2015

Theo.M wrote: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.

User avatar
esselfortium
Posts: 1456
Joined: 15 Jan 2015
Contact:

21 Jan 2015

Great news! Hopefully this will mean some activity from U-he and friends again.
Sarah Mancuso
My music: Future Human

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

21 Jan 2015

esselfortium wrote: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.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

21 Jan 2015

esselfortium wrote:Great news! Hopefully this will mean some activity from U-he and friends again.
avasopht wrote:
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 :)


avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

21 Jan 2015

Theo.M wrote:
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.

User avatar
ScuzzyEye
Moderator
Posts: 1402
Joined: 15 Jan 2015
Contact:

21 Jan 2015

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.)

User avatar
Exowildebeest
Posts: 1553
Joined: 16 Jan 2015

21 Jan 2015

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

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

21 Jan 2015

ScuzzyEye wrote: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. 

User avatar
X1Lo
Posts: 65
Joined: 16 Jan 2015

21 Jan 2015

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
"As I stare into the digital abyss, I will remember when the world was real."


User avatar
ScuzzyEye
Moderator
Posts: 1402
Joined: 15 Jan 2015
Contact:

21 Jan 2015

avasopht wrote: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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

22 Jan 2015

avasopht wrote:Some filter designs are unstable with 32-bit precision. 
ScuzzyEye wrote: 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.

User avatar
SynapseAudio
RE Developer
Posts: 59
Joined: 22 Jan 2015

22 Jan 2015

ScuzzyEye wrote: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


User avatar
-008'
Posts: 380
Joined: 15 Jan 2015
Contact:

22 Jan 2015

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. :/
:reason: "Reason is not measured by size or height, but by principle.” -Epictetus

Free Kits and :refill: @ -008' Sounds

User avatar
JiggeryPokery
RE Developer
Posts: 1174
Joined: 15 Jan 2015

22 Jan 2015

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.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

22 Jan 2015

JiggeryPokery wrote: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.


User avatar
JiggeryPokery
RE Developer
Posts: 1174
Joined: 15 Jan 2015

22 Jan 2015

JiggeryPokery wrote: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 wrote:
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.

User avatar
Kategra
Posts: 327
Joined: 18 Jan 2015

23 Jan 2015

JiggeryPokery wrote: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.






User avatar
motuscott
Posts: 3420
Joined: 16 Jan 2015
Location: Contest Weiner

23 Jan 2015

JiggeryPokery wrote:  I will wield the hammer 'o bans.
Why do I feel oddly comforted by this after PUF?
Who’s using the royal plural now baby? 🧂

User avatar
JiggeryPokery
RE Developer
Posts: 1174
Joined: 15 Jan 2015

23 Jan 2015

Kategra wrote: 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
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

23 Jan 2015

JiggeryPokery wrote: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.
Kategra wrote:
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.

Locked
  • Information
  • Who is online

    Users browsing this forum: No registered users and 29 guests