Le dim. 22 déc. 2024 à 19:55, Waldek Hebisch <de...@fricas.org> a écrit :
[snip]
> > Any idea of the "best" way to do this? And the advantages and/or
> > inconveniences of those two coding styles?
>
> For some reason you did not mention third alternative, that is
> two separate non-parametrized packages.
Hmmm... You make me think about that. In fact I did it that way for
linear algebra as I do not want to pollute the interpreter with direct
access to rarely used routines. )expose can be used for that if
necessary.
> 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;|))".
> 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). 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
routines functions on them and I wanted, at first, to support two CL
implementations. So I use vectors. At the end it is less optimized
code I think because of the arithmetic used for array elements access
but in terms of memory area that's the same, so they can be given
directly to BLAS and LAPACK for example. I think I will continue how I
do right now, use specialized signatures, and document the same
routines two times (Float32 and Float64). But now, with your mail, I
am thinking about separating 32/64 bits packages, that seems to me
preferable.
Last, I understand your use of only 64bit floats for mathematical
purposes (and even, from my point of view, scientific/engineering
purposes used elsewhere) but first I like the _idea_ of using just
what is needed to compute numerically what you're looking for. If I
have 127€ and 7 children, I do not need:
[joke]
(1) -> jfloat(127.0)/7
(1)
18.14285714285714285714285714285714285714285714285714285714285714285714285714
298
and neither does this:
127/7
[/joke]
I also plan to use/test 32bit computation using oneAPI from Intel and
my GPU is an on chip one, only 32 bits, I am not a gamer. After all,
graphical things... One of the advantages of using Julia is for
example the ability to use MKL instead of OpenBLAS at runtime with
just a ' jlUSing "MKL" ' with help of libstrampoline or even openAPI
with a relatively recent computer (it's a work in progress from what I
read for the support of oneAPI) .
> You package at first glance will have rather high overhead,
> so it is not clear to me if inlinig gives you measurable
> benefits.
Yes, it is just an example, it's not destined to be highly efficient,
Lisp can do that. What I want most is that if someone wants to use
some routines defined at Lisp level to call C functions via my C
wrapper (here, for Julia), use some inlined Lisp defun/defmacro but
with checks on parameters. Spad allows this very easily since it is
strongly typed. No low level errors. Function calls using $Lisp can be
dangerous... I don't think Ralf will contradict me about this.
> Note: There is a bug in overload resolution in Spad compiler
> which may lead to compiler missing valid combination of
> arguments depending on internal order of signatures.
> Your various choices affect internal order of signatures,
> so you may see differences due to this bug.
Ok, I will see maybe.
- Greg
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/CAHnU2da0_hKfVUruEeJ4NswyD%3DGG299036%2BQr_ukHjOM2WDJJQ%40mail.gmail.com.
