Who understands 64 bit as it relates to DP?

toodamnhip · Post by **toodamnhip** » Wed Apr 19, 2006 3:12 pm

I keep hearing about 64 bit, such as the windows XP pro 64 bit and would like some info as to when DP will be running at 64 bit> Does it take OSx to move up to true 64 bit first>? Anyone know when this will happen and what kind of performance improvements we should enjoy?

I must admit to being a bit confused about it all.

Thanks...

David

bongo_john_uk · Post by **bongo_john_uk** » Mon Apr 24, 2006 8:04 am

OS X has only had 64 bit support since Tiger. The program must also be coded to make use of it. I doubt if many of the sequencer manufacturers have had the time or inclination to take advantage of it yet. When most customers have 64 bit machines then they will get much keener. The switch to intel is more of a headache and priority for them and this also means back to 32 bit for a while (apple try not to publicise this though!!)

96khz · Post by **96khz** » Mon Apr 24, 2006 8:41 am

bongo_john_uk wrote:The switch to intel is more of a headache and priority for them and this also means back to 32 bit for a while (apple try not to publicise this though!!)

Only the iMac G5 was "downgraded" to 32 bit. The MacMini, iBook and PowerBooks were always 32 bit.

Anyway, the 64 bit question, if it was applied in a sequencer application, the advantage would be higher dynamic resolution in all the mixing process (levels and effects), without any performance penalty. It wouldn't mean more processing power (more plug-ins) but it would mean better quality (more precision) when processing.

There's an exception for this: plug-ins that now use 64-bit precision (like some Waves plug-ins) need at least 2 cycles to process a singe 64 bit word as they're limited to current 32 bit technology. If using a 64-bit processor, it could process it in a single cycle, so in this case it would mean freeing processing power.

In the Windows World, I think Sonar was the first to support 64-bit. I don't know any others that did it yet, but I'm looking forward to it.

More info:
http://mixonline.com/state-64bit-computer-040606/
http://www.cakewalk.com/x64/whitepaper.asp

Timeline · Post by **Timeline** » Mon Apr 24, 2006 9:20 am

I'm looking forward to that but doubt we will enjoy anything that undertaking with the release of Intel mac desktops. More like 5 years off, I would guess.

Do you think we will ever see mixer-no latency monitoring and switching? I doubt that too making me wonder why I haven't purchased a PC and just loaded my Nuendo PC version which supports this now.

They are most likely to get to 64bit first I would think.

I will wait until September and if at least the input latency issue doesn't appear, I may buy an AMD PC and just have dual systems for a while as PCs continue to get cheaper and cheaper.

I could at least do overdubs with real no latency tape switching at that point and maybe bung the tracks back to DP for mix but who knows, they may beat them to the move and I'll stay there.

I also looked into using the 64 bit Vienna Orchestra Library but it only runs on PC unless you buy Halion or Kontak and that won't run in DP. As I'm told, VOL cannot support Mach5 in it's present form. Too bad.

I think if MOTU was smart they would reach out to them and make the necessary changes to allow the Vienna sounds available to us in DP via Mach5. It's by far the best sounding out there IMO.

Sorry to ramble on. The drugs haven't kicked in yet.

Klaus · Post by **Klaus** » Mon Apr 24, 2006 9:47 am

I thought DP has some 64 bit plugs... ?
Could it be that these run 32 bit but DP buffer runs *silently* at double buffer ?
This would explain the ridiculous thruput latency, that, for me is at least doubled.
I would have to check if the thruput latency isn't doubled when only using the easier plugs of DP,
anyone ?

Best

Klaus

grimepoch · Post by **grimepoch** » Mon Apr 24, 2006 11:40 am

64-bit has to do with the address space of the processor, not the data space. I see people get confused on this ALL the time.

For the most part, 64-bit is going to give people who need more that the address space limit of a 32-bit machine. For instance, many processes are limited to only using 2 Gig of memory. There are quite a few people running quad processors who've found that all that extra memory doesn't help if you can't go past the 32-bit address space (given your code was written for 32-bit addressing).

I've done EXTENSIVE testing of both Sun UltraSparc and AMD Opteron 64-bit machines. I can tell you for first hand experience that all things kept equal as far as pipelining, optimizations and such, a 32-bit application is going to be slightly faster. Why? While you may not realize it, all stored address values are now twice as big, you are moving twice as much data, and not all devices in the chain are 64-bit wide.

