Greetings, and thanks for the pointer! We may be able to address the non-null lexical environment if it is deemed important. But the remaining issues if any appear inaccessible as the author states he is not publishing the test code. Why not?
I care a lot about GCL performance. In general, time permitting, I pledge my assistance in getting the best performance out of GCL for any example code submitted. What I'd need for this is of course the source, and preferably the comparative timing information with gc broken out for the compared systems in question. If the systems are other than cmucl and clisp (the ones I have installed), then a disassembly of the code in those systems would be useful as well. To this end, perhaps sbcl is a better reference system than cmucl -- I've never really understood why there are too different projects here. Take care, "Paul F. Dietz" <[EMAIL PROTECTED]> writes: > Juho Snellman benchmarked some code he wrote for a Google > programming project, and found gcl wasn't very good at > all: > > http://www.cs.helsinki.fi/u/jesnellm/blog/archive/2005-08-27b.html > > He told me the biggest problem was gcl wasn't able to compile > defuns in non-null lexical environments: > > ;; compile-file didn't do well on this > > (let ((x ni)) > (defun foo () ...) > (defun bar () ...) > ...) > > Even after he fixed that (with special variables) it was still > rather more slow than sbcl or cmucl. I'd like to see where > the performance bottleneck is for further tuning. > > Paul > > > _______________________________________________ > Gcl-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
