[swift-evolution] Proposal: Universal dynamic dispatch for method calls
clattner at apple.com
Sun Dec 13 15:18:55 CST 2015
> On Dec 12, 2015, at 3:36 PM, Slava Pestov <spestov at apple.com> wrote:
>> On Dec 11, 2015, at 11:45 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 3. C++: C++ is a step up from C in terms of introducing dynamism into the model with virtual functions. Sadly, C++ also provides a hostile model for static optimizability - the existence of placement new prevents a lot of interesting devirtualization opportunities, and generally makes the compiler’s life difficult.
> Interesting, I haven’t heard that placement new is problematic before. What are the problems involved (feel free to reply off-list). Is it legal to use placement new to replace an existing instance and change its vtable pointer or do aliasing rules prohibit that?
It looks like there was a recent discussion on reddit that explained more:
>> The upshot of this is that Swift isn’t squarely in either of the static or dynamic camps: it aims to provide a very predictable performance model (someone writing a bootloader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence)
> To be fair, we still emit implicit heap allocations for value types whose size isn’t known. So your boot loader will have to avoid generics (and non- at noescape closures), at least :-)
Yes. I would expect such system code to be built in a mode that would warn or error when any of these occurred. These are all statically knowable situations.
> Actually, for code within a single module, are we always able to fully instantiate all generics?
We have the mechanics & design to do that, but I don’t thing we have any user-visible way to expose it. There is certainly more to be done in any case.
> JITs can teach us a lot about optimizing for compile time though, which would help REPL usage, tooling and scripting.
Absolutely. I’m not anti-JIT at all, and in fact our REPL and #! script mode use a JIT (as I’m sure you know).
I was trying to convey that building a model that depends on a JIT for performance means it is very difficult to practically target spaces where a JIT won’t work (e.g. because of space constraints). If you have a model that doesn’t rely on a JIT, then a JIT can provide value add.
More information about the swift-evolution