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 <kelvin1...@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 <spes...@apple.com > <mailto:spes...@apple.com>> wrote: > > >> On Oct 4, 2017, at 11:04 PM, Taylor Swift <kelvin1...@gmail.com >> <mailto:kelvin1...@gmail.com>> wrote: >> >> >> >> On Oct 5, 2017, at 12:52 AM, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>> >>> >>>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
