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

301–310 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#301

Post by twic »

ddingus wrote: post #76
sgift wrote: post #71

Earlier quoted context omitted.

Seems to be one of the main risks for any specialized circuits, if I understand you correctly. You always have to guess "will this really be relevant long enough to invest the money to bake it into hardware?" .. and if you guess wrong you just wasted a part of your silicon budget for something no one will use.

Right. Got it. There may still be room for specialized GC assist circuits.

When i thought about this (using my programmer brain which knows nothing about hardware), i came up with the idea of a 'store pointer' instruction, which took two addresses and an offset, and stored the first address into the field of the object pointed to by the second address. And also, if the two addresses referred to different memory regions, recorded the pair of addresses into some kind of buffer on the processor. When that buffer got full, the processor would trap to some preconfigured location.

That could be used as a basis for a write barrier.

The devil would be in the detail of how the regions were defined.

And maybe the trapping would mean this wasn't even all that fast.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#302

Post by cblades »

irq11 wrote: post #292
lossolo wrote: post #287

Earlier quoted context omitted.

> Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the resources here while you're at it? You are missing the point. The main point behind GC is removing the complexity of writing the software. Writing your own destructors, thinking about when to free your memory or writing lifetime annotations, needing to design your app in…

Having spent years writing code in both GC’ed and non-GC’ed languages, it’s pretty clear that it programmers spend about the same amount of time worrying about memory management with either paradigm. The main differences are that people using GC systems spend their time doing magical incantations to manage the GC wizard, and they’re a lot more smug about the goodness of their system.

>programmers spend about the same amount of time worrying about memory management with either paradigm

I have no idea how you've come to that conclusion. For the vast majority of memory allocation in any GC'd language I can think of, you spend zero time thinking about memory management 98% of the time.

whereas in a manual language, you must consider it every time you allocate memory. That's not a bad thing, it's often dead simple in the vast majority of contexts, but still.

I've also very rarely seen code in professional code that's mean to poke or prod the GC into running.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#303

Post by simias »

lossolo wrote: post #287
simias wrote: post #267

Earlier quoted context omitted.

I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…

> Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the resources here while you're at it? You are missing the point. The main point behind GC is removing the complexity of writing the software. Writing your own destructors, thinking about when to free your memory or writing lifetime annotations, needing to design your app in…

My point is that you need a "destructor" even with a GC. Continuing with my example you need to pop your tab from the data structure containing your tabs and you have to make sure that all references are dropped so that the GC will do its work.

When I write Rust code I basically never have to explicitly free anything outside of FFI code dealing with C pointer or the like. The most straightforward way to allocate anything in Rust is to reify a Box which frees its contents when it's dropped. The data is freed when I remove it from containers or when a Box gets dropped. The closest I get to garbage collection is using a reference-counted pointer here and there (and only after careful consideration).

I really don't see what complexity the GC removes in this situation, besides letting you write code without having to care about ownership which, as I stated earlier, I consider to be an antipattern.

>"just do this X and you don't need to use GC" is a reason people use GC languages, because they don't want to think about or write this "X"

A lazy programmer is a good programmer but it's also important to recognize when something can't be pushed under the rug. I don't want to think about or write documentation and unit tests either, yet here we are. If I had to maintain an application and I ask the coder "when exactly are these objects deleted?" and they answer "dunno lol, I let the GC figure it out" I'd be extremely worried.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#304

Post by brandmeyer »

eru wrote: post #168
Patient0 wrote: post #136

Earlier quoted context omitted.

In the ~15 years I spent building software in C++ I don't recall a single time that I wished for garbage collection. By using RAII techniques, it was always possible (nay, easy!) to write code that cleaned up after itself automatically. I always found it easier to reason about and debug programs because I knew when something was supposed to be freed, and in which thread. The only time that use of simple reference cou…

C++ code is full of use after free problems. You can avoid those with garbage collection.

> C++ code is full of use after free problems.

Once upon a time, this statement may have been true, but it isn't any more. ASAN and Valgrind are widely available, and runtime test suites are much more prevalent than they used to be.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#305

Post by tomp »

cyphar wrote: post #255
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…

