New "feature" request

[librik at panix.com]

"J. Foug" <jim_fougeron at yahoo.com> wrote:
> I would love some interface (function(s) or data objects), which
> reported certain "build envirionment" information.  I have wanted
> something like this for a while but never asked.

Yes, yes, a thousand times yes.  This would be very useful
functionality.  I recall Torbjorn stating that it's a feature
which is regrettably missing in GMP:  the ability to query
certain configuration parameters at runtime.

I have written something up for this purpose in my own build of
GMP, but not contributed it (yet), since I didn't know how well
it would go over.  For maximum portability and inter-version
compatibility, the right model is something like:
    mp_size_t __gmp_get_settings( const char * name);
where the "name" is one of a set of standard strings such as
"KARATSUBA_MUL_THRESHOLD" or "WANT_FFT".  gmp_errno is set to
GMP_ERROR_UNSUPPORTED_ARGUMENT if an unrecognized string is
passed.  (This allows for backwards compatibility when used
carefully.)


Here is why this is useful, with reference to J. Foug's points:
> 2.  If alloca (or malloc) are used.
> 3.  if FFT was enabled.
> 4.  Tuning values (basecase, karatusba, toom-n, fft, ...)
> 5.  Other issues (mostly any --enable-* or --disable-* which change
>     the defaults)

Although many applications use only GMP's higher-level interface,
others (such as the one I work on) use the MPN-level code as a
component in a more complex bignum system.  The ability to get
the crossover point for Karatsuba or the presence of FFT in a
given GMP library makes tuning and optimization easier in the
client application.


> 1.  What CPU (--build=*-*.*) this build was intended for.

This is *very* useful.  (Note that the machine type is not currently
stored anywhere in the generated header files -- this would require
a minor change to the autoconf script and the config.h template.)

Although there are plans afoot for support of a "fat" GMP library,
one strength of GMP as a free dynamic library is that multiple
single-CPU DLLs can be present, including built ones for new
platforms.  I think a directory full of GMP DLLs for different
Intel CPUs to select from, including a default i386 build, is a
fine model still worth supporting.

With the ability to get the CPU type for a given dynamic library
via a function call, an application can spin through a set of
GMP DLLs and find the best match.  This allows the library
detection to be the hands of the client app for greater flexibility,
and allows the user (or tech support!) to override the choice with
their own library.

I don't mean to argue against your "fat" library design, but
simply to put as much reasonable power in the hands of the client
as possible -- in this case, this is power that we actually do
need.  It makes GMP easily useful in a wider set of situations
than it could support before.

- David Librik
librik at panix.com