<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 12:01 AM, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.</div></div></blockquote><div><br class=""></div><div>The support for publishing static specializations is envisioned in the current implementation of @_specialize already, though it is not well tested yet.</div><div><br class=""></div><div>If you use the "exported: true" parameter with @_specialize, the body of the produced specialization would not be SIL serialized, but it will emitted into the object file of the defining module and the specialized function will be made available as a public symbol in the object file, so that the clients can link against it and invoke it directly. Since clients can refer to this symbol now, it cannot be removed in the future versions of the library as it would break all such clients linked against it.</div><div><br class=""></div><div><div>@_specialize(exported: true, where K == Int, V == Int)</div><div>func foo<K, V>(dict: Dictionary<K, V>) {</div><div>}</div><div><br class=""></div><div>We could also allow for making those exported specializations @inlinable if required by the user.</div><div><br class=""></div><div>-Roman</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Slava<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 4, 2017, at 11:47 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">See <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038571.html" class="">the thread</a> from july over generic trig functions, where <span style="font-family:monospace,monospace" class="">@_specialize()</span> + <span style="font-family:monospace,monospace" class="">@_inlineable</span> had a small but consistent performance penalty relative to <span style="font-family:monospace,monospace" class="">@_inlineable</span> alone.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov <span dir="ltr" class=""><<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="h5"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 4, 2017, at 11:04 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-1619780893127709301Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Oct 5, 2017, at 12:52 AM, Slava Pestov <<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1619780893127709301Apple-interchange-newline"><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">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.</span></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Slava</div></div></blockquote><br class=""><div class="">Is there a reason using @_specialize() and @_inlineable together is slower than using @_inlineable by itself?</div></div></div></blockquote></div><br class=""></div></div><div class="">By specialization, I mean the optimizer pass which takes a function body and substitutes generic parameters with statically-known types.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Slava</div></font></span></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>