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. Max > On 30. Dec 2020, at 10:38, Massimiliano Gubinelli <m.gubine...@gmail.com> > wrote: > > Dear Giovanni, > >> On 30. Dec 2020, at 01:35, Giovanni Piredda <pired...@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 >>> >>> https://ccrma.stanford.edu/software/snd/snd/s7.html >>> >>> 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. > > Best > Max > > > >> _______________________________________________ >> Texmacs-dev mailing list >> Texmacs-dev@gnu.org <mailto:Texmacs-dev@gnu.org> >> https://lists.gnu.org/mailman/listinfo/texmacs-dev >> <https://lists.gnu.org/mailman/listinfo/texmacs-dev>
_______________________________________________ Texmacs-dev mailing list Texmacs-dev@gnu.org https://lists.gnu.org/mailman/listinfo/texmacs-dev
