Quote from: deathy on January 06, 2016, 05:56:54 pm

If your software is 64 bit, then it will take better advantage of a modern CPU and can address a lot more memory.  However, 32 bit VSTs won't work in a 64 bit host.  So, you either gotta use somethin' like jBridge to wrap your 32 bit VSTs (which is a bit flakey, we're discussing this in another thread), or you just don't use the VST.


32 bit is dying tech, so it's only a matter of time... and chances are, we're not going to bother with 128 bit for a real long time, so we're going to be on 64 bit for a long while.

i thought it was the other way around (64 can't run on 32), just realized it now that i was wrong hahaha
there are a few lovely vst that only runs in 32 though

The Host OS's architecture can be different from the VST host (Ableton, FL, etc.). A 64bit chip & OS can run 32 bit software, 64bit software cannot run on a 32bit chip & OS. (your initial thought is correct when talking about hardware & operating systems)

In a 64bit OS... you can load a 32bit OR 64bit VST into a 64bit OR 32bit host... jBridge bridges both ways.
In a 32bit OS... only 32bit everything.

Hi, I'm a developer and would like to clear up things a bit.

About 32-bit vs 64-bit program bitness:

First, it is possible for both 32-bit and 64-bit programs to use 32-bit or 64-bit instructions.
And whatever the bitness of a plugin, he is able to use the full instruction set: FPU, SSE, AVX...
Some developers think that FPU instructions are not available in 64-bit mode. No, they are there and work well.

64-bit programs have plenty of address space (what is also known as "virtual memory"). That is only valuable if you were maxing out your memory in your 32-bit DAW, which seems a bit unlikely to me but well. Bridging can work-around the restriction of 3gb by program in 32-bit Windows.

True advantages of 64-bit programs are in the speed department. A 64-bit program will typically be 15% faster from what I've seen. 64-bit programs are all kinds of good:
- more registers, larger registers: x86 is traditionally starved by the number of registers, 64-bit instructions solve that.
- more consistent C ABI accross platforms
- red zone: this is a low level optimization
- because there is enough addressing space for anything, stability may be better for plugins with threads or that allocate on the "stack" a lot
- the assembler itself is actually pretty easy to port from 32-bit

About 32-bit vs 64-bit vs 80-bit operands:

This is completely unrelated to program bitness.

Difference between 64-bit and 80-bit is very likely not able to count in the slightest. 64-bit vs 80-bit sounds like splitting hairs.

Difference between 32-bit vs 64-bit computations do matter for some tasks notably recursive filters.

Accidental higher precision when using FPU:

You can get accidental higher-precision when using FPU instructions because they bring the bitdepth of all numbers to 80-bit.

So if porting a plugin to 64-bit, it is possible that a plugin developer was inadvertently relying on 80-bit precision in the FPU for doing computation, and now he's using SSE 32-bit float and it makes things sound worse by accident. This has happened to me before release of my last plugin.

Conclusion:
Naive translations of 32-bit plugins to 64-bit _might_ sound slightly worse for this reason. With a bit of care they sound the same up to say -80dB RMS.

64-bit programs make developer lives easier and are a bit faster. Though you probably won't see much difference as users.

Bridging is so resource intensive, and I only have 6gb of RAM... So I tend to use up more RAM for bridging 32-bit plugins into the 64-bit software. If I had more RAM, bridging wouldn't be an issue at all...

It usually refers to x86 for 32 bit OS and x64 for system with 64 bit.

Technically x86 simply refers to a family of processors and the instruction set they all use. It doesn't actually say anything specific about data sizes. The term x86 started out as a 16-bit instruction set for 16-bit processors (the 8086 and 8088 processors), then was extended to a 32-bit instruction set for 32-bit processors (80386 and 80486), and now has been extended to a 64-bit instruction set for 64-bit processors. It used to be written as 80x86 to reflect the changing value in the middle of the chip model numbers, but somewhere along the line the 80 in the front was dropped, leaving just x86.

Brian