That's cool.
-
-
Replying to @mcclure111 @jckarter
to be clear: vtable pointers are never part of a struct, they are either in the ref-counting header of a box, or passed as an "argument" to polymorphic code. this must be, as e.g. Array<T> lays out struct values inline and has the same layout in polymorphic and specialized code
1 reply 0 retweets 1 like -
that sounds smart. to be clear, the "passed as an argument" is invisible to the user?
1 reply 0 retweets 1 like -
-
you can find a bunch of notes on how generic type metadata is represented here: https://github.com/apple/swift/blob/master/docs/ABI/TypeMetadata.rst … (probably slightly out of date, they made lots of changes in the run up to ABI stability)
1 reply 0 retweets 1 like -
aw bummer, joe did y'all really rip out all the cute vtable entries for "$primitive_op, but do it for an array"? stupid well-defined is_pod query and "caring about code size" and "we have to generate this vtables at runtime oh god" ruining all the fun.
1 reply 0 retweets 1 like -
Replying to @Gankra_ @mcclure111
My next wild idea is to represent the type layout as a bitstring showing where the refcounted are instead of a vtable of primitive operations. Chances are this could end up being faster for runtime-generated types than going through n layers of unspecialized goo
2 replies 0 retweets 0 likes -
I tried this for Rust once! It didn’t go well, but maybe Swift will do better
1 reply 0 retweets 1 like -
What problems did you run into?
1 reply 0 retweets 0 likes -
I wrote an entire VM in C++ templates to interpret these layouts as quickly as possible to adjust reference counts and such. It was a large speed penalty (~30% of time profile of Rust code was spent in it or something) and didn’t even reduce code size that much.
2 replies 0 retweets 0 likes
But this was used for everything; the compiler had no specialization at all. So maybe things would be different if this was only for cold code.
-
-
I was pretty burned on the whole approach after that and resolved that I’ll just use an interpreter and/or a JIT if I ever wanted to avoid template specialization again. Maybe I should have tried harder, but that was the result.
1 reply 0 retweets 0 likes -
You know, I have a sneaking suspicion that a “PGO” for Rust that did nothing more than replace cold functions with MIR and interpret them with Miri would probably be disgustingly effective at reducing code size without much perf hit I don’t think we should do this of course :)
1 reply 0 retweets 5 likes - 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.