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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > >> >> >> On Oct 4, 2017, at 11:04 PM, Taylor Swift <[email protected]> wrote: >> >> >> >> On Oct 5, 2017, at 12:52 AM, Slava Pestov <[email protected]> wrote: >> >> >> >> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution < >> [email protected]> 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 >> > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
