Re: [racket-users] Compiler question
Thank you, Matthias. Thanks to Vincent and everyone else who answered as well. I'll experiment with the coach. Best regards, --Jerry On Fri, Apr 29, 2016 at 9:16 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > Jerry, you may not have understood Vincent's concise response. > > No reasonably expressive PL on Earth will allow you to predict > the performance of micro-benchmarks (not to speak of large programs) > within reasonable bounds. When compiler optimizations fail -- what > you call "pessimizing style" -- the compiler simply generates different > code. In a non-trivial programs, the contexts vary too much to predict > performance. In one context, in-lining may succeed, in another a similar > looking one may fail. > > We have known this for decades, and programmers have suffered from > this problem for equally long. > > Vincent's dissertation does something about it. His "compiler coach" > or "optimization coach" is NOT a profiler. It is a tool that explains > the compiler's design decisions. In this particular case, it explains > that the compiler can in-line a "directly apparent" call (as Matthew > might call it) and will not in-line a "higher-order call" as I might > refer to your choice of style. > > Take a look and experiment. It's NOT a profiler. I doesn't involve > decompilation or looking at the expansion. It's pleasant to use. If > you have feedback, please let us know > > -- Matthias > > > > > > > > > > > On Apr 27, 2016, at 3:52 PM, Jerry Jackson <jrryjc...@gmail.com> wrote: > > > I appreciate the responses; at this point, however, I'm trying to figure > out what to do with my intuition. If those two pieces of code don't compile > to the same thing, I'm not sure how I should approach code style. I tend to > favor ((if x y z) foo) over (if x (y foo) (z foo)) because it avoids > redundancy and localizes the choice. Apparently, that's a pessimising > choice and I now don't feel like I have much intuition at all about how > things will perform. Obviously, I can use profiling to track such things > down but... > > > > I'd really be interested in how the two forms look when they've both > been reduced to some canonical internal format. > > > > Thanks, > > --Jerry > > > > > > > > On Wed, Apr 27, 2016 at 8:49 AM, Vincent St-Amour < > stamo...@eecs.northwestern.edu> wrote: > > When you have a program that's surprisingly fast (or slow), you can use > > the optimization coach in DrRacket (in the "view" menu) to see what > > optimizations Racket applies to your code. > > > > For your program, the coach confirms Matthew's diagnosis that inlining > > is what makes `fib2` faster. > > > > Vincent > > > > > > On Wed, 27 Apr 2016 08:42:03 -0500, > > Jerry Jackson wrote: > > > > > > Hello all, > > > > > > I was experimenting a bit yesterday and discovered something that > surprised me. Here are two fibonacci functions: > > > > > > (define fib1 > > > (letrec ([aux (lambda (i n) > > > (if (< n 2) > > > 1 > > > (+ (fib1 i (- n 2)) (fib1 i (- n 1)]) > > > (let ([funs (vector aux aux)]) > > > (lambda (index num) > > > ((if (= index 0) aux (vector-ref funs index)) index num) > > > > > > (define fib2 > > > (letrec ([aux (lambda (i n) > > > (if (< n 2) > > > 1 > > > (+ (fib2 i (- n 2)) (fib2 i (- n 1)]) > > > (let ([funs (vector aux aux)]) > > > (lambda (index num) > > > (if (= index 0) > > > (aux index num) > > > ((vector-ref funs index) index num)) > > > > > > I expected them to behave basically identically (in fact, I thought > they would probably generate the same code). However, that was not the case: > > > > > > > (time (fib1 0 40)) > > > cpu time: 4490 real time: 4489 gc time: 0 > > > 165580141 > > > > (time (fib1 1 40)) > > > cpu time: 5031 real time: 5027 gc time: 0 > > > 165580141 > > > > (time (fib2 0 40)) > > > cpu time: 3042 real time: 3040 gc time: 0 > > > 165580141 > > > > (time (fib2 1 40)) > > > cpu time: 5031 real time: 5027 gc time: 0 > > > 165580141 > > > > (time (fib1 0 40)) > > > cpu time: 4535 real time: 4532 gc time: 0 > > > 165580141 &
Re: [racket-users] Compiler question
I appreciate the responses; at this point, however, I'm trying to figure out what to do with my intuition. If those two pieces of code don't compile to the same thing, I'm not sure how I should approach code style. I tend to favor ((if x y z) foo) over (if x (y foo) (z foo)) because it avoids redundancy and localizes the choice. Apparently, that's a pessimising choice and I now don't feel like I have much intuition at all about how things will perform. Obviously, I can use profiling to track such things down but... I'd really be interested in how the two forms look when they've both been reduced to some canonical internal format. Thanks, --Jerry On Wed, Apr 27, 2016 at 8:49 AM, Vincent St-Amour < stamo...@eecs.northwestern.edu> wrote: > When you have a program that's surprisingly fast (or slow), you can use > the optimization coach in DrRacket (in the "view" menu) to see what > optimizations Racket applies to your code. > > For your program, the coach confirms Matthew's diagnosis that inlining > is what makes `fib2` faster. > > Vincent > > > On Wed, 27 Apr 2016 08:42:03 -0500, > Jerry Jackson wrote: > > > > Hello all, > > > > I was experimenting a bit yesterday and discovered something that > surprised me. Here are two fibonacci functions: > > > > (define fib1 > > (letrec ([aux (lambda (i n) > > (if (< n 2) > > 1 > > (+ (fib1 i (- n 2)) (fib1 i (- n 1)]) > > (let ([funs (vector aux aux)]) > > (lambda (index num) > > ((if (= index 0) aux (vector-ref funs index)) index num) > > > > (define fib2 > > (letrec ([aux (lambda (i n) > > (if (< n 2) > > 1 > > (+ (fib2 i (- n 2)) (fib2 i (- n 1)]) > > (let ([funs (vector aux aux)]) > > (lambda (index num) > > (if (= index 0) > > (aux index num) > > ((vector-ref funs index) index num)) > > > > I expected them to behave basically identically (in fact, I thought they > would probably generate the same code). However, that was not the case: > > > > > (time (fib1 0 40)) > > cpu time: 4490 real time: 4489 gc time: 0 > > 165580141 > > > (time (fib1 1 40)) > > cpu time: 5031 real time: 5027 gc time: 0 > > 165580141 > > > (time (fib2 0 40)) > > cpu time: 3042 real time: 3040 gc time: 0 > > 165580141 > > > (time (fib2 1 40)) > > cpu time: 5031 real time: 5027 gc time: 0 > > 165580141 > > > (time (fib1 0 40)) > > cpu time: 4535 real time: 4532 gc time: 0 > > 165580141 > > > (time (fib2 0 40)) > > cpu time: 3027 real time: 3025 gc time: 0 > > 165580141 > > > > > > > It looks like one of the functions is 1.5 times faster than the other > (in the i == 0 case). Any ideas as to why? > > > > Thanks, > > --Jerry Jackson > > > > -- > > 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] Compiler question
Hello all, I was experimenting a bit yesterday and discovered something that surprised me. Here are two fibonacci functions: (define fib1 (letrec ([aux (lambda (i n) (if (< n 2) 1 (+ (fib1 i (- n 2)) (fib1 i (- n 1)]) (let ([funs (vector aux aux)]) (lambda (index num) ((if (= index 0) aux (vector-ref funs index)) index num) (define fib2 (letrec ([aux (lambda (i n) (if (< n 2) 1 (+ (fib2 i (- n 2)) (fib2 i (- n 1)]) (let ([funs (vector aux aux)]) (lambda (index num) (if (= index 0) (aux index num) ((vector-ref funs index) index num)) I expected them to behave basically identically (in fact, I thought they would probably generate the same code). However, that was not the case: > (time (fib1 0 40)) cpu time: 4490 real time: 4489 gc time: 0 165580141 > (time (fib1 1 40)) cpu time: 5031 real time: 5027 gc time: 0 165580141 > (time (fib2 0 40)) cpu time: 3042 real time: 3040 gc time: 0 165580141 > (time (fib2 1 40)) cpu time: 5031 real time: 5027 gc time: 0 165580141 > (time (fib1 0 40)) cpu time: 4535 real time: 4532 gc time: 0 165580141 > (time (fib2 0 40)) cpu time: 3027 real time: 3025 gc time: 0 165580141 > It looks like one of the functions is 1.5 times faster than the other (in the i == 0 case). Any ideas as to why? Thanks, --Jerry Jackson -- 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] Sequential vs. Parallel 13-Queens program
This is a bit off-topic (though it is about N-queens) but I've long wanted to ask people if an idea I had once is a well-known one. It once occurred to me that solutions to N-rooks can be viewed as linear transformations that correspond to permutations of a vector. So, then I wondered to what sort of transformations solutions to N-queens correspond. I'll leave a gap in case anyone wants to think about it... Okay, N-queens solutions correspond to transformations in which no two entries in the permuted vector are the same distance apart as they were before. This leads to a simple algorithm for finding solutions. Fill a vector with the digits 1 to veclen, generate permutations, and see if the difference between any two element indices is the same as the difference between their contents. You can then easily reverse engineer the board. Is this well known? Thanks, --Jerry Jackson -- 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] Applying functions to mutable lists
On Thursday, April 9, 2015 at 9:28:54 AM UTC-6, Justin Zamora wrote: Why not use streams? http://docs.racket-lang.org/reference/streams.html Justin On Apr 9, 2015 11:22 AM, Jerry Jackson jrry...@gmail.com wrote: Hello, I'm building a language with racket that includes lazy lists. I'm building lazy lists with mcons cells. The compatibility/mlist module has lots of support functions but I'd like to be able to apply racket functions to the lists I've constructed and I don't see any mapply. I understand that the use of mutable cons cells is discouraged but I don't currently know of a better way to do lazy lists. If there is a different recommended way, I'd like to know about it. If not: 1) Is there an equivalent of mapply that I just haven't found or 2) Is there a reason it's a really bad idea or 3) Was it just left out because nobody so far needed it? Thanks for any help, --Jerry Jackson -- 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. I can't use streams because I'm not just using traditional lazy lists; I'm constructing them from the multiple results of a goal-driven system with backtracking. The lazy lists are built via delimited continuations. Also, I'm supporting semi-greedy lists in that I want to fully populate shorter lists under some circumstances for performance so I generate the first N entries before suspending (unless the list is recursively specified which requires one-by-one semantics). -- 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.
