32-bit vs. 64-bit Windows
in [CSharp]
|
From: Tim Roberts on 13 Dec 2009 22:31 Tom Shelton <tom_shelton(a)comcastXXXXXXX.net> wrote: > >I would still do 64-bit. You can isolate the 32-bit dll in a suragate >process or a com wrapper. This would allow the majority of your application >to target 64-bit, but still make use of the 32-bit code. Why would you still do 64-bit? There's no performance advantage. Unless the application needs access to more than 2 GB of address space, there's really no advantage at all. Why go through the pain of proxies and surrogates, when there is a zero-cost solution available? -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Arne Vajhøj on 13 Dec 2009 22:54 On 13-12-2009 22:31, Tim Roberts wrote: > Tom Shelton<tom_shelton(a)comcastXXXXXXX.net> wrote: >> I would still do 64-bit. You can isolate the 32-bit dll in a suragate >> process or a com wrapper. This would allow the majority of your application >> to target 64-bit, but still make use of the 32-bit code. > > Why would you still do 64-bit? There's no performance advantage. Unless > the application needs access to more than 2 GB of address space, there's > really no advantage at all. Why go through the pain of proxies and > surrogates, when there is a zero-cost solution available? A few things actually do run faster in 64 bit mode (due to more registers, new FP register model etc.), but that is not important (and there is also the factor of larger data that tend to make things slower). The main argument should be that all code is migrating to 64 bit, so the two real options are: 1) get it working now 2) postpone the problem to later Of course one can hope to have better time for the work in the future, but Murphy's Law say otherwise. Arne
From: Eric on 14 Dec 2009 07:45
On Sun, 13 Dec 2009 22:54:44 -0500, Arne Vajh�j <arne(a)vajhoej.dk> wrote: >On 13-12-2009 22:31, Tim Roberts wrote: >> Tom Shelton<tom_shelton(a)comcastXXXXXXX.net> wrote: >>> I would still do 64-bit. You can isolate the 32-bit dll in a suragate >>> process or a com wrapper. This would allow the majority of your application >>> to target 64-bit, but still make use of the 32-bit code. >> >> Why would you still do 64-bit? There's no performance advantage. Unless >> the application needs access to more than 2 GB of address space, there's >> really no advantage at all. Why go through the pain of proxies and >> surrogates, when there is a zero-cost solution available? > >A few things actually do run faster in 64 bit mode (due to >more registers, new FP register model etc.), but that is not >important (and there is also the factor of larger data that >tend to make things slower). > >The main argument should be that all code is migrating to >64 bit, so the two real options are: >1) get it working now >2) postpone the problem to later > >Of course one can hope to have better time for the work >in the future, but Murphy's Law say otherwise. > >Arne If I had time, I'd install both to separate partitions, but by the time I install development tools and all, it would take days. It is tempting to play things safe and stay with 32-bit. All I really need from Windows7 at the moment is a platform for accessing Azure. It would be nice to run 64-bit...just cause that's where things are going. But surrogate processes and wrappers don't sound like much fun. |