> Two small edits close most of it: compute the loop bounds into locals before the loop,
I always assumed any decent runtime/compiler takes care of such optimisations, and usually leave such things to JDK in my Java code. Is that really not the case?
Its possible the JIT would have optimized this but that optimization isn't making its way into the native AOT build.
Also possible if it were more idiomatic C# it would have optimized it better. RyuJIT does in fact do BCE and other loop optimizations. It's improving a lot every year too.
In C++ we have such troubles either. If something looking as constant cannot be 100% proved to be a constant, it cannot be optimized.
> Incrementing vectors (26.08.2019)
https://news.ycombinator.com/item?id=20800076
Decent ones do. .NET's JIT has historically (before ryujit especially and tbh I haven't looked at .NET much in the past decade) not been decent, general statements about decent compilers never applied to it. It has been playing catch-up lately but apparently it still has a ways to go.
That is absolutely not true. Not historically, and not now. .NET's JIT has always been very good, bar a few qualifying statements.
It used to be based on MSVC, with the most expensive optimizations trimmed, things like loop hoisting, devirtualization, generally ones with long runtimes, or ones that required whole program visibility.
But otherwise it was competent, if you wrote code aware of these limitations, it could get very close to even C++, and even on naive code, it was always very competitive (with strange wildcards, that if you used raw pointers, which are an obscure C# feature, you could get code to be even faster, due to the compiler's heritage).
It also helped, that due to MS's nature; C# was meant to be used with MS frameworks, written by people who were aware of the compiler's quirks, which you could learn if you looked at these codebases.
Sure if yo measure against LLVM-compiled static languages, it falls short in certain scenarios, but it's been soldily in the pack of other GC languages like Java or Go, and always has been.
They have been improving, this is one area however where those C# vs Java flamewars kind of miss out.
While C# the language has much more goodies than Java the language, Java the platform has had much better options than the CLR, because it has been mostly Microsoft and Mono (nowadays almost gone after the acquisition), whereas the Java ecosystem has a plethora of implementations, each one wiht their JIT and GC implementations, even AOT caches since almost three decades now.
Thankfully the outcome of Project Midori, and the whole Secure Future Initiative , has had the side effect of Microsoft becoming more serious about .NET performance, instead of always outsourcing performance workloads to C++ and COM.
It never was a priority I believe. As opposed to C, the main target audience of C#/.NET has always been LOB CRUD app shops.
Kind of, us users of .NET would have liked a Delphi, VB 6 kind of attention to performance, however for many years, Microsoft management had exactly that attitude, expecting that anyone that cared about performance would be writting COM in C++, or DLLs, and consuming those artifacts from .NET.
Finally they changed their approach to .NET, besides Midori, SFI that I mention on a sibling comment, certainly also due to Go and Rust competition.
Note how Azure nowadays does most of their open source contributions in Go and Rust, the rewrites that completly ignored .NET, while the team mentions lack of adoption on .NET related podcasts.