Practical difference between 64 & 32-Bit plugins?

[ferez21]

So,

I know this topic was discussed to death, but i just want a simple answer which will be practical for me, don't care much about theory as i'm not a programmer.

I asked this question on Image-Line's forums, because i wanted to know if using 64-Bit plugins will reduce cpu load on my machine. The answer i got from them is that 32\64-Bit is related to the amount of memory a plugin can access, which is of course bigger for 64-Bit, and it have nothing to do with cpu efficiency. The only plugins that i can benefit from using their 64-Bit versions, are Romplers\Samplers which use samples and need to access as much Ram as possible due to the nature of their content's size.

So practically speaking, excluding Romplers, should i care less if the next plugins that i buy are 32 or 64-Bit?

[Bobbotov]

If you have a 64 bit DAW I would opt to acquire 64 bit VST's whenever you can. Bridging software like JBridge are for the most part acceptable tools but why add another program to run if you can avoid it. Some DAWs have bridging software built-in. This is all a transitional phase until everything is 64 bit anyway. However, some older plugins probably will never migrate to 64bit so bridging may be around for some time if you want to keep using them.

But the real benefit of 64bit, like you said, is the ability to use increased RAM up to whatever your motherboard can support. I run several RAM intensive VST programs like Kontakt and Omnisphere but have never needed more then 8gig. With several current synths though the issue is CPU power. Some are very CPU intensive and 64 bit will not address that at all.

[ferez21]

With several current synths though the issue is CPU power. Some are very CPU intensive and 64 bit will not address that at all.

This is the only thing that actually concerned me, I got plenty of Ram, but my cpu is not top notch although it's quite new, and i'm not going to replace it soon.
Why don't we see any general improvement in cpu optimization for vst plugins?
It seems like this situation haven't changed for a long time (from a consumer point of view) - some plugs are more efficient, some are less, but i can't really see any significant improvement overall.

[Bobbotov]

With several current synths though the issue is CPU power. Some are very CPU intensive and 64 bit will not address that at all.

This is the only thing that actually concerned me, I got plenty of Ram, but my cpu is not top notch although it's quite new, and i'm not going to replace it soon.

Well, what will happen is you will get dropouts as the CPU is over taxed and spikes. It happens. Not the end of the world but more annoying than anything. Freezing and rendering tracks can help. And save often in case you crash. Also the more FX and instances of a VST you add burdens the CPU. A good audio card and faster CPU are the cure but not always practical. Multi-core CPUs can help but not all programs are multi-threading so there is no advantage.

The race between RAM, CPU power and programs has been going since forever.

[arakula]

Why don't we see any general improvement in cpu optimization for vst plugins?

Because developers tend to squeeze more features into their PlugIns instead of simply optimizing what's already there. New features mean more CPU usage, not less, and normally swallow the effect of optimizations done to the existing code.

Who would buy a product with the impressive marketing hype "New!!! No changes, but 5% faster thanks to excessive optimizations!!!"

[J.Hartmann]

http://www.meldaproduction.com/audiotut ... 32vs64.php

With the advent of cheap multi-core processing and the subsequent arrival of the latest operating systems to utilize their power, more and more people are demanding 64-bit systems and applications. But how many of us actually understand what 64-bit means?
We try to clear up the confusion by looking at the advantages and disadvantages of each system.

[xoxos]

look, it's new, therefore you need it, buy it, pay for the available upgrades and abandon the rest, and stop asking any questions.

that's how you guarantee being a first class citizen of the music world





and remember to post frequently that any developer who doesn't upgrade to 64 won't get your money. let them know you will sway their behaviour with pecuniation! you, consumer, are the master of the 128 oops i mean 64 bit empire.

[thevinn]

Who would buy a product with the impressive marketing hype "New!!! No changes, but 5% faster thanks to excessive optimizations!!!"

Well I think that if you advertise an improved version that claims "Now process more live tracks simultaneously" because of efficiency gains that would certainly get some sort of attention.

[rootbear]

So the question is can a 64 bit plugin run faster? (ie. the binary is 64 bit)
If you are running 64bit audio isn't it a lot faster to do the math with 64 bit binaries? In 3d rendering it is thought so, people said it was 150% normal speed, though that was one discussion about one particular type of processing.

