Home All Groups Group Topic Archive Search About

AMD/Dual-Core/64 bit: influence on compiled files? - Clients?

Author
23 Jan 2006 8:10 AM
Pieter
Hi,

Maybe a little bit off-topic, but it still seemd the best place to ask for
it :-)

I'm planning to buy a new development laptop, and I would like to buy an
AMD, Dual Core,-bit
But none of my clients has an AMD, most an Intel Pentium 3.
Will the fact that my applications will be compiled on an AMD, Dual Core,
64-bit have any influence on the prestations? I thought there was a way to
compile more effecient for a certain type of processor? I mostly develop in
VB.NET, sometimes C# (for C++ you needed soemthing special on a 64-bit I
thought?) I just want to be sure that I won't make my applications less
performant for the clients...
Does anybody has any experience with this?

Just an aditional question: Is Visual Studio .NET (2003 and 2005) itself
multi-threaded? Just to know if it will take advantage of the dual-core
processor?

thanks a lot in advance,

Pieter

Author
23 Jan 2006 8:47 AM
m.posseth
the answer to all is afaik  NO



I develop on a Acer 1524 WLMI on a 64 bit operating system

The framework will handle everything you mention  ,,,, the only thing you
should take care of is that if you compile specificly in X64 mode the
program will only run on 64 systems
if you compile with the anny cpu option the framework will switch to 64 bits
modus on a 64 bit capable system    ( this becomes a problem when you use MS
Access as a database for your app ,  as there are no 64 bit drivers for it
to work )

about the  multi threading  thingy ,,,, this always deserves special
attention most of the times the synching of threads on a SP system will only
drain the performance if you know for sure that all your customers have a MP
system it will be worthy to use it in more situations .

regards

Michel Posseth [MCP]


Show quoteHide quote
"Pieter" <pietercou***@hotmail.com> wrote in message
news:unwRES$HGHA.3064@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> Maybe a little bit off-topic, but it still seemd the best place to ask for
> it :-)
>
> I'm planning to buy a new development laptop, and I would like to buy an
> AMD, Dual Core,-bit
> But none of my clients has an AMD, most an Intel Pentium 3.
> Will the fact that my applications will be compiled on an AMD, Dual Core,
> 64-bit have any influence on the prestations? I thought there was a way to
> compile more effecient for a certain type of processor? I mostly develop
> in VB.NET, sometimes C# (for C++ you needed soemthing special on a 64-bit
> I thought?) I just want to be sure that I won't make my applications less
> performant for the clients...
> Does anybody has any experience with this?
>
> Just an aditional question: Is Visual Studio .NET (2003 and 2005) itself
> multi-threaded? Just to know if it will take advantage of the dual-core
> processor?
>
> thanks a lot in advance,
>
> Pieter
>
Author
23 Jan 2006 9:04 AM
Cor Ligthert [MVP]
Michel,

>
> about the  multi threading  thingy ,,,, this always deserves special
> attention most of the times the synching of threads on a SP system will
> only drain the performance if you know for sure that all your customers
> have a MP system it will be worthy to use it in more situations .
>
In my opinion is not only your own program from importance if you have a MP
system or not. There are so many processes in the NT environment, that the
OS is using the MP effectively.

However I agree, that because that this are mostly not the time spending
processes, is it not something you real see. My throughput hangs mostly
still forever on the Disk (I use a S-ATA drive).

While modern Microsoft OS's uses all a kind of time slicing, so
multithreading can be used effectively in the Idle time of other processes.

Just my though,

Cor
Author
23 Jan 2006 10:18 AM
m.posseth
Well Cor  ,


The meaning of my remark was that it should be tested in the situation of
his target audience

My personal experience is that a fully MP optimized program will perform
less good on a SP system
i am talking here about pure resource intensive applications ( like data
conversion  wich is a common action in my job )

If i write the same program  SP optimized it will run much faster , on the
MP system it will have the same performance as on the SP system


example  scenario :

hughe text files must be converted in several runs and then uploaded to a
web server

with a multi threading system i could run the conversion and whenever a file
is ready start a extra thread that uploads the finished file to the
webserver

with a SP system  i would first convert a  file and then upload it to the
server   ( you might even get better performance by converting all files an
sendig them all to the server in one run :-)  but that is a totall differnt
story .

