191–200 of 460 posts
Earlier quoted context omitted.
Could that not be hardware implemented / augmented?
It could be, but then after investing a billion dollars what happens when someone develops another algorithm? What happens when a programming language with different gc requirements become popular?
Earlier quoted context omitted.
This is not only a dated paper (a decade and a half old), but it relies on assumptions that do not necessarily hold in practice. If you test actual allocation performance on actual current day hardware, you may end up with completely different results, e.g.: https://github.com/rbehrends/btree-alloc
That's a very fresh repo. I wonder how GHC would fare. I guess I should contribute.
If I were to expand it, I'd look at other allocation patterns rather than more languages; I've already good a fairly good cross-section of garbage collectors and malloc() implementations, so I don't really need any more.
They're comparing to an in-order CPU. Given that most CPUs are out-of-order (at least of the non-embedded variety, and GC is less used in such applications anyway), it would be better and more intellectually honest to actually compare to a typical CPU that performs GC. They kind of address this in the paper but only in a short aside: "Note that previous research [1] showed that out-of-order CPUs, while moderately fas…
Imagine a linked list. Each pointer access is likely to miss to main memory, and no concurrency is possible. Both the highest and lowest end cores will sit around making a single request every 80ns.
They claim that the comparison was to the best alternative and I'd probably take them at their word barring any specific evidence.
Earlier quoted context omitted.
> 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…
> But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. And that's why so much effort has gone into making it fast and low latency, but it was a false dichotomy: We can have memory safety without garbage collection. - Automatic reference counting: Most people know about Objective-C's efforts in this space, but it's admittedly less automatic than programmers wou…
Earlier quoted context omitted.
if you have a decade of C then you know its not slower unless mistakes are made
if you believe that then you have no idea how Garbage Collectors work, period.
Earlier quoted context omitted.
In taxonomy, I say we have "automatic memory management" when we have some kind of `malloc()` type device and no need to `free()` it. Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff. Every theory about why GC can work (or be useful) is predicated on the idea that there is more garbage than live objects so you're touching less stuff. If all you do is mark/sweep,…
> Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff That's a description of tracing GC, not a definition of GC. GC is whatever technology that enables what you've called automatic memory management: a kind of illusion that there is infinite memory, from the programmer's perspective. That might involve some mix of reference counting (Python is probably the biggest…
That's definitely not what McCarthy meant by it. I understand that's probably a common view nontheless, but I can use sbrk() and the fact my computer has gobs of ram/swap, and I'm not going to call that garbage collection. I don't think this definition is useful.
If you re-read what I wrote now understanding what I mean when I say "garbage collection", perhaps we can talk about strategies for providing that infinite view of memory instead.
Earlier quoted context omitted.
Not necessarily no. Just as having type information doesn't lead to a better program. But it helps. And is something you need to reason about regardless. Being explicit about it isn't a huge overhead but has lots of benefits.
Being explicit usually means that you have to drop whole classes of optimizations, or manually perform the analysis yourself (probably resulting in errors).
One talking point I'd like to ask is: For small short lived scripts and applications, do we even need to free any memory these days? For example you write a script which takes several seconds to execute, moves files, computes stuff with strings, etc. Should we really invest time and effort in the script interpreter to free the memory, where instead we can just exit normally and let the OS handle the clean up. I would…
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…
Exactly! And that is the biggest advantage of not relying on a GC, it is easier to detect awkward usage and requires more thought upfront (but not any more than what is actually needed).
This results in less bugs and easier maintenance.
>> consumes a lot of computational power—up to 10 percent or more of the total time a CPU spends on an application. I stopped reading there. 10% is nothing. For such a useful feature as automatic garbage collection, for the vast majority of applications, I'd gladly give away 50% of the CPU. In terms of ensuring code correctness and robustness, if I had to choose static typing or automatic garbage collection, I'd pick…
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 have a million machines, even a 0.1% improvement on either axis is huge. That's racks upon racks worth of equipment that doesn't need to be installed, powered, or maintained. If I could save 10% of 10% ("nothing" according to you) across such a large fleet, I'd be a hero and I'd be rewarded accordingly.