<stikonas>well, I guess it would get easier as more and more tutorials and readme's are written <fossy>tinycc is rather a pile of poo <xentrac>then you are the most heroic plumber since Mario <fossy>woo, 45 minutes to run make configure with gash :p ***Server sets mode: +cnt
***nonlinear3 is now known as nonlinear
<fossy>1.4 hrs for bash configure lessgo ***coldtom0 is now known as coldtom
***ChanServ sets mode: +o rekado
<OriansJ>well performance of scheme code is always a hard problem. Typed languages have a huge bag of dirty tricks to make code run fast. <OriansJ>janneke: how much effort was spent getting MesCC's performance more reasonable? <janneke>OriansJ: the scheme code has not been optimized at all <OriansJ>so performance optimizations in the scheme implementation itself? <OriansJ>or just the generated M1 from the C code? <janneke>the generated M1 code is very straightforward, no performance considerations at all <janneke>if anything, the generated M1 code is optimized somewhat for using a small alphabet, using only three registers (except for division/multiplication maybe) <xentrac>I was surprised at how good Ur-Scheme's performance was <janneke>i spent *a lot* of work on mes.c's performance; but that was mainly experimenting <xentrac>despite doing all its type checks and even operand stack dynamically, it was only like 5× worse than GCC <janneke>in the end, only two things really matter: a fast variable lookup (alist) and proper macro expansion (not re-expanding everything all the time) <xentrac>so I don't know why Schemes are generally so slow. I speculate that it's probably more levels of indirection <fossy>janneke: do you have a statically linked guile for guix yet? <fossy>wow, I found it just after I asked :p <janneke>fossy: the guix bootstrap has been using a static guile forever ;-) <fossy>I am having a lot of trouble building a static guile <fossy>janneke: what was the glibc problem you were having? <janneke>fossy: glibc-2.31 (possibly earlier) needs python during build