.NET Performance
-
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.
-
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
-
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.
Joey Bloggs wrote: and branch to the appropriate chunk at runtime having identified which target the code is running on I am not aware of that. What I know is that there are opportunities for Mono-based JIT compilers for instance. Joey Bloggs wrote: I suspect its (strategy) a bigger part than you are proposing What has made me furious lately is the rate at which they are retiring : - the older SDKs/DDKs/..., read: the non .NET SDKs - the documentation and archive (MSJ and a couple of online papers are still available, but how long will this last?) - and the fact they fill the MSDN library with 100% .NET stuff In other words, if you have old MSDN CDs, you are a lucky guy and had better keep them. Of course, they have been doing all this silently. MS has the right to do so, and invoke the immense amount of storage and maintenance cost needed to keep all of this running. But I don't buy this. Customer satisfaction is against retiring software that fast, especially when you know that almost everyone is using their tools (C/C++) to compile code on the Windows platform. Regarding the .NET picture, as long as the .NET run-time is free, available to everyone ; as long as MS doesn't force developers to certify the apps they are willing to distribute ; as long as MS enforces upward compatibility (in all VS.NET releases, MS has not given a shit about backward compatibility) across the product upgrades, I believe we have a platform to rely on. But then, if this wouldn't hold true any longer, the platform might well fall under itself.
-
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
Hmm, you cannot possibly tell me that going the J2EE route will actually be cheaper. Are you talking IBM, Sun and Oracle or should we be running enterprises on LAMP? It sounds more to me that you just have a problem with Microsoft. It's better that you flat out admit that rather than diss a platform that's pretty damn good at what it does for the most part. I'm also curious as to what platform you develop for day to day and what your feelings are about it :-) What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
-
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: For those of you who are convinced that .NET and CLR will outperform C++ with a P3/P4 optimizing compiler I don't think anyone would belive that would be the case. Sounds like your connfused. Joey Bloggs wrote: Will .NET reduce programmer effort / time to market / life cycle maintenence costs ? I do not know. Well I'm betting it will. 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 just like sun and their J2EE / JMS vendors. Whats the problem - its an open standard. Have you not heard of Mono, Rotor or DotGNU? Have a look at these. These are free, and unlike Sun with JBoss, Microsoft is not trying to stiffle copies - thats why the put out Rotor as a reference implementation for pepople to see how it works and bring other vendors faster to market. Sounds like you need to get your facts straight. http://www.southern-storm.com.au/portable_net.html[^] http://www.dotgnu.org/[^] http://www.go-mono.org/[^] 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. Yeh, for C++ programmers. Not for every one else. I want to be able to cleanly interface some of my Perl code with C# and C++, and .NET allows you to do that.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
-
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
Joey Bloggs wrote: 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. What on earth are you talking about. They are incredibly cheap compared to say databases such as Oracle. Have you actually looked at the prices, and the overall cost to a business when you take into account things like peoples salaries which are for most service companies that largest cost by far. I was at a company recenty where the just embared on 14 million dollar development project, though they final production environment will probably use a couple of 4 processor boxes, with Windows. The actual physical machines being much more expensive that OS. The cost is tiny compared to the investment to develop the main system.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
-
Hmm, you cannot possibly tell me that going the J2EE route will actually be cheaper. Are you talking IBM, Sun and Oracle or should we be running enterprises on LAMP? It sounds more to me that you just have a problem with Microsoft. It's better that you flat out admit that rather than diss a platform that's pretty damn good at what it does for the most part. I'm also curious as to what platform you develop for day to day and what your feelings are about it :-) What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
Senkwe Chanda wrote: Hmm, you cannot possibly tell me that going the J2EE route will actually be cheaper. Are you talking IBM, Sun and Oracle or should we be running enterprises on LAMP? Maybe maybe not. Do we know what the unlimited licence for .NET Server 2003 2005 etc is / will be ? Do we know what the J2EE vendors response to .NET uptake will be in terms of lowering their pricing ? 25 Years ago when we had to pay Per CPU / Per User licencing fees for proprietry os's (with compulsory annual maintenance fees) running on proprietry hardware (with compulsory annual maintenance fees) where we happy. Why are we letting Sun and Microsoft take us back into the dark past. Senkwe Chanda wrote: It sounds more to me that you just have a problem with Microsoft. It's better that you flat out admit that rather than diss a platform that's pretty damn good at what it does for the most part. I have some issues with Microsoft just as I have some issues with Sun neither are particularly honest in their dealings with the developer community IMHO. Beyond that I have bigger picture issues with monopolistic powers in a globalized world. I have not raised any of these, I am simply having a general discussion on what i regard as unrealistic perceptions / expectations of .NET Senkwe Chanda wrote: I'm also curious as to what platform you develop for day to day and what your feelings are about it win16 / win32 / MFC forever. Java for the last 3 years and now i'm starting into .NET Software is Software, i'm a complete software atheist.
-
Senkwe Chanda wrote: Hmm, you cannot possibly tell me that going the J2EE route will actually be cheaper. Are you talking IBM, Sun and Oracle or should we be running enterprises on LAMP? Maybe maybe not. Do we know what the unlimited licence for .NET Server 2003 2005 etc is / will be ? Do we know what the J2EE vendors response to .NET uptake will be in terms of lowering their pricing ? 25 Years ago when we had to pay Per CPU / Per User licencing fees for proprietry os's (with compulsory annual maintenance fees) running on proprietry hardware (with compulsory annual maintenance fees) where we happy. Why are we letting Sun and Microsoft take us back into the dark past. Senkwe Chanda wrote: It sounds more to me that you just have a problem with Microsoft. It's better that you flat out admit that rather than diss a platform that's pretty damn good at what it does for the most part. I have some issues with Microsoft just as I have some issues with Sun neither are particularly honest in their dealings with the developer community IMHO. Beyond that I have bigger picture issues with monopolistic powers in a globalized world. I have not raised any of these, I am simply having a general discussion on what i regard as unrealistic perceptions / expectations of .NET Senkwe Chanda wrote: I'm also curious as to what platform you develop for day to day and what your feelings are about it win16 / win32 / MFC forever. Java for the last 3 years and now i'm starting into .NET Software is Software, i'm a complete software atheist.
Joey Bloggs wrote: I am simply having a general discussion on what i regard as unrealistic perceptions / expectations of .NET :-) I understand. Hopefully if you hang around here a while longer we can lure you over to the dark side. Sounds like it'll take some time, but it'll happen. *evil laugh as he wrings his hands* :) What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
-
Joey Bloggs wrote: 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. What on earth are you talking about. They are incredibly cheap compared to say databases such as Oracle. Have you actually looked at the prices, and the overall cost to a business when you take into account things like peoples salaries which are for most service companies that largest cost by far. I was at a company recenty where the just embared on 14 million dollar development project, though they final production environment will probably use a couple of 4 processor boxes, with Windows. The actual physical machines being much more expensive that OS. The cost is tiny compared to the investment to develop the main system.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
I live in a society where they are constantly trying to increase the taxes I have to pay, find new ways to tax me and still apparently we can not afford to employ sufficent teachers, doctors, nurses, policeman etc. Repair our hospitals etc. Every dollar counts! Oracle and Microsoft have a comfy little duopoly for windows databases (and look what happens to the price). IBM /DB2 etc don't seem to be able to penetrate for some reason ? I imagine that many companies will not embark on expensive inhouse custom developments in the future, they will buy commoditized systems and integrate / adapt them. Software once the development costs have been amortized is essentially free to replicate. It is unlike virtually any other industry on earth. Monopolistic software companies should be forced to limit their margins. 80% is just obscene.
-
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 anyone would belive that would be the case. Sounds like your connfused. Joey Bloggs wrote: Will .NET reduce programmer effort / time to market / life cycle maintenence costs ? I do not know. Well I'm betting it will. 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 just like sun and their J2EE / JMS vendors. Whats the problem - its an open standard. Have you not heard of Mono, Rotor or DotGNU? Have a look at these. These are free, and unlike Sun with JBoss, Microsoft is not trying to stiffle copies - thats why the put out Rotor as a reference implementation for pepople to see how it works and bring other vendors faster to market. Sounds like you need to get your facts straight. http://www.southern-storm.com.au/portable_net.html[^] http://www.dotgnu.org/[^] http://www.go-mono.org/[^] 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. Yeh, for C++ programmers. Not for every one else. I want to be able to cleanly interface some of my Perl code with C# and C++, and .NET allows you to do that.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
Giles wrote: I don't think anyone would belive that would be the case. Sounds like your connfused. I'm not confused. Its other people that i'm worried about. See earlier responses in the thread. Giles wrote: Whats the problem - its an open standard. Have you not heard of Mono, Rotor or DotGNU? Have a look at these. These are free, and unlike Sun with JBoss, Microsoft is not trying to stiffle copies - thats why the put out Rotor as a reference implementation for pepople to see how it works and bring other vendors faster to market. Sounds like you need to get your facts straight Yes they get a few brownie points for this and even score one over sun. I wonder if these orginizations will have the resources to keep up when microsoft change the CLR to support the .net framework v2.x or 3.x Giles wrote: Yeh, for C++ programmers. Not for every one else. I want to be able to cleanly interface some of my Perl code with C# and C++, and .NET allows you to do that. Couldn't COM Interop have wrapped COM wrappers of the C++ libraries and provided a solution for everyone ?
-
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 can almost guarentee that they will not be able to hit that sort of performance level. Why? The .NET CLR is nothing like the Java JVM. Java bytecode is compiled whenever it is used. The .NET CLR precompiles the code and saves it on disk to use next time. There's no reason why it can't get extremely close to straight compiled code. And just in case you're wondering, no, I'm not a big fan of .NET for other reasons. I'm learning C# at the moment, but I don't envisage using it as my main language. I much prefer standard C++.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
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 ?
Joey Bloggs wrote: 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. Read a book on advanced compiler design. You might be surprised to know that they actually do this quite effectively. They don't determine the algorithm as such, but they do certainly use the advanced instructions as appropriate. Compilers (particularly code optimisers) are incredibly difficult things to write, but they are incredibly good at what they do.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Joey Bloggs wrote: I can almost guarentee that they will not be able to hit that sort of performance level. Why? The .NET CLR is nothing like the Java JVM. Java bytecode is compiled whenever it is used. The .NET CLR precompiles the code and saves it on disk to use next time. There's no reason why it can't get extremely close to straight compiled code. And just in case you're wondering, no, I'm not a big fan of .NET for other reasons. I'm learning C# at the moment, but I don't envisage using it as my main language. I much prefer standard C++.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
That is not necessarily the case. JVM's can and do keep and reuse compiled code if they have memory to do so. I am not aware of a JVM that saves code to disk though. I'm not sure it that is for security reasons ? Presumably code cached on disk could be altered by other code executing in the CLR. I wonder how long it will be before someone exploits some bug in the CLR to execute their malicious code off the disk ?
-
Joey Bloggs wrote: I can almost guarentee that they will not be able to hit that sort of performance level. Why? The .NET CLR is nothing like the Java JVM. Java bytecode is compiled whenever it is used. The .NET CLR precompiles the code and saves it on disk to use next time. There's no reason why it can't get extremely close to straight compiled code. And just in case you're wondering, no, I'm not a big fan of .NET for other reasons. I'm learning C# at the moment, but I don't envisage using it as my main language. I much prefer standard C++.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote: The .NET CLR precompiles the code and saves it on disk to use next time. MS haven't documented this one well... There's a tool called NGEN which you can run at install time, or on an MSIL binary, that will cache a JITted copy of the program in a system cache (located at %SystemRoot%\assembly\NativeImages1_v_runtime-version_). Many of the system class libraries are run through NGEN at installation time (for v1.1, this includes mscorlib.dll, System.dll, System.Design.dll, System.Drawing.dll, System.Drawing.Design.dll, System.Windows.Forms.dll and System.Xml.dll, plus some others for J# and VS.NET). However, your own code doesn't get cached - I believe that it has to be JITted for every process that uses that code, processes do not share the memory pages containing native code. One thing that does differ is that MS alleges that MSIL is closer to native code than Java bytecode (from now on, JBC). I think they're indicating that MSIL has a larger instruction set than JBC, which should lead to a closer mapping between MSIL and native code, hence reduced JIT time and potentially better performing generated code. At present, the VB.NET and C# compilers don't optimise the MSIL (e.g. constant folding, expression hoisting, tail recursion, dead code elimination) while the Managed C++ compiler (i.e. CL.EXE with the /clr switch) does. Personally I don't like reference languages, and I don't like non-deterministic destruction - I like to
deleteresources or have them go out of scope once I've finished with them. But I will admit it's harder than garbage collection - you have to be more disciplined. Having said that, not callingDispose(or using ausingblock in C#) can also cause you critical performance problems as finalization is costly. So you still have to be nearly as careful with .NET or other GC environments, IMO.