Re: [racket-dev] [plt] Push #28817: master branch updated
Ok, I see. I'll revise my comment to "this would be better done with a more general form of type inference", leaving out the claim of where that inference should live. I don't currently know how to do it other than building inference into the complier. Matthias's plug-in rules sounds like a point that we hope to eventually reach through macros as a compiler API. On Sam's general question, I agree that there's no simple answer. Some languages/libraries will provide particular optimizations that are made possible by syntactic constraints. A type system is a particularly fancy syntactic constraint, and it can offer particularly fancy optimizations (such as splitting complex numbers). Syntactic constraints are the reason to have multiple languages and a choice, instead of just one language and compiler. I suppose a single compiler could try several languages and find the one that a program matches syntactically, but often the constraints are complex enough that programs won't fit without careful attention. In that case, a programmer knows (and can declare, and would really prefer to declare and get feedback on) the restricted form that they intend to use for a program. Meanwhile, we have a lot of code in plain Racket. Optimizing by hand is so painful that even writing more C code (for the current optimizer) seems like a better trade-off than hand-optimization. I imagine that the PR was provoked by actual code somewhere. When the compiler is finally itself implemented in Racket, the balance should shift even further toward optimizations for plain Racket, whether or not we find better a macro API for optimizations. At Wed, 28 May 2014 19:50:50 -0700, Eric Dobson wrote: > I don't think that TR should provide the majority of the optimizations > in its current form because it has to run before inlining, and this > limits what it can do. > > Here is an example program: > #lang typed/racket > > (: my-sequence-map >(All (A B) > (case-> >((A -> B) (Vectorof A) -> (Vectorof B)) >((A -> B) (Listof A) -> (Listof B) > (define (my-sequence-map f s) > (if (vector? s) > (vector-map f s) > (map f s))) > > > (my-sequence-map add1 (vector 1 2 3)) > (my-sequence-map add1 (list 1 2 3)) > > I would like this to be optimized to: > (vector-map add1 (vector 1 2 3)) > (map add1 (list 1 2 3)) > > I think this case of code will be very common if we move to a world > where we work over generic sequences/datastructures, and specializing > the call sites will be a big win. > > TR cannot do this optimization because it requires inlining. And the > current version of racket cannot optimize this either because it > becomes > > (let ((s (vector 1 2 3))) > (if (vector? s) > (vector-map add1 s) > (map add1 s))) > > Which isn't optimized because when we see (vector? s) we don't know > that s is a vector as Mathew's change only works if the constructor is > inline (i.e. of the form (vector? (vector 1 2 3))). Cases like this > make me think that we need something stronger than context free > rewrite rules over the ast/bytecode. > > > On Wed, May 28, 2014 at 6:36 PM, Matthias Felleisen > wrote: > > > > Perhaps the right answer is to organize the optimizer > > as a rewriting engine to which other devs can add rules > > as they discover them (and their absence in the existing > > rule set). -- Indeed, one could then even have programmers > > extend the rule set for a specific program (though then > > we have to worry about soundness). With syntax-* we should > > have no problem formulating the mostly context-free rules > > and we could figure out in addition how to keep track of > > contexts. (This is the other half of what we used to call > > the 'open compiler' idea at Rice.) > > > > -- Matthias > > > > > > > > > > On May 28, 2014, at 9:25 PM, Sam Tobin-Hochstadt wrote: > > > >> On Thu, May 29, 2014 at 4:26 AM, wrote: > >>> > >>> | optimizer: ad hoc optimization of predicates applied to constructions > >>> | > >>> | This is probably more of a job for Typed Racket, but maybe it's > >>> | useful to detect some obviously unnecessary allocations of lists, etc. > >> > >> I think this is a useful discussion to have. I think there are two > >> questions to answer: > >> > >> 1. Do we want people to need to use a particular language for greater > >> optimization, whether that's Typed Racket or some other optimizer? > >> > >> 2. How should we optimize the code that Typed Racket depends on? > >> Since this is a finite amount, we could manually do this, but we might > >> not want to. > >> > >> Of course, in the absence of other constraints, it would be great to > >> have infinite optimizations at every level. But in our actual setting, > >> I don't know what I think the answer to either of these questions is. > >> > >> Sam > >> _ > >> Racket Developers list: > >> http://lists.racket-lang.org/dev > > _ Racket Developers list: http://
Re: [racket-dev] [plt] Push #28817: master branch updated
I don't think that TR should provide the majority of the optimizations in its current form because it has to run before inlining, and this limits what it can do. Here is an example program: #lang typed/racket (: my-sequence-map (All (A B) (case-> ((A -> B) (Vectorof A) -> (Vectorof B)) ((A -> B) (Listof A) -> (Listof B) (define (my-sequence-map f s) (if (vector? s) (vector-map f s) (map f s))) (my-sequence-map add1 (vector 1 2 3)) (my-sequence-map add1 (list 1 2 3)) I would like this to be optimized to: (vector-map add1 (vector 1 2 3)) (map add1 (list 1 2 3)) I think this case of code will be very common if we move to a world where we work over generic sequences/datastructures, and specializing the call sites will be a big win. TR cannot do this optimization because it requires inlining. And the current version of racket cannot optimize this either because it becomes (let ((s (vector 1 2 3))) (if (vector? s) (vector-map add1 s) (map add1 s))) Which isn't optimized because when we see (vector? s) we don't know that s is a vector as Mathew's change only works if the constructor is inline (i.e. of the form (vector? (vector 1 2 3))). Cases like this make me think that we need something stronger than context free rewrite rules over the ast/bytecode. On Wed, May 28, 2014 at 6:36 PM, Matthias Felleisen wrote: > > Perhaps the right answer is to organize the optimizer > as a rewriting engine to which other devs can add rules > as they discover them (and their absence in the existing > rule set). -- Indeed, one could then even have programmers > extend the rule set for a specific program (though then > we have to worry about soundness). With syntax-* we should > have no problem formulating the mostly context-free rules > and we could figure out in addition how to keep track of > contexts. (This is the other half of what we used to call > the 'open compiler' idea at Rice.) > > -- Matthias > > > > > On May 28, 2014, at 9:25 PM, Sam Tobin-Hochstadt wrote: > >> On Thu, May 29, 2014 at 4:26 AM, wrote: >>> >>> | optimizer: ad hoc optimization of predicates applied to constructions >>> | >>> | This is probably more of a job for Typed Racket, but maybe it's >>> | useful to detect some obviously unnecessary allocations of lists, etc. >> >> I think this is a useful discussion to have. I think there are two >> questions to answer: >> >> 1. Do we want people to need to use a particular language for greater >> optimization, whether that's Typed Racket or some other optimizer? >> >> 2. How should we optimize the code that Typed Racket depends on? >> Since this is a finite amount, we could manually do this, but we might >> not want to. >> >> Of course, in the absence of other constraints, it would be great to >> have infinite optimizations at every level. But in our actual setting, >> I don't know what I think the answer to either of these questions is. >> >> Sam >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28817: master branch updated
Perhaps the right answer is to organize the optimizer as a rewriting engine to which other devs can add rules as they discover them (and their absence in the existing rule set). -- Indeed, one could then even have programmers extend the rule set for a specific program (though then we have to worry about soundness). With syntax-* we should have no problem formulating the mostly context-free rules and we could figure out in addition how to keep track of contexts. (This is the other half of what we used to call the 'open compiler' idea at Rice.) -- Matthias On May 28, 2014, at 9:25 PM, Sam Tobin-Hochstadt wrote: > On Thu, May 29, 2014 at 4:26 AM, wrote: >> >> | optimizer: ad hoc optimization of predicates applied to constructions >> | >> | This is probably more of a job for Typed Racket, but maybe it's >> | useful to detect some obviously unnecessary allocations of lists, etc. > > I think this is a useful discussion to have. I think there are two > questions to answer: > > 1. Do we want people to need to use a particular language for greater > optimization, whether that's Typed Racket or some other optimizer? > > 2. How should we optimize the code that Typed Racket depends on? > Since this is a finite amount, we could manually do this, but we might > not want to. > > Of course, in the absence of other constraints, it would be great to > have infinite optimizations at every level. But in our actual setting, > I don't know what I think the answer to either of these questions is. > > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28817: master branch updated
On Thu, May 29, 2014 at 4:26 AM, wrote: > > | optimizer: ad hoc optimization of predicates applied to constructions > | > | This is probably more of a job for Typed Racket, but maybe it's > | useful to detect some obviously unnecessary allocations of lists, etc. I think this is a useful discussion to have. I think there are two questions to answer: 1. Do we want people to need to use a particular language for greater optimization, whether that's Typed Racket or some other optimizer? 2. How should we optimize the code that Typed Racket depends on? Since this is a finite amount, we could manually do this, but we might not want to. Of course, in the absence of other constraints, it would be great to have infinite optimizations at every level. But in our actual setting, I don't know what I think the answer to either of these questions is. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Connection issue with the "Infogroep" mirror
Yes. Please use rsync from "mirror.racket-lang.org" instead of "download.racket-lang.org". We moved "download.racket-lang.org" to an S3-hosted site, while "mirror.racket-lang.org" refers to the machine that "download.racket-lang.org" refers to. In other words, we had to split names to distinguish between the web site and the mirror-supporting site. FWIW, I tried to send mail to the contact that we have listed for "http://racket.infogroep.be/"; when we made the change. I'll coordinate with you to make sure we have the right contact for the future. Thanks! At Sun, 25 May 2014 17:35:57 +0200, Sam Vervaeck wrote: > Hi, > > I'm one of the new server administrators of the "Infogroep" server that > mirrors the racket executables at http://download.racket-lang.org. For a > while now I'm getting log messages saying that rsync is no longer able > to connect to download.racket-lang.org (timeout error). I've tried to > test the most basic things (DNS reachable, firewall, etc.) and I > discoverd that the server is reachable over HTTP but not with > rsync/pinging. I get the same results on my local machine on a different > network. > > So my question is: has something changed in the infrastructure of the > download server at racket-lang.org? If so, could you please send us the > new connection parameters that need to be used to keep in sync with the > latest releases? > > Thanks in advance, > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Connection issue with the "Infogroep" mirror
Hi, I'm one of the new server administrators of the "Infogroep" server that mirrors the racket executables at http://download.racket-lang.org. For a while now I'm getting log messages saying that rsync is no longer able to connect to download.racket-lang.org (timeout error). I've tried to test the most basic things (DNS reachable, firewall, etc.) and I discoverd that the server is reachable over HTTP but not with rsync/pinging. I get the same results on my local machine on a different network. So my question is: has something changed in the infrastructure of the download server at racket-lang.org? If so, could you please send us the new connection parameters that need to be used to keep in sync with the latest releases? Thanks in advance, Sam _ Racket Developers list: http://lists.racket-lang.org/dev
