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

[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

 

[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]

 

[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

 

[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]

 

[Cor Ligthert [MVP]]

Michel,

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

Right and not only litary.



Cor

 

[Pieter]

Thanks for the input guys

Michel,

Right and not only litary.



Cor

 

[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

 

[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...

 

[Jim Wooley]

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

 

[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]

 

[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


| 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
|
|

 

[Alan Pretre]

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

 

[Norman Diamond]

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 ^_^

 

[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


| message |
| > 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 ^_^
|