Is C# suitable for artificial intelligent systems?
-
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?
Consider the algorithms used for image and speech recognition. Then look at C#'s language features and ask yourself if they make it straightforward to implement those algorithms.
-
After all this time working with both managed and unmanaged and reading a lot on the subject I've come to the thinking that: a) I can write code as optimized as necessary in .net much more quickly and easily than in c++. b) I can write code that might ultimately run faster in c++ if I spend unreasonable amounts of time playing with it and optimizing it but the difference will not be perceptible or of interest to the end user and is thus a huge waste of time.
"The great pleasure in life is doing what people say you cannot do." - Walter Bagehot
That makes complete sense for the areas that you develop in, but you're stating them like they are general principles. Try running that by the guys that write SQL server for instance. They wrote their own thread scheduler because the OS one wasn't good enough for them. 99.95% of the time questions like the OP's are completely misguided but there is still some stuff out there that benefits from more control over memory management. Creating temporary heaps for things like parsing a document can give you some pretty large performance gains as you can essentially ignore memory management and drop the entire heap in one operation when you are done with that document. My C++ days are behind me, and I haven't even considered the need of doing anything like this for years and am very happy working with C#, but I have to admit that the Windows memory APIs gave you some really powerful options, even though the basic C++ new/delete operators were beyond awful for performance.
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
-
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:
Aside from real-time performance, I think you'll find the .NET framework more than adequate for your needs. I'm in the process of porting (from C++) a large rule-based system to .NET and haven't encountered any gotchas. If anything, the programming idioms that C# (and Java) provide make it easier to implement solutions in a more natural and elegant manner, imho. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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:
Why don't you prototype your system in C# and see if it can get it done. I don't mean to be flippant about it but there is no real way to answer your question without knowing the software requirements, deployment targets and, target hardware requirements.
Kobby Kan wrote:
Does the .NET framework make it relatively difficult for practical implementation and slow?
I've found that .net is well suited for business oriented tasks. I've also found it sourly lacking for developing 3D simulations. I've never tackled speech recognition so I can't say. One thing I'd look at if I were you is the amount of existing libraries that you'd be using. The only way I really learned was to try it.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
modified on Monday, May 26, 2008 12:38 PM
-
That makes complete sense for the areas that you develop in, but you're stating them like they are general principles. Try running that by the guys that write SQL server for instance. They wrote their own thread scheduler because the OS one wasn't good enough for them. 99.95% of the time questions like the OP's are completely misguided but there is still some stuff out there that benefits from more control over memory management. Creating temporary heaps for things like parsing a document can give you some pretty large performance gains as you can essentially ignore memory management and drop the entire heap in one operation when you are done with that document. My C++ days are behind me, and I haven't even considered the need of doing anything like this for years and am very happy working with C#, but I have to admit that the Windows memory APIs gave you some really powerful options, even though the basic C++ new/delete operators were beyond awful for performance.
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
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
-
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.