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

Allocation is cheap in .NET until it is not

tooslowexception.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Allocation is cheap in .NET until it is not

#51

Post by pjmlp »

celdon25 wrote: post #50
rjbwork wrote: post #42

Earlier quoted context omitted.

>they'll totally forget that allocation is expensive no matter what the platform or runtime. Well, it's easier to do in a managed language. When you literally don't have to agonize or obsess over every allocation because you aren't responsible for cleaning it up (unmanaged held resources withstanding), you tend not to do so. P.S.: You're always free to drop down into C or C++ if you want to get some speed, but of cou…

>You're always free to drop down into C or C++ if you want to get some speed Wouldn't C# with structs and pointers do the job in many cases? I've been able to get 50-fold increases in speed through heavy optimizations, without switching to another language. Using C or C++ solely for a "speed boost" over C# is not only unnecessary, but it creates more problems than it solves. If you don't know how to optimize within C…

Yes they would, and the C# 7 improvements taken from Midori experience make it much better.

I think in general it is a culture problem.

Those of us that embraced managed languages, including for systems programming (Oberon, D, ...), know that we can be productive 99% of the time and just have to care how to do speed boost tricks on that 1% using profiler and low level language tricks.

In C and C++ communities there is a sub-culture of thinking too much ahead of time how much each line of code costs, thus speeding too much time with design decisions that actually have zero value in the context of the application being delivered.

The problem is not taking those decisions, rather taking them without validating if they are right with a profiler, or regard to the goals that have to be met for the application.

Beyond which any low level fine tuning, while fun, is needless engineering.

Re: Allocation is cheap in .NET until it is not

#52

Post by mrgriffin »

dfox wrote: post #44
ridiculous_fish wrote: post #39

Earlier quoted context omitted.

Aside from the stack, another key challenge for moving GCs is hash tables keyed on object identity. If the object can move the raw address is no longer a suitable hash. .NET at one point stored an extra per-object word, which was either (via its LSB) a random hash code or a pointer to a metadata object that held the lock, etc. Python did this cute thing where moved objects would get an extra word allocated to store t…

Cpython has non-moving GC so this is not an issue. On the other hand CPython's hashmap implementation is probably most educational open source hashmap implementation that you can find, because it is full of wonderful and portable performance hacks (for one thing the hash values of CPython's objects is intentionally computed such that the distribution is non-uniform which allows tuning of the hashmap implementation fo…

> Cpython has non-moving GC so this is not an issue.

I believe the GP was referring to PyPy.

From https://morepypy.blogspot.co.uk/2009/10/gc-improvements.html

> The hash field is not necessarily there; it is only present in classes whose hash is ever taken in the RPython program (which includes being keys in a dictionary). It is an "identity hash": it works like object.__hash__() in Python, but it cannot just be the address of the object in case of a GC that moves objects around.

Re: Allocation is cheap in .NET until it is not

#53

Post by eni »

celdon25 wrote: post #50
rjbwork wrote: post #42

Earlier quoted context omitted.

>they'll totally forget that allocation is expensive no matter what the platform or runtime. Well, it's easier to do in a managed language. When you literally don't have to agonize or obsess over every allocation because you aren't responsible for cleaning it up (unmanaged held resources withstanding), you tend not to do so. P.S.: You're always free to drop down into C or C++ if you want to get some speed, but of cou…

>You're always free to drop down into C or C++ if you want to get some speed Wouldn't C# with structs and pointers do the job in many cases? I've been able to get 50-fold increases in speed through heavy optimizations, without switching to another language. Using C or C++ solely for a "speed boost" over C# is not only unnecessary, but it creates more problems than it solves. If you don't know how to optimize within C…

Can you please point to any resources that talk about heavy optimization options in c#. That 50-fold increase you talk about is very interesting. I would like to learn more.

Re: Allocation is cheap in .NET until it is not

#54

Post by pjmlp »

ridiculous_fish wrote: post #29
dfox wrote: post #22

Earlier quoted context omitted.

The point is that you need moving GC for bump-allocation to be possible. Traditional mark-and-sweep is non-moving while semispace collector is the simplest to describe moving GC. The practical takeaway from all that is that usual generational GC constructions with semispace minor collections and mark-and-sweep/compact major collections are in the complexity/efficiency sweet spot. By the way it is possible and trivial…

Moving collectors get you best allocation throughput but impose other costs, which are hard to measure because they are design constraints. Obviously you cannot have a moving conservative collector so you must have stack maps, safe points, etc. Or interactions with native code. How can native code hold a reference to a potentially movable object? .NET allows pinned pointers (obviously hurting compaction efficiency) w…

Objective-C GC main failure was that is impossible to have any good GC implementation in a language with C semantics.

On top of that, having developers mixing GC compiled libraries with others compiled the traditional was a good recipe for random runtime crashes.

Re: Allocation is cheap in .NET until it is not

#55

Post by pjmlp »

eni wrote: post #53
celdon25 wrote: post #50

Earlier quoted context omitted.

>You're always free to drop down into C or C++ if you want to get some speed Wouldn't C# with structs and pointers do the job in many cases? I've been able to get 50-fold increases in speed through heavy optimizations, without switching to another language. Using C or C++ solely for a "speed boost" over C# is not only unnecessary, but it creates more problems than it solves. If you don't know how to optimize within C…