[AdmiralQuality]

So the question is can a 64 bit plugin run faster? (ie. the binary is 64 bit)

Ours seem to run at the exact same speed.

If you are running 64bit audio isn't it a lot faster to do the math with 64 bit binaries?

No. The built in FPU in modern Intel chips works at 80 bit internally, so it's overkill in either case. (SSE operations were 32 bit, and SSE2 allowed 64 bit.)

In 3d rendering it is thought so, people said it was 150% normal speed, though that was one discussion about one particular type of processing.

This may be particular to the GPU. (Where you can see 150% speed increases just by updating a driver.)

In time compilers may be able to optimize x64 better than now. But all our empirical tests currently show no significant difference in execution speed between x86 and x64 code on the same processor.

[AdmiralQuality]

Who would buy a product with the impressive marketing hype "New!!! No changes, but 5% faster thanks to excessive optimizations!!!"

If we make a performance improvement, we do a release. No point in holding back capabilities from the users just because the marketing hype isn't impressive enough.

http://www.admiralquality.com/products/ ... hp#changes

[davidguda]

Why don't we see any general improvement in cpu optimization for vst plugins?

I think the answer is basicly that optimization is a very advanced subject!
Erlier on when VSTs were new developers did what they could to speed things up, today developers still do what we can to speed things up but it is basicly the same tricks in most cases as what was done before.
Sometimes there is a tradeoff between speed and quality and nowadays when we have faster CPUs we might lean towards quality rather than speed when given an option.

[Ivan_C]

From http://www.agner.org/optimize/

64 bit systems have several advantages over 32 bit systems:
• The number of registers is doubled. This makes it possible to store intermediate data and local variables in registers rather than in memory.
• Function parameters are transferred in registers rather than on the stack. This makes function calls more efficient.
• The size of the integer registers is extended to 64 bits. This is only an advantage in applications that can take advantage of 64-bit integers.
• The allocation and deallocation of big memory blocks is more efficient.
• The SSE2 instruction set is supported on all 64-bit CPUs and operating systems.
• The 64 bit instruction set supports self-relative addressing of data. This makes position independent code more efficient.

64 bit systems have the following disadvantages compared to 32 bit systems:
• Pointers, references, and stack entries use 64 bits rather than 32 bits. This makes data caching less efficient.
• Access to static or global arrays require a few extra instructions for address calculation in 64 bit mode if the image base is not guaranteed to be less than 231. This extra cost is seen in 64 bit Windows and Mac programs but rarely in Linux.
• Address calculation is more complicated in a large memory model where the combined size of code and data can exceed 2 Gbytes. This large memory model is hardly ever used, though.
• Some instructions are one byte longer in 64 bit mode than in 32 bit mode.
• Some 64-bit compilers are inferior to their 32-bit counterparts.

In general, you can expect 64-bit programs to run a little faster than 32-bit programs if there are many function calls, if there are many allocations of large memory blocks, or if the program can take advantage of 64-bit integer calculations. It is necessary to use 64-bit systems if the program uses more than 2 gigabytes of data.

[ferez21]

Sometimes there is a tradeoff between speed and quality and nowadays when we have faster CPUs we might lean towards quality rather than speed when given an option.

This is another marketing issue that draws back preformance in my opinion - "quality" = x1,000,000 oversampling, super antialiasing, 542,965khz for every basic plugin, is not really neccesarry. 99% of the people can't even distinguish betweem 192khz and 48khz, so why bother more with developing features that cant be heard, rather then concentrate in optimization that i t is imo much more importent. It's just absurd that 10 years ago i could run about the same amount of plugins as im able to run today.

[Richard_Synapse]

This is another marketing issue that draws back preformance in my opinion - "quality" = x1,000,000 oversampling, super antialiasing, 542,965khz for every basic plugin, is not really neccesarry. 99% of the people can't even distinguish betweem 192khz and 48khz, so why bother more with developing features that cant be heard, rather then concentrate in optimization that i t is imo much more importent. It's just absurd that 10 years ago i could run about the same amount of plugins as im able to run today.

This is certainly due to complexity, but not only. CPUs haven't improved in per-core performance tremendously, which is why we're seeing more cores, as opposed to faster CPUs. As a result it gets harder to optimize code.

Richard