[swift-dev] Zero-cost 'Service Provider Interface'/Signature Packages

[Erik Eckstein]

> On Nov 10, 2017, at 3:05 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
> 
>> On Nov 8, 2017, at 9:59 PM, Erik Eckstein via swift-dev <swift-dev at swift.org> wrote:
>> 
>> 
>> 
>>> On Nov 8, 2017, at 5:27 PM, Johannes Weiß via swift-dev <swift-dev at swift.org> wrote:
>>> 
>>> Hi Daniel,
>>> 
>>>> On 2 Nov 2017, at 8:15 pm, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
>>>> 
>>>> My personal preference is to:
>>>> 1. Do nothing for now, but encourage publishing standardized protocols to solve this need.
>>>> 2. Hope for a future with WMO+LTO magic which recovers the performance, for the case where the entire application ends up using one implementation.
>>> 
>>> Hmm, but that'll only work if we get 'whole product optimisation', right?
>> 
>> yes.
>> 
>> Even when we have cross-module optimizations (which would be comparable to thin-lto) we could not do that optimization.
>> 
>>> If we still compile one module at the time I don't think the compiler will be able to figure out that there's just one implementation of that protocol in the whole program.
>> 
>> exactly
> 
> If you know you're building for an executable target, then it should be theoretically possible to look at the whole system and see that there's a single conformance to a protocol. For the situation Johannes is talking about, maybe this could be information that the build system feeds the compiler, so in a configuration file somewhere you'd say "I want to specialize all uses of the Logger.Logger protocol for the FancyLogger.FancyLogger<MyOutputStream> implementation" instead of relying on the compiler magically deriving it.

Actually, speculative-devirtualization of protocol methods + cross-module optimization should be able to handle this. The only drawback is code size, which is fortunately not so important for that project.


> 
> -Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171110/ec6feb98/attachment.html>