On Thu, Jul 14, 2005 at 18:06:24 -0700, Dave Whipp wrote: > Yuval Kogman wrote: > > > - optimizers stack on top of each other > > - the output of each one is executable > > - optimizers work in a coroutine, and are preemptable > > - optimizers are small > > - optimizers operate with a certain section of code in mind > > ... > >Optimizers get time slices to operate on code as it is needed. They > >get small portions - on the first run only simple optimizations are > >expected to actually finish. > > ... > > A couple of thoughts spring to mind: in these coming times of ubiquitous > multi-core computing with software transaction support, perhaps it would > be realistic to place optimisation on a low-priority thread. So much code is > single-threaded that anything we can do to make use of dual-cores is > likely to improve system efficiency.
The API i proposed actually has that in mind =) > > The other thing that I thought of was the question of errors detected during > optimisations. It is possible that an optimiser will do a more > in-depth type inference (or dataflow analysis, etc.) and find errors in the > code (e.g. gcc -O2 adds warnings for uninitialised variables). This > would be a compile-time error that occurs while the code is running. If a > program has been running for several hours when the problem is found, > what do you do with the error? Would you even want to send a warning to > stderr? Good question... I think that such errors are only reported if the user either enables a per code pragma like 'use checks::expensive' or something like that, or forces everything to happen at compile time (like when shipping a product, or testing a release).' -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!
pgpYgqIRc4zE2.pgp
Description: PGP signature
