High performance c#
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
Quote:
"See, it's easy," you begin, but are interrupted by the sound of rapid British-sounding footsteps approaching the doorway.
I have to ask, British footsteps sound different from, say, German footsteps? :confused:
-
Quote:
"See, it's easy," you begin, but are interrupted by the sound of rapid British-sounding footsteps approaching the doorway.
I have to ask, British footsteps sound different from, say, German footsteps? :confused:
-
British footsteps sound like an old man shuffling along a rough track. German footsteps sound like an army goosestepping along a wide autobahn (to the sound of an oompah band). :laugh:
And French footsteps just get quieter and quieter... :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
(I haven't followed the link yet - it's Saturday, and I'm feeling lazy.) It's probably rather like the old C / Assembler debate. Yes, a skilled assembler programmer can produce faster, more compact code than a skilled C programmer purely because he can tell the machine exactly what he wants it to do rather than adding a layer of "interpretation" via a compiler. But ... it'll take a lot longer to code, and an unskilled assembler programmer can still make a serious dogs dinner of the same job! I suspect that an average C# coder will produce code that is less efficient than a skilled C++ coder to do the same job - but I also suspect that he'll produce it in less time, and it'll be more easily maintainable by an average developer. And with the performance of modern machines that's a critical factor in most cases. Additionally, I suspect that a skilled C# developer will produce better, faster code than an average C++ dev, and get it out the door quicker as well. Don't get me wrong, C++ is a good language, I used it for many years - but C# produces good code as well which is often a lot more readable and less prone to silly and avoidable bugs.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
I suspect that an average C# coder will produce code that is less efficient than a skilled C++ coder to do the same job - but I also suspect that he'll produce it in less time, and it'll be more easily maintainable by an average developer. And with the performance of modern machines that's a critical factor in most cases. Additionally, I suspect that a skilled C# developer will produce better, faster code than an average C++ dev, and get it out the door quicker as well.
by the same token with newer machines having so much more memory than before you could argue garbage collection / free-ing unused memory can also be ignored in short running programs or where only alloc-ing space for relatively small buffers/structures. [which could also have dramatic results for performance.] OTOH, using the excuse: "todays machines are faster / bigger memory... so optimisation and/or garbage collection matters little" is when people copy or extend that code into small/short running programs into big / long running ones. OP's "sound" app may work fine in optimised C# [and/or without cleaning up unused memory] but when added to a video editing suite would that still be true? On my bicycle I can match (if not beat) the bus on a 10 mile commute and get away without refueling on the way, but let's make that 100 miles. right tools for the job.
Message Signature (Click to edit ->)
-
(I haven't followed the link yet - it's Saturday, and I'm feeling lazy.) It's probably rather like the old C / Assembler debate. Yes, a skilled assembler programmer can produce faster, more compact code than a skilled C programmer purely because he can tell the machine exactly what he wants it to do rather than adding a layer of "interpretation" via a compiler. But ... it'll take a lot longer to code, and an unskilled assembler programmer can still make a serious dogs dinner of the same job! I suspect that an average C# coder will produce code that is less efficient than a skilled C++ coder to do the same job - but I also suspect that he'll produce it in less time, and it'll be more easily maintainable by an average developer. And with the performance of modern machines that's a critical factor in most cases. Additionally, I suspect that a skilled C# developer will produce better, faster code than an average C++ dev, and get it out the door quicker as well. Don't get me wrong, C++ is a good language, I used it for many years - but C# produces good code as well which is often a lot more readable and less prone to silly and avoidable bugs.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Agreed wholeheartedly. If performance can be improved just by throwing more hardware at it, it probably makes more sense to have an average developer write good, maintainable code than having a rock star developer write code that only *he* has the ability to read and maintain, even if that code manages to squeeze every little bit of performance out of the hardware. Simply because developer time is a lot more expensive than hardware.
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
I used unmanaged methods with C# to do some image processing. For fun I was writing something to detect hand-drawn rectangles and circles - so that you can turn a hand-drawn diagram into vectors. I found that the unmanaged methods took around three times less time than using managed code - so it does make a bit of a difference.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
System.Numerics is better than nothing (I recommend it over "doing nothing" at least), but it's really difficult. By which I mean more difficult than using SIMD intrinsics in C++. The API is full of holes (no right shift?? no shuffle? no special operations?) and landmines (you'd think that eg multiplying a vector by a scalar is equivalent to broadcasting that scalar and then doing a vector multiply, but no, you have to do that manually and ban the `scalar*vec` from your code). Of course programming is an exercise in "poking the code until the asm looks good" either way, but the System.Numerics API makes it harder to get it right. Sometimes impossible. The newer SIMD API in .NET Core 3 (System.Runtime.Intrinsics) is more complete and probably will be better. Still tricky to get good codegen in all cases. For example it's not so easy to force it to "broadcast from memory" and avoid the "load-then-broadcast" anti-pattern (this costs a shuffle µop on p5 in addition to the load, broadcast from memory only costs a load).
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
If you like that, have a look at what you can do with Span.
This space for rent
-
And French footsteps just get quieter and quieter... :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
And the Dutch, the Dutch with their woody clutter !
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
C++ is really a system's language, for large systems, where lots of incremental performance gains (or losses) adds up. And of course the thing is, if you looked under the hood of the C# libraries, I'm guessing there's probably a lot of C++ down in there. Languages like C# are good if you are sitting on the top of the food chain. If your code needs to live from the metal up to the UI, then something like C++, with all it's issues, is likely more practical. It's one of those languages that maybe doesn't do anything one thing the absolute best but it does a broad spectrum of things well. If the code base has to cover that broad spectrum, it adds up. If you end up having to do lots of unsafe C#, you sort of give up the biggest advantages of C# without getting the real benefits of C++.
Explorans limites defectum
-
And the Dutch, the Dutch with their woody clutter !
The click of wet thongs (flip flops to you ethnics) for the Aussies
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
Good link! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
C++ is really a system's language, for large systems, where lots of incremental performance gains (or losses) adds up. And of course the thing is, if you looked under the hood of the C# libraries, I'm guessing there's probably a lot of C++ down in there. Languages like C# are good if you are sitting on the top of the food chain. If your code needs to live from the metal up to the UI, then something like C++, with all it's issues, is likely more practical. It's one of those languages that maybe doesn't do anything one thing the absolute best but it does a broad spectrum of things well. If the code base has to cover that broad spectrum, it adds up. If you end up having to do lots of unsafe C#, you sort of give up the biggest advantages of C# without getting the real benefits of C++.
Explorans limites defectum
Dean Roddey wrote:
If you end up having to do lots of unsafe C#, you sort of give up the biggest advantages of C# without getting the real benefits of C++.
I kind of agree, but I think there's a middle-ground there. For me going back to c++, working with header files drives me mad. And the way that .NET assemblies are self-describing so you can just reference them and use them without all those header files and linking is glorious. For me, these are some of the biggest advantages and are still there regardless of going unsafe.
Regards, Rob Philpott.
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
-
The modern C++ is trying to get less cryptic* & the modern C# is trying to get more performant. Someday both meet at a point and people get to choose the project template as easy as picking a green apple or a red apple. :) *a long way to go
I'm not sure at all that I'd agree that modern C++ is less cryptic. The crazy templatization of modern C++ can make it extremely cryptic.
Explorans limites defectum
-
I'm not sure at all that I'd agree that modern C++ is less cryptic. The crazy templatization of modern C++ can make it extremely cryptic.
Explorans limites defectum
Only if you are authoring libraries. If you are a consumer, it's not that bad.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
Only if you are authoring libraries. If you are a consumer, it's not that bad.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
If you are writing pretty substantial applications, there's still a lot of grunt work infrastructure code in such things, so you'd still end up doing a lot of this stuff at your level as well.
Explorans limites defectum
-
Dean Roddey wrote:
If you end up having to do lots of unsafe C#, you sort of give up the biggest advantages of C# without getting the real benefits of C++.
I kind of agree, but I think there's a middle-ground there. For me going back to c++, working with header files drives me mad. And the way that .NET assemblies are self-describing so you can just reference them and use them without all those header files and linking is glorious. For me, these are some of the biggest advantages and are still there regardless of going unsafe.
Regards, Rob Philpott.
I have noticed the issues you are describing often these days. Actually, I have noticed them for a while but I have figured out ways to simplify them and now I notice when other people don't do those things.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness. This may be the case, but then there's an alternative argument that goes if you sidestep garbage collection, and use unsafe constructs you get close, and because your code gets JITed, there may be a chance to hone the code for the actual CPU it will run on which could actually make .NET faster over a generalised native binary. There seems to be better scope for this if you use the SIMD enabled System.Numerics. I've been mucking around with sound synthesis in .NET recently, and by using unmanaged memory (Marshal.AllocHGlobal) and unsafe pointers the performance is good enough. In fact I've got it so there are virtually no garbage collections at all (beware of Linq - it creates enumerators all over the place). GCs are terrible news for audio, because a delay can mean a buffer not being ready in time and you get nasty clicks. It means a different approach to coding, but it's still miles preferable to header files and linking libs and all that 32/64 bit nastiness you get with C++. Then I stumbled on this: [https://www.bepuentertainment.com/\](https://www.bepuentertainment.com/) This is a stunning masterclass in what C# can do. I recommend having a look at the video, and reading the bits about GPU vs. CPU and 'a different kind of c#' entries. I'm fairly hard to impress these days, but I've downloaded the code built it and played with it and just... wow. Moreover, I'd argue its the last nail in the coffin of the argument that C# is not a viable choice for high performance compute bound work.
Regards, Rob Philpott.
Rob Philpott wrote:
There seems to be a general view that if you want to do some serious compute bound work C++ will always win over C# because of its unmanagedness
Same view is true for Java. However.... First that claim supposes that the person doing the programming does in fact have enough experience in C++ to create something faster in that language. In my experience such claims have originated from people that just prefer that language or some other that that they claim is 'better' based on subjective terms rather than objective terms. (Might be relevant to note that I have at least 15 years of C/C++ experience.) Second business programming in terms of programming is never about algorithmic performance. And I am not a person that throws absolutes around, but in terms of statistical significance the probability that a the algorithm in the business is the bottleneck is so far below 1% that it is effectively zero. What actually impacts performance is architecture and design. And business processes, since a faster application might be possible if one refactored 15 years of legacy code but that just isn't cost effective for most businesses. Third if there is in fact a single algorithmic bottleneck and one can find the expertise then obviously implementing it that way might not be the advantage one thinks. I consider it very unlikely that code (vs design decisions at the code level) are going to provide a 1000% speed up or even a 100% speed up. So what are the cases where a 10% speed up, with no other design/architecture changes (which can be done in any language) are going to provide that much actual real benefit to the business?
-
No, I don't. And you don't. But ... we've both seen it done, and sometimes in production code. :omg: I think we have to accept that developers are not what they used to be (and "Hoorah!" for that in some cases), projects generally are a lot larger and more complex than they were, and that we have to change to languages which facilitate that.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
But ... we've both seen it done, and sometimes in production code.
I have seen it many times in production code. And would have been more except that I started reviewing the code of others and catching it. I worked at a place with formal code reviews and I was still the only one finding them. Not to mention that these sorts of problems impact the server far more.
OriginalGriff wrote:
I think we have to accept that developers are not what they used to be
But applications now are not the same either. When I started I wrote the UI and the back end. Now I can't even effectively review the UI code and the developers cannot write the back end code.