If i design a app i will first run some scenario`s before i even start with
coding

But knowing you i feel that we speak the same language    ;-)

regards

Michel Posseth [MCP]




Show quoteHide quote
"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:eCzHsv$HGHA.3984@TK2MSFTNGP14.phx.gbl...
> Michel,
>
>>
>> about the  multi threading  thingy ,,,, this always deserves special
>> attention most of the times the synching of threads on a SP system will
>> only drain the performance if you know for sure that all your customers
>> have a MP system it will be worthy to use it in more situations .
>>
> In my opinion is not only your own program from importance if you have a
> MP system or not. There are so many processes in the NT environment, that
> the OS is using the MP effectively.
>
> However I agree, that because that this are mostly not the time spending
> processes, is it not something you real see. My throughput hangs mostly
> still forever on the Disk (I use a S-ATA drive).
>
> While modern Microsoft OS's uses all a kind of time slicing, so
> multithreading can be used effectively in the Idle time of other
> processes.
>
> Just my though,
>
> Cor
>
Author
23 Jan 2006 10:39 AM
Cor Ligthert [MVP]
Michel,

> But knowing you i feel that we speak the same language    ;-)
>
Right and not only litary.

:-)

Cor
Author
23 Jan 2006 1:03 PM
Pieter
Thanks for the input guys :-)

Show quoteHide quote
"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:ehtdClAIGHA.1676@TK2MSFTNGP09.phx.gbl...
> Michel,
>
>> But knowing you i feel that we speak the same language    ;-)
>>
> Right and not only litary.
>
> :-)
>
> Cor
>
>
Author
23 Jan 2006 1:29 PM
Cor Ligthert [MVP]
Pieter,

I think that you (from what I have the idea that you so seldom) should
recheck this thread. Maby Ken had something to add, as he has expiriences
with 64bit.

Cor
Author
23 Jan 2006 1:58 PM
Pieter
I always do recheck my thread (thanks to the glasses in outlook express,
hehe).
but indeed I do hope to have some more feedback of people that have
experiences with it...

Show quoteHide quote
"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:uFIlvDCIGHA.312@TK2MSFTNGP09.phx.gbl...
> Pieter,
>
> I think that you (from what I have the idea that you so seldom) should
> recheck this thread. Maby Ken had something to add, as he has expiriences
> with 64bit.
>
> Cor
>
Author
24 Jan 2006 1:35 AM
Jim Wooley
"Pieter" <pietercou***@hotmail.com> wrote in message
news:unwRES$HGHA.3064@TK2MSFTNGP10.phx.gbl...
> I'm planning to buy a new development laptop, and I would like to buy an
> AMD, Dual Core,-bit
> But none of my clients has an AMD, most an Intel Pentium 3.

I may be wrong here, but I believe the IL generated by the compiler won't
care about the 64 bit or dual core processor. The JIT will factor in these
hardware components and make the appropriate optomizations. Now if you ngen
the application on your dev box and deploy to the older P3 clients, i'm sure
the results will be quite different. Naturally, the dual core portion will
benefit more if your application actually takes advantage of the
multi-threading capabilities of .Net.

Jim Wooley
Author
24 Jan 2006 8:47 AM
m.posseth
Sorry but you are wrong :-)

see this assembly  header
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version
2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 1
ILONLY    : 1
32BIT     : 0
Signed    : 0

Important value is PE. It tells you whether this assembly is a 32-bit or
'any cpu' compiled assembly. If PE value should be 'PE32+' than you could
conclude that this is a 64-bit capable assembly.

The 32BIT property, contrary to its name, does not represent bitness of the
assembly. In this case, 32BIT property holds a value of 0, which would mean
that this is a 64-bit assembly. Actually this assembly can be run anywhere,
since it was compiled with agnostic setting of 'any cpu'.

This becomes a problem  when you use certain portions of the framework that
do not have a 64 bit equivalant   ( like oledb drivers for instance )

regards



Michel Posseth [MCP]







Show quoteHide quote
"Jim Wooley" <jwool***@bellsouth.net> wrote in message
news:Z7gBf.9949$SC1.6877@bignews3.bellsouth.net...
> "Pieter" <pietercou***@hotmail.com> wrote in message
> news:unwRES$HGHA.3064@TK2MSFTNGP10.phx.gbl...
>> I'm planning to buy a new development laptop, and I would like to buy an
>> AMD, Dual Core,-bit
>> But none of my clients has an AMD, most an Intel Pentium 3.
>
> I may be wrong here, but I believe the IL generated by the compiler won't
> care about the 64 bit or dual core processor. The JIT will factor in these
> hardware components and make the appropriate optomizations. Now if you
> ngen the application on your dev box and deploy to the older P3 clients,
> i'm sure the results will be quite different. Naturally, the dual core
> portion will benefit more if your application actually takes advantage of
> the multi-threading capabilities of .Net.
>
> Jim Wooley
>
Author
24 Jan 2006 4:33 PM
Jay B. Harlow [MVP - Outlook]
Pieter,
In addition to the other comments.

VS 2005 itself is 32-bit, it will run as a 32-bit process on 64-bit windows.

By default it creates assemblies that will run on either 32-bit or 64-bit
..NET, there is an option to instruct it to create 32-bit or 64-bit specific
assemblies.

I'm currently running a 32-bit hyper threaded 3GHz Pentium 4 w/2G of ram.

The biggest advantage I've found so far to DC/HT (dual core/hyper threaded)
development is the dev machine does not get pegged at 100% when I have an
errant program that goes into an endless loop. Only one of the "cpus" is
pegged at 100% ;-)

VB (2002, 2003 & 2005) does run a background compiler for intellisense &
syntax checking, so I'm sure DC/HT helps there...

FWIW: I would recommend you maximize the ram on your new machine.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


Show quoteHide quote
"Pieter" <pietercou***@hotmail.com> wrote in message
news:unwRES$HGHA.3064@TK2MSFTNGP10.phx.gbl...
| Hi,
|
| Maybe a little bit off-topic, but it still seemd the best place to ask for
| it :-)
|
| I'm planning to buy a new development laptop, and I would like to buy an
| AMD, Dual Core,-bit
| But none of my clients has an AMD, most an Intel Pentium 3.
| Will the fact that my applications will be compiled on an AMD, Dual Core,
| 64-bit have any influence on the prestations? I thought there was a way to
| compile more effecient for a certain type of processor? I mostly develop
in
| VB.NET, sometimes C# (for C++ you needed soemthing special on a 64-bit I
| thought?) I just want to be sure that I won't make my applications less
| performant for the clients...
| Does anybody has any experience with this?
|
| Just an aditional question: Is Visual Studio .NET (2003 and 2005) itself
| multi-threaded? Just to know if it will take advantage of the dual-core
| processor?
|
| thanks a lot in advance,
|
| Pieter
|
|
Author
24 Jan 2006 6:13 PM
Alan Pretre
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> wrote in
message news:uSMDoPQIGHA.3144@TK2MSFTNGP11.phx.gbl...
> FWIW: I would recommend you maximize the ram on your new machine.

Ditto - 2 GB made a world of difference over 1 GB for me.

-- Alan
Author
25 Jan 2006 12:07 AM
Norman Diamond
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> wrote in
message news:uSMDoPQIGHA.3144@TK2MSFTNGP11.phx.gbl...

> The biggest advantage I've found so far to DC/HT (dual core/hyper
> threaded) development is the dev machine does not get pegged at 100% when
> I have an errant program that goes into an endless loop. Only one of the
> "cpus" is pegged at 100% ;-)

That's because you misdesigned your errant programs.  If you designed them
properly then they'd peg all available CPUs concurrently  ^_^
Author
25 Jan 2006 1:37 AM
Jay B. Harlow [MVP - Outlook]
Right now I'm having problems with VS 2005 itself "pegging" one of the
processors updating IntelliSense in a C++/CLI project.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


Show quoteHide quote
"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:%23duvONUIGHA.532@TK2MSFTNGP15.phx.gbl...
| "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> wrote in
| message news:uSMDoPQIGHA.3144@TK2MSFTNGP11.phx.gbl...
|
| > The biggest advantage I've found so far to DC/HT (dual core/hyper
| > threaded) development is the dev machine does not get pegged at 100%
when
| > I have an errant program that goes into an endless loop. Only one of the
| > "cpus" is pegged at 100% ;-)
|
| That's because you misdesigned your errant programs.  If you designed them
| properly then they'd peg all available CPUs concurrently  ^_^
|