Serge D. Mechveliani wrote:
>
> Dear Axiom (and FriCAS) developers,
>
> After several attempts, the Haskell -- Axiom (FriCAS) interface by
> String and named pipes (in Unix, Linux) seems starting to work.
<snip>
> ***********************************************************************
> The remaining problems are as follows.
>
> 0. FriCAS dependence on Lisp
> ----------------------------
> My examples with Haskell, C -- FriCAS work under
> Squeeze Debian Linux + GNU CLISP 2.48,
> and they do not work under Lenny Debian Linux + GNU CLISP 2.44.1.
> Is this due to the Lisp version?
Possible. ATM I do not have machine with CLISP 2.44.1 to check.
>
> a) Maybe FriCAS can message when loading:
> "FriCAS 1.1.5 with Lisp = such and such version"?
I will think about this.
ATM you can get information about Lisp version from Lisp
like this:
)lisp (lisp-implementation-version)
Alas, this tells you only version number and not the Lisp
flavour.
> b) How long Axiom (FriCAS) is going to depend on Lisp ?
> Will Aldor remove this dependence?
> (there is also the question of the Aldor license, etc.)
Personally I have no hope about Aldor. While FriCAS dependence
on Lisp is much smaller than in the past there is no set
timeframe for removing it.
> 2. Fast parsing
> ---------------
> I hope, I can provide fast parsing on both ends. This hope bases on that
> each time DoCon has both an internal data d and its string image dStr.
> So, a special output with tags is possible for dStr, and a special
> parsing (in Spad) on the Axiom end.
> To make the Axiom end, I shall need to study more of Spad.
>
> 3. IO performance in FriCAS
> ---------------------------
> For the exchange of short strings and without parsing,
> Haskell -- FriCAS works about 15 times slower than Haskell -- C.
> After (1) and (2) are done, this will become the bottleneck -- for the
> calls of a small computation time.
> I have the impression that the factor of 5 here is due to the interpreter
> mode itself in the loop and another factor of 3, is may be, due to
> readLine!, writeLine!.
> This can be verified by running this loop separately, and with replacing
> readLine! and writeLine! with something simple, say,
> i : Integer := 100000
> repeat
> i := i - 1
> if i = 0 then output "done"
> if size?(lowerCase "ABC", 4) then output "size = 4"
>
> -- something which does not use IO in the loop.
I will look into this issue. However note:
1) ATM you have chosen slowest Lisp. IME sbcl is the fastest one,
but to work with pipes you need newer version than the one
provided by Debian (I do not know when the problem was fixed,
but Debian version block reading from pipe while 1.0.54 works
fine).
2) I would have to check to be sure, but IIRC code at top level
in the file is interpreted. If you create a function it will
be compiled. But for top performance you should put your
code in a Spad file
3) FriCAS strings are Lisp strings which in Clisp (and Sbcl) are
Unicode strings. More precisely in those Lisps string is
an array of Unicode characters. Compared to C this causes
overhead for encoding between external and internal
representation.
4) In the short term Lisp function 'read-from-string' may be
fastest way of parsing.
> 4. IO performance for named pipes
> ---------------------------------
> After (1), (2) and (3) are done, this will become the bottleneck -- for
> the calls of a small computation time.
> I wonder whether the alternative approach of C interface + shared memory
> will help.
Probably not much (if at all) unless you have huge amount of data.
Normally (with small data portions) the main cost is process
(context) switching, and system developers tried to make this
fast when using pipes. For large amounts of data you can
save number of copy operations and possibly number of context
switches (when pipe buffer is full context switch is needed
even if sending process is ready to produce more data).
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
