[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation time with Guile 3.0.3-to-be
From: |
Ludovic Courtès |
Subject: |
Re: Compilation time with Guile 3.0.3-to-be |
Date: |
Thu, 04 Jun 2020 15:29:57 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hello!
Andy Wingo <wingo@igalia.com> skribis:
> On Thu 04 Jun 2020 09:50, Ludovic Courtès <ludo@gnu.org> writes:
[...]
>> For the record, the optimizations currently used in (guix build compile)
>> are between the new -O0 and -O1:
>>
>> (cond ((or (string-contains file "gnu/packages/")
>> (string-contains file "gnu/tests/"))
>> ;; Level 0 is good enough but partial evaluation helps preserve the
>> ;; "macro writer's bill of rights".
>> (override-option #:partial-eval? #t
>> (optimizations-for-level 0)))
>
> Here fwiw I would use -O1. It is basically the same as -O0 except that
> it adds partial evaluation and it inlines primcalls. If you are willing
> to do partial evaluation, you are probably willing to inline primcalls
> too; I think it typically leads to less code and the compilation time is
> similar to -O0.
Alright, let’s do that.
>> ((string-contains file "gnu/services/")
>> ;; '-O2 -Ono-letrectify' compiles about ~20% faster than '-O2' for
>> ;; large files like gnu/services/mail.scm.
>> (override-option #:letrectify? #f
>> (optimizations-for-level 2)))
>
> Interesting. I think this is probably a bug of some sort that we'll
> have to keep working on.
Yeah I think memory consumption increases noticeably with
letrectification, which in turns means more GC activity.
> Note that in 3.0.3 there is also a new phase called "lowering". Before
> a compiler from Tree-IL to language X is called, the tree-IL program is
> "lowered" -- meaning canonicalized and optionally optimized.
>
> (define (lower-exp exp env optimization-level opts)
> (let ((make-lowerer (language-lowerer (lookup-language 'tree-il))))
> ((make-lowerer optimization-level opts) exp env)))
>
> Similarly there is an analysis pass for warnings, which runs before
> lowering:
>
> (define (analyze-exp exp env warning-level warnings)
> (let ((make-analyzer (language-analyzer (lookup-language 'tree-il))))
> ((make-analyzer warning-level warnings) exp env)))
>
> These can be interesting to test different phases of the tree-il ->
> bytecode path.
OK, I’ll take a look.
>> The profile looks like this:
>>
>> scheme@(guile-user)> ,pr (define t (call-with-input-file
>> "gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to
>> 'tree-il))))
>> % cumulative self
>> time seconds seconds procedure
>> 13.16 0.45 0.40 anon #x1136458
[...]
>> It’d be great to waive the anonymity of that first lambda. :-)
>
> I think I just fixed it :)
Yay, thank you, it’s much nicer now!
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(system base compile)
scheme@(guile-user)> ,pr (define t (call-with-input-file
"gnu/packages/python-xyz.scm" (lambda (port) (read-and-compile port #:to
'tree-il))))
% cumulative self
time seconds seconds procedure
16.24 0.52 0.49 set-source-properties!
12.82 0.47 0.39 ice-9/boot-9.scm:3128:0:module-gensym
4.27 0.13 0.13 ice-9/popen.scm:168:0:reap-pipes
4.27 0.13 0.13 ice-9/psyntax.scm:749:8:search
3.42 0.13 0.10 ice-9/boot-9.scm:2201:0:%load-announce
3.42 0.10 0.10 ice-9/boot-9.scm:3434:11:b
3.42 0.10 0.10 read
3.42 0.10 0.10 source-properties
2.56 50.34 0.08 ice-9/threads.scm:388:4
2.56 12.56 0.08 ice-9/psyntax.scm:1611:10:parse
2.56 0.08 0.08 module-variable
2.56 0.08 0.08 memoize-expression
2.56 0.08 0.08 ice-9/psyntax.scm:668:4:make-binding-wrap
1.71 0.08 0.05 ice-9/boot-9.scm:2790:0:module-ref-submodule
1.71 0.05 0.05 number->string
1.71 0.05 0.05 ice-9/boot-9.scm:1396:0:symbol-append
1.71 0.05 0.05 append
1.71 0.05 0.05 string-append
0.85 270.25 0.03 ice-9/boot-9.scm:220:5:map1
--8<---------------cut here---------------end--------------->8---
Nowadays I freak out every time I see those weak hash tables show up. ;-)
Well, given the size of the file, it’s no surprise that
‘set-source-properties!’ is called a lot, but it’s still worrying that
it’s #1. (Perhaps an issue similar to <https://bugs.gnu.org/40194>?)
> I think the reap-pipes call is a pretty bad sign, incidentally!
Yeah, it was discussed recently and I can’t explain it:
https://lists.gnu.org/archive/html/guile-devel/2020-05/msg00019.html
Thanks for your feedback!
Ludo’.