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 ztell...@gmail.com 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 ztel...@gmail.com 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. 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
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 ztell...@gmail.com 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
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 ztel...@gmail.com javascript: 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 javascript: 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 javascript: 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 javascript:. 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
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
-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.
