that sounds smart. to be clear, the "passed as an argument" is invisible to the user?
-
-
-
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.
1 reply 0 retweets 1 like -
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 :)
-
-
You should totally do it. I suspect an interpreter is the right answer even for unspecialized Swift code, since it's already a bunch of indirect jumps anyway
1 reply 0 retweets 1 like -
Yeah, I'd be very tempted to do an interpreter for Swift in your position. Could even allow for some cool hot code reload and instant feedback, and maybe even dynamic code generation on iOS devices
1 reply 0 retweets 0 likes - 4 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.