gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiler design reference sought


From: Camm Maguire
Subject: Re: Compiler design reference sought
Date: Wed, 07 Feb 2024 10:46:46 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Greetings!  Yes, this has been the roadblock for 2.7 for quite a
while -- compiler speed.  In general, the 2.7 compiler is substantially
heavier than 2.6, but the code produced is much better, at least
potentially so.  All users I have polled have said this is a worthwhile
trade off at least in general.  With work I have reduced the gcl compiler
overhead to less than one half the gcc overhead when building gcl
itself, which I think is acceptable.  I am just tackling the
applications now but will aim for the same minimum compiler performance.

There are quite a few known optimizations yet to be implemented because
of the impact on compiler speed.  I do believe there is an algorithmic
solution to this, but backing out the impact of changing the type of a
binding down the line when one has discovered it is more restricted than
thought without catch/throw is challenging.  These types are primarily
used in branch elimination and type propagation.  In principle, if the
output of pass 1 (e.g. c1lambda-expr) were constrained to reference a
small number of primitives, ideally just special operators, one might be
able to redo the propagation/elimination on this output after the fact.

2.6 has an extremely bare and ad-hoc type system but which is very
fast.  Almost all variables and bindings are type T.  2.7 computes
everything accurately and attains good performance with bitvector
representations.  So the basic operations are sound and fast, it is just
the processing on conflicts which needs work.

I can build maxima on my machine with approximately 2.6 performance and
just 3 test errors at present.  fricas builds are the slowest by far --
evidently the code generated are generating many more type conflicts
than typical in other systems.  I will pinpoint and address this at some
point hopefully in the near future.

Take care,

"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:

> Sorry, I should really try again before sending the last email. The
> "tangle0.lisp" I extracted, can indeed be compiled by GCL 2.7.0 in a few
> seconds:
>
>>(compile-file "tangle0.lisp")
>
> ;; Compiling tangle0.lisp.
> ;; End of Pass 1.
> ;; End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> ;; Finished compiling /Users/binghe/Lisp/AXIOM/axiom-code/books/tangle0.o.
> #P"/Users/binghe/Lisp/AXIOM/axiom-code/books/tangle0.o"
> NIL
> NIL
>
> P.S. The full "tangle.lisp" from AXIOM source code, when compiled by GCL
> 2.7.0, is really low. But now I don't have confidence to say anything
> like "infinite loop" now. Perhaps it just needs some more time, e.g. 10
> minutes.
>
> --Chun
>
> On 07/02/24 20:34, Chun Tian (binghe) wrote:
>> Hi Camm,
>> 
>> Is it possible that the "iteration" in the GCL compiler that you
>> mentioned, may not terminate (i.e. falling into infinite loops) for
>> certain inputs?
>> 
>> The attached Lisp code is the very beginning part of AXIOM's "tangle"
>> utility for extracting code from LaTeX files. In my machine, GCL 2.7.0
>> compiler seems take forever to compile the (only) Lisp function in it.
>> 
>> My guess is that, in the function, many other Lisp functions are
>> referenced, but these functions are to be defined at later position of
>> the code, and thus their type information is unknown. GCL 2.6.x can
>> compile this file any way, but the current GCL 2.7.0 compiler seems
>> failing into infinite loops.
>> 
>> Regards,
>> 
>> Chun TIAN
>> 
>> On 05/02/24 02:27, Camm Maguire wrote:
>>> Greetings!  Over the years, various theoretical papers on algorithms for
>>> Common Lisp utilities have been very helpful in GCL development,
>>> e.g. Baker's paper on the type system.
>>>
>>> I am looking for a reference on compiler design algorithms which handle
>>> type inferencing most efficiently.  Right now we iterate on conflict,
>>> and I think this is too slow.  Pointers most appreciated!
>>>
>>> Take care,
>>>
>

-- 
Camm Maguire                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]