Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Improvements in .NET 10

devblogs.microsoft.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Performance Improvements in .NET 10

#61

Post by feoren »

Rohansi wrote: post #31
PaulHoule wrote: post #12

Earlier quoted context omitted.

I haven't written C# professionally since the early 2010s but back then the language had a big problem in that the old Container classes were not compatible with the Container classes that were added when they added generics to C#. This created an ugly split in the ecosystem because if you were using Container you could not pass it to an old API that expected a Container. Java on the other hand had an implementation…

This hasn't been an issue for a long time because nobody uses the non-generic collections anymore. That doesn't help you with your reliance on type erasure though. If you're up for it you should give it another try. Your example of subclassing GenericType and GenericType may be supported with covariance and contravariance in generics [1]. It's probably not very well known among C# developers (vs. basic generics) but…

Covariance and contravarience is very useful, but it's quite annoying that it can only be used with interfaces and not classes/structs. I write lots of little monoid-like data wrappers like Named, and I have to either go through the hassle of dealing with interfaces for something that shouldn't need it, or I have to abandon covariance. The .NET maintainers seem to think that nobody wants covariance on classes, but it would be very helpful to me.

Re: Performance Improvements in .NET 10

#62

Post by pron »

rudedogg wrote: post #32
bob1029 wrote: post #25

Earlier quoted context omitted.

Use of a GC does not imply we are trying to avoid memory management or no longer have a say in how memory is utilized. Getting sweaty chasing around esoteric memory management strategies leads to poor designs, not good ones.

> Getting sweaty chasing around esoteric memory management strategies I’m advocating learning about, and understanding a couple different allocation strategies and simplifying everything by doing away with the GC and minimizing the abstractions you need. My guess is this stuff used to be harder, but it’s now much easier with the languages and knowledge we have available. Even for application development. See https://…

Arenas are fantastic when they work; when they don't, you're in a place that's neither simple nor particularly efficient.

Generational tracing garbage collectors automatically work in a manner similar to arenas (sometimes worse; sometimes better) in the young-gen, but they also automatically promote the non-arena-friendly objects to the old-gen. Modern GCs - which are constantly evolving at a pretty fast pace - use algorithms that reprensent a lot of expertise gathered in the memory management space that's hard to beat unless arenas fully solve your needs.

Re: Performance Improvements in .NET 10

#63

Post by PaulHoule »

ofrzeta wrote: post #59
PaulHoule wrote: post #42

Earlier quoted context omitted.

The counter to that is that is that performance really matters in inner loops and in those cases the hot area is not that big, it doesn’t matter if your setup and tear down give up a lot of possible performance. Early this year my son was playing chess which motivated me to write a chess program. I wrote one in Python really quickly that could challenge him. I was thinking of writing one I could bring to the chess cl…

I guess you could to now try some realtime audio processing. Surprisingly (to me) there are actuall existing realtime DSP packages for Java.

Yeah, audio DSP is not challenging which is what killed off the high-end soundcard.

So far my collab with him has been over physics and electronics such as scaling for the prototype electric octobase (one string so far) that he made. His current stretch project is: he cut a MIDI keyboard in half and stacked the segments on top of each other like an organ keyboard and he's attaching that to two electric guitar necks. Probably the MIDI is going to go to a rack-mount MIDI synth so it's going to have one hell of a wire bundle coming out of it.

Personally I am really fascinated with

https://en.wikipedia.org/wiki/Guitar_synthesizer

which can take the sound from an electric guitar or bass and turn it into MIDI events or the equivalent that controls a synthesizer. Most commercial versions have six independent pickups, they used to be connected to the brains with a ribbon cable but some of them now digitize on the guitar and send the data to the controller over a serial link

https://www.boss.info/us/categories/guitar_synthesizers/seri...

Re: Performance Improvements in .NET 10

#64

Post by Grikbdl »

PaulHoule wrote: post #43
gpderetta wrote: post #17

Earlier quoted context omitted.

GC is problematic for cross-language foundational libraries though (unless they run on the same VM of course).

But what’s so bad about that Clojure and Java make a great team.

Yeah but now try to make your Java library useful to a C#, Go or Python application.

Re: Performance Improvements in .NET 10

#65

Post by qingcharles »

The big benefit of this for my work is being able to run sites on smaller and cheaper boxes every year. It's not just the speed, but they've made huge strides in the last couple of versions in massively reducing the memory use of different object types.

This is only being compared to last year's v9, but if you compare against v7 from a couple of years ago, the changes are huge.

And this only reflects the changes to the underlying framework compilation, and doesn't factor in changes to say the Kestrel web server and static asset delivery that have taken a ton of load away.

Intel are also regularly checking in changes before they release new CPUs now so that the framework is ahead of their releases and takes advantage of new features.

Re: Performance Improvements in .NET 10

#66

Post by gwbas1c »

gpderetta wrote: post #17
PaulHoule wrote: post #9

This kinda stuff brings languages like C# and Java closer to Rust in performance, thinking like the "borrow checker" it understands the scope of some objects and puts them on the stack and avoids garbage collection and allocation overhead. It keeps the unsung benefit of garbage collection for "programming in the large" in which memory allocation is treated as a global concern independent of everything else instead of…

GC is problematic for cross-language foundational libraries though (unless they run on the same VM of course).

Makes me wonder how easy/hard it is to write a library in Rust and expose it to other languages.

Re: Performance Improvements in .NET 10

#67

Post by PaulHoule »

Grikbdl wrote: post #64
PaulHoule wrote: post #43

Earlier quoted context omitted.

But what’s so bad about that Clojure and Java make a great team.

Yeah but now try to make your Java library useful to a C#, Go or Python application.

In the case of Python I think you could produce something like Jython that runs inside the Java runtime and lines up

https://openjdk.org/jeps/454

with the Python FFA so you could run things like numpy inside of it. Would be transformative for my side projects.

Re: Performance Improvements in .NET 10

#68

Post by duncans »

anonymars wrote: post #49
throwaway13337 wrote: post #38

C# is definitely fast. There are some benchmark games that I relied on in the past as a quick check and saw it as underwelming vs rust/c++. For example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... We see that the fastest C# version is 6 times slower than the rust/c++ implementation. But that's super deceiving because those versions use arena allocators. Doing the same (wrote this morning, actually…

Even way back when: https://devblogs.microsoft.com/oldnewthing/20060731-15/?p=30... > The fact that Rico Mariani was able to do a literal translation of the original C++ version into C# and blow the socks off it is a testament to the power and performance of managed code. It took me several days of painful optimization to catch up, including one optimization that introduced a bug, and then Rico simply had to do a lit…

Unrelated, but Microsoft should be ashamed that most of the links in that blog no longer work.

Re: Performance Improvements in .NET 10

#69

Post by steveklabnik »

gwbas1c wrote: post #66
gpderetta wrote: post #17

Earlier quoted context omitted.

GC is problematic for cross-language foundational libraries though (unless they run on the same VM of course).

Makes me wonder how easy/hard it is to write a library in Rust and expose it to other languages.

Can be viewed as either, you expose a C ABI and then the other languages can use it, which is fundamentally not super hard but fiddly, which could be viewed as hard but some languages have nice libraries that exist to make it easier, which is of course easier.

Re: Performance Improvements in .NET 10

#70

Post by verdie-g »

doctorpangloss wrote: post #33
verdie-g wrote: post #18

Earlier quoted context omitted.

In my company running maybe 20K servers on .NET, we get a 10-20% CPU decrease every time we upgrade to the next major.

Running what application?

Adtech, filtering users, selecting campaigns, selecting products, computing "eCPM".
Post reply on HN