undefined | Better HN

0 pointskristoff_it8mo ago0 comments

> (And before anyone mentions it, devirtualization is a myth, sorry)

In Zig it's going to be a language feature, thanks to its single unit compilation model.

https://github.com/ziglang/zig/issues/23367

0 comments

Wouldn't this only work if there's only one implementation throughout the entire compliation unit? If you use 2 allocators in your app, your restricted function type has 2 possible callees for each entry, and you're back to the same problem.

Zambyte8mo ago

> A side effect of proposal #23367, which is needed for determining upper bound stack size, is guaranteed de-virtualization when there is only one Io implementation being used (also in debug builds!).

> In the less common case when a program instantiates more than one Io implementation, virtual calls done through the Io interface will not be de-virtualized, as that would imply doubling the amount of machine code generated, creating massive code bloat.

From the article

yxhuvud8mo ago

I wonder how massive it actually would be. I'm guessing it really wouldn't be all that massive in practice even if it of course is easy to create massive examples using ways people typically don't write code.

thrwyexecbrain8mo ago

Having a limited number of known callees is already better than a virtual function (unrestricted function pointer). A compiler in theory could devirtualize every two-possible-callee callsite into `if (function_pointer == callee1) callee1() else callee2()` which then can be inlined at compile time or branch-predicted at runtime.

In any case, if you have two different implementations of something then you have to switch between them somewhere -- either at compile-time or link-time or load-time or run-time (or jit-time). The trick is to find an acceptable compromise of performance, (machine)code-bloat and API-simplicity.

throwawaymaths8mo ago

> Wouldn't this only work if there's only one implementation throughout the entire compliation unit

in practice how often are people using more than one io in a program?

latch8mo ago

I think having a thread pool on top of some evented IO isn't _that_ uncommon.

You might have a thread pool doing some very specific thing. You can do your own threadpool which wont use the Io interface. But if one of the tasks in the threadpool wanted to read a file, I guess you'd have to pass in the blocking Io implementation.

1 more reply

NobodyNada8mo ago

In larger Rust applications or servers I find myself doing this very often -- for example, one application I'm working on mostly uses blocking I/O for occasional filesystem access but has a little bit of async networking.

j / k navigate · click thread line to collapse