The C# programmer will likely be more productive (wont be spending 30% of his time chasing down pointer bugs and memory leaks) and that will leave him more time to optimise what needs to be optimised.
As an example, a top-notch C# programmer and a top-notch C++ programmer both read a new tutorial on a new method of terrain rendering - after T=10 hours of programming time, who is more likely to have the faster rendering demonstration? How about T=100 hours? T=1000?
Clearly as T increases the more efficient language as far as code generation will start to shine - but the most important factor for programmers is not necessarily the end result after an infinite number of coding hours but instead is based on how many hours they can reasonable expect to be able to devote to the problem.
They (should) want the fastest code given a specific number of design hours. If they have an inexhaustable amount of time to throw at the problem then they are at the end trying all sorts of silly tricks that just might shave a clock off some loop here or there.. having a seperate routine for P4''s, P3''s, Athlons, and so forth..
My point being that I believe the C# programmer will get to this stage of micro-optimisation sooner than the C++ programmer and if the C++ programmer cannot reasonably devote the time necessary to get to the micro-optimisation stage then he is worse off than the C# programmer.
As for me.. I code in VB and Assembler.. so hey.. maybe I know all about the importance of time-to-completion.
C# is not Fast! Re: Today's Earlier Benchmark
quote:Original post by Anonymous Poster
The C# programmer will likely be more productive (wont be spending 30% of his time chasing down pointer bugs and memory leaks) and that will leave him more time to optimise what needs to be optimised.
As an example, a top-notch C# programmer and a top-notch C++ programmer both read a new tutorial on a new method of terrain rendering - after T=10 hours of programming time, who is more likely to have the faster rendering demonstration? How about T=100 hours? T=1000?
Clearly as T increases the more efficient language as far as code generation will start to shine - but the most important factor for programmers is not necessarily the end result after an infinite number of coding hours but instead is based on how many hours they can reasonable expect to be able to devote to the problem.
They (should) want the fastest code given a specific number of design hours. If they have an inexhaustable amount of time to throw at the problem then they are at the end trying all sorts of silly tricks that just might shave a clock off some loop here or there.. having a seperate routine for P4''s, P3''s, Athlons, and so forth..
My point being that I believe the C# programmer will get to this stage of micro-optimisation sooner than the C++ programmer and if the C++ programmer cannot reasonably devote the time necessary to get to the micro-optimisation stage then he is worse off than the C# programmer.
As for me.. I code in VB and Assembler.. so hey.. maybe I know all about the importance of time-to-completion.
Ahahahhahahahahahahah!
You make good points, but I love how insecure people are in here. It almost makes me want to troll more.
quote:Original post by Raghar
Would you like more replies without grammar errors and with factual errors, or with grammar errors and without factual errors? You can't have all you know.
False dilemma that does nothing to help your arguments.
Meta-post: Why do C# threads always attract more misinformation, anyway?
[edited by - antareus on April 17, 2004 5:58:26 PM]
quote:Original post by antareus
Meta-post: Why do C# threads always attract more misinformation, anyway?
I think that many people do not understand really what .NET is and what C# is and how they fit together. I constantly see people calling .NET a language alternative to the Java programming language, see people interchanging C# and .NET like they were the same, etc.
Author
I have published my perlin noise texture generator on my webpage here - the new version that uses a C++ DLL and the old version that is pure #C.
My contention is that nobody will be able make the C# version run as fast as the C++ DLL. Even if you rip out all the nice C# features and use unsafe code with pointers everywhere, you won''t be able to do it. Even if you could, you''ve just completely subverted all of the nice managed structure of C# and you might as well have used C++ in the first place.
So to any of you who seem to think I don''t know what I''m talking about, either put up or shut up. Show me the code.
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Shedletsky''s Code Library:
Open source projects and demos
My contention is that nobody will be able make the C# version run as fast as the C++ DLL. Even if you rip out all the nice C# features and use unsafe code with pointers everywhere, you won''t be able to do it. Even if you could, you''ve just completely subverted all of the nice managed structure of C# and you might as well have used C++ in the first place.
So to any of you who seem to think I don''t know what I''m talking about, either put up or shut up. Show me the code.
----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------
Shedletsky''s Code Library:
Open source projects and demos
Your code is just math... It will surely be as fast in C# as in C++. It will probabaly run about as fast in Java too.
I decided to take a look at your code.... I didn''t spend too much time with it but I did notice in your GetColor Method you have your ColorPt(structure/value type) stored in an ArrayList. This would result in a lot of boxing/unboxing.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
