Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Johnny B]

Now I do not know if this will embarrass me or not, but, "what the heck?" I'm beyond that...ha..ha...

I just got some kind of automated email notice for the NYC AES with all kinds of new product announcements on it.

And CAKEWALK, yes, that's right, CAKEWALK is making a claim that it is the first truly 64-DAW....that claim may be a bit exaggerated...

But more importantly how will 64 bit DAW's affect the "thruput" of the digital audio formats and signals? Will it slow it down, speed it up...it may be hard to tell at this point without more data...

Perhaps the people going to AES could press the "thruput" issue and get some definitive answers about "thruput impacts"



 

[danickstr]

hey combine this with Creative's E-MU 192K converters and voila! Overdone power in the low end package!  What more could little Junior want?

[Johnny B]

Yeah, maybe...maybe not...

The question still remains regarding the "Thruput Issue"...

If all the DAW's go to 64-bit, then what will happen with the "Thruput Issue?"

[PookyNMR]

In another forum an engineer from Apple stated how at this point there will be little benefit to the DAW software other than obvious things like addressable RAM.

Not sure on how things are going on the Windows side, but AFAIK the 64 bit Windows is not near done yet.  64 bit app on an incomplete OS?  No thanks.  Windows has enough problems at 32 bits...

Sound like another sales gimick to me to trick the ignorant into thinking their getting more than they really are.  Kind of like 192k converters.  

[Johnny B]

You may get some argument on both counts...

But let's say the OS already was 64-bit, just for purposes of discussion and that it was now stable...say Longhorn was stable and was now at a full 64-bits, OK.

Now address the thruput issue...

[Jon Hodgson]

Johnny B wrote on Mon, 03 October 2005 08:06

You may get some argument on both counts... But let's say the OS already was 64-bit, just for purposes of discussion and that it was now stable...say Longhorn was stable and was now at a full 64-bits, OK. Now address the thruput issue...

It's a hard one to be certain of, because in such complex systems you have more than one factor.

If the programmer (or the compiler) is not using the vector unit of the processor (SSE2) to do operations in parallel, then the processing should happen at pretty much the same speed, but if he makes extensive use of it then he can only process two samples at once rather than four.

With 64 bits moving around there's just more data to move, which is going to fill up your caches and slow things down there.

On the other hand, using the 64 bit mode of the processor gives you more registers, which can really speed things up in some cases (probably not the audio processing, but other aread of the code).

All in all I would expect throughput to be lower, but by how much I don't know, especially since I don't know how much actual audio processing goes on at 64 bits... for example if they just used it in the mix bus, then I would guess that the performance improvements from the extra registers would more than make up for the performance hit in the mixbus.

[PookyNMR]

Johnny B wrote on Mon, 03 October 2005 01:06

You may get some argument on both counts... But let's say the OS already was 64-bit, just for purposes of discussion and that it was now stable...say Longhorn was stable and was now at a full 64-bits, OK. Now address the thruput issue...

Since my friend from Apple deigned the 64-bit G5, I'll take his word over what any other person less qualified has to say.

It's pointless to event disucss "assuming there was a full release 64-bit version of Windows" because there is not such a version.  This is one of the things that makes this new Cakewalk release a pointless gimick.

As far as thruput goes..  I think there is a lot of misconceptions of what 64 bit actually is and what it does.  I'm certainly not a computer engineer or any kind of expert.  But when I hear people who are saying that there will be little increase for those of us processing audio.  I believe them.  

[Johnny B]

Jon,

Let's continue with our assumption about a stable full 64-bit OS, OK?

Now let's consider this factor, there are those who argue about bit depths, conversion, dither, truncation and whatnot, right?

Those are all intermediate steps. And those kinds of intermediate steps can create mischief, right?

What if you wasted some bits in the ADDA but you were able to bypass all or most of the intermediate steps as a result? That might actually result in some benefits: i.e., it could result in the elimination of some of the introduced errors, timing problems, and might even eventually speed up the thruput.

In more simple terms: Less steps = Less problems.



 

[Jon Hodgson]

Johnny B wrote on Mon, 03 October 2005 17:56

Jon, Let's continue with our assumption about a stable full 64-bit OS, OK? Now let's consider this factor, there are those who argue about bit depths, conversion, dither, truncation and whatnot, right? Those are all intermediate steps. And those kinds of intermediate steps can create mischief, right? What if you wasted some bits in the ADDA but you were able to bypass all or most of the intermediate steps as a result? That might actually result in some benefits: i.e., it could result in the elimination of some of the introduced errors, timing problems, and might even eventually speed up the thruput. In more simple terms: Less steps = Less problems.

If clock cycles were no object, then I'd simply process everything in 64 bit floats and be done with it. It certainly reduces the chances of problems. However processor speed is for the time being still an issue, so the brute force approach loses out to more careful algorithm design and implementation on commercial grounds for the time being.

However there aren't many places where it would lead to a reduction in processing steps, so compared to having to move and process twice as much data it is unlikely you'd see a throughput increase.

Compiling in 64 bit mode on the AMD and Intel processors will improve the speed of 32 bit calculations though, since the compiler has twice as many registers to play with.

