On Sunday, 6 December 2020 at 08:12:58 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 07:45:17 UTC, Bruce Carneal wrote:
GCs scan memory, sure. Lots of variations. Not germane. Not
a rationale.
We need to freeze the threads when collecting stacks/globals.
D is employed at multiple "levels". Whatever level you call
it, Go and modern JVMs employ low latency GCs in
multi-threaded environments. Some people would like to use D
at that "level".
Yes, but they don't allow low level programming. Go also freeze
to sync threads this has a rather profound impact on code
generation. They have spent a lot of effort on sync
instructions in code gen to lower the latency AFAIK.
They surely do.
Looking forward to see D achieve the same performance level as
.NET 5 is capable of, beating Google's own gRPC C++
implementation, only Rust implementation beats it.
https://www.infoq.com/news/2020/12/aspnet-core-improvement-dotnet-5/
And while on the subject of low level programming in JVM or .NET.
https://www.infoq.com/news/2020/12/net-5-runtime-improvements/
Many of the performance improvements in the HTTP/2
implementation are related to the reimplementation from
unmanaged C++ code to managed C# code. Lander notes that there
"still is this kind of idea that managed languages are not
quite up to the task for some of those low-level super
performance sensitive components,
Rich Lander being one of the main .NET architects, and upcoming
Java 16 features, http://openjdk.java.net/jeps/389 (JNI
replacement), http://openjdk.java.net/jeps/393 (native memory
management).
As I already mentioned in another thread, rebooting the language
to pull in imaginary crowds will only do more damage than good,
while the ones deemed unusable by the same imaginary crowd just
keep winning market share, slowly and steady, even if takes yet
another couple of years.
