I just pushed a commit to the new multiple-values branch that implements REFLECT_CODE_MULTIPLE_VALUES. Most of the smarts still end up in Prim_values, the stack magician. The reflection(?) improves the performance of the tests (aka tests/check.scm) dramatically.
With a Prim_call_with_values that longjmps out of compiled code at every opportunity, (load "check") was 124% slower (taking more than twice as long!). With a reflect code, it is only 20% slower. I'm not sure why tests/check.scm hammers so on poor Prim_values. The compiler was relatively unaffected by ALL of this, but it uses its own implementation of call-with-values, calling it transmit-values and implementing it in compiler/base/mvalue.scm. I replaced transmit-values with call-with-values but realized later that I really didn't need to. I do not have SVM builds working yet, but I don't expect that will be a problem. Is tools/patch.scm a problem? Too kludgerrific? How SHOULD I train a 9.2 build host? Using Prim_values may be 20% slower than the old, closure-based, restricted implementation, but maybe it is good enough? Normal continuations are unaffected. The restriction is removed and r7rs mollified. Is there something more that can be done? Is the 20% slow-down mostly the unavoidable cost of using primitives, crossing the C / Scheme divide? _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
