News for hackers. Stuff that matters.
Re:Apple Silicon M1: Black Magic Fuckery by jandrese on Tuesday November 24, 2020 @09:13PM (#25205259)
I think it's more a design pattern you see more with GC collected languages where people instantiate objects with pretty much every action and then let the the GC handle the mess afterward. Every function call involves first creating a parameters object, populating it, then forgetting about it immediately afterward.

I've seen this with java where the memory usage graph looks like a sawtooth, with 100s of MB being allocated and then freed up a couple of seconds later.

Re:Apple Silicon M1: Black Magic Fuckery by jhgb on Wednesday November 25, 2020 @03:18AM (#25207014)
Isn't it the case with Java that it will do this because you do have the memory to spend on it? Generally this "handling the mess afterward" involves some kind of nursery or early generation these days, but their size may be use-case-dependent. If tuned for a 8/16 GB environment, presumably the "sawtooth" wouldn't need to be as tall.
Re:Apple Silicon M1: Black Magic Fuckery by notriddle on Wednesday November 25, 2020 @10:22AM (#25210123)
Yes, but the reason it does it is to make it fast. The shorter your sawtooth spokes, the slower your app.
Re:Apple Silicon M1: Black Magic Fuckery by jhgb on Wednesday November 25, 2020 @02:24PM (#25213155)
Slower in what metrics? Latency? Throughput? Not to mention that the behavior may strongly depend on the GC design and the HW platform in question. It seems far too difficult to make a blanket statement about what is and isn't achievable in a specific use case.