When people talk about the audio processing, that is a completelty different beast altogher and is dependent on your floating point operations. Plugins like Ozone3 use 64-bits. This is because you could do things in any number of bits if you wanted to, it's just you may not reap all the benefits if you surpase your floating point processor. Also, the larger your data, the longer it takes to move it.

So, all that said. If you need to use a lot of RAM for samples and pre-loading and stuff, you will probably more than likely see enhancements at 64-bit as working in memory is going to be MUCH faster than working on disk.

billf · Post by **billf** » Mon Apr 24, 2006 3:29 pm

grimepoch wrote:For the most part, 64-bit is going to give people who need more that the address space limit of a 32-bit machine. For instance, many processes are limited to only using 2 Gig of memory. There are quite a few people running quad processors who've found that all that extra memory doesn't help if you can't go past the 32-bit address space (given your code was written for 32-bit addressing).

Very true. It's even applicable to the dual G5's that can house up to 8 gb of ram. And the reason why laptops are not an issue with regards to 32 v 64 bit is because ram space in them is limited.

FWIW, I read somewhere recently that the first Macintel towers will probably be 64 bit mainly because of Apple's video market. We shall see.

dgatwood · Post by **dgatwood** » Mon Apr 24, 2006 9:08 pm

grimepoch wrote: For the most part, 64-bit is going to give people who need more that the address space limit of a 32-bit machine. For instance, many processes are limited to only using 2 Gig of memory. There are quite a few people running quad processors who've found that all that extra memory doesn't help if you can't go past the 32-bit address space (given your code was written for 32-bit addressing).

Depends. The buffer caching in the kernel can significantly decrease disk load by having RAM that isn't used by the application. This is particularly true with audio.

grimepoch wrote: I've done EXTENSIVE testing of both Sun UltraSparc and AMD Opteron 64-bit machines. I can tell you for first hand experience that all things kept equal as far as pipelining, optimizations and such, a 32-bit application is going to be slightly faster. Why? While you may not realize it, all stored address values are now twice as big, you are moving twice as much data, and not all devices in the chain are 64-bit wide.

Agreed. That is true on any architecture in which all other things are equal. The reason that PC users talk about 64-bit so much is that 32-bit on x86 architectures is somewhat register starved. It does a very good job of making up for that deficiency through massive on-die caching, but it still causes a bit of a performance hit.

The 64-bit x86 variant not only makes the registers wider, but also increases the number of registers. Thus, amd64 often performs better than ia32 even taking into account the increased cache misses, data/address fetch overhead, etc.

Thus, you'll hear Windows users frequently saying that 64-bit apps are faster. On x86, they often are. On PowerPC, Sparc, etc., they generally aren't, though they may be for certain workloads (e.g. being able to do true 64-bit integer math outside of leaf functions instead of having to simulate it with a pair of 32-bit registers to avoid register passing compatibility issues on the stack).

PPC:
32 GPRs, 32 FPRs, 32 SIMD

IA32:
8 GPRs, 8 FPRs, 8 SIMD

x86_64:
16 GPRs, 8 GPRs, 16 SIMD

grimepoch · Post by **grimepoch** » Wed Apr 26, 2006 12:55 am

True, very true. The biggest thing is that most 64-bit architectures are newer, and typically just faster overall. I've run 32-bit code on the Opteron's and it is faster than 64-bit code, but not by some huge amount. Also, the tests I was doing were not real time, more like rendering.

My next purchase will be a Intel tower after a few revisions as long as it is a quad processor. For me, I run a lot of live tracks so the more multiprocessing the better. Right now I use the UAD so I am sticking with my dual 1.8 for the time being. It works great, I really can't complain.

It just makes me laugh when I am in some store and hear some random person going on about how they NEED 64-bit, I laugh.

To think I started on 8-bits....

All I have to say is this; there are 10 kinds of people in the world, those that understand binary and those that don't

96khz · Post by **96khz** » Wed Apr 26, 2006 1:43 am

Do any of you know the bit-depth of the floating-point units in "traditional" 32-bit CPUs (x86 or PowerPC) versus the new 64-bit ones? Does the 32 vs 64 bit only relate to the integer calculations? To me, the big advantage of 64bit regarding audio (besides memory address space) was the possibility of the mixing engine and plug-ins working at 64-bit floating point instead of 32...

Quote from http://www.cakewalk.com/x64/whitepaper.asp:

The future holds even more promise for 64-bit platforms. We see the potential for building efficient 64-bit data paths within our mixing engine, in other words, processing using 64-bit floats instead of 32-bit floats. This would put the word length of host based systems beyond that of DSP based systems.

grimepoch · Post by **grimepoch** » Thu Apr 27, 2006 1:19 pm

