[Top][All Lists]

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

Re: [Texmacs-dev] TeXmacs with S7 Scheme

From: Massimiliano Gubinelli
Subject: Re: [Texmacs-dev] TeXmacs with S7 Scheme
Date: Wed, 30 Dec 2020 11:40:36 +0100

Hi all,
 Just to have some comparison metrics in this discussion, I've tried to run this program

(define (fib n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))
(display (fib 40))

on my machine (MacBook Air 2019) for Guile 1.8, Guile 2.2.7, Guile 3.0.4 and S7, this are the results:
Guile 1.8.8 : 40.595 sec
Guile 2.2.7 : 8.102 sec
Guile 3.0.4 : 3.864 sec
S7 : 3.297 sec

The results for Guile2/3 are from the compiled code (excluding the compilation time). If we force Guile2/3 to use only the interpreter (with GUILE_AUTO_COMPILE=0 and clean cache) we have

Guile 2.2.7: 120 sec
Guile 3.0.4: 60 sec

So, S7 seems a quite fast interpreter and also the benchmark shows the situation in Guile-land. For some reason however, our use-case is not fully captured by this benchmark.


On 30. Dec 2020, at 10:38, Massimiliano Gubinelli <m.gubinelli@gmail.com> wrote:

Dear Giovanni,

On 30. Dec 2020, at 01:35, Giovanni Piredda <pireddag@posteo.de> wrote:

Am 30.12.2020 um 00:58 schrieb Massimiliano Gubinelli:
Dear all,
I've spent the last few days in integrating S7 Scheme


with TeXmacs to replace Guile. S7 is a very small scheme interpreter and I wanted to see how difficult was to port TeXmacs to it and whether performance is acceptable. The good thing is that porting is not very difficult and now that I understand the process better, I think will be also possible to port TeXmacs to other scheme interpreters if needed. Unfortunately performance seems to be worser than Guile 1.8 so at the moment does not seems a viable option.

I have a suspicion here---that having many different possible implementations of Scheme may be dangerous: packages written for one implementation may not work with another one, and this might hinder the development of user-contributed packages, and I think user contributions would help the development and diffusion of TeXmacs.

But perhaps it is sufficient that there is one "official" TeXmacs version (with Guile :-) ) and then the presence of alternatives would not hinder developments on the official version.

I'm also maintaining a port to Guile 2/3 which seems to work fine.

I am eagerly waiting for it to become the main TeXmacs version.

I'm not doing this for the sake of having various implementations. From the point of view of the user there is not much difference. However there are some issues inherent with the use of Guile which I was considering and trying to find alternatives for.

The current situation is the following:

1) Guile 1.8 is not supported in major Linux distributions. This makes more difficult than it should be for us to keep up to date packages. 

2) Guile 2 is supported in all the major linux distributions, however I'm not sure what happens on Windows. Moreover the performance of Guile 2 for our use-case seems not great, i.e. not better than Guile 1.8. Lilipond, a program which uses Guile much as we do, seems to be still on Guile 1.8 for this reason. I've checked how they do to support Windows and they cross-compile from a Linux machine. 

3) Guile 3 is not yet in all the major Linux distributions, as far as I understand. 

4) As far as I see Guile developers do not care too much about Windows. It is usually not easy to compile Guile on Windows and currently Guile 3 seems not supported there, also I do not know what will happen to the passage to the ARM architecture on Mac (Guile3 has a machine code compiler so it depends on the underlying architecture).

5) Guile 3 is faster than Guile 2 and interpreted code run as far as Guile 1.8 (but to faster). However Guile 2/3 can also compile code to a bytecode interpreter and Guile 3 has a JIT compiler which produce machine code, so we could hope that it make TeXmacs faster and that we can write more parts in scheme instead of C++.

From my point of view is unclear what is the best decision for the long term future of TeXmacs. Currently I see two reliable alternatives:

1) We stick to Guile 1.8. We can just integrate it in our codebase (as we do with PDFWriter) and strip away all the parts we do not need, so that it is easier to maintain and compile in Windows and packageable in Linux. 

2) Follow Guile developers into Guile 3+ and maintain compatibility with Guile 1.8 as a fallback. On Linux we link against Guile 2/3 and on the other platforms we use the best alternative we have.


Texmacs-dev mailing list

reply via email to

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