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

An in-depth look at OCaml’s new “best-fit” garbage collector strategy

ocamlpro.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#11

Post by jjoonathan »

ignoramous wrote: post #8
jjoonathan wrote: post #6

Hell is other peoples' algorithmic choices. My GC-fu isn't high level enough to comment on this one, but I just spent the last two days suffering in dependency hell because someone thought it would be a good idea to use a full-blown SAT solver for package management. Grr.

> ...someone thought it would be a good idea to use a full-blown SAT solver for package management Relevant: https://research.swtch.com/version-sat

Right. SAT solvers are an excellent theoretical fit and a terrible practical fit, at least at the current state of tooling. Their runtime _does_ explode and the tooling _is not_ any good at hinting as to why even when the explanation turns out to be very simple. "lol install takes an hour now" makes for a very poor error message, and debugging a black box that takes an hour to evaluate each input is just.... ugggggghh, and I can only thank my lucky stars that it did finish after an hour rather than taking an indefinite amount of time.

In contrast, the "danger" of heuristics is that they fail to dig up an exceedingly clever combination of archaic package versions that technically fit the user's specified requirements. It's such a small problem that it might even be considered a feature, since said exceedingly clever combinations are likely to be the result of poor version definitions and unlikely to be what the user actually wants.

Of course, if the only people who can be persuaded to write package managers are people doing research in the subject, then I suppose letting them inflict their pet projects on us is one way to compensate them for an otherwise thankless task, and perhaps in that sense it's fair.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#12

Post by marcinzm »

pjmlp wrote: post #10
StreamBright wrote: post #2

"Remember that whatever works best for you, it’s still better than having to malloc and free by hand. Happy allocating!" Nice, they are saying exactly the same as those pesky game developers. https://www.youtube.com/watch?v=tK50z_gUpZI

Yeah, like Tim Sweeney. "It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." https://twitter.com/timsweeneyepic/status/880607734588211200 https://wiki.unrealengine.com/Garbage_Collection_Overview Which was it again, the engine chosen by Nintendo, Microsoft and Google as first party to their 3D APIs? https://developer.nintendo.com…

>"It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection."

Why is that surprising?

Games are basically about humans predicting things and random spikes prevent that from happening in time sensitive games. Beyond game play implications, I suspect there's also something about jerkiness in movement that bugs human senses.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#13

Post by sgrove »

marcinzm wrote: post #12
pjmlp wrote: post #10

Earlier quoted context omitted.

Yeah, like Tim Sweeney. "It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." https://twitter.com/timsweeneyepic/status/880607734588211200 https://wiki.unrealengine.com/Garbage_Collection_Overview Which was it again, the engine chosen by Nintendo, Microsoft and Google as first party to their 3D APIs? https://developer.nintendo.com…

>"It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." Why is that surprising? Games are basically about humans predicting things and random spikes prevent that from happening in time sensitive games. Beyond game play implications, I suspect there's also something about jerkiness in movement that bugs human senses.

It's not entirely surprising, but one might imagine a different approach: always allocate a 1% buffer for an unexpected GC.

It's not a very satisfactory answer (and there are likely much better tradeoffs to be made), but given the 10x and 1% comparison (not entirely apples to apples though) the comment sounds a bit more interesting.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#14

Post by whateveracct »

pjmlp wrote: post #10
StreamBright wrote: post #2

"Remember that whatever works best for you, it’s still better than having to malloc and free by hand. Happy allocating!" Nice, they are saying exactly the same as those pesky game developers. https://www.youtube.com/watch?v=tK50z_gUpZI

Yeah, like Tim Sweeney. "It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." https://twitter.com/timsweeneyepic/status/880607734588211200 https://wiki.unrealengine.com/Garbage_Collection_Overview Which was it again, the engine chosen by Nintendo, Microsoft and Google as first party to their 3D APIs? https://developer.nintendo.com…

When you're doing gamedev & are bumping up against your FPS, the GC is just another form of memory management. Doing GC-per-frame tends to work pretty well with a generational GC (generational hypothesis & frame-by-frame updates go hand-in-hand), but you usually have to take care about long-lived data. That's when you end up getting into more manual memory management combined with a GC. In a way, your GC'd high-level language RTS ends up being your scripting language.

