View Single Post
Old 11-06-2009, 07:21 PM   #40
Human being with feelings
Join Date: Jun 2007
Location: Berlin, Germany
Posts: 75

Wavosaur x86 (32-Bit) will work fine in Win x64 (64-Bit)
At least version is doing so here...

If anyone cares... I am currently running Win7 x64 and have been for some months, since the RTM was out. Coming from XP x86 and the nauseous XP x64 and having to work on the agonizing Vista (in the case of Vista, x86 is no guarantee for stability!) I expected the worst of Win7 ... more colors, more FX, more this and that and BSODs and all the usual flaws that usually fluff up the fun and productivity resting inside computers.
But what can I say... beggar never let me down once. Yet. And I sure hope it stays that way. Finally, Microsoft's overclocked synapses have yielded a stable operating system and I'm glad to say that in moving on from XP I never had to look back once.
On x64 that is, remember. Not x86.
Coded like a brick, just won't crash.

As an environment to work with, Win7 (in disregard of x86 or x64 architecture) is fast, stable (even after months of intense testing and installing and removing... you know the routine) and has a very efficient workflow once you get it tamed.

I decided to stay with 64-bits, without really knowing what that meant. Apart from this "more than 4gig"-thing everybody's excited about.
And I guess it seems natural that in a x64 environment you don't want to worry about lots of effort going to waste for the sake of compatibility and downward-bitted-integration. I'm glad to say that I have not a single device in my machine that wasn't at least written a driver for to work under Vista x64 (which in a personally estimated percentage of 95 will also do its deeds under Win7), so no compatibility issues hiding there.

I got interested in Reaper x64, as it would seem logical that an x64 application should run steadier and more efficient than an application compiled for the -to x64- alien x86 architecture, maybe greatly profit from that and reward me with a whole lotta more plugin instances - or what do I know, "what do we need? ... *more power!*"

The thing that always fluffed my plans up was the un-interoperability of Reaper x64 and x86 plugins. Just couldn't get them to work. Of course.
Now that the Cockos guys have been toying (umm... code-wise! ^^) with the x86-bridging I started listening up again.

Since noone seems to have any figures or charts or numbers, I conducted my own little benchmark. Or well, it's not a real benchmark, more of a little comparison I did to satisfy my curiosity as noone else could do that. But it's conclusive enough for me.

Have a look at these pictures, and hopefully you'll be able to follow:

Here's how I did it:

Went and found myself 2 plugins that I feel comfortable with.
For one, the free mono version of the SinusWeb Peak Compressor which I LOVE because it does its job just as it promises and you can insert it practically anywhere (umm... into tracks and stuff! ^^) as it hardly chews at the CPU at all.
And as not the opponent but rather the accomplice I chose Cockos ReaXcomp, as it's in contrary a relatively complex tool and yet also surprisingly CPU efficient.
Quickly shoved some samples onto two tracks of an empty project and off we go.

I made sure that all instances of the PeakCompressor had the same settings while testing, just cranked the faders until it showed a rise in CPU hunger. As you can/might notice, the gain reduction is actually doing quite a hard job.
The same for all instances of the ReaXcomp, yanked it into some senseless but demanding function and watched it breathe.

(Of course, the parameter settings used in the first hosted instance were exported to a patch and reloaded into the other instance/s! Be assured: no parameter cheating!)

As the CPU use values are always changing as the track continues, I observed those values for a while to find their "realistic" max and min values and simply made a picture when the average / middle-value was shown.
The PeakCompressor native x86 under Reaper x86 just wouldn't come above 0.7% or 0.8%, so rather not see that value as an average but more of a maximum!

My goal was to prove (to myself) that under Win7 x64 an instance of Reaper x64 with a native x64 plugin would show better performance than an instance of Reaper x64 with a bridged x86 version of the exact same plugin - and that bridging x86 plugins into an instance of Reaper x64 comes with a decrease in performance in comparison to a native x86 version of a plugin inside an instance of Reaper x86.

And from what I observed, that was just the case.

The x86 plugin in Reaper x86 work just fine.
The x64 plugin in Reaper x64 work just fine.
But both x86 plugins in Reaper x64 (bridged) were hungrier for CPU than their native companions. (EDIT: or them in their native environment)

Uhm, yeah: I know that 1.15% bridged from x86 to x64 compared to 0.75% in native x86 is not a hell of a lot of a difference - but don't forget, that's over 53% of "hot air" wasted in just 1 instance.
In, say, a project with 20 instances we'd suddenly be talking about ~23% instead of 15%, and thats a respectable amount... nearly 8% of CPU performance gone to waste on bridging... That's 10+ more instances of the PeakCompressor...

some kind of disclaimer, I guess...
These are MY results, made on MY machine with plugins I use and collected in a way I thought would be appropriate.
Maybe other testing processes and other plugins will result in other ... results.

But for all I care ... I'd like plugin development to concentrate on x64 architecture rather than VST3... fluff that, any decent host can handle more than 2 channels per track and any decent plugin can handle more that 2 in- and outputs... so what's the magic with sidechaining... it's just... morer CPU munch...

You trying to tell me you read all this?
Gad, you should definitely go out, find some friends...

In the words of George Carlin: "Just wanting to share".
Or in the words of my ol' man: "Hope it chokes you".

Greetings from icy Munich

Last edited by caleb82; 11-06-2009 at 07:44 PM.
caleb82 is offline   Reply With Quote