HN Simulatornew | past | comments | lists | submit | Sesse__'s commentslogin

Alexa was the 39th most popular baby girl name in the US in 2006. It is… not as popular for baby girls now.

> Whether reference counting is a GC algorithm depends on how you define what GC is.

Pretty much all the high-performance GC/refcounting algorithms are hybrids in one form or the other; it's a spectrum of choices. https://dl.acm.org/doi/10.1145/1028976.1028982 explores this in some detail.


That is a classic paper and obviously I am aware of it.

However, if you have distinct names it is efficient to use them with distinct meanings.

Making "garbage collection" synonymous with "freeing memory" is bad, because it eliminates a means to distinguish various methods for freeing memory.

Like I have said, I consider useful to define "garbage collection" as any method of freeing memory where the memory is not freed as soon as possible (i.e. when a block is exited), but freeing is deferred to be performed at a later time, even as late as possible (i.e. when new memory allocation requests cannot be satisfied).

Indeed, many garbage collection algorithms use reference counts, where memory deallocation is deferred, but when I use the term "reference counting" without any other qualifier, I mean it in the sense in which it was originally defined in 1960, where the time when memory deallocation is run is predictable, exactly like for stack-allocated memory.

I prefer to write programs with well-defined worst-case behavior, so I normally prefer deterministic algorithms. Thus I always prefer to use reference counts instead of GC. I have never encountered a case when avoiding reference cycles was difficult.


> but the point of CVEs is to let you make judgement calls

Realistically, most admins cannot make judgment calls about 1000+ CVEs for a kernel release.


And not only that, remember the hn crowd is not at all representative of the average.

Even more realistically, many admins do not have the background to be able to reason (by themselves) about the actual risk of most CVEs, so just going along with specialized media coverage is often a sound strategy.


>And not only that, remember the hn crowd is not at all representative of the average.

We should keep our hopes up, someday we may get there.


Usually the security team mandates a zero CVE policy on all deployments and the organization complies.

we in security teams can only dream of such incompetent management

zero CVE policy = halt on business development.


So, you basically want an economist to be President? Not unreasonable, and certainly not unheard of. At least the pool of candidates is pretty large.

Bartlet / Hoynes '98!

I've used LZO as a spam classifier on chat. Spam tends to be very content-less and repetitive...


Match-finding does not need to be quadratic. However, truly optimal gzip block splitting is very slow, indeed.


You're probably thinking of https://github.com/simonlindholm/decomp-permuter, which is used across many more decomp projects (and can do a lot more than swap lines). It's a huge help, but it's by no means enough for all regalloc differences; there's lots of stuff it cannot do.


https://decomp.dev/ is probably (roughly) what you're looking for.


> It’s AOT dynamic recompilation and the original IP isn’t distributed.

The Git repository contains tens of thousands of lines of assembler code that seem to come from the original.


I see that now… why did they check it in? One of the whole points of this approach is that that assembler should be trivial to re-derive by the end user since it’s just the original program listing. Some of the Xbox 360 recomp projects like https://github.com/mchughalex/skate3recomp offer a better example of how this pattern can be achieved without distributing the binary at any intermediate level.


They are designed by different teams and have different ways of doing math. You could just as easily say “why are the efficiency cores wasting an extra cycle for each multiplication doing fixups of an uncommon case”.

Fabian Giesen explains in more detail here: https://mastodon.gamedev.place/@rygorous/117277063419144390


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: