Greetings, and thanks! Matt Kaufmann <[email protected]> writes:
... > Please let me know if you have any suggestions for improvement. Can > you point me to a recent GCL already built at UT for which > (get-internal-run-time) returns four values, so that I can try this > out for that case? /p/bin/gcl-2.6.10pre is the latest. I don't plan anything else but bugfixes as defined by failures in acl2,maxima,hol88 or axiom on the various platforms, now in test. I think you should see some speedup. I can post the breakdown of a run with the four values if you are interested. The big culprit is the second, the child user time, which is gcc. There are gains to be had in addressing this interface, though I don't think there is any point to gcl were it not to compile in some fashion into the FSF compiler toolchain. This design also is a major portability gain, though perhaps the future will be 'one chip to rule them all' :-) Eventually gcl should become a gcc frontend. This is far in the future. We already pre-compile cmpinclude.h, but this can be made significantly smaller. We could just leave gcc running and avoid the startup costs. But I don't plan to do anything about this now. It appears that gcl is quite competitive short of gcc as you state, and I guess we'll have to live with this for the moment. Take care, -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
