EDIT: Cue the posts where it's claimed that an optimized Satin RE would sell millions.Urs wrote: Note that we have 10 employees on the payroll now, and our 9 REs together contribute less than 2% to revenues.
u-he SATIN as Reason Rack Extension?
-
- KVRAF
- 3389 posts since 7 Aug, 2008
Here's one reason why a an involved re-write of Satin to optimize the RE probably doesn't seem worth it to the u-he team.
-
- Banned
- 22457 posts since 5 Sep, 2001
[DELETED]
-
- u-he
- 30173 posts since 8 Aug, 2002 from Berlin
I don't understand why my answer wasn't correct.TheoM wrote:That's not even remotely what i asked and was quoted out of context. it's fine if you don't want to answer as i felt you might not want to.
we ALL know, even the code illiterate amongst us, that there is no SSE optimisations in RE. That's been the complaint of many a dev for years already.
In VST we have SSE right at our hands, in RE we don't.
The whole concept of Uhbiks is based on the idea that things can be optimised for SSE or Altivec. Every single line of DSP code is vector based when we compile for VST/AU/AAX. Every single line of DSP code is non-vector based when compiling for RE. Every single operation translates to 1 operation when compiling for VST/AU/AAX and 4 operations when compiling for RE. That is the only difference, nothing from our side can be done about that.
We can not somehow magically calculate only 1 operation in RE as well and hope for things to sound the same. They won't. It would break the sound.
The only thing that can be done is this:
- PH (or someone else) can improve auto-vectorization on the compiler
- PH can add a general SIMD extension format that then e.g. translates to SSE for the Intel architecture
If there is any other way, I'm all ears.
- Urs
-
- Banned
- 22457 posts since 5 Sep, 2001
[DELETED]
-
- Banned
- 22457 posts since 5 Sep, 2001
[DELETED]
-
- u-he
- 30173 posts since 8 Aug, 2002 from Berlin
Well, I wouldn't know how any "from the ground up" rewrite would change anything in terms of performance. But I'm quite sure that if we had to write everything from the ground up for RE, there would not have been a single RE from us.
-
- u-he
- 30173 posts since 8 Aug, 2002 from Berlin
So what do you suggest we do about it?TheoM wrote:Ps i have told you many times Urs, that it is not 4 to 1.
-
- Beware the Quoth
- 35414 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
I believe he's saying '4 instructions to 1' not '4 times the processor cycles to 1'TheoM wrote:Ps i have told you many times Urs, that it is not 4 to 1.
Even using single core stacking on live input buffer (so no logic "cheat" playback buffers are in effect) the differences are *minimum* 10 to 1. Sorry but it's true.
I have made the videos and have no need to lie about that, nor would I. I approach my performance testing with full integrity.
Different processor instructions take different numbers of processor cycles to complete. Its entirely plausible the instructions being compiled to for RE could be slower than SIMD instructions as well as having the lack of 4-way parallelism.
Set Theory claim:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate.
Red is Red and anything that is Red is an object, a class in itself or a real thing if you prefer"
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate.
Red is Red and anything that is Red is an object, a class in itself or a real thing if you prefer"
-
- u-he
- 30173 posts since 8 Aug, 2002 from Berlin
Actually, I don't think I want to deal with RE any further. I've asked them to take our out of the store. We'll see hat they say and how they suggest to handle this.
It's nothing but distress.
It's nothing but distress.