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:
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
-
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
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
-
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?
Er... I think the point is, you need to understand the performance implications of what you're writing, as well as the capabilities of your platform. Fast VB6 code did not necessarily translate to fast code under .NET, and C++ optimization techniques aren't always terribly effective there either.
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
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:
It's too bad you didn't ask for VB. The responses would have been hysterical.
Software Zen:
delete this;
Fold With Us![^] -
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:
Does the .NET framework make it relatively difficult for practical implementation and slow?
I would say that the .NET Framework most certainly does not make practical implementations more difficult. As for performance, 99% of the processing work you would need to do in any application is going to be as fast (if not faster in some cases) than any other language. Microsoft has taken some very deliberate measures to ensure that performance in .NET is as optimal as possible. There are certain areas where you take a slight one-time performance hit, mainly in application startup time if it's the first .NET application that has been run since the system was booted.
Kobby Kan wrote:
How well does C# cope for artificial intelligent systems like image and speech recognition?
I would think that this is going to be more an issue of your implementation of such systems than any limitations in the runtime.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]
-
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
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
-
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:
Given that algorithmic performance is probably the leading type of performance problem, good design that allows you the greatest flexibility to make performance improvements when and where you need to is the most important consideration. That and measure often and early. When I start making performance improvements, the first thing I do is make sure I instrument everything I need to and build performance tests first. As far as C++ and C# go, they have different strengths and weaknesses, the same can be said for any language or platform. I wouldn't trust anyone else's opinion on it anyway and start by building a simple enough core in both platforms then seeing which one gives the performance I need with the least number of trade offs.
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:
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.
-
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.
-
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.
-
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.