fricas0 and "how to find a regression in 150 seconds"
9 views
Skip to first unread message
Qian Yun
Jul 3, 2022, 6:38:39 AM7/3/22
to fricas-devel
I find the idea of pure lisp build of FriCAS very interesting and
useful. I did some improvement of Kurt's fricas0 at
https://github.com/oldk1331/fricas0
The biggest advantage is that you can start FriCAS quickly and
do computation right away.
No need to spend 1.5 minutes (this is parallel build, single core
can take 6 minutes) to compile FriCAS from source before doing
computation.
fricas0 comes with lisp files pre-compiled from spad files.
Another improvement I did is to allow "load on demand" or
"compile on demand".
If you want to do some (simple) computation like "1+1",
there is no need to compile all lisp files to do that.
You can load the needed algebra lisp files on demand.
Of course, the load (aka interpreting) can be slow. If your
computation is not that simple, you can compile the needed
lisp files before loading.
I find that sbcl has very slow interpreting speed for unknown reason.
ECL calls gcc to do compilation, so it is a bit slow.
I find that CLISP has good loading speed, relatively good compiling
speed, not good but good enough execution speed.
This can have great speed up for using git-bisect to find regression.
I have compiled all 131 versions from 1.3.7 to current git HEAD,
and put them into a separate git repo. It takes surprisingly small
amount of storage -- .git is only 16 MB.
git-bisect will need at most 10 runs to find the faulty commit.
So if a test takes 20 seconds (compile time and execution time) to run,
we can find the faulty commit in under 200 seconds.
For example, the pattern-match integration regression, I have the
following test script:
====test.sh
rm algebra/*fas
echo -e
"f:=integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x)\nis?(operator
mainKernel f,'integral)\n)quit\n" | clisp fricas.lisp | grep false
====
git bisect start; git bisect bad; git checkout HEAD~130; git bisect good
time git bisect run ./test.sh
This gives correct result (c8ef0784485f8106bccbc7c8ecb63be485ec654e)
in 145 seconds.
I have published this (sample/beta) fricas0-repo at
https://github.com/oldk1331/fricas0-repo
== Further optimizations
Current fricas0 runs in single thread. If we run a test once, we then
know which files it uses. Then we can compile them in parallel in
advance for following bisect runs. This should improve git-bisect speed
by a few times more on multi-core machines.
(In the above example, compile time is 12s and execution time is 8s.
So with parallel complication we can get total time from 20s to 10s.)
I think the format of *.daase and *.text can be improved. Some of the
KAF optimization doesn't make sense anymore. Small changes in code
should not cause huge changes in them.
- Qian
useful. I did some improvement of Kurt's fricas0 at
https://github.com/oldk1331/fricas0
The biggest advantage is that you can start FriCAS quickly and
do computation right away.
No need to spend 1.5 minutes (this is parallel build, single core
can take 6 minutes) to compile FriCAS from source before doing
computation.
fricas0 comes with lisp files pre-compiled from spad files.
Another improvement I did is to allow "load on demand" or
"compile on demand".
If you want to do some (simple) computation like "1+1",
there is no need to compile all lisp files to do that.
You can load the needed algebra lisp files on demand.
Of course, the load (aka interpreting) can be slow. If your
computation is not that simple, you can compile the needed
lisp files before loading.
I find that sbcl has very slow interpreting speed for unknown reason.
ECL calls gcc to do compilation, so it is a bit slow.
I find that CLISP has good loading speed, relatively good compiling
speed, not good but good enough execution speed.
This can have great speed up for using git-bisect to find regression.
I have compiled all 131 versions from 1.3.7 to current git HEAD,
and put them into a separate git repo. It takes surprisingly small
amount of storage -- .git is only 16 MB.
git-bisect will need at most 10 runs to find the faulty commit.
So if a test takes 20 seconds (compile time and execution time) to run,
we can find the faulty commit in under 200 seconds.
For example, the pattern-match integration regression, I have the
following test script:
====test.sh
rm algebra/*fas
echo -e
"f:=integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x)\nis?(operator
mainKernel f,'integral)\n)quit\n" | clisp fricas.lisp | grep false
====
git bisect start; git bisect bad; git checkout HEAD~130; git bisect good
time git bisect run ./test.sh
This gives correct result (c8ef0784485f8106bccbc7c8ecb63be485ec654e)
in 145 seconds.
I have published this (sample/beta) fricas0-repo at
https://github.com/oldk1331/fricas0-repo
== Further optimizations
Current fricas0 runs in single thread. If we run a test once, we then
know which files it uses. Then we can compile them in parallel in
advance for following bisect runs. This should improve git-bisect speed
by a few times more on multi-core machines.
(In the above example, compile time is 12s and execution time is 8s.
So with parallel complication we can get total time from 20s to 10s.)
I think the format of *.daase and *.text can be improved. Some of the
KAF optimization doesn't make sense anymore. Small changes in code
should not cause huge changes in them.
- Qian
Waldek Hebisch
Jul 3, 2022, 8:42:30 AM7/3/22
to fricas...@googlegroups.com
On Sun, Jul 03, 2022 at 06:38:22PM +0800, Qian Yun wrote:
> I find the idea of pure lisp build of FriCAS very interesting and
> useful. I did some improvement of Kurt's fricas0 at
> https://github.com/oldk1331/fricas0
>
> The biggest advantage is that you can start FriCAS quickly and
> do computation right away.
>
> No need to spend 1.5 minutes (this is parallel build, single core
> can take 6 minutes) to compile FriCAS from source before doing
> computation.
>
> fricas0 comes with lisp files pre-compiled from spad files.
>
> Another improvement I did is to allow "load on demand" or
> "compile on demand".
>
> If you want to do some (simple) computation like "1+1",
> there is no need to compile all lisp files to do that.
> You can load the needed algebra lisp files on demand.
>
> Of course, the load (aka interpreting) can be slow. If your
> computation is not that simple, you can compile the needed
> lisp files before loading.
>
> I find that sbcl has very slow interpreting speed for unknown reason.
What we use is called by sbcl folks "old interpreter". There
> I find the idea of pure lisp build of FriCAS very interesting and
> useful. I did some improvement of Kurt's fricas0 at
> https://github.com/oldk1331/fricas0
>
> The biggest advantage is that you can start FriCAS quickly and
> do computation right away.
>
> No need to spend 1.5 minutes (this is parallel build, single core
> can take 6 minutes) to compile FriCAS from source before doing
> computation.
>
> fricas0 comes with lisp files pre-compiled from spad files.
>
> Another improvement I did is to allow "load on demand" or
> "compile on demand".
>
> If you want to do some (simple) computation like "1+1",
> there is no need to compile all lisp files to do that.
> You can load the needed algebra lisp files on demand.
>
> Of course, the load (aka interpreting) can be slow. If your
> computation is not that simple, you can compile the needed
> lisp files before loading.
>
> I find that sbcl has very slow interpreting speed for unknown reason.
is also new interpreter which is supposed to be much faster.
Historically, early sbcl compiled everything, "interpreter"
compiled on the fly. Later sbcl folks added true interpreter.
Early in FriCAS developement it turned out that FriCAS passed
a lot of expression to Lisp 'eval' and compiling them (which was
sbcl default) took substantial time. So in 'fricas-lisp.lisp'
we have:
(setf sb-ext:*evaluator-mode* :interpret)
This gave subtantial speedup. Some time ago it tunrned out
that this setting is incompatible with using new sbcl interpreter.
So you may wish to experiment with this new interpreter
(which was configured (and probably still is) at sbcl
build time) removing or changing setting above.
> ECL calls gcc to do compilation, so it is a bit slow.
> I find that CLISP has good loading speed, relatively good compiling
> speed, not good but good enough execution speed.
to bytecode is quite fast and interpretation of byte code
also is reasonably fast. IIRC ECL bytecode runs faster
than "compiled" CLISP.
Similarly GCL has fast interpreter (but I do not know if
it has any advantage over ECL).
Also, Clozure CL compiles much faster than sbcl.
One may also look at old Codemist CLL build. With CCL
vast majority of algebra was interpreted, but few selected
parts were compiled to C for speed (for this CCL has special
Lisp to C compiler). While trying to resurect CCL probably
is not worth the effort similar idea could save compile
time with other Lisp-s: identify speed-critical files and
compile them, interpret the rest. CCL list of compiled
files may be a start (but probably there are more critical
files now).
> This can have great speed up for using git-bisect to find regression.
>
> I have compiled all 131 versions from 1.3.7 to current git HEAD,
> and put them into a separate git repo. It takes surprisingly small
> amount of storage -- .git is only 16 MB.
> git-bisect will need at most 10 runs to find the faulty commit.
>
> So if a test takes 20 seconds (compile time and execution time) to run,
> we can find the faulty commit in under 200 seconds.
>
> For example, the pattern-match integration regression, I have the
> following test script:
>
> ====test.sh
> rm algebra/*fas
> echo -e "f:=integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x)\nis?(operator
> mainKernel f,'integral)\n)quit\n" | clisp fricas.lisp | grep false
> ====
>
> git bisect start; git bisect bad; git checkout HEAD~130; git bisect good
> time git bisect run ./test.sh
>
> This gives correct result (c8ef0784485f8106bccbc7c8ecb63be485ec654e)
> in 145 seconds.
> I have published this (sample/beta) fricas0-repo at
> https://github.com/oldk1331/fricas0-repo
>
> == Further optimizations
>
> Current fricas0 runs in single thread. If we run a test once, we then
> know which files it uses. Then we can compile them in parallel in
> advance for following bisect runs. This should improve git-bisect speed
> by a few times more on multi-core machines.
>
> (In the above example, compile time is 12s and execution time is 8s.
> So with parallel complication we can get total time from 20s to 10s.)
>
> I think the format of *.daase and *.text can be improved. Some of the
> KAF optimization doesn't make sense anymore. Small changes in code
> should not cause huge changes in them.
lead to large change in object code (but usually change to
object code is also small), this is nature of compilation.
--
Waldek Hebisch
Qian Yun
Jul 3, 2022, 9:48:22 AM7/3/22
to fricas...@googlegroups.com
On 7/3/22 20:42, Waldek Hebisch wrote:
>
> What we use is called by sbcl folks "old interpreter". There
> is also new interpreter which is supposed to be much faster.
You are right, this new interpreter is blazing fast when loading
the fricas.lisp (SPAD interp directory)!
For the same integral, sb-fasteval takes 12.5 seconds, sbcl copmile+run
takes 26 seconds, clisp compile+run takes 20 seconds.
> Some time ago it tunrned out
> that this setting is incompatible with using new sbcl interpreter.
> So you may wish to experiment with this new interpreter
> (which was configured (and probably still is) at sbcl
> build time) removing or changing setting above.
>> ECL calls gcc to do compilation, so it is a bit slow.
>> I find that CLISP has good loading speed, relatively good compiling
>> speed, not good but good enough execution speed.
>
> Hmm, if you wish ECL compiles to bytecode. Compilation
> to bytecode is quite fast and interpretation of byte code
> also is reasonably fast. IIRC ECL bytecode runs faster
> than "compiled" CLISP.
ECL bytecode compile+run time is 38.5 seconds.
The default C compile+run time is 25 seconds.
> Similarly GCL has fast interpreter (but I do not know if
> it has any advantage over ECL).
and FriCAS does not support newer 2.6.13-pre releases.
> Also, Clozure CL compiles much faster than sbcl.
loading (actually compiling) fricas.lisp (SPAD interp directory),
but that can be optimized.)
> One may also look at old Codemist CLL build. With CCL
> vast majority of algebra was interpreted, but few selected
> parts were compiled to C for speed (for this CCL has special
> Lisp to C compiler). While trying to resurect CCL probably
> is not worth the effort similar idea could save compile
> time with other Lisp-s: identify speed-critical files and
> compile them, interpret the rest. CCL list of compiled
> files may be a start (but probably there are more critical
> files now).
compile some files and interpret the rest, to achieve the smallest
compile+run time.
>> This can have great speed up for using git-bisect to find regression.
>>
>> I have compiled all 131 versions from 1.3.7 to current git HEAD,
>> and put them into a separate git repo. It takes surprisingly small
>> amount of storage -- .git is only 16 MB.
>> git-bisect will need at most 10 runs to find the faulty commit.
>>
>> So if a test takes 20 seconds (compile time and execution time) to run,
>> we can find the faulty commit in under 200 seconds.
>>
>> For example, the pattern-match integration regression, I have the
>> following test script:
>>
>> ====test.sh
>> rm algebra/*fas
>> echo -e "f:=integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x)\nis?(operator
>> mainKernel f,'integral)\n)quit\n" | clisp fricas.lisp | grep false
>> ====
>>
>> git bisect start; git bisect bad; git checkout HEAD~130; git bisect good
>> time git bisect run ./test.sh
>>
>> This gives correct result (c8ef0784485f8106bccbc7c8ecb63be485ec654e)
>> in 145 seconds.
>
> Nice.
And ClozureCL takes 117 seconds.
ClozureCL can be faster because it spent almost half of the time
compiling src/interp.
I think we can exclude loading of unneeded part, like hyperdoc
interface, and SPAD compiler, etc.
>> I think the format of *.daase and *.text can be improved. Some of the
>> KAF optimization doesn't make sense anymore. Small changes in code
>> should not cause huge changes in them.
>
> I am not sure what you mean. Small changes in source code may
> lead to large change in object code (but usually change to
> object code is also small), this is nature of compilation.
>
in SPAD file can result in thousands lines of changes in *daase and
*text. They have some "Keyed Access File" optimization, right?
- Qian
Qian Yun
Jul 3, 2022, 10:57:09 AM7/3/22
to fricas...@googlegroups.com
On 7/3/22 21:48, Qian Yun wrote:
>>> git bisect start; git bisect bad; git checkout HEAD~130; git bisect good
>>> time git bisect run ./test.sh
>>>
>>> This gives correct result (c8ef0784485f8106bccbc7c8ecb63be485ec654e)
>>> in 145 seconds.
>>
>> Nice.
>
> Now the sbcl fasteval takes 95 seconds.
> And ClozureCL takes 117 seconds.
>
With the help of https://github.com/hoelzro/git-pisect, one can run
parallel.
With git-bisect, it was 95 seconds.
With 2 cores git-pisect, it's 72 seconds.
With 4 cores git-pisect, it's 60 seconds.
With 8 cores git-pisect, it's 51 seconds.
- Qian
Waldek Hebisch
Jul 3, 2022, 1:25:50 PM7/3/22
to fricas...@googlegroups.com
On Sun, Jul 03, 2022 at 09:48:04PM +0800, Qian Yun wrote:
>
>
> On 7/3/22 20:42, Waldek Hebisch wrote:
> >
> >What we use is called by sbcl folks "old interpreter". There
> >is also new interpreter which is supposed to be much faster.
>
> Yes, that is sb-fasteval documented in sbcl/src/interpreter/README.
> You are right, this new interpreter is blazing fast when loading
> the fricas.lisp (SPAD interp directory)!
>
> For the same integral, sb-fasteval takes 12.5 seconds, sbcl copmile+run
> takes 26 seconds, clisp compile+run takes 20 seconds.
>
>
> >Some time ago it tunrned out
> >that this setting is incompatible with using new sbcl interpreter.
>
> More info?
Really nothing to add to what I wrote:
>
>
> On 7/3/22 20:42, Waldek Hebisch wrote:
> >
> >What we use is called by sbcl folks "old interpreter". There
> >is also new interpreter which is supposed to be much faster.
>
> Yes, that is sb-fasteval documented in sbcl/src/interpreter/README.
> You are right, this new interpreter is blazing fast when loading
> the fricas.lisp (SPAD interp directory)!
>
> For the same integral, sb-fasteval takes 12.5 seconds, sbcl copmile+run
> takes 26 seconds, clisp compile+run takes 20 seconds.
>
>
> >Some time ago it tunrned out
> >that this setting is incompatible with using new sbcl interpreter.
>
> More info?
(setf sb-ext:*evaluator-mode* :interpret)
gave error when sbcl was configured with sb-fasteval. I seems
that sbcl folks fixed this.
> >>ECL calls gcc to do compilation, so it is a bit slow.
> >>I find that CLISP has good loading speed, relatively good compiling
> >>speed, not good but good enough execution speed.
> >
> >Hmm, if you wish ECL compiles to bytecode. Compilation
> >to bytecode is quite fast and interpretation of byte code
> >also is reasonably fast. IIRC ECL bytecode runs faster
> >than "compiled" CLISP.
>
> ECL bytecode is enabled by (ext:install-bytecodes-compiler).
> ECL bytecode compile+run time is 38.5 seconds.
> The default C compile+run time is 25 seconds.
to C? Strange.
> >>I think the format of *.daase and *.text can be improved. Some of the
> >>KAF optimization doesn't make sense anymore. Small changes in code
> >>should not cause huge changes in them.
> >
> >I am not sure what you mean. Small changes in source code may
> >lead to large change in object code (but usually change to
> >object code is also small), this is nature of compilation.
> >
>
> I'm not talking about object code, I'm saying that some small changes
> in SPAD file can result in thousands lines of changes in *daase and
> *text. They have some "Keyed Access File" optimization, right?
are used by interpreter and Spad compiler. Anyway, IMO changes
to interp.daase after source change are justified: we have an
index and since positions changed there are changes in index.
Index means that there is no need to load whole interp.daase
which saves startup time and memory use. The savings are not
big but IMO worth to have.
--
Waldek Hebisch
Bill Page
Jul 3, 2022, 3:43:36 PM7/3/22
to fricas...@googlegroups.com
On Sun, 3 Jul 2022 at 06:38, Qian Yun <oldk...@gmail.com> wrote:
>
> I find the idea of pure lisp build of FriCAS very interesting and
> useful. I did some improvement of Kurt's fricas0 at
> https://github.com/oldk1331/fricas0
>
> The biggest advantage is that you can start FriCAS quickly and
> do computation right away.
> ...
>
> I find the idea of pure lisp build of FriCAS very interesting and
> useful. I did some improvement of Kurt's fricas0 at
> https://github.com/oldk1331/fricas0
>
> The biggest advantage is that you can start FriCAS quickly and
> do computation right away.
Clasp is a new implementation of Lisp based on LLVM similar to the way
that ABCL is based on the Java VM.
https://github.com/clasp-developers/clasp
I was interested to see whether Clasp could run fricas0 since one of
the selling points for Clasp is the ability to directly and easily
link with c++ libraries. Apparently Clasp can run maxima. See
https://github.com/clasp-developers/clasp/wiki/How-to-run-maxima-in-clasp
Building Clasp from source is quite time consuming so I ran Clasp
using the pre-compiled docker image:
----
wspage@strix:~$ docker run -it ghcr.io/clasp-developers/clasp:latest
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
app@48e1623454d5:~$ git clone https://github.com/oldk1331/fricas0.git
Cloning into 'fricas0'...
remote: Enumerating objects: 5550, done.
remote: Counting objects: 100% (1531/1531), done.
remote: Compressing objects: 100% (926/926), done.
remote: Total 5550 (delta 1024), reused 657 (delta 603), pack-reused 4019
Receiving objects: 100% (5550/5550), 23.91 MiB | 1.83 MiB/s, done.
Resolving deltas: 100% (4484/4484), done.
app@48e1623454d5:~$ cd fricas0
app@48e1623454d5:~/fricas0$ clasp --load fricas
Starting cclasp-boehmprecise-1.0.0-313-gea5c624d9-cst ... loading image...
Loading resource file /home/app/.clasprc
; caught STYLE-WARNING:
; The variable OPTIONS is defined but never used.
; at unknown location
;
;
; compilation unit finished
; caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
; The variable CORE-IMAGE is defined but never used.
; at unknown location
;
; caught STYLE-WARNING:
; The variable RESTART is defined but never used.
; at unknown location
;
;
; compilation unit finished
; caught 2 STYLE-WARNING conditions
;
; caught STYLE-WARNING:
; Undefined function EXIT-WITH-STATUS
; at unknown location
;
;
; compilation unit finished
; caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
; The variable VAR-NAME is defined but never used.
; at unknown location
;
;
; compilation unit finished
; caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
; The variable S is defined but never used.
; at unknown location
;
;
; compilation unit finished
; caught 1 STYLE-WARNING condition
;
; caught WARNING:
; Undefined variable |writeablep|
; at unknown location
;
; caught WARNING:
; Undefined variable INT
; at unknown location
;
; caught WARNING:
; Undefined variable C-STRING
; at unknown location
;
; caught STYLE-WARNING:
; Undefined function FILENAME
; at unknown location
;
; caught STYLE-WARNING:
; Undefined function FRICAS-FOREIGN-CALL
; at unknown location
;
;
; compilation unit finished
; caught 3 WARNING conditions
; caught 2 STYLE-WARNING conditions
;
Condition of type: UNBOUND-VARIABLE
The variable FRICAS-LISP:|writeablep| is unbound.
No restarts available.
Top level in: #<PROCESS TOP-LEVEL @0x7efdd244cf09 (Running)>.
----
But the result is an error when FriCAS tries to call an external
routine via FFI. I don't know much about this except that after a
quick search of the FriCAS mailing list suggests that a apparently
similar problem involving |writeablep was reported at one point with
ECL The resolution of the problem had something to do with implicit
declarations and external function calls.
https://github.com/fricas/fricas/issues/59
Does anyone have any suggestions on what to try?
Bill Page.
Waldek Hebisch
Jul 3, 2022, 6:50:19 PM7/3/22
to fricas...@googlegroups.com
of macro called 'fricas-foreign-call'. When code tries
to use undefined macro Lisp treats it as a function which
leads to weird error. 'writeablep' is first thing defined
using this macro...
You should be able to go far using fake definition like:
#+:poplog
(eval-when (:compile-toplevel :load-toplevel :execute)
(defmacro fricas-foreign-call (name c-name return-type &rest arguments)
nil)
)
Note: the above is for Poplog, replace 'poplog' above by
whatever string clasp uses for conditional compilation.
Note2: The snippet above is from 'fricas-lisp.lisp". You can
put clasp snippet just after Poplog snippet.
--
Waldek Hebisch
Qian Yun
Jul 3, 2022, 8:36:38 PM7/3/22
to fricas...@googlegroups.com
On 7/4/22 01:25, Waldek Hebisch wrote:
>>> Some time ago it tunrned out
>>> that this setting is incompatible with using new sbcl interpreter.
>>
>> More info?
>
> Really nothing to add to what I wrote:
>
> (setf sb-ext:*evaluator-mode* :interpret)
>
> gave error when sbcl was configured with sb-fasteval. I seems
> that sbcl folks fixed this.
The REPL defaults to :INTERPRET if :sb-fasteval is enabled.
If you build sb-fasteval successfully, and it lanuches successfully,
then sb-ext:*evaluator-mode* is already set to :interpret.
>> ECL bytecode is enabled by (ext:install-bytecodes-compiler).
>> ECL bytecode compile+run time is 38.5 seconds.
>> The default C compile+run time is 25 seconds.
>
> Hmm, so with bytecode compiler it is slower than with compile
> to C? Strange.
With a real world timer, here is result:
ECL C compiler: 85 seconds total, execution time is 1 s.
ECL bytecode compiler: 18 seconds total, execution time is 9 s.
For ECL C compiler, ")time on" probably doesn't count the time of
external "gcc" processes.
For bytecode compiler, ")time on" reports time that is twice of
the actual time.
- Qian
Qian Yun
Jul 3, 2022, 8:50:02 PM7/3/22
to fricas...@googlegroups.com
On 7/4/22 03:43, Bill Page wrote:
>
> Clasp is a new implementation of Lisp based on LLVM similar to the way
> that ABCL is based on the Java VM.
>
> https://github.com/clasp-developers/clasp
>
> I was interested to see whether Clasp could run fricas0 since one of
> the selling points for Clasp is the ability to directly and easily
> link with c++ libraries. Apparently Clasp can run maxima. See
some local patches with ugly hacks that makes clasp able to
compile fricas (loading fricas0 is no problem, of course).
A few problems so far:
1. Clasp compilation is very slow. (and results in huge object files)
2. Clasp runtime speed is not that great. (but it can do parallel
compilcation)
3. The dumping (save-lisp-and-die) is the main problem. Seems that
it dumps snapshot instead of executable.
4. Still some errors when running src/input tests.
Basically the following code solves many issues.
I'll put more Clasp support to fricas0 later, then to fricas.
(I think I'll do ABCL first.)
- Qian
=========
#+:CLASP
(progn
(setq |$lisp_bin_filetype| "fasp")
(defun exit-with-status (s)
(core:quit s))
(defun chdir (dir)
(ext:chdir dir))
(defun file-kind (filename)
(case (core:file-kind filename nil)
(:directory 1)
((nil) -1)
(t 0)))
)
Waldek Hebisch
Jul 3, 2022, 9:20:49 PM7/3/22
to fricas...@googlegroups.com
On Mon, Jul 04, 2022 at 08:36:23AM +0800, Qian Yun wrote:
>
>
> On 7/4/22 01:25, Waldek Hebisch wrote:
> >>>Some time ago it tunrned out
> >>>that this setting is incompatible with using new sbcl interpreter.
> >>
> >>More info?
> >
> >Really nothing to add to what I wrote:
> >
> > (setf sb-ext:*evaluator-mode* :interpret)
> >
> >gave error when sbcl was configured with sb-fasteval. I seems
> >that sbcl folks fixed this.
>
> Not sure why you met this problem. From documentation:
>
> The REPL defaults to :INTERPRET if :sb-fasteval is enabled.
>
> If you build sb-fasteval successfully, and it lanuches successfully,
> then sb-ext:*evaluator-mode* is already set to :interpret.
'sbcl' behaved differently. Look at message by Jeronimo Pellegrini
>
>
> On 7/4/22 01:25, Waldek Hebisch wrote:
> >>>Some time ago it tunrned out
> >>>that this setting is incompatible with using new sbcl interpreter.
> >>
> >>More info?
> >
> >Really nothing to add to what I wrote:
> >
> > (setf sb-ext:*evaluator-mode* :interpret)
> >
> >gave error when sbcl was configured with sb-fasteval. I seems
> >that sbcl folks fixed this.
>
> Not sure why you met this problem. From documentation:
>
> The REPL defaults to :INTERPRET if :sb-fasteval is enabled.
>
> If you build sb-fasteval successfully, and it lanuches successfully,
> then sb-ext:*evaluator-mode* is already set to :interpret.
from Sun, 7 Jun 2020.
> >>ECL bytecode is enabled by (ext:install-bytecodes-compiler).
> >>ECL bytecode compile+run time is 38.5 seconds.
> >>The default C compile+run time is 25 seconds.
> >
> >Hmm, so with bytecode compiler it is slower than with compile
> >to C? Strange.
>
> OK, that time is reported by ")time on" and is not accurate.
> With a real world timer, here is result:
>
> ECL C compiler: 85 seconds total, execution time is 1 s.
> ECL bytecode compiler: 18 seconds total, execution time is 9 s.
>
> For ECL C compiler, ")time on" probably doesn't count the time of
> external "gcc" processes.
count external processes.
> For bytecode compiler, ")time on" reports time that is twice of
> the actual time.
Could you try adding something like
)lisp (get-internal-run-time)
before and after. And also
)lisp INTERNAL-TIME-UNITS-PER-SECOND
Our time report should be close to difference of values
reported by 'get-internal-run-time' and converted to
normal units based on INTERNAL-TIME-UNITS-PER-SECOND.
--
Waldek Hebisch
Qian Yun
Jul 4, 2022, 12:03:28 AM7/4/22
to fricas...@googlegroups.com
On 7/4/22 09:20, Waldek Hebisch wrote:
>>
>> If you build sb-fasteval successfully, and it lanuches successfully,
>> then sb-ext:*evaluator-mode* is already set to :interpret.
>
> 'sbcl' behaved differently. Look at message by Jeronimo Pellegrini
> from Sun, 7 Jun 2020.
https://bugs.launchpad.net/sbcl/+bug/1882582
The developer replies that the bug reporter spelled it wrong.
>
>> For bytecode compiler, ")time on" reports time that is twice of
>> the actual time.
>
> We base our time report on Lisp 'get-internal-run-time'.
> Could you try adding something like
>
> )lisp (get-internal-run-time)
>
> before and after. And also
>
> )lisp INTERNAL-TIME-UNITS-PER-SECOND
>
> Our time report should be close to difference of values
> reported by 'get-internal-run-time' and converted to
> normal units based on INTERNAL-TIME-UNITS-PER-SECOND.
>
One thread takes 100% CPU and rest threads take a few percent
CPU (total is around 100%), so together it takes 200% CPU.
I wonder if it is the same on your machine.
My ECL version is 21.2.1.
- Qian
Qian Yun
Jul 5, 2022, 8:10:46 AM7/5/22
to fricas...@googlegroups.com
The total time for sb-fasteval is 13.4 seconds,
compile SMP.lsp reduce it to 9.9s,
then compile PR.lsp reduce it further to 8.3s,
IDPO.lsp to 7.1s,
PGCD.lsp to 6.3s,
KERNEL.lsp to 5.6s,
LIST.lsp to 5.2s,
FM.lsp to 4.9s,
INT.lsp to 4.7s,
FRAC.lsp to 4.6s,
POLYVEC.lsp to 4.4s.
This integral computation needs to load/compile 247 files, compile
these 10 files takes 1.8s, but saves 10.8s in execution.
Net gain is 9s (67% of original time, aka 3 times faster.)
Now coupled with git-pisect, with 5 cores in 3 runs,
(because the number of commits is less than (5+1)^3),
we can find the regression in 18 seconds.
- Qian
compile SMP.lsp reduce it to 9.9s,
then compile PR.lsp reduce it further to 8.3s,
IDPO.lsp to 7.1s,
PGCD.lsp to 6.3s,
KERNEL.lsp to 5.6s,
LIST.lsp to 5.2s,
FM.lsp to 4.9s,
INT.lsp to 4.7s,
FRAC.lsp to 4.6s,
POLYVEC.lsp to 4.4s.
This integral computation needs to load/compile 247 files, compile
these 10 files takes 1.8s, but saves 10.8s in execution.
Net gain is 9s (67% of original time, aka 3 times faster.)
Now coupled with git-pisect, with 5 cores in 3 runs,
(because the number of commits is less than (5+1)^3),
we can find the regression in 18 seconds.
- Qian
Ralf Hemmecke
Jul 5, 2022, 8:20:02 AM7/5/22
to fricas...@googlegroups.com
Hi Qian,
that sounds amazing. Are you going to document is somewhat so that one
then would only have to write a little scritpt for "git pisect run" and
would have the bad git-sha1 in about 3 min.
BTW, I wonder how you are actually mapping the non-linear commit graph
of FriCAS to your fricas0-repo. I guess having the same graph would be
relevant for git-bisect.
Ralf
that sounds amazing. Are you going to document is somewhat so that one
then would only have to write a little scritpt for "git pisect run" and
would have the bad git-sha1 in about 3 min.
BTW, I wonder how you are actually mapping the non-linear commit graph
of FriCAS to your fricas0-repo. I guess having the same graph would be
relevant for git-bisect.
Ralf
Qian Yun
Jul 5, 2022, 8:34:43 AM7/5/22
to fricas...@googlegroups.com
On 7/5/22 20:20, Ralf Hemmecke wrote:
> Hi Qian,
>
> that sounds amazing. Are you going to document is somewhat so that one
> then would only have to write a little scritpt for "git pisect run" and
> would have the bad git-sha1 in about 3 min.
0. Compile sbcl yourself to enable sb-fasteval.
1. It is "git bisect run ./test.sh" and "git pisect ./test.sh"
2. Choose PISECT_JOBS wisely. (PISECT_JOBS+1)^n should be bigger than
the number of commits. More cores does not always mean more speed.
3. For "pisect", since it runs in parallel, it checks out new commit
in new tmp directory, so you need to use absolute path in "test.sh".
Current testing need fricas.lisp from fricas0, so you need to copy
it first, I have following:
======= test.sh
cp ~/github/fricas0/fricas.lisp ./
cp ~/github/fricas0/lisp/{interp.lisp,load-*,compile-*} ./lisp/
echo ")r /tmp/fricas4/1.input" | sbcl --load fricas.lisp | grep testpass
=======
4. Put your fricas command into a input file:
===== /tmp/fricas4/1.input
)time on
)lisp (compile-file "algebra/SMP.lsp")
)lisp (compile-file "algebra/PR.lsp")
)lisp (compile-file "algebra/IDPO.lsp")
)lisp (compile-file "algebra/PGCD.lsp")
)lisp (compile-file "algebra/KERNEL.lsp")
)lisp (compile-file "algebra/LIST.lsp")
)lisp (compile-file "algebra/FM.lsp")
)lisp (compile-file "algebra/INT.lsp")
)lisp (compile-file "algebra/FRAC.lsp")
)lisp (compile-file "algebra/POLYVEC.lsp")
f:=integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x);
if(is?(operator mainKernel f,'integral)) then print "test""fail" else
print "test""pass"
=====
5. There is room to improve for this process: I plan to use a single
"fricas.lisp" to simplify the usage. And I'd like to put the
recommended compile list into "fricas.lisp", so that it provides
a good default experience. Another improvement is to provide a list
of commits without code change to "git bisect skip".
> BTW, I wonder how you are actually mapping the non-linear commit graph
> of FriCAS to your fricas0-repo. I guess having the same graph would be
> relevant for git-bisect.
with something like HEAD~${NUM}. So it skips some merge commits.
Not a big deal, I think.
- Qian
Waldek Hebisch
Jul 6, 2022, 7:51:08 PM7/6/22
to fricas...@googlegroups.com
On Mon, Jul 04, 2022 at 12:03:11PM +0800, Qian Yun wrote:
> >>For bytecode compiler, ")time on" reports time that is twice of
> >>the actual time.
> >
> >We base our time report on Lisp 'get-internal-run-time'.
> >Could you try adding something like
> >
> >)lisp (get-internal-run-time)
> >
> >before and after. And also
> >
> >)lisp INTERNAL-TIME-UNITS-PER-SECOND
> >
> >Our time report should be close to difference of values
> >reported by 'get-internal-run-time' and converted to
> >normal units based on INTERNAL-TIME-UNITS-PER-SECOND.
> >
>
> For ECL bytecode, I observed that it runs in parallel somehow:
>
> One thread takes 100% CPU and rest threads take a few percent
> CPU (total is around 100%), so together it takes 200% CPU.
>
> I wonder if it is the same on your machine.
> My ECL version is 21.2.1.
I did a simple test, in file 'll5' I have had:
> >>For bytecode compiler, ")time on" reports time that is twice of
> >>the actual time.
> >
> >We base our time report on Lisp 'get-internal-run-time'.
> >Could you try adding something like
> >
> >)lisp (get-internal-run-time)
> >
> >before and after. And also
> >
> >)lisp INTERNAL-TIME-UNITS-PER-SECOND
> >
> >Our time report should be close to difference of values
> >reported by 'get-internal-run-time' and converted to
> >normal units based on INTERNAL-TIME-UNITS-PER-SECOND.
> >
>
> For ECL bytecode, I observed that it runs in parallel somehow:
>
> One thread takes 100% CPU and rest threads take a few percent
> CPU (total is around 100%), so together it takes 200% CPU.
>
> I wonder if it is the same on your machine.
> My ECL version is 21.2.1.
(load "fricas.lisp")
integrate((F^((-a*x+1)^(1/2)/(a*x+1)^(1/2)))^n/(-a^2*x^2+1),x)
)quit
Then I run:
time /mnt/lv0/fricas/usr-16.1.2/bin/ecl < ll5 > rapp12 2>&1
and similar for Clozure CL 1.11 and sbcl-2.2.6 with fasteval.
Results are:
ECL 16.1.2
real 0m16.018s
user 0m23.464s
sys 0m0.124s
sbcl-2.2.6 with sb-fasteval
real 0m22.867s
user 0m22.348s
sys 0m0.480s
Clozure CL 1.11
real 0m25.276s
user 0m25.080s
sys 0m0.120s
So, in real time ECL was fastest, but it shows slightly bigger
CPU time than sbcl-2.2.6. At least for use with FriCAS ECL-16.1.2
seem to be few percent faster than newer versions.
--
Waldek Hebisch
Waldek Hebisch
Jul 31, 2022, 9:35:13 AM7/31/22
to fricas...@googlegroups.com
I did few more tests with fricas0. One thing to note is that
fricas0 is incompatible with Poplog: Poplog Lisp will _not_
add '.lisp' extension to file name without extention, so
I had to add explicit file extentions. Second, we do not
get useful command line from Poplog ("user" command line
skips executable, and if we dig deeper we get flags
internal to Poplog, but paths point to Poplog installation).
Also, fricas0 skipped a few Poplog specific hunks. However,
hacking around problems I was able to run fricas0 with
Poplog. Note that Poplog compiles files on load. There
are no compilation to .fasl. As an alternative Poplog
offers "stacked images", that is one can dump what
is new in given image but reuse previous (say system)
image. With Poplog time to run integration
test is:
real 0m12.149s
user 0m6.460s
sys 0m0.120s
For comparison, without extra tweaks time for sbcl
in intrpret mode (with fasteval) is 22 sec, time
for Clozure CL 11 is 25 sec. In this test for
ECL I got:
real 0m15.486s
user 0m22.764s
sys 0m0.096s
Anyway, both Poplog and Clozure CL compile files on
load and both have fast compilers, but Poplog compiler
is significantly faster (Clozure CL optimizes better).
Interestingly, ECL has CPU time significantly higher
than real time, while Poplog has real time significantly
higher than CPU time.
Compiling first files given by Qian with sbcl I
get compile+load+execute time 6.955. So, this
is fastest, but require knowledge of critical
files.
More on Poplog: as you can see from above, Poplog
has many quirks and you may wonder why to bother?
Well, one reason is compile time: using sbcl significant
part of compile time is Lisp compile time. Similarly
with ECL and GCL (here we have mostly C compile
time) but worse since _all_ times are longer.
So to get significant improvement of compile time
we need both to improve Spad compile time _and_
Lisp compile time. Somewhat related, Poplog has
also more direct compiler interface, so it gives
hope for non-Lisp compilation mode.
--
Waldek Hebisch
fricas0 is incompatible with Poplog: Poplog Lisp will _not_
add '.lisp' extension to file name without extention, so
I had to add explicit file extentions. Second, we do not
get useful command line from Poplog ("user" command line
skips executable, and if we dig deeper we get flags
internal to Poplog, but paths point to Poplog installation).
Also, fricas0 skipped a few Poplog specific hunks. However,
hacking around problems I was able to run fricas0 with
Poplog. Note that Poplog compiles files on load. There
are no compilation to .fasl. As an alternative Poplog
offers "stacked images", that is one can dump what
is new in given image but reuse previous (say system)
image. With Poplog time to run integration
test is:
real 0m12.149s
user 0m6.460s
sys 0m0.120s
For comparison, without extra tweaks time for sbcl
in intrpret mode (with fasteval) is 22 sec, time
for Clozure CL 11 is 25 sec. In this test for
ECL I got:
real 0m15.486s
user 0m22.764s
sys 0m0.096s
Anyway, both Poplog and Clozure CL compile files on
load and both have fast compilers, but Poplog compiler
is significantly faster (Clozure CL optimizes better).
Interestingly, ECL has CPU time significantly higher
than real time, while Poplog has real time significantly
higher than CPU time.
Compiling first files given by Qian with sbcl I
get compile+load+execute time 6.955. So, this
is fastest, but require knowledge of critical
files.
More on Poplog: as you can see from above, Poplog
has many quirks and you may wonder why to bother?
Well, one reason is compile time: using sbcl significant
part of compile time is Lisp compile time. Similarly
with ECL and GCL (here we have mostly C compile
time) but worse since _all_ times are longer.
So to get significant improvement of compile time
we need both to improve Spad compile time _and_
Lisp compile time. Somewhat related, Poplog has
also more direct compiler interface, so it gives
hope for non-Lisp compilation mode.
--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages