Hi Bryce, can you explain, please, what you mean is 'failed to compile'? What blocking Exupery to compile them? Primitives, special bytecodes?
On 26/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > My current plan for 0.13 is: > * Get background compiler to ignore methods that failed to compile > * Don't flush the code cache on every class change > * Fix more bugs > * Add some instrumentation to get quantitative information on time > spent compiling and the percentage of time spent in compiled code. > > The goal is to make the background compiler practical. It will still > be limited due to missing features slowing down compiled code and slow > compile times. A test would be to run the background compiler until > Exupery was compiled then to start playing with tinyBenchmarks and to > see the improvement as it compiles the methods and inlines the > primitives. > > Currently the background compiler doesn't avoid methods that have > failed to compile once. This is a problem as the compilation queue > could get full of methods that don't compile blocking compilation of > methods that do compile. > > Flushing the code cache on every class change is overkill. It also > reduces the value of some of the acceptance testing as it can't > effectively test compiling tests that change classes and several do. > > It would be nice if Exupery reported the percentage of time spent in > compiled code to gauge how well the background compiler was doing. I > can measure this using oprofile but not in Squeak. It would also be > nice if Exupery recorded how long a method took to compile to gauge > how much of a problem compilation speed currently is. It would be nice > if Exupery recorded why methods failed to compile so it was easy to > figure out how important adding the remaining missing features is. > > > The other possibility for 0.13 would be to optimise compilation time. > There are a few methods that take minutes to compile due to known > performance bugs in the register allocator. Increasing the speed of > the compiler will both make compilation more practical and make it > cheaper to compile more code in tests. > > The third major thing required before a 1.0 would be to implement > cascades and a few more bytecodes. This should allow Exupery to > optimise more code successfully. This is aiming to optimise run time > performance. I'm not considering this for 0.13 but is needed before > 1.0. > > Bryce > _______________________________________________ > Exupery mailing list > [email protected] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