Can you please point to any resources that talk about heavy optimization options in c#. That 50-fold increase you talk about is very interesting. I would like to learn more.

Here is a list, not easy to track all of them down, but maybe as keywords to easy googling.

- structs

- unsafe code

- stack allocation in unsafe code (think alloca())

- attribute annotations for packing and inline calls across assemblies

- ref parameters

- ref returns

- readonly ref parameters

- Span and Memory

- Native memory allocation via MarshalInterop, SafeHandles

- Buffer and ArraySegment

- SIMD (with RyuJIT)

- Profiled code cache for JIT code background generation between executions (System.Runtime.ProfileOptimization)

Re: Allocation is cheap in .NET until it is not

#56

Post by pjmlp »

xxs wrote: post #47
vvanders wrote: post #45

Earlier quoted context omitted.

> of which there's a limit (65k in Android!) Oh man JNI and Android. I've never heard a developer curse up a storm like I did when one of my co-workers inadvertently stumbled across the 512 LocalRef limit(also a fun one) during an intermittent crash repro. By the time he got done with his rant we had to talk him out of purchasing a one-way plane ticket to Mountain View.

I've mentioned it earlier, yet - if you need native code use direct byte buffers as shared memory between java/c and hold/use no refs inside the native code.

Those lucky enough to focus on Oreo can make use of the new shared memory classes, that they introduced to the new microkernel-like architecture for Treble drivers.

Re: Allocation is cheap in .NET until it is not

#57

Post by pjmlp »

vvanders wrote: post #45
ridiculous_fish wrote: post #29

Earlier quoted context omitted.

Moving collectors get you best allocation throughput but impose other costs, which are hard to measure because they are design constraints. Obviously you cannot have a moving conservative collector so you must have stack maps, safe points, etc. Or interactions with native code. How can native code hold a reference to a potentially movable object? .NET allows pinned pointers (obviously hurting compaction efficiency) w…

> of which there's a limit (65k in Android!) Oh man JNI and Android. I've never heard a developer curse up a storm like I did when one of my co-workers inadvertently stumbled across the 512 LocalRef limit(also a fun one) during an intermittent crash repro. By the time he got done with his rant we had to talk him out of purchasing a one-way plane ticket to Mountain View.

As Java dev, there are so many things that just feel wrong on Android.

Leaving aside the fact how Google treated Sun, the whole framework has a feeling that was written by former C and C++ devs, learning Java on the job while implementing Android.

Re: Allocation is cheap in .NET until it is not

#58

Post by sterlind »

pjmlp wrote: post #51
celdon25 wrote: post #50

Earlier quoted context omitted.

>You're always free to drop down into C or C++ if you want to get some speed Wouldn't C# with structs and pointers do the job in many cases? I've been able to get 50-fold increases in speed through heavy optimizations, without switching to another language. Using C or C++ solely for a "speed boost" over C# is not only unnecessary, but it creates more problems than it solves. If you don't know how to optimize within C…

Yes they would, and the C# 7 improvements taken from Midori experience make it much better. I think in general it is a culture problem. Those of us that embraced managed languages, including for systems programming (Oberon, D, ...), know that we can be productive 99% of the time and just have to care how to do speed boost tricks on that 1% using profiler and low level language tricks. In C and C++ communities there i…

Midori was so beautiful. I think it would have succeeded as a .Net runtime replacement with picoprocesses. it frustrates me that we didn't open-source it.

Re: Allocation is cheap in .NET until it is not

#59

Post by pjmlp »

tybit wrote: post #27
cpeterso wrote: post #19

Earlier quoted context omitted.

For a VM as mature as .NET, I am surprised they don't do escape analysis. Java and Go both do escape analysis, though the coreclr issue you linked to makes the point that Java really needs escape analysis because it doesn't have value types like C# structs.

I'd say .NET is surprisingly immature considering it's age and it's popularity, at least compared to JVM and JS options. Don't get me wrong I think .NET is great, and they've made some smart decisions that allow it to be competitive with much less engineering work on the VM. As well as not having escape analysis it also lacks tiered compilation which is a much more pressing problem from my perspective, and is being a…

Looking from the outside, but also following everything that comes out of MS and MSR, I think it was a political consequence.

There was always the DevTools vs WinDev differences regarding the role of .NET in Windows, and for a while it seemed Microsoft has happy having .NET just be good enough.

Thankfully they have changed their mindset and are improving .NET to be as close to C++ as possible, at least for 99% of the use cases where using a GC language is an acceptable trade off.

Re: Allocation is cheap in .NET until it is not

#60

Post by pjmlp »

sterlind wrote: post #58
pjmlp wrote: post #51

Earlier quoted context omitted.

Yes they would, and the C# 7 improvements taken from Midori experience make it much better. I think in general it is a culture problem. Those of us that embraced managed languages, including for systems programming (Oberon, D, ...), know that we can be productive 99% of the time and just have to care how to do speed boost tricks on that 1% using profiler and low level language tricks. In C and C++ communities there i…

Midori was so beautiful. I think it would have succeeded as a .Net runtime replacement with picoprocesses. it frustrates me that we didn't open-source it.

As believer in GC enabled system programming languages, I do feel it was indeed a missed opportunity, specially to change the mind of those that think C and C++ are the only way to write OSes.
Post reply on HN