Some minor remarks:

On Sun, Feb 23, 2020 at 9:58 AM Matthew Flatt <mfl...@cs.utah.edu> wrote:

> [Replying to three messages]
>
> At Sat, 22 Feb 2020 08:05:28 -0800, Matthew Butterick wrote:
> > 1) As a package maintainer with zero exposure to Chez Scheme, how do I
> start
> > to optimize for Racket CS? Are there certain patterns and idioms from BC
> that
> > should be systematically eradicated?
>
> No. For most Racket users, you should *not* try to optimize for Racket
> CS, and Racket CS should just do the right thing.
>
>
I agree, 99.9% of the time just write nice idiomatic code and hope the
optimizer will do the right thing.




> > But my understanding is that Chez’s optimizer is much more
> > sophisticated than Racket BC’s.
>
> I wouldn't characterize it that way. If anything, Racket BC is more
> sophisticated and aggressive than Chez Scheme on high-level
> optimizations, especially around type reconstruction and cross-module
> optimizations. (For Racket CS, Gustavo added a type-reconstruction pass
> to Chez Scheme, and schemify handles cross-module optimization.)
>
> Chez Scheme's advantages are more on the back end: register allocation,
> calling conventions, and continuation management.
>

About the type recovery part: RacketCS can get the type information from
more primitives than RacketBC.
It was very handy that Chez Scheme had a list with the signatures of all
the primitives.
On the other hand, RacketCS still doesn't have some tricks like
    (bitwise-and <exact-integer?> <positive-fixnum?>)  ==>
<positive-fixnum?>




> > At the very least, I’d expect it to be able to identify that `v`
> > is never used here and simplify it to this:
> >
> >     (let loop ([i 0])
> >       (define j (add1 i))
> >       (if (< j N)
> >           (loop j)
> >           i))
>
> None of Racket BC, Racket CS, or Chez Scheme by itself will optimize
> away the unused loop argument. That kind of interprocedural dead-code
> elimination is out of reach for the current compilers, except to the
> degree that inlining turns them into intraprocedural questions.
>

I'm more optimistic, and I think that detecting that an argument is unused
and deleting it is not so difficult, at east in thigh loops. It is similar
to the lifting of closures that is already done.
If this pattern is common enough, I think this can be added in a week as an
independent pass (that's like a month of wall clock time :) ).
(This is one of the advantages of RacketCS. It's much easier to write
complex transformations. Writing this in the traditional Racket is
theoretical possible, but it would be more difficult.)
(It would be better to add it as part of cp0 or as part of cptypes, or as
part of a more complete pass about loops. So don't expect to see this in a
month.)



Gustavo

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAPaha9OWgHMDs%3DV0LXv%2BCp2jnH241VuFjPH%2BfF7TpupXu2m4%2BQ%40mail.gmail.com.

Reply via email to