On Mon, Dec 23, 2024 at 02:43:43AM +0100, Grégory Vanuxem wrote:
> Le dim. 22 déc. 2024 à 19:55, Waldek Hebisch <[email protected]> a écrit :
>
> > AFAICS main differences
> > are overload resolution and inlining. Parametrized package
> > makes inlinig harder (in fact normally inlining from parametrized
> > package is disabled). Single package puts more stress on
> > overload resolution, with separate packages (either non-parametrized
> > ones or two instances of parametrized package) it is easier to
> > control visiblity. Interpreter normally do not invent package
> > parameters, so use from interpreter is easier in non-parametric
> > cases. If you want to share code for both cases, then single
> > package makes it slightly easier.
>
> Ok, thanks, that's interesting. About optimization, actually I have no
> idea how to measure internal elementary operations, which ones, and
> time consumed, I no longer remember in the past how I did it. With GCL
> probably. I just noticed that with or without parameterization of
> packages the "(DECLAIM (NOTINLINE |JuliaMachineFloatFunctions;|))".
In sbcl I use sb-sprof package (included in normal FriCAS build)
to identify hot routines. For more details I look at Lisp code
or disassembly. ECL recomended general C-oriented tools, which
worked but for me was less useful than sbcl profiles. sbcl profile
shows relations between routne, its caller and called routines.
Theoretically other tools should give this info too, but somewhat
with other tools I was able only to use flat profile. Closure CL
had something to make Lisp binary look like C-one so one could
use C oriented tools. I do not think I tried this, but it would
have the same drawbacks as for ECL.
> > Which of the above is more important depends on your goals.
> > You may notice that there is DoubleFloatVector and few similar
> > "DoubleFloat" domains, but no SingleFloatVector. My rationalle
> > was that for math computations we frequently want higher
> > precision, so we need DoubleFloat version. Single float could
> > in principle double performance in some cases, but ATM
> > I decided that increase in complexity is not worth it. You
> > may notice that those packages are non-parametrized: some
> > operations are quite simple and benefit a lot from inlinig,
> > so that was natural choice maximizing performance.
>
> For DoubleFloatVector etc. I saw them a little later after I began to
> code contiguous memory area for array of numbers at the Lisp level, in
> fact I borrowed some of your code for Complex(JF32)|JF64) array
> access. That saved me a lot of time as Complexes are implemented in
> spad using cons, I borrowed that for example :)
>
> ; Complex double float vectors
> ; 1-based index
>
> (defmacro jcdelt(ov oi)
> (let ((v (gensym))
> (i (gensym)))
> `(let ((,v ,ov)
> (,i ,oi))
> (cons
> (aref (the (simple-array double-float (*)) ,v) (- (* 2 ,i) 2))
> (aref (the (simple-array double-float (*)) ,v) (1- (* 2 ,i)))))))
>
> (slightly modified)
>
> I also did not parameterize those domains, like you, since they are
> very specialized, but your scheme is different from mine; mines are
> 1-based at Spad level and at lisp level I use (1- ...). (hoping some
> lisp internal optimizations).
Well, I think that logic is simpler with 0 based indexing, and
optimization not always happen (in some cases 0 based indexing
gave measurably better performance).
> And, furthemore, for 2D arrays you're
> using the '(m n) scheme to specify dimensions but Clozure CL requires
> a specialized vector from what I know if you want to call Fortran/C
I do not know what Clozure CL folks say now, but when I asked
the answer was: to call non-lisp code you need to allocate special
buffer and copy data. So for Clozure CL gmp interface dully allocates
buffer and performs copy. That really does not depend much on
what is on Lisp side. Also, in Lisp there are thing like
ROW-MAJOR-AREF, so in reasonably fast Lisp there will be specialized
vector possibly behind some interface.
Using real 2D arrays causes some slowdown in Lisp access compared
to vectors. For sbcl it seem to be of order 2 (basically 2D array
indexing is less optimized than it should be), for some other
Lisp-s much bigger (2D array access may use Lisp function call
to an accessor function). But it is faster that old scheme
based on vector of vectors. I am thinking of using ROW-MAJOR-AREF
in few critical places (like matrix multiplication or vector-matrix
multiplication), that should remove most of slowdowns compared
to vectors.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/Z2jIYmcScbSPdcwp%40fricas.org.