That's how I've been thinking about it with Haskell at least (lots of GC knobs, manual performGC hook, compact regions for having long-lived data, good FFI, as high-level as any scripting language you could hope for)

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#15

Post by StreamBright »

pjmlp wrote: post #10
StreamBright wrote: post #2

"Remember that whatever works best for you, it’s still better than having to malloc and free by hand. Happy allocating!" Nice, they are saying exactly the same as those pesky game developers. https://www.youtube.com/watch?v=tK50z_gUpZI

Yeah, like Tim Sweeney. "It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." https://twitter.com/timsweeneyepic/status/880607734588211200 https://wiki.unrealengine.com/Garbage_Collection_Overview Which was it again, the engine chosen by Nintendo, Microsoft and Google as first party to their 3D APIs? https://developer.nintendo.com…

I guess this mentality leads to the current state of play where all UI related latencies are out of the roof compare to the 80s. At work, I deal with systems that require 16G of heap as the minimum. Funnily when things get rewritten in Rust providing the exact same functionality and the same or better performance the memory requirement goes down 10x (or more). It is up to us how much garbage our systems producing, how much CO2 is wasted on this. I guess many of us are ok with it. While some of us are not. https://blog.discordapp.com/why-discord-is-switching-from-go...

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#16

Post by StreamBright »

k__ wrote: post #7
StreamBright wrote: post #2

"Remember that whatever works best for you, it’s still better than having to malloc and free by hand. Happy allocating!" Nice, they are saying exactly the same as those pesky game developers. https://www.youtube.com/watch?v=tK50z_gUpZI

What's their opinion on Rust?

Great question. I am really hoping that the non-GC world is taking off with Rust.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#17

Post by Jhsto »

k__ wrote: post #7
StreamBright wrote: post #2

"Remember that whatever works best for you, it’s still better than having to malloc and free by hand. Happy allocating!" Nice, they are saying exactly the same as those pesky game developers. https://www.youtube.com/watch?v=tK50z_gUpZI

What's their opinion on Rust?

I would imagine excited. Rust's affine type system is an application of logic theory. OCaml is initially French academic production and (from an anecdotal experience) those academics tend to dis how impure most software (and memory management) is. While Rust does not have the purest theoretical foundations, it's still fresh air and will likely result in people paying more attention to the work of researchers in theoretics.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#18

Post by whateveracct »

StreamBright wrote: post #15
pjmlp wrote: post #10

Earlier quoted context omitted.

Yeah, like Tim Sweeney. "It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." https://twitter.com/timsweeneyepic/status/880607734588211200 https://wiki.unrealengine.com/Garbage_Collection_Overview Which was it again, the engine chosen by Nintendo, Microsoft and Google as first party to their 3D APIs? https://developer.nintendo.com…

I guess this mentality leads to the current state of play where all UI related latencies are out of the roof compare to the 80s. At work, I deal with systems that require 16G of heap as the minimum. Funnily when things get rewritten in Rust providing the exact same functionality and the same or better performance the memory requirement goes down 10x (or more). It is up to us how much garbage our systems producing, ho…

I've seen multiple production systems rewritten in Rust and the consensus of the developers working on it is that, while the Rust version was more performant, the majority of that performance is attributable to the rewrite itself and not the language. And that a performance-focused rewrite in the original language would have also seen huge performance gains.

As the truism goes, if you require your software to be performant, you must first make Performance a Requirement.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#20

Post by [deleted] »

StreamBright wrote: post #15
pjmlp wrote: post #10

Earlier quoted context omitted.

Yeah, like Tim Sweeney. "It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection." https://twitter.com/timsweeneyepic/status/880607734588211200 https://wiki.unrealengine.com/Garbage_Collection_Overview Which was it again, the engine chosen by Nintendo, Microsoft and Google as first party to their 3D APIs? https://developer.nintendo.com…

I guess this mentality leads to the current state of play where all UI related latencies are out of the roof compare to the 80s. At work, I deal with systems that require 16G of heap as the minimum. Funnily when things get rewritten in Rust providing the exact same functionality and the same or better performance the memory requirement goes down 10x (or more). It is up to us how much garbage our systems producing, ho…

[deleted]
Post reply on HN