|
Hello,
a 3rd party supplier informs me their components are compiled for "ANY CPU", so they'll run x86 or x64 based on the platform to which they're deployed. This confuses me a bit; I had thought a select choice of x64 compilation would ensure the best performance, which is why so many companies these days deliver product-installers for both x86 and x64. But if I'm to take his word for good measure, there's no need (at least .net-wise) to ever compile to a specific CPU architecture, as the "ANY CPU" option will always ensure the assemblies run as fast as possible, given the host CPU?
Hope someone might be able to clarify on this,
thanks in advance,
Morten
|
|
|
|
|
The Any CPU option is not optimised for a specific processor. It will give you good general all round performance that works across any of the target processors. If you absolutely must have all the performance you want then target the appropriate processor.
[ADDITIONAL]
First Addition::
There seems to be a lot of confusion about this. MSDN says one thing. The C# compiler command line help says another.
Second Addition:
See Guffa's post as he links to an article that explains exactly what is happening, and contradicts the MSDN article I used as the source of my original answer.
[/ADDITIONAL]
modified on Friday, January 9, 2009 1:24 PM
|
|
|
|
|
Hello Colin,
this was also my impression. Thanks a lot for clearing this up for me.
best,
Morten
|
|
|
|
|
harleydk wrote: Hello Colin,
this was also my impression. Thanks a lot for clearing this up for me.
Then your impression was also wrong.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Colin Angus Mackay wrote: It will give you good general all round performance that works across any of the target processors. If you absolutely must have all the performance you want then target the appropriate processor.
That is not correct. The IL code generated is the same regardless of which CPU target you specify.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
|
I saw that one. It doesn't go ino any depth, and I don't think that it's correct. Have a look at this, for example:
Visual Studio .NET Platform Target Explained[^]
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
The IL code in your assembly isn't specific to any processor at all. Regardless of what CPU target you choose, the IL code could still be used on any processor. The CPU target is simply information that the code should only be allowed to be used on a specific type of CPU.
You can use the CPU target for example to specify that your assembly only can be used in x86 mode as you are calling methods in an unmanaged x86-dll.
It's the JIT compiler that creates the machine code from the IL code when your assembly is loaded. It can create different code depending on the actual processor that will run the code, so that it will take advantage of the capabilities or that specific processor.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: The IL code in your assembly isn't specific to any processor at all.
That was also my thought until the OP asked the question and it got me thinking. I then looked at MSDN and this article suggests (although not explicitly to do with the IL output) otherwise: http://msdn.microsoft.com/en-us/library/5b4eyb0k.aspx[^]
|
|
|
|
|
c:\> csc /?
...
/platform:<string>
Limit which platforms this code can run on: x86, Itanium, x64, or anycpu. The default is anycpu.
</string>
It has nothing to do with optimization.
As usual, MSDN is wrong.
|
|
|
|
|
nice one:[^]
- the title is "How to: Optimize an Application for a Specific CPU Type"
- for C# the page says "Choose a CPU type from the Platform target list. The options are ..."
- and Guffa rightfully says "The IL code in your assembly isn't specific to any processor at all"
So the page not only fails to tell you how to decide on the right platform, it also leads you to believe that by choosing you would be optimizing the application. The whole page is crap 
|
|
|
|
|
Yes, very confusing. It even got me and I should have known better. 
|
|
|
|
|
harleydk wrote: I had thought a select choice of x64 compilation would ensure the best performance
Wrong. Selecting x64 does NOT give the best performance. This only forces the code to work on a 64-bit processor using the 64-bit .NET Framework. This also give you coding options that are specific to 64-bit. Performance really has nothing to do with it.
|
|
|
|
|
Thank you, everyone, for your insight on this issue.
Can I ask you, now, how I should go about optimizing my code for x64 processors? Any links you would recommend would be much appreciated.
Many thanks,
Morten
|
|
|
|
|
Hello.
I am new development of dvd player. Any good material to start with. and Some sample codes too.
Thanks.
"C makes it easy to shoot yourself in the foot. C++ makes it
harder, but when you do, it blows away your whole leg."
- Bjarne Stroustrup
|
|
|
|
|
Wow are you in over your head.
|
|
|
|
|
I am sorry, my bad.
What I meant was:
I am new to the software development of dvd player for windows. I need some basic tutorials and resources to start with.
Thanks.
|
|
|
|
|
|
Hello guys,
As I said in the subject line, the goal is to deploy a console application to another machine without Visual studio 2008 installed on that machine. It does have 2005 installed on it though.
Questions:
1- Do I need to install the Framework 3.5 on this machine for the console app to work?
2- I'm not sure what steps should be taken to accomplish this deployment (provided that I install the framework). In other words the Bin directory of this folder contains consoleApp.vsHost.exe.manifest (type: manifest file), consoleApp.vsHost (type: Application), ConsoleApp (type: Application).
3- Should I just copy over these files and a few other DLLs that are being referenced from this console application over to the other machine and be able to run the executible from there?
4- when I right click, and look at the properties of the console application project, i see quite a few options (in VS 2008) Is the publish option relavent to this deployment? Especially the publish location and install Mode and settings options?
Thank you all so much in advance for your help 
Tina
|
|
|
|
|
1 - Yes, if it uses 3.5
2 - See 3
3 - You can, and I do it that way, but it depends on other factors
4 - That's another way to do it, which maybe I should do, but don't
|
|
|
|
|
Tina P wrote: 1- Do I need to install the Framework 3.5 on this machine for the console app to work?
Yes
Tina P wrote: 2- I'm not sure what steps should be taken to accomplish this deployment (provided that I install the framework). In other words the Bin directory of this folder contains consoleApp.vsHost.exe.manifest (type: manifest file), consoleApp.vsHost (type: Application), ConsoleApp (type: Application).
Just Take all files of Bin folder to destination machine
Tina P wrote: 3- Should I just copy over these files and a few other DLLs that are being referenced from this console application over to the other machine and be able to run the executible from there?
You do not require source files on client computer
Tina P wrote: 4- when I right click, and look at the properties of the console application project, i see quite a few options (in VS 2008) Is the publish option relavent to this deployment? Especially the publish location and install Mode and settings options?
I don't know
|
|
|
|
|
Please dont crosspost, however see my answer in the other forum.
|
|
|
|
|
in my app i've apicture box and when clicked on that i want to show that this picturebox is clicked by changing the color of the border, how can i do it?
|
|
|
|
|
Sadly enough, this control does not expose a border color, even for classes inheriting from it. Your only choice is to draw it yourself, you can for example create a class that inherits from the PictureBox and override the OnClick (or just handle it) to paint the border, it can be something like that:
public class PictureBoxEx
: PictureBox
{
protected override void OnClick(EventArgs e)
{
base.OnClick(e);
Pen pen = new Pen(Color.Red);
this.CreateGraphics().DrawRectangle(pen, base.ClientRectangle);
}
}
This code is not entirely correct, the base.ClientRectangle rectangle is inside the real border but I'll leave it to you to compute the correct coordinates.
The disadvantage of this approach is that it is not done in the "Paint event" of the control, so any redraw (caused if you ALT-TAB or just move something over it, like another window) will cause the control to redraw itself and your border will disappear. I don't know what you really want, if the idea is that it should STAY colored after the click, then override the OnClick and trigger the OnPaint after having set a boolean or so to indicate the clicked state; in the OnPaint, check this boolean and draw the border if the "clicked" state check is positive.
Another disadvantage, but this was really quick code to show the idea, is that I am using a Graphics object that I create myself. In the OnPaint handler, you should use the provided Graphics object from the eventArgs, otherwise you loose Double-Buffering.
Jean-Christophe Grégoire
|
|
|
|
|
hi.........
im developing driver lock project. i could not find the code in c#.net, could u do and sent me the source code and project.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
