Is C# suitable for artificial intelligent systems?
-
Kobby Kan wrote:
Does the .NET framework make it relatively difficult for practical implementation and slow?
What is it with people who complain that .NET is slow? I recently saw a presentation called "Writing Crap Code in C# - Anti-patterns for performance" and the presenter showed various examples of crap code and how they were hurting performance. In some cases people actually thought the slow version should be the best performing until he showed them the numbers. So, if your C# (or any .NET code) is slow then perhaps you might want to look at your own coding style before bitching on .NET.
Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) - (part 3) My website | Blog
Colin Angus Mackay wrote:
What is it with people who complain that .NET is slow?
Because it's true? :~ By definition, managed code must be slower than native code - assuming both code bases may utilize optimizations. Granted, .NET apps are quite a lot faster than the comparative java applications, but it's not as fast as a well written Win32 app.
-
It's too bad you didn't ask for VB. The responses would have been hysterical.
Software Zen:
delete this;
Fold With Us![^]Homer Simpson style AI would probably be doable in VB. Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh! Doh!
-
Interestingly in every online debate about any subject someone always brings up a rare edge condition case and uses it to cast FUD on an assertion, but in fact 99.95% of us are *not* writing sql server or guided missle control software or a game engine so while there is generally a grain of truth on all sides I still think the majority of developers won't find their .net app to be any slower than their unmanaged app. :) Here's some further proof: Jeff atwoods very concise summary: http://www.codinghorror.com/blog/archives/000299.html[^] A meta link to the overall description of the process: http://blogs.msdn.com/jonathanh/archive/2005/05/20/optimizing-managed-c-vs-native-c-code.aspx[^]
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
Thanks for restating my post. Actually given the "average" developer, their managed app would probably be faster then their unmanaged app, and about a million times more stable. :laugh: All, I'm saying is that just because John C doesn't have a need for something, doesn't mean that everyone doesn't have a need for something. I just tried to back it up with some real world examples where custom memory management can make a significant difference. Maybe I miss some of the moments I had in the past where I optimized something then sat back going holly crap was it really that fast. Anyway, as far as performance goes, it's pretty simple. Figure out what you need before you start developing and test along the way, which is exactly what Rico recommends.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Colin Angus Mackay wrote:
What is it with people who complain that .NET is slow?
Because it's true? :~ By definition, managed code must be slower than native code - assuming both code bases may utilize optimizations. Granted, .NET apps are quite a lot faster than the comparative java applications, but it's not as fast as a well written Win32 app.
Jörgen Sigvardsson wrote:
Because it's true?
Amen.
Jörgen Sigvardsson wrote:
Granted, .NET apps are quite a lot faster than the comparative java applications
I haven't seen any difference between Java and .NET. Both are slow and both consume memory like crazy.
-
Jörgen Sigvardsson wrote:
Because it's true?
Amen.
Jörgen Sigvardsson wrote:
Granted, .NET apps are quite a lot faster than the comparative java applications
I haven't seen any difference between Java and .NET. Both are slow and both consume memory like crazy.
Nemanja Trifunovic wrote:
I haven't seen any difference between Java and .NET. Both are slow and both consume memory like crazy.
I might be singling out a specific case: GUI. .NET GUIs feel more responsive than Java GUIs. On the other hand, .NET doesn't have the cross platform baggage as Java does.
-
How well does C# cope for artificial intelligent systems like image and speech recognition? Does the .NET framework make it relatively difficult for practical implementation and slow? :confused::confused::confused:
Kobby Kan wrote:
How well does C# cope for artificial intelligent systems like image and speech recognition?
Don't know about speech recognition, but I used to work with machine translation a lot, and all our prototypes with C# (and Java for that matter) showed that it is not a good language for the task - not so much because of the speed, but because of memory consumption.
-
Colin Angus Mackay wrote:
What is it with people who complain that .NET is slow?
Because it's true? :~ By definition, managed code must be slower than native code - assuming both code bases may utilize optimizations. Granted, .NET apps are quite a lot faster than the comparative java applications, but it's not as fast as a well written Win32 app.
>>managed code must be slower than native code Its not like we are dealing with old interpreted bytecode. The jitter outputs native code. If you go C style in C# with lookup arrays and all that stuff, then you get pretty nice speed. Just take a look at #ziplib, its extremely fast. (if you look at the implementation you will see that its not very .NET'ish, pretty much only working with arrays and oldschool tricks)
-
>>managed code must be slower than native code Its not like we are dealing with old interpreted bytecode. The jitter outputs native code. If you go C style in C# with lookup arrays and all that stuff, then you get pretty nice speed. Just take a look at #ziplib, its extremely fast. (if you look at the implementation you will see that its not very .NET'ish, pretty much only working with arrays and oldschool tricks)
Reiterations of .NET/Java/et al may be faster than their predecessors, but they won't produce code as fast as native code.
-
Thanks for restating my post. Actually given the "average" developer, their managed app would probably be faster then their unmanaged app, and about a million times more stable. :laugh: All, I'm saying is that just because John C doesn't have a need for something, doesn't mean that everyone doesn't have a need for something. I just tried to back it up with some real world examples where custom memory management can make a significant difference. Maybe I miss some of the moments I had in the past where I optimized something then sat back going holly crap was it really that fast. Anyway, as far as performance goes, it's pretty simple. Figure out what you need before you start developing and test along the way, which is exactly what Rico recommends.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
Yup, I agree. Somehow the way I state things seems to trigger this response in people. :) Probably because I tend to skip ahead rather than connecting all the points to get to the inevitable conclusion anyway. Drives my wife crazy, she's a serial thinker, I'm a random access thinker. Makes for a good combination most of the time. I fully understand that the edge conditions are out there, just not terribly relevant for a general purpose programming site such as this one and they tend to bring the discourse to a grinding halt for no useful purpose.
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
-
Colin Angus Mackay wrote:
What is it with people who complain that .NET is slow?
Because it's true? :~ By definition, managed code must be slower than native code - assuming both code bases may utilize optimizations. Granted, .NET apps are quite a lot faster than the comparative java applications, but it's not as fast as a well written Win32 app.
I disagree entirely from a practical perspective. In all ways that matter in the real world, performance is entirely due to the quality of the design and the developer who implements it and is entirely unrelated to the platform it runs on or language it was written in.
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
-
Yup, I agree. Somehow the way I state things seems to trigger this response in people. :) Probably because I tend to skip ahead rather than connecting all the points to get to the inevitable conclusion anyway. Drives my wife crazy, she's a serial thinker, I'm a random access thinker. Makes for a good combination most of the time. I fully understand that the edge conditions are out there, just not terribly relevant for a general purpose programming site such as this one and they tend to bring the discourse to a grinding halt for no useful purpose.
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
Though, for purposes of this discussion, AI might be one of those edge cases, though I doubt there will be any practical difference between a fast AI engine and a slow AI engine. ;P So far I think Chris has had the best response, get off your butt and try both of them and see. I kinda had that somewhere in my reply to the OP, but it got lost in my rambling, which is something that drives my wife batty.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Though, for purposes of this discussion, AI might be one of those edge cases, though I doubt there will be any practical difference between a fast AI engine and a slow AI engine. ;P So far I think Chris has had the best response, get off your butt and try both of them and see. I kinda had that somewhere in my reply to the OP, but it got lost in my rambling, which is something that drives my wife batty.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
Yeah, AI is definitely an edge case but if it were me I'd approach it by looking for good AI libraries with .net interfaces to tie the whole thing together into a real world application. My days of writing the framework are definitely behind me, all my interest is in the end result. I used to be fascinated by that stuff but I guess I'm just not an engineer at heart, I want to change the world, not write the tools that others use to change the world.
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
-
Reiterations of .NET/Java/et al may be faster than their predecessors, but they won't produce code as fast as native code.
Just because it is "not as fast" doesnt mean that is slow. Languages like Ruby are slow.. C# is doing pretty damn good considering all the safety belts and training wheels that the managed environment offers.
-
Colin Angus Mackay wrote:
What is it with people who complain that .NET is slow?
Because it's true? :~ By definition, managed code must be slower than native code - assuming both code bases may utilize optimizations. Granted, .NET apps are quite a lot faster than the comparative java applications, but it's not as fast as a well written Win32 app.
Jörgen Sigvardsson wrote:
but it's not as fast as a well written Win32 app.
i think that's john's point ... that most "programmers" couldn't write a well designed and implemented win32 app if their lives depended on it ... the whole idea of frameworks was that the really good people can write stuff that the not necessarily so good people can use to get useful work done ... not optimized win32 c++ apps
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
I wish I could remember where I found it but someone did some quite extensive testing on .NET performance and in some crucial areas it was actually faster than C++ because of the JIT inlining. I think he left the defaults on for "optimisation". Of course if everything was optimised by hand then C++ would be faster but then what's the point, why not just write assembly? :rolleyes:
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
Ed.Poore wrote:
Of course if everything was optimised by hand then C++ would be faster but then what's the point, why not just write assembly?
Sometimes it does make sense to use assembly. Having said that, assembly is too un-portable for most scenarios; well optimized C(++) code compiles to very good machine code on many different hardware platforms - assembly often needs to be re-written.
-
Just because it is "not as fast" doesnt mean that is slow. Languages like Ruby are slow.. C# is doing pretty damn good considering all the safety belts and training wheels that the managed environment offers.
don't even go there with ruby!! i had a guy write a data processing app to crunch 1.8Gb of csv data into a database with special data clean-up and image processing in the mix ... and he used RoR ... and when i asked him how it was going he said (and i quote): "it's been running for 2 days now and should be finished in another 8 or 9" :wtf:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
How well does C# cope for artificial intelligent systems like image and speech recognition? Does the .NET framework make it relatively difficult for practical implementation and slow? :confused::confused::confused:
Kobby Kan wrote:
How well does C# cope for artificial intelligent systems like image and speech recognition?
That depends on if you stay inside or outside of the framework. Generally speaking, as long as you stay within the framework's preconstructed functionality (in other words someone has laid all the ground work for you already) C# is reasonably good. As long as you avoid R&D type work, where you are laying the ground work of new and innovative concepts. And even then, as long as you do not mind it taking 10 times longer C# may still be good enough. The question is more what you need to get out of it, and how much has already been laid for you. If the groundwork is all in the frame work and all you have to do is assemble the pieces, go for it!
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
Though, for purposes of this discussion, AI might be one of those edge cases, though I doubt there will be any practical difference between a fast AI engine and a slow AI engine. ;P So far I think Chris has had the best response, get off your butt and try both of them and see. I kinda had that somewhere in my reply to the OP, but it got lost in my rambling, which is something that drives my wife batty.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
Andy Brummer wrote:
though I doubt there will be any practical difference between a fast AI engine and a slow AI engine. [Poke tongue]
I guess that depends on if you are going head-to-head against a real person in a game or if the AI decision is helping a soldier get his job done. Neither of those two are really good at waiting for an outcome.
Andy Brummer wrote:
So far I think Chris has had the best response, get off your butt and try both of them and see.
I actually agree, but I think practically it doesn't apply to most people. I would not recommend writing an SQL client in C++, nor would I recommend writing a real-time navigation system for an unmanned craft or a game engine in C#. Though the latter is getting closer, the problem is "edge" to be in the gaming community as a big name game, you want an edge. That edge tends to be R&D from normal compression to terrain texture blending methods, R&D kills C# because it does not fit the framework concept (everyone does things the same way). If every game was programmed exactly the same way, no edge, we would have a lot of mediocre games, and no really good ones. Luckily frameworks apply to multiple languages because you can have the best of both worlds, you can apply frameworks/API's like DirectX9 & OpenGL to handle core technologies, you can go higher up the chain with gaming systems, Delta3D, or Open Scene Graph, or an engine sold by another gaming company. It all depends on how much edge you want. ID makes their own engine, because they like to keep the edge. Others do the same. Others will build on someone else's technology by buying those engines, they know they will not get the 'extras' the 'edge' ID saves for their own games, but they can benefit from reduced programming by letting someone else make the underlying framework they build their games upon. There is room in this world for all of us last I checked. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
Yeah, AI is definitely an edge case but if it were me I'd approach it by looking for good AI libraries with .net interfaces to tie the whole thing together into a real world application. My days of writing the framework are definitely behind me, all my interest is in the end result. I used to be fascinated by that stuff but I guess I'm just not an engineer at heart, I want to change the world, not write the tools that others use to change the world.
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
John C wrote:
I want to change the world
We have that in common, I like to shake the world up a lot. Sometimes a bit too literally. :laugh: okay, I like the pyrotechnics.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
don't even go there with ruby!! i had a guy write a data processing app to crunch 1.8Gb of csv data into a database with special data clean-up and image processing in the mix ... and he used RoR ... and when i asked him how it was going he said (and i quote): "it's been running for 2 days now and should be finished in another 8 or 9" :wtf:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
hehehe, we have a java fan at work, all areas have their furry animals.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."