On Sat, Feb 27, 2021 at 10:13:17AM +0100, Ralf Hemmecke wrote:
> > Forgot to write this: currently there is
> > '--enable-algebra-optimization' option to configure. As explained in
> > INSTALL, if you give:
> >
> > --enable-algebra-optimization="((speed 3) (safety 0))"
> >
> > you get fastest code (but unsafe).
>
> Thanks. I knew this, but have not used it. I have bad experiences with
> high optimization with the Aldor compiler. I probably don't tell you
> anything new, but there were at least 3 errors.
>
> (1) the compiler optimizes too much and produces garbage from correct
> sources
> (2) the library sources were buggy and just getting a
> "Segmentation fault" is not very helpful to find the
> source of the problem.
> (3) I write buggy user library extensions.
>
> With all-or-noting and no concrete error message a distinction between
> (2) and (3) would be hard to make. But this is certainly not a big
> problem for me, because you are just speaking about the library code
> that is inside the FriCAS repository.
>
> Distinction between (1) and (2) is probably more delicate. But don't we
> need a bigger set of unit tests for these low-level domains if they are
> going to be super-optimized?
I do not think (1) is a problem. Current default is due to (2)
and (3). To explain more: the setting above essentially tells
compiler to trust declarations. Without such setting sbcl
inserts checks for overflow and bounds checks for arrays.
In slow code such checks does not make much difference to
speed, in fast code they can take half of execution time.
Skipping checks is unlikely to introduce/trigger bugs,
just is is harder to find reasons for bugs. Note that
even with '(safety 0)' sbcl still inserts some checks,
so there is more runtime error checking than in typical
C code. You are somewhat comfortable with idea of
running C code which has no automatic error checking...
Concerning tests, the code is intensively used, in the past
a few bugs were found, but recently it worked quite well.
> > Currently this is all-or-nothing choice, that is applies to whole
> > algebra. I probably will rework it, in particular I think that low
> > level domains like U32Vector, U32VectorPolynomialOperations and bunch
> > of similar domain should be compiled at high optimization settings,
> > while rest of algebra should use current settings. This should give
> > us most gain from optimization with only small decrease in safety.
>
> As far as I remember, you have introduced the U32... domains. How can
> the optimize level of those influence the spead of the finite field
> factorizer?
Current finite field factorizer does not use U32... types, so
ATM there is no influence. However, factorizer in 'ffact.spad'
uses U32... types for basic operations and in fact it
spends about 90 % of time in operations from
POLYVEC. Currently 'ffact.spad' only factorizes over prime
fields, but the algorithm is general, that is applies to
all finite fields. One possiblity to generalize 'ffact.spad'
is to parametrise it by basic polynomial and matrix domain
(like ModularAlgebraicGcd2). ATM missing ingredient is
implementation for operations over non-prime fields.
I can not say when it will be done, but we need such operations
to speed up gcd (and later factorization) for polynomials
with algebraic coefficients. Currently we have
ModularAlgebraicGcdTools2 which handles single algebraic
extension, but is somewhat naive way and ModularAlgebraicGcdTools3
which handles multiple extensions (triangular systems)
by generic (that is slow) code.
We need to replace ModularAlgebraicGcdTools2 by faster
version. ATM is not clear for me what to do with
ModularAlgebraicGcdTools3. Namely, triangular systems
seem to be inherently slow. For applications we
should be able to replace triangular system by single
polynomial (that is use primitive element), and this
may be faster (despite cost of convertion). Anyway,
speed of Expression depends very much on those
routines so I want to make them faster. Beside
speed of basic routines there are other issues
like using Zippel method (ATM Axiom family seem to
be the only major CAS family that does not use
Zippel method).
Anyway, coming back to finite fields: we should
call routines in 'ffact.spad' from finite field
code.
> Nevertheless, don't you think that it would be a good idea to allow
> including calls to FLINT in the FriCAS library? Unfortunately, I have no
> idea how to do such an interface right, but it would be nice to have one.
Nice yes. But who should do this? Currently there is reasonably
general machinery for foreign calls, one needs to write
some Lisp code but this is moderate effort. Problem with
FLINT (and NTL) is that official FLINT interfaces are
abstract which is very good design if you work at C
level, but makes interfacing harder. So probably somebody
would need to write more interface-friendly wrappers.
Anyway, to have interface like this as part of FriCAS
we would need configure machinery, deal with different
machine architectures, etc.
--
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 on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210227152459.GA33489%40math.uni.wroc.pl.
