Performance Improvements in .NET 7 • Hacker News Board

Re: Performance Improvements in .NET 7

#121

Post by smcl » Wed, Aug 31, 2022, 8:28 PM UTC

ThunderSizzle wrote: post #64

smcl wrote: post #41

Earlier quoted context omitted.

I recall a few bumpy bits in the various upgrades from 1.0 to 2.2 - they reworked quite a few areas such that updating the .NET Core version required changing your code. They provided good documentation and migration guides, but they did definitely break things along the way.

I recall most developers didn't jump from 472 to core 1 since this was thr expectation. I barely started touching core until core 3, and really started checking out .net 5.

To be honest we didn't migrate .NET Framework apps - new build was done in .NET Core and thankfully there were a few smaller projects in the pipeline to allow us to fiddle with a bit through the transition 'til it was a bit more stable.

Re: Performance Improvements in .NET 7

#122

Post by devmunchies » Wed, Aug 31, 2022, 8:34 PM UTC

chusk3 wrote: post #106

devmunchies wrote: post #71

> A huge amount of effort in .NET 7 went into making code gen for Arm64 as good or better than its x64 counterpart Awesome. I was using an LSP server for F# (in Sublime Text) on an M2 Mac and it was always running at 500%+ CPU. I had to turn off the LSP server. Hopefully this version fixes it.

Assuming you're talking about FsAutoComplete and this was recently, that's nothing to do with the .NET Runtime and entirely a coding mistake that I made that we've released a fix for :)

Oh! HAHA it was FsAutoComplete. right on. Thank you!

Re: Performance Improvements in .NET 7

#123

Post by pjmlp » Wed, Aug 31, 2022, 8:43 PM UTC

zeroc8 wrote: post #104

kevingadd wrote: post #77

Earlier quoted context omitted.

I do extensive profiling of managed apps and while the JIT does eat a measurable amount of CPU time, it's really not much. And at least on .NET, you can manually ask the runtime to JIT methods, so you can go 'okay, it's startup time, I'm going to spin up a pool of threads and use them to JIT all my code' without blocking execution - for a game I'm working on it takes around 2 seconds to warm ~4000 methods while the o…

I 've never understood the point of JITing. Just compile the thing once for your target architecture and you're done. No more spawning threads for doing the same thing over and over again. I'm glad that languages like Go and Rust are bringing back the lost simplicity of yesteryear's dinosaur languages. Life can be so easy.

IBM OS/400 binaries (nowadays IBM i), can be executed in a completly different architecture from 1988, without any changes, possibly the source code doesn't exist anymore, while taking full advantage of IBM Power10 on its last iteration.

Same applies to any other bytecode format making use of dynamic compilers.

Re: Performance Improvements in .NET 7

#124

Post by pjmlp » Wed, Aug 31, 2022, 8:44 PM UTC

lillecarl wrote: post #120

zeroc8 wrote: post #104

Earlier quoted context omitted.

I 've never understood the point of JITing. Just compile the thing once for your target architecture and you're done. No more spawning threads for doing the same thing over and over again. I'm glad that languages like Go and Rust are bringing back the lost simplicity of yesteryear's dinosaur languages. Life can be so easy.

Reflection in C# is a thing, it isn't in either Go or Rust. I've read some kind of compiler shenanigans can get something that resembles reflection in C++. I love reflection, the fact that libraries can look at your types is really really cool. Not saying it can't be done with a compiled language but I don't see it anywhere. Being able to load a shared library, search it for classes implementing interfaces, instantia…

Go has reflection, and you can make use of compile time reflection on Rust via the macros infrastructure.

Re: Performance Improvements in .NET 7

#125

Post by SideburnsOfDoom » Wed, Aug 31, 2022, 8:46 PM UTC

TillE wrote: post #50

SideburnsOfDoom wrote: post #5

Earlier quoted context omitted.

> they should release LTS versions of some kind. Uh? .NET 6 is the current LTS version. 8 will be the next. https://dotnet.microsoft.com/en-us/platform/support/policy I don't comment on Java or Python platform versioning policies because, like you with .NET, "I don't follow the ecosystem closely enough" so I don't have anything meaningful to say about it. > It feels kind of scary committing to .NET 7 right now .. Or…

