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

For Better Computing, Liberate CPUs from Garbage Collection

spectrum.ieee.org

Post reply on HN
Print view View original

271–280 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#271

Post by maxxxxx »

blub wrote: post #239
simiones wrote: post #215

Earlier quoted context omitted.

The nicest point about GC is that, for the vast majority of data, you no longer need to have a concept of ownership at all. Ownership is not a fundamental architectural property - it is "only" a powerful technique for tracking data with a specific lifetime (of course, even in GC languages you still need proper ownership semantics for some pieces of data).

Ownership itself might not be, but lifetimes are and the two concepts are tightly related. That's why Java and C# both had to introduce a way of (semi-)automatically closing resources, waiting for the GC was a catastrophe.

That’s what I find ironic about C#. In some ways I worry more about and do more manual memory management than I did in C++.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#272

Post by p_l »

glenneroo wrote: post #222
notacoward wrote: post #200

Earlier quoted context omitted.

> for the vast majority of applications, I'd gladly give away 50% of the CPU. Don't you think you're over-generalizing a bit much from your own circumstances? If these issues don't matter to you then you basically don't belong in this conversation. They matter a lot to people who write software that runs on large numbers of servers, with both CPU and memory utilization pushed to the limits. That's a lot of us. If you…

Don't forget game development, especially users of the Unity game engine, where their "aggressive" GC has often been the bane of projects such as Kerbal Space Program. I have been struggling lately with my own Unity GC issues, where it's running the GC every frame, subsequently dropping my FPS from the 90 I need for VR down to 50 every few frames. Even the new experimental GC they have implemented seems to have no ef…

Would probably help if they had constant-time GC available, where you bind mutator ("application code") and collector (GC) to specific quanta of time to run, thus providing reliable timings.

The question is whether it would be fast enough.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#274

Post by lossolo »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

> Rust is a start,

Rust is not a start, it's a next iteration over old ideas (look at Ada, Cyclone etc). All of those languages were niche and will stay niche for a reason.

> Garbage collection is just plain bad. I for one am glad we're finally ready to consider moving on.

We are not moving anywhere. You still need lifetime annotations in Rust and design your application in specific way to satisfy the borrow checker. You can't just write it the same way like you would in GC language. You trade productivity for complexity to avoid GC. Simplicity and productivity will always win in current market with complexity. Developers time is money, a lot more money than money spent on energy and hardware. That's why companies throw money at hardware and use GC languages, because it's a lot cheaper, simple and productive way to create software.

So unless you solved the halting problem GC is here to stay.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#275

Post by tempguy9999 »

AsyncAwait wrote: post #209
titzer wrote: post #180

Earlier quoted context omitted.

IMO manual memory management is the epitome of sunk cost fallacy. Sixty years of good programmer effort thrown at a bad idea that has produced an endless stream of security bugs and performance problems that have only hidden the cost of memory management behind non-obvious barriers and done severe violence to systems languages with an absurd obsession with custom allocators and baked ownership into otherwise straight…

I think he was simplifying to make a point.

I think he was simply wrong.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#276

Post by fnord123 »

viraptor wrote: post #233
tempguy9999 wrote: post #135

Earlier quoted context omitted.

You say > but it was a false dichotomy: We can have memory safety without garbage collection. but then say > Automatic reference counting (ARC henceforth). Naive ARC is AFAIK very expensive as it causes a lot of updates at each pointer 'take' even if it's a read only (chasing pointers), trashing caches. Poss. even worse if multithreading is used as a memory barrier may have to be issued. Also it does not collect cycl…

> Naive ARC is AFAIK very expensive as it causes a lot of updates It also means you can't really rely on CoW after fork(). After a while your whole heap will be duplicated in every process because of the RC updates.

That's a nice point. yikes.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#277

Post by SlipperySlope »

In Java, I created thread local resource pools including strings which eliminate garbage collection in sensitive routines. Of course it’s much faster in java to perform pooled string comparison with ==. Likewise I always use the indexed version of a for loop to avoid the iterator otherwise allocated.

GC in java is great for non-priority code which is most of the application.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#278

Post by stephc_int13 »

maaaats wrote: post #203
stephc_int13 wrote: post #186

I never understood the need for Garbage Collectors. In my opinion, the difficulties of memory management are extremely overrated. I write code in C/C++ for almost 20 years and I never encountered a difficult bug that would have been avoided with a Garbage Collector. If a coder really has a hard time with manual memory management it means he can't really code, this is a beginner problem...

I only work in GCed languages, so I don't know how manual memory management works, except segfaults in some courses at university. Guess I should quit my job, as you say I apparently can't really code :/ Thanks for letting me and others here know!

Let me rephrase this. In the CS / Programming space, we have quite a lot of difficult problems to solve, in my opinion, memory management is really easy compared for example to multithreading.

In fact the so called Garbage Collector do not really solve the problem of memory management, there are still a lot of potential for leaks and poor memory management when GC is used.

And it adds a lot of complexity to the language runtime, and it gets in the way, I've seen a lot of discussions about how to avoid triggering the GC, in the end, the solutions are more complex than good old manual memory management.

I am not saying that memory management is trivial if it was it could efficiently be handled by the compiler or the runtime.

There is no magic bullet solution for easy memory management, one has to choose the right policy considering the context, which is most of the time out of reach for the compiler.

The context is mostly the expected lifetime of the memory allocation.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#279

Post by powerapple »

davedx wrote: post #82
arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

> It wastes time, it wastes space, it wastes energy. But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Anecdotally, I spent the first ~6 years of my career working with C++, and when I started using languages that did have GC, it made my job simpler and easier. I'm more productive and less stressed due to garbage collection. It's o…

C++ is not bad. I think it sits in the middle between C and GC languages. I actually like what C++ offers. Languages with GC are actually easy to debug. I remember once I had my own memory management code, suddenly the write beyond boundary is not segfaulting any more, took me more time to figure out the problem.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#280

Post by coldtea »

StreamBright wrote: post #220
tomp wrote: post #210

Earlier quoted context omitted.

This comment is just bad and misinformed all over. (1) Automatic Reference Counting doesn't work; its equivalent in interpreted languages is, well, reference counting , which can be optimized quite a lot (though has some issues with multithreading), but cannot collect cycles. (2) therefore, if you want reference counting, you have to either also have GC (for cycles), or program carefully to avoid creating cycles (whi…

It is weird, I do not feel restricted when I write non-GC code. Btw. you still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Rust made it easy and simple to deal with memory in a non-malloc level while not having GC. Erlang on the other hand has a VM that makes GC much faster than in other languages. I can live with that because if you do it right i…

>It is weird, I do not feel restricted when I write non-GC code.

Some people don't feel C has any safety issues either -- perhaps they think all others are idiots and their code is mistake proof because they do it right.

Post reply on HN