Re: [racket-users] Optimizing closures
At Fri, 31 Jul 2015 18:56:15 +0100, Laurent wrote: > On Fri, Jul 31, 2015 at 5:40 PM, Matthew Flatt wrote: > > > At Fri, 31 Jul 2015 15:03:53 +0100, Laurent wrote: > > > I don't really understand why `in-range` makes such a difference. It > > looks > > > like the kind of sequence iterator is tested at each step, whereas I was > > > expecting it to be tested only at the beginning of the loop, since this > > > sequence iterator kind can't change from one iteration to the next, > > right? > > > > > > Hence, I was expecting the `in-range` (and actually all other `in-*`) > > issue > > > to appear only inside nested loops, where some loops are started many > > times > > > (thus requiring many iterator kind tests). > > > > Right: The `in-*` functions tell `for` what kind of step operations to > > inline into the loop (after an initial guard that confirms that it has > > a number, list, etc., to iterate through). Otherwise, there's a > > run-time dispatch to take each step, which is usually more significant > > than a run-time dispatch to set up the loop. > > > > Apparently the optimizer is looking very specifically for `in-range`. This: > > (define my-in-range in-range) > (time (for ([x (my-in-range 4000)]) > (+ x 3))) > > is as slow as not using `in-range` at all, which I find rather strange. It's really the `for` macro that recognizes `in-*`. The expansion of a `for` form is too complex for the optimizer to see through the levels of dispatching. Giving macros more power to interact with the optimizer is a long-term goal, but it's beyond the things that Racket macros can do right now. > By "run-time dispatch", do you mean that the check of which kind the > argument is is done at each iteration? No... > Isn't it possible to test this only on the very first iteration? Then the > rest of the loop should be as fast as with `in-range`. The fact that `add1` should be used for stepping is determined once at the start of the loop. Since that determination is dynamic, however, the call to `add1` is not static in the bytecode, and so the JIT doesn't inline `add1`. Some JITs would detect that `add1` turns out to be the stepping function on the first iteration, when the loop is compiled. Then, the JIT would optimistically generate a faster path for future iterations where `add1` turns out to be the stepping function. It's possible that Racket's JIT could do that and achieve some intermediate performance --- not as fast as `in-range` but better than current performance without `in-range`. I'll have to try some experiments. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
On Fri, Jul 31, 2015 at 5:40 PM, Matthew Flatt wrote: > At Fri, 31 Jul 2015 15:03:53 +0100, Laurent wrote: > > I don't really understand why `in-range` makes such a difference. It > looks > > like the kind of sequence iterator is tested at each step, whereas I was > > expecting it to be tested only at the beginning of the loop, since this > > sequence iterator kind can't change from one iteration to the next, > right? > > > > Hence, I was expecting the `in-range` (and actually all other `in-*`) > issue > > to appear only inside nested loops, where some loops are started many > times > > (thus requiring many iterator kind tests). > > Right: The `in-*` functions tell `for` what kind of step operations to > inline into the loop (after an initial guard that confirms that it has > a number, list, etc., to iterate through). Otherwise, there's a > run-time dispatch to take each step, which is usually more significant > than a run-time dispatch to set up the loop. > Apparently the optimizer is looking very specifically for `in-range`. This: (define my-in-range in-range) (time (for ([x (my-in-range 4000)]) (+ x 3))) is as slow as not using `in-range` at all, which I find rather strange. By "run-time dispatch", do you mean that the check of which kind the argument is is done at each iteration? Isn't it possible to test this only on the very first iteration? Then the rest of the loop should be as fast as with `in-range`. I'm certainly missing something here (unless it's only a question of spending the necessary time to implement this, rather than a question of feasibility?). > At Fri, 31 Jul 2015 16:41:51 +0100, Laurent wrote: > > My question still holds though: Can I expect the JIT to optimize the > cases > > of my primary concern? (Or are these cases unlikely to be a bottleneck?) > > I'm unsure about how to set up correct stress tests as the JIT does a > good > > job at optimizing a number of things and then I'm not sure what precisely > > I'm measuring. > > I think you should expect optimization in cases like this, but you'll > be disappointed sometimes. All optimizations are hueristics, and > heuristics for inlining (the relevant optimization here) are especially > tricky. I think the v6.2 difference is probably a result of Gustavo's > refinements to the heuristics for inlining. > The Optimization Coach helps you with one reliable strategy for dealing > with the optimizer, which is to compile some code and see what the > optimizer does. > Thanks. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
At Fri, 31 Jul 2015 15:03:53 +0100, Laurent wrote: > I don't really understand why `in-range` makes such a difference. It looks > like the kind of sequence iterator is tested at each step, whereas I was > expecting it to be tested only at the beginning of the loop, since this > sequence iterator kind can't change from one iteration to the next, right? > > Hence, I was expecting the `in-range` (and actually all other `in-*`) issue > to appear only inside nested loops, where some loops are started many times > (thus requiring many iterator kind tests). Right: The `in-*` functions tell `for` what kind of step operations to inline into the loop (after an initial guard that confirms that it has a number, list, etc., to iterate through). Otherwise, there's a run-time dispatch to take each step, which is usually more significant than a run-time dispatch to set up the loop. At Fri, 31 Jul 2015 16:41:51 +0100, Laurent wrote: > My question still holds though: Can I expect the JIT to optimize the cases > of my primary concern? (Or are these cases unlikely to be a bottleneck?) > I'm unsure about how to set up correct stress tests as the JIT does a good > job at optimizing a number of things and then I'm not sure what precisely > I'm measuring. I think you should expect optimization in cases like this, but you'll be disappointed sometimes. All optimizations are hueristics, and heuristics for inlining (the relevant optimization here) are especially tricky. I think the v6.2 difference is probably a result of Gustavo's refinements to the heuristics for inlining. The Optimization Coach helps you with one reliable strategy for dealing with the optimizer, which is to compile some code and see what the optimizer does. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Some help with syntax-parse: macro in macro
Hi Stephen, At the moment, "collect" is syntax, itself defined through syntax-parse. So you suggest making "collect" a literal and changing the underlying macro name? It's part of a #lang experiment I'm writing which manages a series of actions from a controller. The file, when required, provides a (run controller model) procedure which takes a controller for executing (collect ...) actions and a model to store the data returned by the (collect ...) output. Right now what I have is something like this with some cluttering details omitted #lang experiment (define-experiment (collect uv #:points 10 #:seconds 2) ; collect a point every 2 seconds 10 times (collect uv #:points 10 #:minutes 30) ...) But it does no checking that it is called with anything other than (define-experiment exps ...) which is Not Good. This will eventually morph into something much more detailed, like #lang experiment (define-experiment (with-reference ; optional (with-standard ; optional (collect uv #:points 10 #:seconds 10) (collect uv #:points 20 #:minutes 1))) (with-reference ; optional (collect uv #:points 10 #:seconds 10) (collect uv #:points 20 #:minutes 1) (collect uv #:points 30 #:hours 1))) And the (define-experiment ...) macro will need to reorder all this so it makes sense in how a person interacts with a device. Describing an experiment and running it are usually very different! So whatever strategy is adopted for "collect" will multiply quickly. I remember reading about how there are some gotchas with treating macro names as literals in patterns (maybe this is a syntax-case problem?) and I wanted to avoid just assuming things. Deren On Fri, Jul 31, 2015 at 12:05 PM, Stephen Chang wrote: > You might want to specify "collect" in #:datum-literals if it is not a > defined name. > > Can you describe some usage examples? That may lead to better insight > for the implementation. > > On Fri, Jul 31, 2015 at 11:49 AM, Deren Dohoda > wrote: > > Suppose I have a macro (experiment ...) which is intended, among other > things, to be composed of uses of a macro (collect ...). > > > > For instance: > > (experiment > > (collect ...) > > (collect ...) ...) > > > > To my understanding, "collect" is not a literal. Can I turn the collect > macro itself into a syntax class somehow? Should I instead create a dummy > literal "collect" for this purpose, and then create a (collect* ...) macro? > > > > Thanks for any advice. > > > > Deren > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Full (fifth RacketCon) Program is up!
Yes, the plan is to both videotape and live stream the talks, like we did in previous years. You're welcome to hop on IRC (#racket on Freenode) during RacketCon and join the discussions! Vincent On Thu, 30 Jul 2015 03:16:58 -0500, Paulo Matos wrote: > > > On 29/07/2015 17:46, Vincent St-Amour wrote: > > The full program of (fifth RacketCon) is now available! [1] Don't > > forget > > to register! [2] > > > > For those not able to go to St Louis, will this be videotaped? > > Thanks. > -- > Paulo Matos > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Some help with syntax-parse: macro in macro
You might want to specify "collect" in #:datum-literals if it is not a defined name. Can you describe some usage examples? That may lead to better insight for the implementation. On Fri, Jul 31, 2015 at 11:49 AM, Deren Dohoda wrote: > Suppose I have a macro (experiment ...) which is intended, among other > things, to be composed of uses of a macro (collect ...). > > For instance: > (experiment > (collect ...) > (collect ...) ...) > > To my understanding, "collect" is not a literal. Can I turn the collect macro > itself into a syntax class somehow? Should I instead create a dummy literal > "collect" for this purpose, and then create a (collect* ...) macro? > > Thanks for any advice. > > Deren > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Full (fifth RacketCon) Program is up!
On 29/07/2015 17:46, Vincent St-Amour wrote: The full program of (fifth RacketCon) is now available! [1] Don't forget to register! [2] For those not able to go to St Louis, will this be videotaped? Thanks. -- Paulo Matos -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Some help with syntax-parse: macro in macro
Suppose I have a macro (experiment ...) which is intended, among other things, to be composed of uses of a macro (collect ...). For instance: (experiment (collect ...) (collect ...) ...) To my understanding, "collect" is not a literal. Can I turn the collect macro itself into a syntax class somehow? Should I instead create a dummy literal "collect" for this purpose, and then create a (collect* ...) macro? Thanks for any advice. Deren -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
Yes indeed (and thanks all). My question still holds though: Can I expect the JIT to optimize the cases of my primary concern? (Or are these cases unlikely to be a bottleneck?) I'm unsure about how to set up correct stress tests as the JIT does a good job at optimizing a number of things and then I'm not sure what precisely I'm measuring. On Fri, Jul 31, 2015 at 4:25 PM, Vincent St-Amour < stamo...@eecs.northwestern.edu> wrote: > FWIW, the optimization coach reports these kinds of issues, and > recommends that solution. > > Vincent > > > > On Fri, 31 Jul 2015 09:03:53 -0500, > Laurent wrote: > > > > Oh wow, this makes a huge difference indeed! (both in-range and v6.2) > > Congrats for the efforts put in the new version! > > > > I don't really understand why `in-range` makes such a difference. It > > looks like the kind of sequence iterator is tested at each step, whereas > > I was expecting it to be tested only at the beginning of the loop, since > > this sequence iterator kind can't change from one iteration to the next, > > right? > > > > Hence, I was expecting the `in-range` (and actually all other `in-*`) > > issue to appear only inside nested loops, where some loops are started > > many times (thus requiring many iterator kind tests). > > > > Neil: Sure :) > > > > On Fri, Jul 31, 2015 at 2:21 PM, Matthew Flatt > > wrote: > > > > Also, which version of Racket are you using? With v6.1.1 and > > `in-range`, I get > > > > cpu time: 745 real time: 744 gc time: 0 > > cpu time: 205 real time: 205 gc time: 0 > > cpu time: 782 real time: 782 gc time: 0 > > cpu time: 205 real time: 206 gc time: 0 > > > > but with v6.2 and `in-range`, I get > > > > cpu time: 209 real time: 209 gc time: 0 > > cpu time: 204 real time: 203 gc time: 0 > > cpu time: 206 real time: 206 gc time: 0 > > cpu time: 203 real time: 204 gc time: 0 > > > > At Fri, 31 Jul 2015 14:05:57 +0100, Laurent wrote: > > > > > > > Hi, > > > > > > A little stress test seems to suggest that the JIT is currently > > not able to > > > optimize closures with static arguments: > > > https://gist.github.com/Metaxal/4beb286cacc0966b433a > > > > > > That's a simplified version of some cases of mine where several > > complex > > > procedures that look very much alike, so I'd really like to avoid > > > copy/paste/maintain, but these procedures are also inside > > intensive loops, > > > so I'd really like to not sacrifice speed. > > > > > > Is there a better way to write this code with copy/paste to allow > > for > > > optimizations? > > > > > > Thanks, > > > Laurent > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > > Groups > > > "Racket Users" group. > > > To unsubscribe from this group and stop receiving emails from it, > > send an > > > email to racket-users+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 "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
FWIW, the optimization coach reports these kinds of issues, and recommends that solution. Vincent On Fri, 31 Jul 2015 09:03:53 -0500, Laurent wrote: > > Oh wow, this makes a huge difference indeed! (both in-range and v6.2) > Congrats for the efforts put in the new version! > > I don't really understand why `in-range` makes such a difference. It > looks like the kind of sequence iterator is tested at each step, whereas > I was expecting it to be tested only at the beginning of the loop, since > this sequence iterator kind can't change from one iteration to the next, > right? > > Hence, I was expecting the `in-range` (and actually all other `in-*`) > issue to appear only inside nested loops, where some loops are started > many times (thus requiring many iterator kind tests). > > Neil: Sure :) > > On Fri, Jul 31, 2015 at 2:21 PM, Matthew Flatt > wrote: > > Also, which version of Racket are you using? With v6.1.1 and > `in-range`, I get > > cpu time: 745 real time: 744 gc time: 0 > cpu time: 205 real time: 205 gc time: 0 > cpu time: 782 real time: 782 gc time: 0 > cpu time: 205 real time: 206 gc time: 0 > > but with v6.2 and `in-range`, I get > > cpu time: 209 real time: 209 gc time: 0 > cpu time: 204 real time: 203 gc time: 0 > cpu time: 206 real time: 206 gc time: 0 > cpu time: 203 real time: 204 gc time: 0 > > At Fri, 31 Jul 2015 14:05:57 +0100, Laurent wrote: > > > > Hi, > > > > A little stress test seems to suggest that the JIT is currently > not able to > > optimize closures with static arguments: > > https://gist.github.com/Metaxal/4beb286cacc0966b433a > > > > That's a simplified version of some cases of mine where several > complex > > procedures that look very much alike, so I'd really like to avoid > > copy/paste/maintain, but these procedures are also inside > intensive loops, > > so I'd really like to not sacrifice speed. > > > > Is there a better way to write this code with copy/paste to allow > for > > optimizations? > > > > Thanks, > > Laurent > > > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, > send an > > email to racket-users+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 "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
Oh wow, this makes a huge difference indeed! (both in-range and v6.2) Congrats for the efforts put in the new version! I don't really understand why `in-range` makes such a difference. It looks like the kind of sequence iterator is tested at each step, whereas I was expecting it to be tested only at the beginning of the loop, since this sequence iterator kind can't change from one iteration to the next, right? Hence, I was expecting the `in-range` (and actually all other `in-*`) issue to appear only inside nested loops, where some loops are started many times (thus requiring many iterator kind tests). Neil: Sure :) On Fri, Jul 31, 2015 at 2:21 PM, Matthew Flatt wrote: > Also, which version of Racket are you using? With v6.1.1 and > `in-range`, I get > > cpu time: 745 real time: 744 gc time: 0 > cpu time: 205 real time: 205 gc time: 0 > cpu time: 782 real time: 782 gc time: 0 > cpu time: 205 real time: 206 gc time: 0 > > but with v6.2 and `in-range`, I get > > cpu time: 209 real time: 209 gc time: 0 > cpu time: 204 real time: 203 gc time: 0 > cpu time: 206 real time: 206 gc time: 0 > cpu time: 203 real time: 204 gc time: 0 > > At Fri, 31 Jul 2015 14:05:57 +0100, Laurent wrote: > > Hi, > > > > A little stress test seems to suggest that the JIT is currently not able > to > > optimize closures with static arguments: > > https://gist.github.com/Metaxal/4beb286cacc0966b433a > > > > That's a simplified version of some cases of mine where several complex > > procedures that look very much alike, so I'd really like to avoid > > copy/paste/maintain, but these procedures are also inside intensive > loops, > > so I'd really like to not sacrifice speed. > > > > Is there a better way to write this code with copy/paste to allow for > > optimizations? > > > > Thanks, > > Laurent > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
Laurent wrote on 07/31/2015 09:05 AM: That's a simplified version of some cases of mine where several complex procedures that look very much alike, so I'd really like to avoid copy/paste/maintain, but these procedures are also inside intensive loops, so I'd really like to not sacrifice speed. Is there a better way to write this code with copy/paste to allow for optimizations? If there's an optimization that you really want, but the compiler&JIT don't currently do it... before copy&paste, there's macros. Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
Also, which version of Racket are you using? With v6.1.1 and `in-range`, I get cpu time: 745 real time: 744 gc time: 0 cpu time: 205 real time: 205 gc time: 0 cpu time: 782 real time: 782 gc time: 0 cpu time: 205 real time: 206 gc time: 0 but with v6.2 and `in-range`, I get cpu time: 209 real time: 209 gc time: 0 cpu time: 204 real time: 203 gc time: 0 cpu time: 206 real time: 206 gc time: 0 cpu time: 203 real time: 204 gc time: 0 At Fri, 31 Jul 2015 14:05:57 +0100, Laurent wrote: > Hi, > > A little stress test seems to suggest that the JIT is currently not able to > optimize closures with static arguments: > https://gist.github.com/Metaxal/4beb286cacc0966b433a > > That's a simplified version of some cases of mine where several complex > procedures that look very much alike, so I'd really like to avoid > copy/paste/maintain, but these procedures are also inside intensive loops, > so I'd really like to not sacrifice speed. > > Is there a better way to write this code with copy/paste to allow for > optimizations? > > Thanks, > Laurent > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Optimizing closures
I think you want to use `in-range`. On my machine, adding `in-range` makes each loop run 20 times faster --- which means that the original loops are just testing the performance of the generic sequence case of `for`. (Probably we should make `for` recognize and specialize literal integers, and I think someone has suggested that before...). At Fri, 31 Jul 2015 14:05:57 +0100, Laurent wrote: > Hi, > > A little stress test seems to suggest that the JIT is currently not able to > optimize closures with static arguments: > https://gist.github.com/Metaxal/4beb286cacc0966b433a > > That's a simplified version of some cases of mine where several complex > procedures that look very much alike, so I'd really like to avoid > copy/paste/maintain, but these procedures are also inside intensive loops, > so I'd really like to not sacrifice speed. > > Is there a better way to write this code with copy/paste to allow for > optimizations? > > Thanks, > Laurent > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: Optimizing closures
In particular, I often have a keyword #:update? to modify (set!) some variables, a keyword #:debug? to print some values on screen and perform some tests, and without these keywords the procedure is completely functional. So I suspect that the non-update non-debug version would be much faster if such a procedure could be optimized. On Fri, Jul 31, 2015 at 2:05 PM, Laurent wrote: > Hi, > > A little stress test seems to suggest that the JIT is currently not able > to optimize closures with static arguments: > https://gist.github.com/Metaxal/4beb286cacc0966b433a > > That's a simplified version of some cases of mine where several complex > procedures that look very much alike, so I'd really like to avoid > copy/paste/maintain, but these procedures are also inside intensive loops, > so I'd really like to not sacrifice speed. > > Is there a better way to write this code with copy/paste to allow for > optimizations? > > Thanks, > Laurent > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Optimizing closures
Hi, A little stress test seems to suggest that the JIT is currently not able to optimize closures with static arguments: https://gist.github.com/Metaxal/4beb286cacc0966b433a That's a simplified version of some cases of mine where several complex procedures that look very much alike, so I'd really like to avoid copy/paste/maintain, but these procedures are also inside intensive loops, so I'd really like to not sacrifice speed. Is there a better way to write this code with copy/paste to allow for optimizations? Thanks, Laurent -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Slack team for racket
Wow, is it two way then? On Fri, Jul 31, 2015 at 9:03 AM, Jack Firth wrote: > On Monday, July 27, 2015 at 1:15:31 AM UTC-7, mazert wrote: > > Le 27/07/2015 04:13, Jason Yeo a écrit : > > > Hi Everyone! > > > > > > For anyone out there who finds IRC too daunting and difficult to use, > there's a slack team created just for racketlang at > http://racket.slack.com. Get invites to the team at > http://racket-slack.herokuapp.com. > > > > > > Cheers, > > > Jason > > > > > > > Hello, > > > > IRC and a Newsgroup/Mailing-list is largely enough. I think it is better > > to centralize a community around 1-2 services, otherwise you have to > > post your question on a lot of services to hope having an answer, or to > > discuss about a specific subject. > > > > And honestly, if a developer finds that IRC is too complicated, he > > should do something else ;). But for people who already use slack.com > > why not ! > > Note that the Slack channel is integrated with the IRC chat room so > anything in IRC is visible in Slack > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+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 "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
