redbarchetta

guitardood

redbarchetta


@guitardude
Correct me if I'm wrong but isn't part of the alure of 64 bit vs 32 bit the ability to move more data more quickly.  Like for fetch operations and what not?

I'm a software developer myself but not a bit twiddler. As said, I didn't like my assembly classes.  Closest I'd ever want to go there again is "C"

I'm sure that's part of it, though with all the caching being done on-die I think the real significant reason for 64-bit is the ability to access more in-memory data.  IMHO, in a streaming app such as Sonar, you could have a 256-bit CPU/OS/Compiler  and it will still stream at whatever speed the disks could provide data.  It's a bit different for the sampling soft-synths which utilize large memory buffers (BFD,Kontakt,Machfive, et al) to load as many samples in ram as possible, primarily to cut down on latency.


Best,

 
How much memory can Sonar utilize?  Also, have you ran sonar with a SSD? Wondering what kind of performance enhancements you'd get with one of those.

sharke


Good God the sight of assembly language makes me aroused. Well maybe that's a bit of an exaggeration - it does make me semi-pleased though. 

John


Ah who writes in machine language? That separates the men from the boys. Me I took a look at assembly once and nearly had a stroke. 

I liked PC BASIC.  

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.

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.

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!

chuckebaby


i thought it also made applications run faster.
im not sure if this thread helps.
http://superuser.com/questions/9112/other-benefits-of-64-bit-os-apart-from-memory-expansion