> (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. This is what weakrefs (or better data structures) are for. The Linux kernel uses reference counting incredibly effectively for almost every structure. I think that pretty much discounts any arg…

Weakrefs require “careful programming” i.e. knowing which ref must be a weakref.

By “cheating” I don’t mean “unsafe” but all kinds of pointers that aren’t just unique or borrowed such as different reference-counted pointers, the existence and use of which demonstrates that ownership+borrowing isn’t a complete memory-management technique. You need reference counting, therefore you need GC or careful programming.

Hopefully we discover some technology that makes these needs go away, but not so far AFAIK.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#306

Post by tomp »

pedrocr wrote: post #254
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…

>Rust features a lot of "cheating" - pointers that allow mutation from multiple threads You're confounding GC and synchronization of multi-threaded access here. What rust does with things like Arc other languages will need some other synchronization primitive to enable. Their GC or manual memory management does not guarantee the multi-threaded semantics. That's one of the advantages of the rust memory model, some pat…

No, Rust is conflating memory safery and multithreading safety.

JVM state-of-the-art GC guarantees multithreaded memory safety.

AFAIK many wait-free data structures are pretty much impossible without a GC.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#307

Post by dleslie »

norswap wrote: post #250
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…

Ridiculous. The problem is not that you don't know when/where the lifetime will end — that can usually be characterized by a terse "English" description. The problem is that this lifetime is dynamic in nature. The end of the lifetime of an object may coincide with some user input, for instance. At this point, either you go back to manual management, with the potential for errors (and for what it's worth, I think manu…

If the lifetime can be expressed with a state machine then it needn't be garbage collected so long as the language is sufficiently expressive.

Reference counting isn't garbage collection, as most people consider it. There is no need to sweep or otherwise traverse memory to discover objects that are not referenced.

Claiming that ref counting is gc is a bit like claiming malloc/free is gc.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#308

Post by rienbdj »

bunderbunder wrote: post #252
jandrewrogers wrote: post #230

Earlier quoted context omitted.

I tend to take the position that arguments about the merits of GCs are proxies for a different issue at a higher level of abstraction that is rarely tackled directly. One of the correctly argued advantages of GC is that it automatically handles some difficult edge cases like ambiguous lifetimes and cyclical references. In my opinion, there is an interesting discussion to be had around why these edge cases need to be…

This hits on something I've been wondering about lately: For those of us who might want some of the performance characteristics of Rust, but not to the extent that we're willing to take on all of the strictures it imposes, what's the feasibility of building a compiler that can avoid GC for objects whose lifetime can be determined statically, while still retaining GC for the rest? My (wild) guess is that it wouldn't a…

I think this was the promise of D. For some reason it's not very popular.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#309

Post by dleslie »

cblades wrote: post #302
irq11 wrote: post #292

Earlier quoted context omitted.

Having spent years writing code in both GC’ed and non-GC’ed languages, it’s pretty clear that it programmers spend about the same amount of time worrying about memory management with either paradigm. The main differences are that people using GC systems spend their time doing magical incantations to manage the GC wizard, and they’re a lot more smug about the goodness of their system.

>programmers spend about the same amount of time worrying about memory management with either paradigm I have no idea how you've come to that conclusion. For the vast majority of memory allocation in any GC'd language I can think of, you spend zero time thinking about memory management 98% of the time. whereas in a manual language, you must consider it every time you allocate memory . That's not a bad thing, it's oft…

For 95% of the code you write it's not a concern; that last 5% sure can eat up time if your software has any concern about performance.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#310

Post by notacoward »

jillesvangurp wrote: post #300
notacoward wrote: post #201

Earlier quoted context omitted.

> On servers, idling CPUs is the norm. The competition for "least true statement on HN" is always fierce, but you've just submitted a contender. All the people who have lots of servers work really hard to coalesce workloads and drive up utilization. I know because that's what I do, and it's what everyone around me does. It's why the cloud you use is cost-effective. The machines that are mostly idle are clients , not…

When do you start sending alerts? 10%, 50%, or 90% CPU? For us we like our cheap T2s. We have multiple for redundancy; not for performance reasons. All the places I've been tended to over provision servers to be able to deal with spikes in usage. 90% is typically bad news.

Whatever your alert threshold is, that still defines a fixed amount of work per machine and thus how many machines you need to satisfy a given workload. If you need 100 machines to stay below your alert threshold, and you make a 1% improvement in efficiency, you now need 99 machines to stay below that same threshold. Whatever it is. For just about any load distribution that's not already problematic (e.g. if all of the load gets concentrated on one machine you're screwed no matter what).

I work all day every day on dozens of clusters much bigger than that, and so do a lot of other people. For us, spending half a year to get a 1% improvement is an opportunity big enough to get excited about.

Post reply on HN