Open larceny-trac-import opened 11 years ago
Author: pnkfelix I opened up Ticket #76 after I realized what the problem here was. So we're almost certainly not going to get the error message above anymore.
I don't want to close this ticket until I got a chance to see what our status is on attempting to compile Testsuite/Lib now.
Author: pnkfelix punt
Author: pnkfelix BlarGh, this is that damn time-dependant "test"; as a reminder, here's the note that goes with it:
; NOTE! This test can fail because it computes a ratio of execution
; times of two identical programs, but the programs are not the sole
; determinant of how fast they run... I have observed a factor-of-two
; difference on _identical_ binary code running in the _same_ process,
; where the only difference between the two was where in memory the
; code was located.
Why are we checking for this again? Could we at the very least lower the ratio to something more reasonable than expecting +/- 10% of variation? I'm going to change the test so that it prints out the ratio in the failure cases...
Author: pnkfelix (the original bug that this test was introduced for, bug 105, had the following time ratios:
> (time (test1))
Words allocated: 474
Words reclaimed: 0
Elapsed time...: 4280 ms (User: 4270 ms; System: 0 ms)
Elapsed GC time: 0 ms (in 0 collections.)
100000000
> (time (test2))
Words allocated: 482
Words reclaimed: 0
Elapsed time...: 15787 ms (User: 15650 ms; System: 0 ms)
Elapsed GC time: 0 ms (in 0 collections.)
100000000
So if we wanted to keep this as a true "regression test" but make it something more reasonable in terms of not signalling false positives, we could try to detect a speed difference of 70% or more, rather than 10%...
Author: tov mono punt
Author: pnkfelix punt
Reported by: pnkfelix on Tue May 16 13:55:29 2006 Well, we can get a bootstrap heap going, and my hacked up
(build-twobit)
completes without dying, so that's good.But my first attempt to compile a file led to this: