Impressive optimization! I wonder what it was that changed specifically. Sam
On Sat, Sep 19, 2015 at 9:02 PM, Gustavo Massaccesi <[email protected]> wrote: > Probably the difference is caused by the diference of the Racket > version in your machine and in PasteRack. In my machine: > > *** Using Racket 6.2 > cpu time: 687 real time: 702 gc time: 0 > cpu time: 14352 real time: 14838 gc time: 0 > cpu time: 3619 real time: 3674 gc time: 0 > cpu time: 5429 real time: 5430 gc time: 0 > cpu time: 3245 real time: 3252 gc time: 0 > cpu time: 3213 real time: 3242 gc time: 0 > > *** Using Racket almost the current HEAD (~one week old) > cpu time: 717 real time: 742 gc time: 0 > cpu time: 4368 real time: 4465 gc time: 0 > cpu time: 3526 real time: 3550 gc time: 0 > cpu time: 5616 real time: 5809 gc time: 0 > cpu time: 3057 real time: 3056 gc time: 0 > cpu time: 2996 real time: 2996 gc time: 0 > > Gustavo > > > On Sat, Sep 19, 2015 at 9:22 PM, Sam Tobin-Hochstadt > <[email protected]> wrote: >> When I run my original program on my own machine (instead of >> Pasterack), the difference is more like 2-3x. So my original email >> overstated the speed difference a bunch. I don't know what's going on >> that makes it so different on pasterack. >> >> An interesting side note -- we tried this program in Pycket, and two >> interesting things happened: >> - it turned out to be another test case for a problem we are working >> on right now -- memq was too slow because it was used previously with >> different types >> - when that's fixed, memq and member are the same speed, because >> Pycket's version of `eq?` is slower than it would be otherwise, >> precisely because it has to maintain the semantics that Robby doesn't >> like :) >> >> Sam >> >> On Sat, Sep 19, 2015 at 5:38 PM, Gustavo Massaccesi <[email protected]> >> wrote: >>> There is something very strange with memq vs member: >>> http://pasterack.org/pastes/80845 (note: I added one 0 to the loop >>> constants) >>> >>> I used two mutable variables eq?? and equal?? to avoid (most of) the >>> optimizations and I get that the time with equal? is 2x than the time >>> with eq?. This is closer to the range I expected. >>> >>> Using directly eq? and equal? is slightly faster, and the time is the >>> same because under the hood the optimizer transforms equal? to eq? >>> when one of the arguments is an explicit symbol. >>> >>> The implementation of member and memq is very short but very >>> entangled. I think that with some tweaks is possible to reduce the >>> time difference to x2, and with some luck to make it more optimizer >>> friendly and gain some additional speed. >>> >>> Gustavo >>> >>> >>> >>> On Thu, Sep 17, 2015 at 11:01 PM, Sam Tobin-Hochstadt >>> <[email protected]> wrote: >>>> Unfortunately, that's only true when eq? produces #t, which probably isn't >>>> an issue when using eq? directly, but can be when using memq or similar. >>>> This benchmark suggests about a 10x speed difference when the symbols are >>>> different: http://pasterack.org/pastes/94877 >>>> >>>> Sam >>>> >>>> >>>> On Thu, Sep 17, 2015, 9:52 PM Robby Findler <[email protected]> >>>> wrote: >>>>> >>>>> FWIW, if you use equal? in those cases, you'll get the same >>>>> performance behavior and you will have fewer eq?s to audit when things >>>>> go wonky. >>>>> >>>>> ;) >>>>> >>>>> Robby >>>>> >>>>> On Thu, Sep 17, 2015 at 8:36 PM, Neil Van Dyke <[email protected]> >>>>> wrote: >>>>> > Whew. :) I only rarely have a non-symbol use for `eq?`, but I use `eq?` >>>>> > heavily for symbols in everyday application code. >>>>> > >>>>> > Robby Findler wrote on 09/17/2015 09:27 PM: >>>>> >> >>>>> >> eq? on symbols is a special part of the specification and that seems >>>>> >> benign to me, all things considered. The "giant hash in the sky" that >>>>> >> makes sure that works isn't exactly trouble free, but we seem to have >>>>> >> it under control. >>>>> > >>>>> > >>>>> > -- >>>>> > 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 [email protected]. >>>>> > 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 [email protected]. >>>>> 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 [email protected]. >>>> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
