Hacker News Reader

Comment by baobrien | Hacker News Reader

huh, this is fun: https://lore.kernel.org/lkml/ZFrBEsjrfseCUzqV@moria.home.lan...

There's a little x86-64 code generator in bcachefs to generate some sort of btree unpacking code.

This is also the point which is the most likely to cause problems for this patch series (which is only fixes and utils added to the kernel) and the bcachefs in general.

Like when you have an entry like "bring back function which could make developing viruses easier (through not a vulnerability by themself) related to memory management and code execution" the default answer is nop .. nooop .. never. (Which doesn't mean that it won't come back).

It seems while it's not necessary to have this it's a non-neglible performance difference.

It would be really nice if he posted the difference with/without the optimisation for context. I hope it's going to be included in the explanation post he's planning.

It looks like the code generator is only available for x86 anyway, so it seems niche that way. I am all about baseline being good performance, not the special case.

He mentions he wants to make the same type of optimization for ARM, so ARM+x86 certainly wouldn't be niche.

I wouldn't even call x86 alone niche...

With eyes on portability, any single-arch-specific code is niche

I'll be eagerly waiting for the upcoming optimization writeup mentioned here: https://lore.kernel.org/lkml/ZFyAr%2F9L3neIWpF8@moria.home.l...

Please post it on HN because I won't remember to go looking for it.

It's bad enough that the kernel includes a JIT for eBPF. Adding more of them without hardware constraints and/or formal verification seems like a bad idea to me.

yeah, most of the kernel maintainers in that thread seem to be against it. bcachefs does seem to also have a non-code-generating implementation of this, as it runs on architectures other than x86-64.

Reply on news.ycombinator.com