guitardood

The only need for 64-bit, IN A DAW APPLICATION AS STREAMLINED AS SONAR, is for the memory-starved synths.   Can anyone possible disagree with that statement and keep a straight face?

Noel Borthwick of Cakewalk apparently can. 
 
http://www.cakewalk.com/Press/release.aspx/White-Paper-Benifits-of-x64-for-Audio-Workstations

In the year 2525, If man is still alive...

dmbaer

guitardood

The only need for 64-bit, IN A DAW APPLICATION AS STREAMLINED AS SONAR, is for the memory-starved synths.   Can anyone possible disagree with that statement and keep a straight face?

Noel Borthwick of Cakewalk apparently can. 
 
http://www.cakewalk.com/Press/release.aspx/White-Paper-Benifits-of-x64-for-Audio-Workstations

I've spoken with Noel via email on many occasions especially during one of the betas I was involved with some years back and have quite a bit of respect for him.


However, marketing literature notwithstanding, the only real revelation in the above article is that Sonar will store loops in RAM if possible.  This I did not know.  However, I still stand by my original posting albeit with the following caveat "unless you're doing tracks made up of a lot of loops".  The additional registers and FPU registers are only going to be used if the code specifically is processor-optimized.   Go and read some of John Carmack's old posts and see how much hand-tooled voodoo had to be done to accomplish the 3D rendering.  Not to mention the fact that the article was written in 2005.  Does anyone really see a 20-40% performance benefit on a Audio/HardwareSynth project just by moving to 64-bit Sonar (not Windows, Sonar)?

Best,

guitardood

CakeAlexS


Er guitar dood with all due respect you seem to think you are the only developer here. I own a copy of visual studio too and my degree is in computer science. That doesn't make me a know it all or qualify me to judge what you know or do not know. Nothing I said was incorrect in my last statement. You merely expanded it but again neglected to mention that actually some operations and subroutines (not just registers etc) are specifically optimized for 64 bit code. In a lot of instances some of the assembled code can be far more efficient. 64 bit compilers are different to 32 bit compilers. End of.

Wrong sir!

First, my comment was directed at your statement that "64-bit compilers are different than 32-bit compilers".  This implication that 64-bit code is generated with a different compiler than the 32-bit is a patently false statement.  Most modern compilers have switches that turn on certain optimizations depending on the mode, but is not separate compilers for the different modes.


Secondly, being a casual or even advanced programmer in Visual Studio does not necessarily equate to intimate knowledge of the CPU's machine language, in which all compiled languages eventually get translated.  One of my original classes in computer science (1981) entailed the instructor giving us a cardboard CPU simulator.  It had a sliding piece of cardboard for the accumulator, a sliding piece of cardboard for the register and yet another sliding piece of cardboard for the stack.  Our task was essentially to "be the one-operations-per-minute CPU" and execute the machine language instructions, in binary I might add.  Most of my classmates at the time could not even get past the binary math and the decimal-to-binary conversions let alone understand pushing and popping (EDIT) a stack.  One of my first professional projects entailed writing assembly language interfaces between the high-level Informix 4GL (which compiled to 'C', which compiled to assembler, which compiled to machine code) and Allen-Bradley PLCs (ladder-logic) for a Westinghouse Job Costing system we were developing.  So when it comes to CPU logic and machine code, I'm quite versed.  Not necessarily a know-it-all, but definitely a have-forgotten-more-than-some-will-ever-know.  But, I digress.

To further illustrate my point, here's an example for you:
Note: all created with a single version of the GNU C compiler, specifically: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1  This is pretty much the compiler being used on 85% of the non-Microsoft platforms and about 98% of non-Microsoft embedded systems.


helloworld.c

#include <stdio.h>
char *main(int argc,char *argv[])
{
   printf("Hello World\n");
}

Here's the 23-line i386 (32-bit) Assembler that the C compiler creates:
helloworld_i386.s

      .section        __TEXT,__text,regular,pure_instructions
      .globl        _main
      .align        4, 0x90
_main:
      pushl        %ebp
      movl        %esp, %ebp
      subl        $8, %esp
      call        L1$pb
L1$pb:
      popl        %eax
      leal        L_.str-L1$pb(%eax), %eax
      movl        %eax, (%esp)
      call        _puts
      addl        $8, %esp
      popl        %ebp
      ret

      .section        __TEXT,__cstring,cstring_literals
L_.str:
      .asciz         "Hello World"


.subsections_via_symbols

Here's the 69-line x86_64 (64-bit) Assembler source:
helloworld_x86_64.s

      .section        __TEXT,__text,regular,pure_instructions
      .globl        _main
      .align        4, 0x90
_main:
Leh_func_begin1:
      pushq        %rbp
Ltmp0:
      movq        %rsp, %rbp
Ltmp1:
      leaq        L_.str(%rip), %rdi
      popq        %rbp
      jmp        _puts  # TAILCALL
Leh_func_end1:

      .section        __TEXT,__cstring,cstring_literals
L_.str:
      .asciz         "Hello World"

      .section        __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame0:
Lsection_eh_frame:
Leh_frame_common:
Lset0 = Leh_frame_common_end-Leh_frame_common_begin
      .long        Lset0
Leh_frame_common_begin:
      .long        0
      .byte        1
      .asciz         "zR"
      .byte        1
      .byte        120
      .byte        16
      .byte        1
      .byte        16
      .byte        12
      .byte        7
      .byte        8
      .byte        144
      .byte        1
      .align        3
Leh_frame_common_end:
      .globl        _main.eh
_main.eh:
Lset1 = Leh_frame_end1-Leh_frame_begin1
      .long        Lset1
Leh_frame_begin1:
Lset2 = Leh_frame_begin1-Leh_frame_common
      .long        Lset2
Ltmp2:
      .quad        Leh_func_begin1-Ltmp2
Lset3 = Leh_func_end1-Leh_func_begin1
      .quad        Lset3
      .byte        0
      .byte        4
Lset4 = Ltmp0-Leh_func_begin1
      .long        Lset4
      .byte        14
      .byte        16
      .byte        134
      .byte        2
      .byte        4
Lset5 = Ltmp1-Ltmp0
      .long        Lset5
      .byte        13
      .byte        6
      .align        3
Leh_frame_end1:


.subsections_via_symbols

Perhaps you could share how the 69-line 64-bit assembler code is more optimized than the 23-line 32-bit code, because I certainly don't see it.  The binary versions had a difference of 44 bytes, with the 64-bit version being the larger at 8688 bytes.

Upon runtime, the only performance gains I was able to see were in the the runtime dynamic linker able to load the code 0.012 seconds faster on the x86_64 bit.

I'm sure that a more complex program would benefit, however, that benefit is overshadowed by the instability of using another program in every fx-chain (bit-bridge) for 90% of my plugins(fx which are mostly still 32-bit) as opposed to using jbridge for 10% of my plugins(soft-synths, which btw can easily be frozen and/or converted to audio eliminating the necessity for having the soft-synth active throughout the entire mixing process.  This is for my system.  If you're happy with the status-quo, more power to ya.

And btw, you could have made your point without the personal attacks.  I don't think I'm the only programmer here and only called you on your false statement which you made in such an authoritative posture.

Best,


