Just to add a little, I am working on addressing the compilation time
issue,
and the newer version is significantly faster, but there is more to be done.
A second issue is that Aldor is much stricter about imports and function
declarations. I have a set of changes that may help to address these, but
there is a bit more to do. If there's anyone who wants to help with these,
it would be appreciated.
Peter
On 2 July 2018 at 20:43, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote:
> Riccardo GUIDA wrote:
> >
> > Thoughts:
> >
> > * The Aldor compiler is an improved version of the Spad compiler,
> written by one of its authors. So, as a non-expert, I would blindly tend to
> say that Aldor compiler is "better" than Spad compiler. At least it has
> written documentation and, I guess, it should produce faster compiled code
> (eg by compiling via the C compiler not the lisp one).
> >
> > * Spad syntax is, say, "90% equal" to Aldor, so moving the .spad files
> in algebra to .as files should not be impossible.
> >
> > * I guess the really "hard" problem is "porting" the interpreter to work
> on the top of Aldor, maybe using its -gloop shell.
> >
> > * On this list, I've never heard mentioning this "port to Aldor" even as
> a long term/dreamy project, while I've heard hypothetical mentions on
> rewriting the current fricas interpreter, which should also be "hard".
> >
> > So my questions:
> >
> > * would "porting" the interpreter on the top of aldor be much more
> difficult & unrealistic than rewriting the current fricas interpreter?
> >
> > * Which solution do you prefer, and, more important, could you somehow
> explain why?
>
> This "porting to Aldor" thing is more complex than your questions
> suggest. First, Aldor was intended to be "library compiler", so
> natural use of Aldor would be to compile FriCAS library. Clearly
> "not impossible", but requires some work. I view this as main
> part of port, because once it is done could use Aldor interpreter
> as user interface and get "FriCAS on Aldor" in this way (of course
> loosing most of functionality of current FriCAS interpreter).
>
> There is question of desired runtime support ("virtual machine").
> Since Aldor can generate Lisp code we could continue to use Lisp
> runtime. With Lisp runtime it should be possible to use
> current FriCAS interpreter with minimal changes. Or we could
> try to port to Aldor runtime (working on top of C). Using
> Aldor runtime and compilation via C has advantage to better
> speed of compiled code (my guesstimate is that we can gain
> factor of 2 compared to sbcl).
>
> You write about porting "interpreter". Using Lisp runtime
> this should be quite small job. If one want interpreter
> on Aldor runtime, then IMO best way is to rewrite
> interpreter -- you need it in a language which is compatible
> with Aldor runtime. In other words I treat interpreter
> rewrite as preconditiont to port to Aldor.
>
> Before we spent time on port we should think about benefits.
> Unfortunatly, this does not look so good. First, speed
> on current Spad code depends on several optimizations
> performed by Spad compiler. Aldor in principle can do
> better optimizations, but current Aldor interface
> essentially disables all possibilities for optimization.
> So in intermediate stages we will get _slower_ code.
> Only when port is done and we have "native Aldor"
> (as opposed to using Aldor-FriCAS interface) we can
> count on faster code and benefit from Aldor
> optimizations.
> Second, my recent experiments suggest that Spad compiler
> compiles about 10 times faster than Aldor compiler.
> I would say that Spad compiler is slow, but tolerable.
> ATM for me Aldor is "too slow", IMO it needs significant
> improvement to compilation speed.
> Third, Aldor language is better. However, there is
> a factor here: while better I do not treat Aldor as
> kind of ultimate language. I think that various aspects
> of Aldor need improvement. So there is question
> how much effort improvements to Aldor compiler would
> take?
>
> Now, which solution I take? ATM I leave question of
> Aldor port open. As I wrote I consider interpreter
> rewrite as precondition to porting intepreter to Aldor,
> so before rewrite I see no point in planning/attempting port.
> For FriCAS library ("algebra") problem is that at
> intermedate stages there is loss, only at the end
> we would get benefits. Important question is
> developement of Aldor. Namely, Aldor compiler is much
> larger than Spad compiler, so probaly will require
> much more effort. It seems that currently only
> Peter Broadbery is working on Aldor -- I have
> informed him about speed problem (and some other).
> I must admit that I am reluctant to spent significant
> work on Aldor -- simply I have limited time available
> and it would compete with work on FriCAS.
>
> --
> Waldek Hebisch
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
