[swift-evolution] Pitch: Cross-module inlining and specialization

[Taylor Swift]

why is runtime dispatch even necessary? Why can’t the client just call the
specialized version directly?

On Thu, Oct 5, 2017 at 2:01 AM, Slava Pestov <spestov at apple.com> wrote:

> Oh right. @_specialize modifies the original entry point to do runtime
> dispatch among the possible specializations. So the overhead comes from the
> unnecessary checks. I guess ideally we would have two versions of
> @_specialize, one adds the runtime dispatch whereas the other one just
> publishes static specializations which can be deserialized and used as
> needed.
>
> Since @_specialize is not an officially supported attribute though, I
> would suggest punting this discussion until someone decides to push through
> an evolution proposal for it. For all intents and purposes, @inlinable is a
> superset of @_specialized because it defers the specialization decisions to
> the client.
>
> Slava
>
>
> On Oct 4, 2017, at 11:47 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> See the thread
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038571.html>
> from july over generic trig functions, where @_specialize() + @_inlineable
> had a small but consistent performance penalty relative to @_inlineable
> alone.
>
> On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov <spestov at apple.com> wrote:
>
>>
>>
>> On Oct 4, 2017, at 11:04 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>
>>
>>
>> On Oct 5, 2017, at 12:52 AM, Slava Pestov <spestov at apple.com> wrote:
>>
>>
>>
>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> i’m just tryna follow along here && this is probably a dumb question, but
>> is it possible for a generic function to be emitted as a set of specialized
>> functions into the client, but not inlined everywhere? It can be the case
>> where a large generic function gets slowed down by the large number of
>> generic operations inside it but it doesn’t make sense for it to be inlined
>> completely.
>>
>>
>> This is already possible. The optimizer doesn’t have to inline an
>> @_inlineable function at its call site; it can emit a call to a specialized
>> version instead.
>>
>> Slava
>>
>>
>> Is there a reason using @_specialize() and @_inlineable together is
>> slower than using @_inlineable by itself?
>>
>>
>> By specialization, I mean the optimizer pass which takes a function body
>> and substitutes generic parameters with statically-known types.
>>
>> I’m not sure what your question means though. Adding a @_specialize
>> attribute should never make anything slower. Rather it makes the optimizer
>> eagerly emit specializations of a function in the defining module. You can
>> think of @_specialize and @inlinable as mostly mutually exclusive; either
>> you publish the complete function body for clients to optimize as they
>> please, or you publish a fixed set of specializations.
>>
>> You might prefer the latter for secrecy (serialized SIL is much closer to
>> source code than machine code), but the the former enables more general
>> optimizations.
>>
>> Slava
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171005/2f9c47bd/attachment.html>