Re: What does Zach Tellman mean by "factored out for greater inlining joy"
Sure, absolutely - there's nothing like profiling to see what's actually going on and his recommendation seems sound either way, I just thought the information was interesting. On 11 August 2015 at 23:44, Zach Tellman wrote: > It's fluid, but the output that Norman uses in his post (and that > motivated the changes to Aleph) were from the JVM explicitly saying "I > would have inlined this, but it was too big". That may not be true under > other circumstances, but you're only helping by factoring out uncommon, > large code branches. > > On Tuesday, August 11, 2015 at 2:01:59 PM UTC-7, Colin Fleming wrote: >> >> That's a really interesting post, thanks for that. I actually cornered >> Cliff Click at Curry On because I was interested in knowing how well the >> JVM inlined var indirection. The short answer is "it's complicated". But if >> the JVM does inline your method, then the var indirection shouldn't cost >> you as long as the var content is stable. >> >> Tom Crayford's great talk at EuroClojure also pointed out that another >> thing which affects inlining is the stack depth, which can mean you're >> damned if you do and you're damned if you don't when trying to refactor to >> help with inlining. However Cliff said that all these limits are pretty >> fluid - it's not like a method over 325 bytecodes will never be inlined, if >> it's identified as hot that limit goes way up, and a relatively cold method >> can still be inlined even if it's small. >> >> I'd actually love to sit down and test this with Clojure sometime, but I >> never seem to find time for it. >> >> On 11 August 2015 at 21:00, Zach Tellman wrote: >> >>> The inlining part is explained very well by this blog post >>> http://normanmaurer.me/blog/2014/05/15/Inline-all-the-Things/ >>> >>> As for why I left all the repetition in there, I tend to let code expand >>> before getting annoyed and compacting it. Sometimes there's a commit >>> between those two events, sometimes there's not. In this case, you get to >>> see how the macro/abstraction sausage is made. >>> >>> Happy to answer any other questions, >>> Zach >>> >>> >>> On Sunday, August 9, 2015 at 9:38:51 AM UTC-7, Lawrence Krubner wrote: Reid, thank you. I think you answer half the question. You make a good point about giving the JVM a way to better optimize a hot path. I think you are right about that. But, given the large amount of repetition between "chain'-" and "chain-" I'm wondering why this wasn't done with a macro? On Sunday, August 9, 2015 at 2:08:47 AM UTC-4, Reid McKenzie wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lawrence, > > This is just a theory, but in the interests of response time, the JVM > uses a large number of heuristics to determine what optimizations will > likely prove profitable. One of them is a budget for method size. I > would guess that lifting this code out into a separate fn made the JVM > see that it was optimizing a hot path between the main body and > several small but tightly related methods thus giving itself more > leeway to inline and optimize in ways that it would otherwise presume > are more expensive and not pursue. > > Reid > -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post
Re: What does Zach Tellman mean by "factored out for greater inlining joy"
There's code splits like that in Clojure's RT.java too - things like seq() and seqFrom() have the same intention. We have run into cases where we blew the inlining budget and performance was affected. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What does Zach Tellman mean by "factored out for greater inlining joy"
It's fluid, but the output that Norman uses in his post (and that motivated the changes to Aleph) were from the JVM explicitly saying "I would have inlined this, but it was too big". That may not be true under other circumstances, but you're only helping by factoring out uncommon, large code branches. On Tuesday, August 11, 2015 at 2:01:59 PM UTC-7, Colin Fleming wrote: > > That's a really interesting post, thanks for that. I actually cornered > Cliff Click at Curry On because I was interested in knowing how well the > JVM inlined var indirection. The short answer is "it's complicated". But if > the JVM does inline your method, then the var indirection shouldn't cost > you as long as the var content is stable. > > Tom Crayford's great talk at EuroClojure also pointed out that another > thing which affects inlining is the stack depth, which can mean you're > damned if you do and you're damned if you don't when trying to refactor to > help with inlining. However Cliff said that all these limits are pretty > fluid - it's not like a method over 325 bytecodes will never be inlined, if > it's identified as hot that limit goes way up, and a relatively cold method > can still be inlined even if it's small. > > I'd actually love to sit down and test this with Clojure sometime, but I > never seem to find time for it. > > On 11 August 2015 at 21:00, Zach Tellman > > wrote: > >> The inlining part is explained very well by this blog post >> http://normanmaurer.me/blog/2014/05/15/Inline-all-the-Things/ >> >> As for why I left all the repetition in there, I tend to let code expand >> before getting annoyed and compacting it. Sometimes there's a commit >> between those two events, sometimes there's not. In this case, you get to >> see how the macro/abstraction sausage is made. >> >> Happy to answer any other questions, >> Zach >> >> >> On Sunday, August 9, 2015 at 9:38:51 AM UTC-7, Lawrence Krubner wrote: >>> >>> >>> Reid, thank you. I think you answer half the question. You make a good >>> point about giving the JVM a way to better optimize a hot path. I think you >>> are right about that. But, given the large amount of repetition between >>> "chain'-" and "chain-" I'm wondering why this wasn't done with a macro? >>> >>> >>> >>> On Sunday, August 9, 2015 at 2:08:47 AM UTC-4, Reid McKenzie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lawrence, This is just a theory, but in the interests of response time, the JVM uses a large number of heuristics to determine what optimizations will likely prove profitable. One of them is a budget for method size. I would guess that lifting this code out into a separate fn made the JVM see that it was optimizing a hot path between the main body and several small but tightly related methods thus giving itself more leeway to inline and optimize in ways that it would otherwise presume are more expensive and not pursue. Reid >>> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What does Zach Tellman mean by "factored out for greater inlining joy"
That's a really interesting post, thanks for that. I actually cornered Cliff Click at Curry On because I was interested in knowing how well the JVM inlined var indirection. The short answer is "it's complicated". But if the JVM does inline your method, then the var indirection shouldn't cost you as long as the var content is stable. Tom Crayford's great talk at EuroClojure also pointed out that another thing which affects inlining is the stack depth, which can mean you're damned if you do and you're damned if you don't when trying to refactor to help with inlining. However Cliff said that all these limits are pretty fluid - it's not like a method over 325 bytecodes will never be inlined, if it's identified as hot that limit goes way up, and a relatively cold method can still be inlined even if it's small. I'd actually love to sit down and test this with Clojure sometime, but I never seem to find time for it. On 11 August 2015 at 21:00, Zach Tellman wrote: > The inlining part is explained very well by this blog post > http://normanmaurer.me/blog/2014/05/15/Inline-all-the-Things/ > > As for why I left all the repetition in there, I tend to let code expand > before getting annoyed and compacting it. Sometimes there's a commit > between those two events, sometimes there's not. In this case, you get to > see how the macro/abstraction sausage is made. > > Happy to answer any other questions, > Zach > > > On Sunday, August 9, 2015 at 9:38:51 AM UTC-7, Lawrence Krubner wrote: >> >> >> Reid, thank you. I think you answer half the question. You make a good >> point about giving the JVM a way to better optimize a hot path. I think you >> are right about that. But, given the large amount of repetition between >> "chain'-" and "chain-" I'm wondering why this wasn't done with a macro? >> >> >> >> On Sunday, August 9, 2015 at 2:08:47 AM UTC-4, Reid McKenzie wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Lawrence, >>> >>> This is just a theory, but in the interests of response time, the JVM >>> uses a large number of heuristics to determine what optimizations will >>> likely prove profitable. One of them is a budget for method size. I >>> would guess that lifting this code out into a separate fn made the JVM >>> see that it was optimizing a hot path between the main body and >>> several small but tightly related methods thus giving itself more >>> leeway to inline and optimize in ways that it would otherwise presume >>> are more expensive and not pursue. >>> >>> Reid >>> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What does Zach Tellman mean by "factored out for greater inlining joy"
The inlining part is explained very well by this blog post http://normanmaurer.me/blog/2014/05/15/Inline-all-the-Things/ As for why I left all the repetition in there, I tend to let code expand before getting annoyed and compacting it. Sometimes there's a commit between those two events, sometimes there's not. In this case, you get to see how the macro/abstraction sausage is made. Happy to answer any other questions, Zach On Sunday, August 9, 2015 at 9:38:51 AM UTC-7, Lawrence Krubner wrote: > > > Reid, thank you. I think you answer half the question. You make a good > point about giving the JVM a way to better optimize a hot path. I think you > are right about that. But, given the large amount of repetition between > "chain'-" and "chain-" I'm wondering why this wasn't done with a macro? > > > > On Sunday, August 9, 2015 at 2:08:47 AM UTC-4, Reid McKenzie wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Lawrence, >> >> This is just a theory, but in the interests of response time, the JVM >> uses a large number of heuristics to determine what optimizations will >> likely prove profitable. One of them is a budget for method size. I >> would guess that lifting this code out into a separate fn made the JVM >> see that it was optimizing a hot path between the main body and >> several small but tightly related methods thus giving itself more >> leeway to inline and optimize in ways that it would otherwise presume >> are more expensive and not pursue. >> >> Reid >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What does Zach Tellman mean by "factored out for greater inlining joy"
Reid, thank you. I think you answer half the question. You make a good point about giving the JVM a way to better optimize a hot path. I think you are right about that. But, given the large amount of repetition between "chain'-" and "chain-" I'm wondering why this wasn't done with a macro? On Sunday, August 9, 2015 at 2:08:47 AM UTC-4, Reid McKenzie wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lawrence, > > This is just a theory, but in the interests of response time, the JVM > uses a large number of heuristics to determine what optimizations will > likely prove profitable. One of them is a budget for method size. I > would guess that lifting this code out into a separate fn made the JVM > see that it was optimizing a hot path between the main body and > several small but tightly related methods thus giving itself more > leeway to inline and optimize in ways that it would otherwise presume > are more expensive and not pursue. > > Reid > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What does Zach Tellman mean by "factored out for greater inlining joy"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lawrence, This is just a theory, but in the interests of response time, the JVM uses a large number of heuristics to determine what optimizations will likely prove profitable. One of them is a budget for method size. I would guess that lifting this code out into a separate fn made the JVM see that it was optimizing a hot path between the main body and several small but tightly related methods thus giving itself more leeway to inline and optimize in ways that it would otherwise presume are more expensive and not pursue. Reid -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
What does Zach Tellman mean by "factored out for greater inlining joy"
I'm always interested in anything Zach Tellman does, though I don't always understand it. I see that he defines a function twice, via (let), of which he says "factored out for greater inlining joy". Does anyone know what he means by that? Can anyone suggest a reason why this was more convenient that writing a macro? And what is the point of the repetition? I feel lost. https://github.com/ztellman/manifold/blob/4e1fff70c5380b33e9cc2f50f03ce16af6d393b4/src/manifold/deferred.clj#L705 (let [;; factored out for greater inlining joy subscribe (fn ([this d x] ( let [d (or d (deferred))] (on-realized x #(this d %) #(error! d %)) d)) ([this d x f] (let [d (or d (deferred))] (on-realized x #(this d % f) #( error! d %)) d)) ([this d x f g] (let [d (or d (deferred))] (on-realized x #(this d % f g) #(error! d %)) d)))] https://github.com/ztellman/manifold/blob/4e1fff70c5380b33e9cc2f50f03ce16af6d393b4/src/manifold/deferred.clj#L799 (let [;; factored out for greater inlining joy subscribe (fn ([this d x] (let [d (or d (deferred))] (on-realized x #(this d %) #(error! d %)) d)) ([this d x f] (let [d (or d (deferred))] (on-realized x #(this d % f) #(error! d %)) d)) ([this d x f g] (let [d (or d (deferred))] (on-realized x #(this d % f g) #(error! d %)) d)))] -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