I don't believe it is so cut and dry, food for thought:

http://en.wikipedia.org/wiki/64-bit

Important notes:

* Many processors already have internal support for 64-bit (double precision) and higher. It was the external interface that was the limiting factor. For instance, I believe some of the SSE extentions gave 128-bit internal registers. There is a lot of variety in FPU design, pipelining, and such. You'd really have to look at the architecture you are interested in.

* 32-bits of dynamic range is HUGE, I personally believe going to 64 is a waste when that extra precision is WAY beyond any equipment in your input/output chain when crossing from A -> D or D -> A. When I say waste, I refer to chewing up twice as much bandwidth in your memory when things have to be pushed around on serial devices, or even semi serial (discrete parallel sizes).

dgatwood · Post by **dgatwood** » Thu Apr 27, 2006 11:26 pm

96khz wrote:Do any of you know the bit-depth of the floating-point units in "traditional" 32-bit CPUs (x86 or PowerPC) versus the new 64-bit ones? Does the 32 vs 64 bit only relate to the integer calculations? To me, the big advantage of 64bit regarding audio (besides memory address space) was the possibility of the mixing engine and plug-ins working at 64-bit floating point instead of 32...

There's no real benefit to doing so, IMHO. 32-bit float should handle the precision of any sane number of 24-bit integer tracks with plenty of headroom.

That said, you can do 64-bit (double) floating point on PowerPCs all the way back to the original PowerMac 6100's PPC601. In recent versions of Mac OS X (10.4+) with gcc4, you can even to 128-bit (long double) floating point (even on very old CPUs).

So 64-bit has nothing to do with that at all.

dgatwood · Post by **dgatwood** » Thu Apr 27, 2006 11:31 pm

grimepoch wrote:It just makes me laugh when I am in some store and hear some random person going on about how they NEED 64-bit, I laugh.

Well, for certain things I do, I NEED a 64-bit Perl, but....

grimepoch wrote: All I have to say is this; there are 10 kinds of people in the world, those that understand binary and those that don't

No, there are 11 kinds of people in the world: those who understand unary and those who don't.

Fun things to do: count to 31 on one hand. Some particularly embarrassing numbers are 4, 19, and 21.

grimepoch · Post by **grimepoch** » Fri Apr 28, 2006 10:52 am

Haha, I write in Perl all the time, of course the things I am writing I normally don't store too much data in memory. A friend of mine who does bioinformatics, well that's a different story!

Now, when I am working on an integrated circuit, which is what I do during the day, it's not uncommon for me to have processes taking up 7 Gig or more. Although honestly, we break most things down to work smaller, you get better throughput and better results. A lot of things are exponential in run times depending on size.

What I'd LOVE to try is an 8-processor machine with DP and compare it to a 4 -processor (you know, when they all exist). For real time, I wonder where the right combination is, I am sure there is an upper limit somewhere given the communication with drives and the firewire bus!

medienhexer · Post by **medienhexer** » Tue May 02, 2006 4:01 am

grimepoch wrote: * 32-bits of dynamic range is HUGE, I personally believe going to 64 is a waste when that extra precision is WAY beyond any equipment in your input/output chain when crossing from A -> D or D -> A. When I say waste, I refer to chewing up twice as much bandwidth in your memory when things have to be pushed around on serial devices, or even semi serial (discrete parallel sizes).

I Disagree. Raising the Bit-Resolution means being able to push the noise floor even further. So there‘s theoretically more acurate Low Signal quality.
BUT the whole mixing engine thing isn‘t just about the available headroom. It‘s always about summing signals. The more precise the summing, the more open the sound will be. You‘ve always rounding errors inherent in the digital domain. And by doubling the bit depth in every summing operation you don‘t just double the dynamic range (which is limited by the 24 Bit converters in any case), but increase the precision, meaning you reduce rounding errors.

The signal going into the converters has a defined maximum of 0 dB Full Scale which translates into a certain Voltage. By increasing the resolution, you determine, how many steps you‘ve got between Full Scale and 0 V.

On the processing side, you have 0dB as a maximum as well, since otherwise the signal is going to clip. The trick is that with higher precision, you can use the sub-0dB-range more effectively, since the noise floor and quantisation noise are further away.
And anybody who has ever tried to mix via onboard AC97-Sound in a PC, knows what that means: with a noisy output, you don‘t hear neither room information, nor freqency balance, not even to think about using dynamics correctly.
On the other hand, raising the resolution always means a less sterile, more natural sound (try the 16Bit-bounce in comparison to the 24Bit tracks).