[swift-evolution] Proposal: Universal dynamic dispatch for method calls

[Chris Lattner]

> 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:
https://www.reddit.com/r/programming/comments/3wla9f/chris_lattner_author_of_the_swift_programming/cxx7k0m

>> 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.

>> Finally, while it is possible that a JIT compiler might be interesting someday in the Swift space, if we do things right, it will never be “worth it” because programmers will have enough ability to reason about performance at their fingertips.  This means that there should be no Java or Javascript-magnitude "performance delta" sitting on the table waiting for a JIT to scoop up.  We’ll see how it works out long term, but I think we’re doing pretty well so far.
> 
> 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.

-Chris