On Thu, Jul 14, 2005 at 06:06:24PM -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.

Yes, that's kind of what I was trying to say.

: 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?

Perl 6 already defines ways for dealing with interesting values of
undef, so the particular case of an uninitialized variable is already
something we know might happen, and if it does happen, we kind of
ignore it unless you actually try to use the initialized variable.
But I understand you're asking a more general question.

So maybe what the optimizer wants to do is store such messages off in
some kind of "I could have told you that" location and not bring it
up unless you actually run into the problem, or you ask it to tell
you what warnings it was sitting on somehow.  If all else fails,
some kind of log file maybe.  On the other hand, if you aren't ready
to deal with warnings on stderr, maybe you shouldn't be running an
OS that supports it...


Reply via email to