|
Lopatir wrote: but let's make that 100 miles.
Nice analogy.
But most business programming these days is more akin to a trip to china or even the moon.
|
|
|
|
|
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.
|
|
|
|
|
How do you find the Audio performance on Windows though, do you notice the lag through the kernel?
(For example to run recording studio type stuff you need to bin it all and put in ASIO)
|
|
|
|
|
No not really. I think Microsoft likes to occasionally upload your entire browsing history so it can 'improve your windows experience' and if that were to happen the same moment as you're filling your buffers you may come unstuck. Ultimately, we're all slaves to the thread scheduler.
But, that's just windows. I've mucked about with thread and process priorities, but it doesn't seem to make much difference.
In terms of the driver, I am using ASIO. And so far it's all single threaded too.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: I am using ASIO
Good, you have fixed 99% of your problems right there.
I did some audio work, it was a service that had to open a pin on two sound cards and send the data between them, so it used the KS API.
It was OK, ish, but much better when I put it in the kernel (same KS API, so pretty easy to move it over).
(Since it used KS it did the same thing as ASIO, it kicks the windows audio mixer off the hardware and give you pretty much real time IO)
|
|
|
|
|
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?
|
|
|
|
|
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).
|
|
|
|
|
And French footsteps just get quieter and quieter...
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 !
|
|
|
|
|
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
|
|
|
|
|
Or footsteps of a person looking down at their phone?
|
|
|
|
|
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
|
|
|
|
|
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).
|
|
|
|
|
If you like that, have a look at what you can do with Span.
This space for rent
|
|
|
|
|
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.
|
|
|
|
|
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?"
|
|
|
|
|
While I wouldn't defend C++ that much on this front, I think you are making C# a little more straightforward than it really is. Someone I've been helping with a C# project has jumped through endless hoops with versioning of things and all the many variations of .Net, dealing with client vs. server side blazor and such. I look in the .csproj files of some of those projects and they are very complicated.
I would also say that not all C++ is as bad either. My stuff is nothing like what most C++ is wrt to build infrastructure and includes and such. Each library has a single public include file that brings in anything needed for the public interfaces of that library and exposes all the public interfaces, and a private header that brings in stuff only needed internally (which includes the public header). Each program has a main include file that brings anything needed within that program, including its own other headers.
So each library cpp file usually includes just its own internal header. And each program cpp file typically just includes its own public header. There are some occasional exceptions, but generally that's it.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: 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.
The C# compiler and most of the libraries are written in C#.
|
|
|
|
|
Good link!
|
|
|
|
|
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
|
|
|
|
|
Only if you are authoring libraries. If you are a consumer, it's not that bad.
|
|
|
|
|
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
|
|
|
|
|