One of the weirder HN tropes is being upset that new software continues to be released, or that languages get updated with new features. I've so rarely seen truly major breaking changes that require substantial effort in updating your own code. Like, the Python 2->3 transition is notable because it's unusual.

What I'm finding the weird trope is the pattern of: "I don't know anything about X, anyway why doesn't X do (thing that X has been doing for ages)"

ignorance is no problem, I am ignorant of the details of most popular programming languages, and I know that. it's another thing to show awareness of ignorance, and then lose that awareness before the end of the paragraph.

Whatever happened to "Whereof one cannot speak, thereof one must be silent."

Re: Performance Improvements in .NET 7

#126

Post by copperx » Wed, Aug 31, 2022, 8:50 PM UTC

branko_d wrote: post #93

pwdisswordfish0 wrote: post #75

Earlier quoted context omitted.

"Framework" is such a poor differentiator to contrast with modern .NET (owing to the original poor naming decision in the first place--it's not like ".NET" itself is amazing) that it's hard, from a casual reading, to pick up on the fact that "Framework" is even being used a differentiator. I propose that when people want to differentiate between the modern .NET Core vs the legacy closed source .NET implementation, th…

IMHO, they should have just named the new one .CORE and called it a day. It would have made it immeasurably easier to google, and could have been be incorporated into other names to differentiate them from old versions: ASP.CORE, ADO.CORE, WinForms.CORE…

No, it's in their DNA to name things like that. "Windows" ... nuff said.

Re: Performance Improvements in .NET 7

#127

Post by Mindless2112 » Wed, Aug 31, 2022, 8:51 PM UTC

> try running Console.WriteLine((object)new uint[42] is int[]);, and you’ll find it prints out True

I knew .NET's array variance rules were kinda bad, but that's really surprising.

Re: Performance Improvements in .NET 7

#128

Post by lillecarl » Wed, Aug 31, 2022, 8:52 PM UTC

pjmlp wrote: post #124

lillecarl wrote: post #120

Earlier quoted context omitted.

Reflection in C# is a thing, it isn't in either Go or Rust. I've read some kind of compiler shenanigans can get something that resembles reflection in C++. I love reflection, the fact that libraries can look at your types is really really cool. Not saying it can't be done with a compiled language but I don't see it anywhere. Being able to load a shared library, search it for classes implementing interfaces, instantia…

Go has reflection, and you can make use of compile time reflection on Rust via the macros infrastructure.

Does that cover all mentioned usecases though? They're discussing source generation in this thread, not even close to the same thing (for certain usecases)

Re: Performance Improvements in .NET 7

#129

Post by pjmlp » Wed, Aug 31, 2022, 9:51 PM UTC

lillecarl wrote: post #128

pjmlp wrote: post #124

Earlier quoted context omitted.

Go has reflection, and you can make use of compile time reflection on Rust via the macros infrastructure.

Does that cover all mentioned usecases though? They're discussing source generation in this thread, not even close to the same thing (for certain usecases)

Kind of, you can use the parsing package for that, alongside the //go:generate infrastructure.

Or you can use Go reflection package and generate the source code from it.

Of if wanting to do something like Assembly.Emit, generate the machine code directly with a little help from unsafe and syscall packages.

Depends pretty much on the actual use case.

Re: Performance Improvements in .NET 7

#130

Post by noveltyaccount » Wed, Aug 31, 2022, 10:04 PM UTC

chusk3 wrote: post #106

devmunchies wrote: post #71

> A huge amount of effort in .NET 7 went into making code gen for Arm64 as good or better than its x64 counterpart Awesome. I was using an LSP server for F# (in Sublime Text) on an M2 Mac and it was always running at 500%+ CPU. I had to turn off the LSP server. Hopefully this version fixes it.

Assuming you're talking about FsAutoComplete and this was recently, that's nothing to do with the .NET Runtime and entirely a coding mistake that I made that we've released a fix for :)

This is the most Hacker News comment I have ever seen, lol. The actual guy behind the bug here replying to comments with a mea culpa :D