Re: srfi-18 and the vm
l...@gnu.org (Ludovic Courtès) writes: Hello, Andy Wingo wi...@pobox.com writes: For loading uncompiled scripts, things will be slower, unless your modules #:use-syntax some other transformer. I don't know where the tradeoff is between the increased expansion speed due to compilation and slowdown due to a complete codewalk, but it's certainly there. Yes. Likewise, it may be reasonable to assume from now on that most of the code will be compiled. For instance, an uncompiled script may just be a small code snipped that uses mostly compiled code. It seems to me that once we have a completely working compiler, we need to ask if there are any circumstances left where it is better to use the current interpreter instead. If the answer to that is yes, the details of those remaining circumstances will (probably) make it obvious whether the pre-memoization idea is worthwhile. Do we already have performance measurements, and are those recorded / summarized somewhere? OTOH I would suspect that we can implement some kind of just-in-time compilation -- essentially for each use-modules we can check to see if the module is compiled, and if not just compile it then and there. It would be a little slow the first time, but after that it would load much faster, even faster than before. Python does this. We could add a guile --no-comp option to disable it. I don't like this idea because it implies implicitly letting Guile fiddle with the user's file system. I don't see why that should be. Isn't it possible to read a .scm file, compile its contents, and hold the compiled programs in memory? Regards, Neil
Re: srfi-18 and the vm
Hello, Andy Wingo wi...@pobox.com writes: For loading uncompiled scripts, things will be slower, unless your modules #:use-syntax some other transformer. I don't know where the tradeoff is between the increased expansion speed due to compilation and slowdown due to a complete codewalk, but it's certainly there. Yes. Likewise, it may be reasonable to assume from now on that most of the code will be compiled. For instance, an uncompiled script may just be a small code snipped that uses mostly compiled code. OTOH I would suspect that we can implement some kind of just-in-time compilation -- essentially for each use-modules we can check to see if the module is compiled, and if not just compile it then and there. It would be a little slow the first time, but after that it would load much faster, even faster than before. Python does this. We could add a guile --no-comp option to disable it. I don't like this idea because it implies implicitly letting Guile fiddle with the user's file system. OTOH, it's a pragmatic approach to the problem at hand. Thanks, Ludo'.
Re: srfi-18 and the vm
Andy Wingo wi...@pobox.com writes: With psyntax running a pre-analysis phase on all source code, we can do away with lazy memoization entirely -- a neat hack, but it made eval.c buggy and impenetrable. I'll write more about that in the future. Anticipating your more in the future, do you mean that the pre-analysis does all the memoization in advance? Neil
Re: srfi-18 and the vm
Hi! On Sun 24 May 2009 00:03, l...@gnu.org (Ludovic Courtès) writes: I'm slightly concerned that doing things ahead of time rather than just in time (i.e., lazily) would have a negative impact on the interpreter's start-up time, which may be noticeable for short-lived scripts. In the guile -c 0 case, we don't have this issue, because no source is expanded; it's all compiled already. The load time on my machine is about 20 ms, which is about equal to what we discussed before (10 ms base + 10 ms for psyntax). It is faster than before, and will get faster. For loading uncompiled scripts, things will be slower, unless your modules #:use-syntax some other transformer. I don't know where the tradeoff is between the increased expansion speed due to compilation and slowdown due to a complete codewalk, but it's certainly there. OTOH I would suspect that we can implement some kind of just-in-time compilation -- essentially for each use-modules we can check to see if the module is compiled, and if not just compile it then and there. It would be a little slow the first time, but after that it would load much faster, even faster than before. Python does this. We could add a guile --no-comp option to disable it. What do you think? I think it's a good question, and we're going to have to settle on a good answer at some point. Cheers, Andy. -- http://wingolog.org/
Re: srfi-18 and the vm
¡Hola! Andy Wingo wi...@pobox.com writes: I'm catching up with mail. On my syncase-in-boot-9 branch, I enabled compilation of srfi-18 and fixed a bug in it regarding multiple-value returns. Now I just ran the srfi-18 test like 100 times in a row and it didn't show any strange errors. Yy! What kind of strange errors would it lead to before? When SRFI-18 wasn't compiled, I would expect multiple value returns would translate in a `value.c' struct that would then be passed along as a single value. Thanks, Ludo'.
Re: srfi-18 and the vm
On Fri 22 May 2009 17:10, l...@gnu.org (Ludovic Courtès) writes: ¡Hola! Andy Wingo wi...@pobox.com writes: I'm catching up with mail. On my syncase-in-boot-9 branch, I enabled compilation of srfi-18 and fixed a bug in it regarding multiple-value returns. Now I just ran the srfi-18 test like 100 times in a row and it didn't show any strange errors. Yy! What kind of strange errors would it lead to before? Random ones based on races, as code was lazily memoized from multiple threads at once. When SRFI-18 wasn't compiled, I would expect multiple value returns would translate in a `value.c' struct that would then be passed along as a single value. Indeed. The VM truncates multiple values, but here we were doing a (let ((x (values))) something x), which returned 0 values to a continuation needing a value, raising a valid error. Fixed that in the original source code. In addition, we were sometimes getting 0 values in a for-effect context, which the GHIL-GLIL compiler didn't support. Like this: (begin (call/cc (lambda (k) (k))) 10) I've fixed this in the tree-il-glil compiler. Cheers, Andy -- http://wingolog.org/
