After reading the paper, I see that the missing ingredient in our
compiler is a data-flow analysis along the lines of 0-CFA. Others
(i.e., not me) are working on integrating such analyses and
optimizations into Racket, so I think that it will be possible
eventually.
At Tue, 29 Jun 2010 02:21:00 +0
If I understand you correctly, it is possible to see such an optimization in
Racket? It would be awesome to use this style to control the loops.
28.06.10, 23:47, "Matthias Felleisen" :
>
> I pointed out Jinx's paper to Matthew last week.
>
> Not surprisingly, reality and theory never match
I pointed out Jinx's paper to Matthew last week.
Not surprisingly, reality and theory never match with the MIT Scheme
compiler.
On Jun 28, 2010, at 3:04 PM, Joe Marshall wrote:
On Fri, Jun 25, 2010 at 11:50 AM, Matthew Flatt
wrote:
Compilers can't easily see through a Y combinator, an
On Fri, Jun 25, 2010 at 11:50 AM, Matthew Flatt wrote:
>
> Compilers can't easily see through a Y combinator, and a factor of 8 or
> so difference is probably typical for Lisp compilers. (I tried Ikarus
> and Gambit to double check, and performance was about the same as with
> Racket.)
See
@INPRO
Matthias Felleisen
writes:
> CODE:
>
> #lang racket
>
> (define-syntax U
> (syntax-rules ()
> [(_ f) (f f)]))
>
> (define-syntax define/comb
> (syntax-rules ()
> [(_ comb name (arg1 arg2) body)
> (define name
>(comb (λ (name) (λ (arg1 arg2) body]))
>
> (define (Z
This version misses an explicit combinator passing. Z can be replaced by I,
Z-memoize, Z-verbose or any other, this is the point.
25.06.10, 22:58, "Ryan Culpepper" :
> On 06/25/2010 12:59 PM, Groshev Dmitry wrote:
> > Is there any way to avoid this overhead? I'm really interested in
> > combin
On 06/25/2010 12:59 PM, Groshev Dmitry wrote:
> Is there any way to avoid this overhead? I'm really interested in
> combinator style, but if it makes programs 8 times slower, it is
> useless. Maybe some compiler/macro optimizations is possible?
You might find this version interesting:
(define-syn
Is there any way to avoid this overhead? I'm really interested in combinator
style, but if it makes programs 8 times slower, it is useless. Maybe some
compiler/macro optimizations is possible?
25.06.10, 22:50, "Matthew Flatt" :
> If you're interested in specially the overhead of combinator styl
If you're interested in specially the overhead of combinator style,
then your example still understates the overhead compared to relatively
cheap operations.
In addition to Matthias's change to get rid of `apply', I've revised
your program (see below) to replace `first' and `rest' with `car' and
`
I think you're comparing apples and oranges here.
The use of _apply_ should make things a lost slower
for comb-sum than for sum. Also, you should collect
garbage before you run timed microbenchmarks. Otherwise
you might have bad interactions. With that done, I
get the following results:
> [:~/D
I've mistyped. In fact things are even worse.
#lang racket
(define-syntax U
(syntax-rules ()
[(_ f) (f f)]))
(define-syntax define/comb
(syntax-rules ()
[(_ comb name (arg . args) f)
(define name
(comb (λ (name) (λ (arg . args) f]))
(define (Z f)
(U (λ (g) (λ x
11 matches
Mail list logo
