.NET Performance
-
Joey Bloggs wrote: For those of you who are convinced that .NET and CLR will outperform C++ with a P3/P4 optimizing compiler I don't think it could ever do that but it could get in the 90% efficiency range.. You give up performance for added features. John
Well as a windows developer for 13 years and a java developer for the last 3. I can almost guarentee that they will not be able to hit that sort of performance level. I doubt that they will get the CLR much faster than the JVM. And beyond that heap based instantiation of 'every' object and no placment new etc almost guarentees that you cannot write faster code.
-
Well as a windows developer for 13 years and a java developer for the last 3. I can almost guarentee that they will not be able to hit that sort of performance level. I doubt that they will get the CLR much faster than the JVM. And beyond that heap based instantiation of 'every' object and no placment new etc almost guarentees that you cannot write faster code.
Joey Bloggs wrote: I doubt that they will get the CLR much faster than the JVM. They already have. One of the ways they do it is to only JIT compile the parts of the assembly that you use, and not the parts you don't.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Joey Bloggs wrote: I do not know That's obvious... Joey Bloggs wrote: But instead they are trying to move everyone into a proprietry managed environment where they can licence .net server products for big bucks Maybe that's the cause they call Microsoft a company??? I don't know, but if you bother selling something, than it maybe you're on the wrong site... just ranting a little back...
Olli "Ooooooh, they have the internet on computers now!"
Homer Simpson
:beer: + :java: = NULL :=> X|Yes but they are being very underhanded in the way they are trying to move everyone to .net and not stating their real intentions. When you hold a worldwide monopolistic power social responsibility and democratic public policy must come into play.
-
Joey Bloggs wrote: I doubt that they will get the CLR much faster than the JVM. They already have. One of the ways they do it is to only JIT compile the parts of the assembly that you use, and not the parts you don't.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiGo to the kitchen right now. Hurry there is not much time left!
-
Go to the kitchen right now. Hurry there is not much time left!
Time left for what??? ;P ;P ;P So, instead of answering to what I said in the post, you gave a low blow. :rolleyes:
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Look, If you're not (and do not plan on) selling your services to a company that has bought into the MS line and will happily pay for all the new toys you desire, then i'd say it's rather unwise for you to be using MS tech. There's better, lower-cost stuff out there for many purposes. For those of us feeding on the MS teat, your rantings sound more like sour grapes. Either have fun doing what makes you the $$$, or find something else to do - such criticism is only useful if you follow it with: "and so this is what i'm going to do personally to correct this terrible problem."
Shog9
Let your mercy spill / On all these burning hearts in hell If it be your will / To make us well...
I am concerned at the long term costs to OUR societies. The lost opportunites the increased taxes and product costs that will flow from having a worldwide monopolistic power lead a large segment of the planets developers into such a proprietry solution. As to a response, I feel powerless against the beast. The open source communities are making small steps but I wonder if it will be enough.
-
I am concerned at the long term costs to OUR societies. The lost opportunites the increased taxes and product costs that will flow from having a worldwide monopolistic power lead a large segment of the planets developers into such a proprietry solution. As to a response, I feel powerless against the beast. The open source communities are making small steps but I wonder if it will be enough.
-
For those of you who are convinced that .NET and CLR will outperform C++ with a P3/P4 optimizing compiler please go into the kitchen now and fashion a helmet out of aluminium foil. The microsoft marketing / brainwashing / indoctrination signals being beamed from the satelltes are obviously too strong in your area. Will .NET reduce programmer effort / time to market / life cycle maintenence costs ? I do not know. What I do know is that if ms had developed all the appropriate libraries in open source c++ along with a new compiler. We would all be better of. But instead they are trying to move everyone into a proprietry managed environment where they can licence .net server products for big bucks just like sun and their J2EE / JMS vendors. just having a little rant
Joey Bloggs wrote: What I do know is that if ms had developed all the appropriate libraries in open source c++ along with a new compiler. We would all be better of. I don't understand, how this can improve performance? Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer
-
Joey Bloggs wrote: What I do know is that if ms had developed all the appropriate libraries in open source c++ along with a new compiler. We would all be better of. I don't understand, how this can improve performance? Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer
Open VC6 go to Project, Settings, C/C++, Code Generation and see what is the lastest processor that you can optimize for. Plus various other comments in this thread about heap based object instantiation etc. We won't even get into gc impacts on performance but do you really think letting the machine figure out what memory your using instead of telling it is going to improve performance.
-
But what about Mono and SharpDevelop? BTW, Do you use VC++?
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiI'm not so worried about the development environments. Its the .NET Server products that will be sold to every customer needing to run large .net solutions that are going to cost the big bucks. since v1.1 or 1.2 i can't quite remember
-
I'm not so worried about the development environments. Its the .NET Server products that will be sold to every customer needing to run large .net solutions that are going to cost the big bucks. since v1.1 or 1.2 i can't quite remember
-
But will they have to use those, or can alternative be made?
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiI really don't know. Is the CLR rated to run efficently on a multiprocessor 64bit XP platform for example and will it come with the OS or will you have to licence it seperately ?
-
Open VC6 go to Project, Settings, C/C++, Code Generation and see what is the lastest processor that you can optimize for. Plus various other comments in this thread about heap based object instantiation etc. We won't even get into gc impacts on performance but do you really think letting the machine figure out what memory your using instead of telling it is going to improve performance.
I actually was talking about "open source", that can improve performance. Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer
-
I really don't know. Is the CLR rated to run efficently on a multiprocessor 64bit XP platform for example and will it come with the OS or will you have to licence it seperately ?
The .NET Framework for 64-bit platforms is free. Also, you can run the same assembly in both 64-bit and 32-bit environments without re-compiling, provided that you don't have any unsafe code in that assembly (which could be wrapped in a seperate DLL as necessary). BTW, Joey, I don't intend to hurt your feelings or cause excessive strife between us. I have a different viewpoint, but let me know if something I say hurts your feelings. :rose:
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
jdunlap wrote: NET will out-perform native code, because of its optimizations. Do you know if .NET will make use of MMX, SIMD ...?? Also I was thinking one of the things that can really slow some algorithms written in C is float to int conversions. C states it must truncate, but the hardware rounds by default so the compiler has to remove the rounding effect and also add out of bounds checking. In a bilinear interpolation algorithm I used a couple of asm statements to do the conversion and it speeded up the algorithm by more than 10 times the original code speed... I really needed that because the images were taking several seconds to scale (they were over 30MB) and that was too long for the user to wait to view them... John
I find it hard to believe that the CLR will be able to analyze your vb.net or c# source code and determine the algorithim you are trying to implement and call the appropriate simd mmx instructions etc. However you are certainly able to call un/managed C++ functions from those environments and presumably you can still put asm code into your MC++ / C++ function ?
-
I find it hard to believe that the CLR will be able to analyze your vb.net or c# source code and determine the algorithim you are trying to implement and call the appropriate simd mmx instructions etc. However you are certainly able to call un/managed C++ functions from those environments and presumably you can still put asm code into your MC++ / C++ function ?
However moving your data between the managed and unmanaged environments may take quite a performance hit, if you need to access it piecemeal it both environments ?
-
I actually was talking about "open source", that can improve performance. Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer
Well only in the sense that a variety of different people over time might be able to contribute optimizations I guess.
-
The .NET Framework for 64-bit platforms is free. Also, you can run the same assembly in both 64-bit and 32-bit environments without re-compiling, provided that you don't have any unsafe code in that assembly (which could be wrapped in a seperate DLL as necessary). BTW, Joey, I don't intend to hurt your feelings or cause excessive strife between us. I have a different viewpoint, but let me know if something I say hurts your feelings. :rose:
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiNo problems, this has filled a spare hour up nicely. I just hope that it doesn't get out of control when all our american friends wakeup.
-
For those of you who are convinced that .NET and CLR will outperform C++ with a P3/P4 optimizing compiler please go into the kitchen now and fashion a helmet out of aluminium foil. The microsoft marketing / brainwashing / indoctrination signals being beamed from the satelltes are obviously too strong in your area. Will .NET reduce programmer effort / time to market / life cycle maintenence costs ? I do not know. What I do know is that if ms had developed all the appropriate libraries in open source c++ along with a new compiler. We would all be better of. But instead they are trying to move everyone into a proprietry managed environment where they can licence .net server products for big bucks just like sun and their J2EE / JMS vendors. just having a little rant
Regarding .NET performance, we are too much in the early phase I am afraid. The CLR is changing fast, and by reading a few CLR horse weblogs, I can tell they are trying their best to push the envelope. JIT compilers will be better and better in the future, and if they can really take advantage of the processor, then you'll end up with better native code in the end. I believe that regarding JIT compilers, we are not quite there yet, but then why wouldn't you start your own business and sell a JIT compiler? With a static C/C++ compiler, you end up distributing as many versions as processors you target. And, more to the point, are you sure that compiler significantly takes advantage of MMX instructions, etc. all by itself? Haven't we a chicken and egg issue here? Plus, dedicated Intel compilers[^] versus MS compilers. I believe that the fight against monopoly is somewhere else, and more about the licensing, OEM (key apps like the web browser). It's really another debate.
-
Regarding .NET performance, we are too much in the early phase I am afraid. The CLR is changing fast, and by reading a few CLR horse weblogs, I can tell they are trying their best to push the envelope. JIT compilers will be better and better in the future, and if they can really take advantage of the processor, then you'll end up with better native code in the end. I believe that regarding JIT compilers, we are not quite there yet, but then why wouldn't you start your own business and sell a JIT compiler? With a static C/C++ compiler, you end up distributing as many versions as processors you target. And, more to the point, are you sure that compiler significantly takes advantage of MMX instructions, etc. all by itself? Haven't we a chicken and egg issue here? Plus, dedicated Intel compilers[^] versus MS compilers. I believe that the fight against monopoly is somewhere else, and more about the licensing, OEM (key apps like the web browser). It's really another debate.
Are there not compilers that will produce optimized code for a variety of targets and branch to the appropriate chunk at runtime having identified which target the code is running on ? Its been so long since i've looked at this kind of stuff. I agree with you on the mmx simd issues, its hard to see the CLR taking advantage of them all by itself. Sure .NET is only part of the strategy but I suspect its a bigger part than you are proposing.