EDIT: for anyone interested, here is the wikipedia page for the CARDIAC (http://en.wikipedia.org/wiki/CARDboard_Illustrative_Aid_to_Computation) cardboard computer which actually has 4 slides.  I forgot about the memory cells.

The performance analysis of these two examples is flawed. The size of the text of the two assembly programs does not relate in any way to run time performance. In fact, the executable instruction count of the 32-bit version is 11, while the instruction count of the 64-bit one is 5, so at first glance, the 64-bit one would seem to be more optimized. Also note that a special "TAILCALL" technique has been applied to the puts() call, saving some instructions after puts() is done. Is that a feature of the CPU instruction set or the compiler and libraries? Also hard to tell about absolute count of memory fetches (even a 32-bit program can use a 64-bit wide data path.) Also, looks like the 64-bit version has more built-in debug or linking information, unrelated to run-time performance. Both are optimized by not calling printf() at all but recognizing that puts() can be called directly. For a final point, that was not a Microsoft compiler and can't be used to guess at relative performance of Visual Studio-built programs.
 
Setting the above examples aside: generally, a cpu in 64-bit mode has some more registers available and some additional instructions. Whether an arbitrary program can be compiled to use those to good effect is unknown until you see how the compiler has been designed. Also my guess is that running 32-bit plugins in a 64-bit DAW is less efficient (as well as sometimes more troublesome) than 32-32. In any case, any serious debate about this ought to be backed up by reproducible measurements, not code size or instruction count.
 
Bill B.

 The only real difference between the posted example, is that the 64 bit version uses opcodes that work on 64 bits, and the 32 bit version on 32 bits for example:

lea - is "Load Effective Address" ,which loads an address into a register.

the 32 bit version uses leal, which is the "long" or 32 bit version.
the 64 bit version uses leaq, which is the "quad" or 64 bit version (q = quad word or 4 x 16 bit words).


So other than some some-and-mirrors (inclusion of debug data in one example but not the other only serves to confuse average forum members), there is *no* real difference between the two that can be used to imply any kind of performance benefit.

Also realize that besides 64/32 bit:
- There are several command extensions (SSE for example) that can be leveraged by a compiler, if that extension is available on the processor the code is running on.
- There are manufacturer specific tweaks (Intel vs AMD).
- There are Compiler and library performance tweaks (intel vs microsoft vs gnu).
- There are third party libraries that can affect performance as well (SmartHeap for example)

So arguing performance benefits is dubious at best. We do not know what optimizations are used by Cakewalk, if there are hand-written optimizations, what additional libraries Cakewalk used, and how much of the code base contains code rot (old code thats been there for awhile and has been buried under repeated enhancements, making it inefficient, and a maintenance liability).

The one universal truth about 64 bit code is that it can access a larger address space, which on windows means less swapping of memory regions to the hard disk.

js516

The one universal truth about 64 bit code is that it can access a larger address space, which on windows means less swapping of memory regions to the hard disk.

So, pretty much after all of this ... we've come back to the fundamental fact that the only measurable benefit of 64-bit is being able to access more RAM which is what we all knew already.

Sweet.


Thanks.


LOL!

Sorry, I seem to have stumbled into the wrong thread... where is the door? OH... OK...

I see it...

I always thought Mario 64 was a pretty sweet upgrade from the previous 8 and 16 bit versions....lol

> So, pretty much after all of this ... we've come back to the fundamental fact that the only measurable benefit of 64-bit is being able to access more RAM which is what we all knew already.

Yeap, its like dirt track racing. The more you go around, the dirtier you get. (Dang it lost the quote. got too much mud on my monitor.. lol)
Trivia: How many entendres can you count? }B>

Bub

js516

The one universal truth about 64 bit code is that it can access a larger address space, which on windows means less swapping of memory regions to the hard disk.

So, pretty much after all of this ... we've come back to the fundamental fact that the only measurable benefit of 64-bit is being able to access more RAM which is what we all knew already.

Sweet.


Thanks.


LOL!

@bub: Thanks for some sanity, Bub.  I was beginning to feel like Oliver Douglas in Hooterville....LOL!!

@js516:  You other points (though maybe still debatable) notwithstanding, thanks for reading all that was posted and getting my whole point.

@bvideo: As with js516, I could still debate the issue.  But thanks for understanding what I was trying to get across.



Best,