Re: [Chicken-hackers] Handling multiple args in types.db
> In scrutinizer, just at the beginning of 'walk' just try different kind > of optimizations. Like rewrite 19 and the constant folding thing that > was added recently (which is done in pretty icky place currently). Like > this: > > (try-optimizations node) > .. continue with normal walk .. > > The optimizations done here would be "scrutinizer-aware" in that they > don't make scrutiny harder. > > Starting this way would be pretty easy and shouldn't add much new hair > (famous last words...) > > Thoughts? You are just duplicating machinery that already exists. The optimizations in the scrutinizer came after the CPS optimzation passes (and was/is optional) and the interplay is not particularly good. The optimal way would do some rewrites in the scrutinizer based on type-information that later give easily optimizable intermediate structures (or internal forms) that can be taken advantage of. We just need to review the rewrites both in scrutiny and normal optimization so that they interact in a better way. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
> > In this case I would just move rewrite 19 to happen before scrutiny. > > In general, some optimizations like rewrite 19 help the scrutinizer. The > scrutinizer makes transformations that might enable some optimizations, > which might help the scrutinizer, ... i.e. "cascading optimizations". > > The optimizer seems to do this kind of looping. The scrutinizer just > isn't part of that (and probably can't be as the optimizer works with > CPS IIUC). That's true. There is no way to change the order of the scrutinizer with respect to the CPS-based optimization passes. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
Peter Bex writes: > On Sat, Apr 27, 2019 at 09:35:21AM +0300, megane wrote: >> Peter Bex writes: >> > Ah, so this effectively means some of the rewrites are useless since the >> > specializations make them inapplicable. We should consider what to do >> > with that. I have no clue what would happen if we change the order in >> > which they run, so maybe just remove rewrite 19 and replace it with your >> > suggestion? >> >> In this case I would just move rewrite 19 to happen before scrutiny. > > I don't think we can selectively move particular rewrites before scrutiny, > that's what I was getting at; scrutiny is just one big operation that > runs once, and optimizations happen in a loop. I see, I see. > >> In general, some optimizations like rewrite 19 help the scrutinizer. The >> scrutinizer makes transformations that might enable some optimizations, >> which might help the scrutinizer, ... i.e. "cascading optimizations". > > Yeah, it would be great to make use of that. > >> The optimizer seems to do this kind of looping. The scrutinizer just >> isn't part of that (and probably can't be as the optimizer works with >> CPS IIUC). > > That's what I mean. So I think (for now at least?) we're "stuck" with > doing it like you suggested, but then the rewrite is unnecessary (for the > most part?). I think the declarative way of doing the thing rewrite 19 is doing is better than manually doing it in types.db like I suggested. I think this rewrite 19 thing could be solved in the scrutinizer. This would in preparation for that "cascading optimization" feature. In scrutinizer, just at the beginning of 'walk' just try different kind of optimizations. Like rewrite 19 and the constant folding thing that was added recently (which is done in pretty icky place currently). Like this: (try-optimizations node) .. continue with normal walk .. The optimizations done here would be "scrutinizer-aware" in that they don't make scrutiny harder. Starting this way would be pretty easy and shouldn't add much new hair (famous last words...) Thoughts? > > Cheers, > Peter ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
On Sat, Apr 27, 2019 at 09:35:21AM +0300, megane wrote: > Peter Bex writes: > > Ah, so this effectively means some of the rewrites are useless since the > > specializations make them inapplicable. We should consider what to do > > with that. I have no clue what would happen if we change the order in > > which they run, so maybe just remove rewrite 19 and replace it with your > > suggestion? > > In this case I would just move rewrite 19 to happen before scrutiny. I don't think we can selectively move particular rewrites before scrutiny, that's what I was getting at; scrutiny is just one big operation that runs once, and optimizations happen in a loop. > In general, some optimizations like rewrite 19 help the scrutinizer. The > scrutinizer makes transformations that might enable some optimizations, > which might help the scrutinizer, ... i.e. "cascading optimizations". Yeah, it would be great to make use of that. > The optimizer seems to do this kind of looping. The scrutinizer just > isn't part of that (and probably can't be as the optimizer works with > CPS IIUC). That's what I mean. So I think (for now at least?) we're "stuck" with doing it like you suggested, but then the rewrite is unnecessary (for the most part?). Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
Peter Bex writes: > On Sat, Apr 27, 2019 at 07:33:49AM +0300, megane wrote: >> Peter Bex writes: >> > On Fri, Apr 26, 2019 at 10:06:15PM +0300, megane wrote: >> >> Hi folks! >> >> >> >> Do you think that adding specializations for multiple argument calls to >> >> mathematical functions is worth it? Like this: >> > >> > We have a rewrite for this already, I wonder why it's not being applied. >> > >> > That's (rewrite 'scheme#+ 19) in c-platform.scm (on line 728). >> >> I see. That is handled in optimizer.scm (line 1221). The optimizer runs >> after the scrutinizer and the scrutinizer only runs once. And it's the >> scrutinizer that installs the specializations in types.db. > > Ah, so this effectively means some of the rewrites are useless since the > specializations make them inapplicable. We should consider what to do > with that. I have no clue what would happen if we change the order in > which they run, so maybe just remove rewrite 19 and replace it with your > suggestion? In this case I would just move rewrite 19 to happen before scrutiny. In general, some optimizations like rewrite 19 help the scrutinizer. The scrutinizer makes transformations that might enable some optimizations, which might help the scrutinizer, ... i.e. "cascading optimizations". The optimizer seems to do this kind of looping. The scrutinizer just isn't part of that (and probably can't be as the optimizer works with CPS IIUC). > > What do the others think? > > Cheers, > Peter ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
On Sat, Apr 27, 2019 at 07:33:49AM +0300, megane wrote: > Peter Bex writes: > > On Fri, Apr 26, 2019 at 10:06:15PM +0300, megane wrote: > >> Hi folks! > >> > >> Do you think that adding specializations for multiple argument calls to > >> mathematical functions is worth it? Like this: > > > > We have a rewrite for this already, I wonder why it's not being applied. > > > > That's (rewrite 'scheme#+ 19) in c-platform.scm (on line 728). > > I see. That is handled in optimizer.scm (line 1221). The optimizer runs > after the scrutinizer and the scrutinizer only runs once. And it's the > scrutinizer that installs the specializations in types.db. Ah, so this effectively means some of the rewrites are useless since the specializations make them inapplicable. We should consider what to do with that. I have no clue what would happen if we change the order in which they run, so maybe just remove rewrite 19 and replace it with your suggestion? What do the others think? Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
Peter Bex writes: > On Fri, Apr 26, 2019 at 10:06:15PM +0300, megane wrote: >> Hi folks! >> >> Do you think that adding specializations for multiple argument calls to >> mathematical functions is worth it? Like this: > > We have a rewrite for this already, I wonder why it's not being applied. > > That's (rewrite 'scheme#+ 19) in c-platform.scm (on line 728). I see. That is handled in optimizer.scm (line 1221). The optimizer runs after the scrutinizer and the scrutinizer only runs once. And it's the scrutinizer that installs the specializations in types.db. > > Cheers, > Peter ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Handling multiple args in types.db
On Fri, Apr 26, 2019 at 10:06:15PM +0300, megane wrote: > Hi folks! > > Do you think that adding specializations for multiple argument calls to > mathematical functions is worth it? Like this: We have a rewrite for this already, I wonder why it's not being applied. That's (rewrite 'scheme#+ 19) in c-platform.scm (on line 728). Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
