Is C# a JOKE? [modified]
-
Hi All! I have to write my own app to make a living. I am not an IT pro, or anything close to it. I do have a 32 bit app that is absoultely better than anyone else's. So I want to port my 32 bit app to 64 to stay ahead of the competition. So I go out and shell out big bucks for that 64 bit compiler. So I hear all this stuff about C# being the "language of the future". So I believe it. So I re-write the entire thing in C#. Now I have a 64 bit dog that runs 40% slower than my 32 bit app. Now I am pissed. So I go to the C# forums for some advice. No one helps. I get chastised. Now I have come to the conclusion that Bill Gates and all C# touts need their faces slapped. Rant Over bigchump edit: some expletives were "deleted".
modified on Thursday, June 12, 2008 5:20 PM
-
Hi All! I have to write my own app to make a living. I am not an IT pro, or anything close to it. I do have a 32 bit app that is absoultely better than anyone else's. So I want to port my 32 bit app to 64 to stay ahead of the competition. So I go out and shell out big bucks for that 64 bit compiler. So I hear all this stuff about C# being the "language of the future". So I believe it. So I re-write the entire thing in C#. Now I have a 64 bit dog that runs 40% slower than my 32 bit app. Now I am pissed. So I go to the C# forums for some advice. No one helps. I get chastised. Now I have come to the conclusion that Bill Gates and all C# touts need their faces slapped. Rant Over bigchump edit: some expletives were "deleted".
modified on Thursday, June 12, 2008 5:20 PM
C# is almost identical to C++, except that C# is the official NET Framework language. Microsoft is trying to promote the NET Framework in a huge way, which is why you read that kind of thing (language of the future). And with programmers, the NET Framework is not very popular, for a number of reasons, speed being mentioned alot. The fundamental problem is that the NET Framework, still interops most of its functionality through the underlying Win32 APIs, and in the process, creates greater dependency, in addition to alot more conditional code jumps. Still, it's an improvement over COM in a number of aspects (like metadata uniquely identifying each assembly and type, garbage collection and memory allocation).
-
C# is almost identical to C++, except that C# is the official NET Framework language. Microsoft is trying to promote the NET Framework in a huge way, which is why you read that kind of thing (language of the future). And with programmers, the NET Framework is not very popular, for a number of reasons, speed being mentioned alot. The fundamental problem is that the NET Framework, still interops most of its functionality through the underlying Win32 APIs, and in the process, creates greater dependency, in addition to alot more conditional code jumps. Still, it's an improvement over COM in a number of aspects (like metadata uniquely identifying each assembly and type, garbage collection and memory allocation).
Baltoro wrote:
C# is almost identical to C++, except that C# is the official NET Framework language. Microsoft is trying to promote the NET Framework in a huge way, which is why you read that kind of thing (language of the future). And with programmers, the NET Framework is not very popular, for a number of reasons, speed being mentioned alot. The fundamental problem is that the NET Framework, still interops most of its functionality through the underlying Win32 APIs, and in the process, creates greater dependency, in addition to alot more conditional code jumps. Still, it's an improvement over COM in a number of aspects (like metadata uniquely identifying each assembly and type, garbage collection and memory allocation).
Thanx Baltoro for responding! I'll boil my problem down into a nutshell: With C/C++ writing a struct to file was easy. Now, I have to use "serialization" which causes datafiles to become HUGE with overblown overhead. My question is really simple: Can I use native c++ and compile to 64 bits???????? That would be a major fix if possible.... Thanx in advance bigchump
-
Baltoro wrote:
C# is almost identical to C++, except that C# is the official NET Framework language. Microsoft is trying to promote the NET Framework in a huge way, which is why you read that kind of thing (language of the future). And with programmers, the NET Framework is not very popular, for a number of reasons, speed being mentioned alot. The fundamental problem is that the NET Framework, still interops most of its functionality through the underlying Win32 APIs, and in the process, creates greater dependency, in addition to alot more conditional code jumps. Still, it's an improvement over COM in a number of aspects (like metadata uniquely identifying each assembly and type, garbage collection and memory allocation).
Thanx Baltoro for responding! I'll boil my problem down into a nutshell: With C/C++ writing a struct to file was easy. Now, I have to use "serialization" which causes datafiles to become HUGE with overblown overhead. My question is really simple: Can I use native c++ and compile to 64 bits???????? That would be a major fix if possible.... Thanx in advance bigchump
I actually didn't know the answer to your question, so I searched over at MSDN, and found this: 64-bit Programming with Visual C++[^] If I was writing a 64-bit application, I'd probably want to have several versions (both C++ and NET Framework, for compatibility reasons). But, I have absolutely no experience doing this, and typically, my initial concepts often turn out to be completely wrong once I've actually gone through the process. I hope you have a sense of humor about this.
-
Baltoro wrote:
C# is almost identical to C++, except that C# is the official NET Framework language. Microsoft is trying to promote the NET Framework in a huge way, which is why you read that kind of thing (language of the future). And with programmers, the NET Framework is not very popular, for a number of reasons, speed being mentioned alot. The fundamental problem is that the NET Framework, still interops most of its functionality through the underlying Win32 APIs, and in the process, creates greater dependency, in addition to alot more conditional code jumps. Still, it's an improvement over COM in a number of aspects (like metadata uniquely identifying each assembly and type, garbage collection and memory allocation).
Thanx Baltoro for responding! I'll boil my problem down into a nutshell: With C/C++ writing a struct to file was easy. Now, I have to use "serialization" which causes datafiles to become HUGE with overblown overhead. My question is really simple: Can I use native c++ and compile to 64 bits???????? That would be a major fix if possible.... Thanx in advance bigchump
bigchump, I've posted some suggestions in the c# forum regarding your problem, so I don't want to talk about that here. What I'm interested in is why you seem to think 64 bit applications should automatically run faster? Firstly, being 64 bit does not mean faster. a 64 bit app means all your number variables (ints/longs) are twice the size (ints become 64 bits large, longs become 128 bits), so they take up more space. More importantly, all pointers to objects become 64 bits long, so also take up more space. This could mean a potential slow down, as there are lots of hidden issues here related to processing 64 bit pointers. As I understand it, your app is processing a bunch of data. There is a good chance that on a 64 bit system, this is taking up extra space so can't all fit in memory at one time. This means that the data will be swapped out of memory to the disk. This is a huge time cost. You can investigate this by using a tool such as ProcessExplorer from SysInternals[^]. Try looking at the amount of memory your app is using, and more importantly, the number of page faults that occur during the main processing phase of the app. Compare this to your old c++ version. The primary reason to switch to 64 bit is that it allows you to address a much larger amount of memory. 32 bit systems are limited to 4GB. 64 bit on the other hand can access 17.2 billion gigabytes. This is of most use on high end database servers. 64 bit does not on it's own give a speed improvement. If anything, switching to 64 bit (using native c++) and not doing anything else is likely to hurt performance. Finally, real pure 64 bit apps will not run on 32 bit operating systems (not even if you have an 64 bit CPU, the actual operating system must be 64 bit. This means you need windows XP x64 or Vista 64). C# code set to compile to "any cpu" is actually a special case that can change and run as 32 or 64 bit depending on the operating system it is being run on. This is a common misunderstanding. Can you confirm exactly what operating system and compiler settings you are using for your 64 bit app?
Simon
-
Hi All! I have to write my own app to make a living. I am not an IT pro, or anything close to it. I do have a 32 bit app that is absoultely better than anyone else's. So I want to port my 32 bit app to 64 to stay ahead of the competition. So I go out and shell out big bucks for that 64 bit compiler. So I hear all this stuff about C# being the "language of the future". So I believe it. So I re-write the entire thing in C#. Now I have a 64 bit dog that runs 40% slower than my 32 bit app. Now I am pissed. So I go to the C# forums for some advice. No one helps. I get chastised. Now I have come to the conclusion that Bill Gates and all C# touts need their faces slapped. Rant Over bigchump edit: some expletives were "deleted".
modified on Thursday, June 12, 2008 5:20 PM
C# is generally slower than C++ but there are techniques for speeding it up. For example, 1. C# does safety checks that you can skip by running sections in unsafe mode. For example if you're doing an operation on every element of an array, C# will check the array bounds on EVERY array access unless you do it in unsafe mode. 2. When you combine value items and reference items, C# will do "boxing" to convert the value item to a reference item, which is very slow. Avoid this. 3. You can speed up a critical section of your C# by writing a C++ DLL to do it, and calling it from C#. 4. XML serialization in C# is easy, but the SOAP format is insane. It's many times larger than it has to be, and the XML generated is unintelligible. Using a custom format that writes out just the data you need will be faster and more compact. 5. If you're processing bitmaps, look at LockBits to get the bitmap data to work on, which is faster than getpixel/setpixel.
-
C# is generally slower than C++ but there are techniques for speeding it up. For example, 1. C# does safety checks that you can skip by running sections in unsafe mode. For example if you're doing an operation on every element of an array, C# will check the array bounds on EVERY array access unless you do it in unsafe mode. 2. When you combine value items and reference items, C# will do "boxing" to convert the value item to a reference item, which is very slow. Avoid this. 3. You can speed up a critical section of your C# by writing a C++ DLL to do it, and calling it from C#. 4. XML serialization in C# is easy, but the SOAP format is insane. It's many times larger than it has to be, and the XML generated is unintelligible. Using a custom format that writes out just the data you need will be faster and more compact. 5. If you're processing bitmaps, look at LockBits to get the bitmap data to work on, which is faster than getpixel/setpixel.
Hi Alan! My o/s is Vista 64 Ultimate w/ 8 gigs mem. I have an identical machine (both are Velocity Micro hotrods) with Vista 32 Ultimate and 4 gigs. I also have two other machines with XP home. To load and display a 22meg file takes at least 17 seconds on the 32 bit puters and only 6.4 seconds on the 64. So, for my purposes 64 is much faster even though the 32 bit apps are written in C with some assy. and the 64 is written in C#. I have ported all my apps to 64 bit C# and all except the one in question have performance gains. Using binary serialization to write classes to disk causes the file to become 16x larger than it should be. I THINK YOU SOLVED MY PROBLEM: write a c++ dll to do file reads/writes. I've never written a dll so I'm sure I'll have some fun with that. I could use some tips on writing and calling a c++ dll from a C# program. Thanx again Alan! I would have never figured out the problem on my own.
-
Hi Alan! My o/s is Vista 64 Ultimate w/ 8 gigs mem. I have an identical machine (both are Velocity Micro hotrods) with Vista 32 Ultimate and 4 gigs. I also have two other machines with XP home. To load and display a 22meg file takes at least 17 seconds on the 32 bit puters and only 6.4 seconds on the 64. So, for my purposes 64 is much faster even though the 32 bit apps are written in C with some assy. and the 64 is written in C#. I have ported all my apps to 64 bit C# and all except the one in question have performance gains. Using binary serialization to write classes to disk causes the file to become 16x larger than it should be. I THINK YOU SOLVED MY PROBLEM: write a c++ dll to do file reads/writes. I've never written a dll so I'm sure I'll have some fun with that. I could use some tips on writing and calling a c++ dll from a C# program. Thanx again Alan! I would have never figured out the problem on my own.
To create a C++ DLL, create a C++ project and choose Win32 Project as the type (Microsoft probably decided a type named "DLL" would make it too easy), click Next, and select DLL as the application type. Put the following attribute before your C++ functions so they can be seen from C#: __declspec(dllexport) To call a function in a C++ DLL from C#, first declare it like this: [DllImport("User32.dll")] public extern static int GetScrollInfo( IntPtr hWnd, int fnBar, IntPtr lpsi ); There's lots of info on the web on doing this. Good luck.
-
To create a C++ DLL, create a C++ project and choose Win32 Project as the type (Microsoft probably decided a type named "DLL" would make it too easy), click Next, and select DLL as the application type. Put the following attribute before your C++ functions so they can be seen from C#: __declspec(dllexport) To call a function in a C++ DLL from C#, first declare it like this: [DllImport("User32.dll")] public extern static int GetScrollInfo( IntPtr hWnd, int fnBar, IntPtr lpsi ); There's lots of info on the web on doing this. Good luck.
-
Hi Alan! Let me thank you again. The only question I have left is about this Win32 thing. Does that mean my dll will run @32 bits (or does it even matter)? thanx bigchump
It means it's a standard Windows application, as opposed to MFC or .NET. I've never tried to run one on a 64-bit platform, but it seems like it would have to work to maintain backward compatibility.