|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
AMD/Dual-Core/64 bit: influence on compiled files? - Clients?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 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 > Michel,
> In my opinion is not only your own program from importance if you have a MP > 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 . > 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 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 > Michel,
> But knowing you i feel that we speak the same language ;-) Right and not only litary.> :-) CorThanks 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 > > 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 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 > "Pieter" <pietercou***@hotmail.com> wrote in message I may be wrong here, but I believe the IL generated by the compiler won't 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. 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 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 > 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. -- Show quoteHide quoteHope this helps Jay [MVP - Outlook] ..NET Application Architect, Enthusiast, & Evangelist T.S. Bradley - http://www.tsbradley.net "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 | | "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> wrote in Ditto - 2 GB made a world of difference over 1 GB for me.message news:uSMDoPQIGHA.3144@TK2MSFTNGP11.phx.gbl... > FWIW: I would recommend you maximize the ram on your new machine. -- Alan "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> wrote in That's because you misdesigned your errant programs. If you designed them 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% ;-) properly then they'd peg all available CPUs concurrently ^_^ Right now I'm having problems with VS 2005 itself "pegging" one of the
processors updating IntelliSense in a C++/CLI project. -- Show quoteHide quoteHope this helps Jay [MVP - Outlook] ..NET Application Architect, Enthusiast, & Evangelist T.S. Bradley - http://www.tsbradley.net "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 ^_^ |
Hepl! No accessible 'Main' method with an appropriate signature was found ...
Q: primary key OK....forget the code...how about some pointers? Multithreading Can I hide base class properties in a derived class? Problem with objects and automatic numbering in VB.NET executing a .dll? .NET 2.0 question ? Reading from the COM Port stopping a process |
|||||||||||||||||||||||