Anyway there's no point in your ADC and DAC being more than 24 bit even if your processing is 64bit.

[Johnny B]

Jon,

You have some good answers. Still, I'm not so sure about some of it. This line of reasoning makes me wonder a bit about it.

I'm also assuming you will be seeing some super fast 64-bit CPU chips in the future, dual core, quad...who knows?...but extremely fast...

So I'm assuming a stable 64-bit OS with a super fast 64-bit CPU cranking along at blinding speeds, sufficient horsepower and adequate support chips...

And a great bus structure for the I/O....

I'm always amazed at how far we've come and how fast we got there...a long, long way from front panels, removable disk packs, and paper tape...that's for sure.














 

[seriousfun]

PookyNMR wrote on Mon, 03 October 2005 08:48

It's pointless to event disucss "assuming there was a full release 64-bit version of Windows" because there is not such a version.

Of course there is http://www.microsoft.com/windowsxp/64bit/default.mspx.

From Cakewalk's Ron Kuper http://www.digitalproducer.com/articles/viewarticle.jsp?id=3 0309:

Quote:

But the bottom line is on most of the benchmarks we’re running, there was an improvement, and it was signficant. It was like 20-30 percent more CPU efficient. Basically this is taking the same box, the same hardware, the same audio interface, running 32-bit native SONAR with a 32-bit OS, and then dual-booting and running 64-bit SONAR, 64-bit OS, the same box. And we saw a 20 to 30 percent performance gain. Now, that wasn’t on every benchmark -- I have to say your mileage may vary. In some cases, it was the same performance. The worst I saw was it was the same. But in almost all the cases it was better, and when it was better, it was significantly better.

We're certainly in a transitional period, but by all reports, better native DAW performance is just around the corner. Sonar/WXP is a stable, good sounding, full-featured DAW, as is Logic/OSX. In either case, let's look forward to embracing this 64-bit opportunity, as opposed to dismissing it before it arrives.

[Jon Hodgson]

seriousfun wrote on Mon, 03 October 2005 23:18

PookyNMR wrote on Mon, 03 October 2005 08:48 It's pointless to event disucss "assuming there was a full release 64-bit version of Windows" because there is not such a version.     Of course there is http://www.microsoft.com/windowsxp/64bit/default.mspx. From Cakewalk's Ron Kuper  http://www.digitalproducer.com/articles/viewarticle.jsp?id=3 0309: Quote: But the bottom line is on most of the benchmarks we’re running, there was an improvement, and it was signficant. It was like 20-30 percent more CPU efficient. Basically this is taking the same box, the same hardware, the same audio interface, running 32-bit native SONAR with a 32-bit OS, and then dual-booting and running 64-bit SONAR, 64-bit OS, the same box. And we saw a 20 to 30 percent performance gain. Now, that wasn’t on every benchmark -- I have to say your mileage may vary. In some cases, it was the same performance. The worst I saw was it was the same. But in almost all the cases it was better, and when it was better, it was significantly better. We're certainly in a transitional period, but by all reports, better native DAW performance is just around the corner. Sonar/WXP is a stable, good sounding, full-featured DAW, as is Logic/OSX. In either case, let's look forward to embracing this 64-bit opportunity, as opposed to dismissing it before it arrives.

Well the processor is more efficient in 64 bit mode because it has more registers (not because it is processing 64 bits at a time)... but are they actually doing the audio processing at 64 bits?

[Johnny B]

Jon,

Another good question...and something that should be tested.

We just saw that this Cakewalk guy was initially skeptical until he actually did it...but he did it anyway and got the the good results....

That's how it often works, you try stuff anyway regardless of what some people may say...and sometimes what you find after testing is that some stuff just works better...

You have to be willing to try new stuff..

[Jon Hodgson]

Johnny,

I'm not quite sure I see what you're saying.

The fact is that the extended (64bit) mode of the 64 bit x86 range is faster than the 32 bit mode, whether it is processing 32 bit samples or 64 bits samples.

But it will be slower processing 64 bit samples than 32 bit samples.

Basically if you use it to the max, the fastest processing on those processors will be 32 bit processing in 64 bit mode, that's a given, since you have twice as many normal and vector registers available compared to 32 bit mode, but twice the processing units and bandwidth compared to processing 64 bit values.

A simple recompile without changing a single line of source code will see a performance improvement, the processor is quite simple faster at doing the same things.

[Johnny B]

Emmm, the basic idea I'm trying to relate is that for every intermediate step you can eliminate, the less errors will be introduced and the faster the overall process should be. Just for the purposes of discussion, let's say you did everything in 64-bit words.

Sure, there would be some bits wasted in some of the process, but doing away with some of the conversions in the chain may yield some unexpected benefits. It's not enough to simply attack new or novel approaches based solely on theoretical analysis, you actually have to try new things to see what will happen.

Anyway, here's my major point...just look at the data flow and see how it might be improved...can we eliminate steps? What happens when we eliminate steps?

I hope you are getting the idea I'm trying to express. Speed up the data flow and make it more efficient on an overall system basis.