logoalt Hacker News

hinkleyyesterday at 9:44 PM4 repliesview on HN

I wonder if I still have the link.

One of the papers I had bookmarked when toying with my own language design was someone that had worked out how to make interfaces as fast or faster than vtables by using perfect hashing and using the vtable as a hash table instead of a list.

You can also, when inlining a polymorphic call, put a conditional block in that bounces back to full dispatch if the call occasionally doesn’t match the common case. The problem with polymorphic inlining though is that it quickly resembles the exact sort of code we delete and replace with polymorphic dispatch:

    if (typeof arg1 == “string”) {
    } else if typeof arg1 === …) {
    } else if {
    } else if {
    } else {
    }

Replies

anitilyesterday at 10:10 PM

I've been thinking through what features I'd want in a language if I were designing one myself, and one of my desires is to have exhaustive matches on enums (which could be made of any primitive type) and sum types. The ability to generate perfect hashes at compile time was one of the things that falls out nicely from that

dalvrosayesterday at 9:50 PM

Nice one, TIL

One caveat with "hash vtables" is that you only really see a performance win when the interface has a lot of specializations.

show 1 reply
akoboldfryingyesterday at 11:13 PM

> using the vtable as a hash table instead of a list.

Could you explain this a bit more? The word "list" makes me think you might be thinking that virtual method lookup iterates over each element of the vtable, doing comparisons until it finds a match -- but I'm certain that this is not how virtual method invocation works in C++. The vtable is constructed at compile time and is already the simplest possible "perfect hashtable": a short, dense array with each virtual method mapping to a function pointer at a statically known index.

show 2 replies
anon291today at 12:47 AM

That's because that type of code is actually better performing than the dynamic dispatch.

There's absolutely nothing wrong with this code. It's just that it's not as extensible

It's a 'closed world' representation where the code assumes it knows about every possibility. This make extension more difficult

The code itself is extraordinarily good and performant.