Re: Symbol hiding and unit tests
Ciao,
Il Lun, 6 Luglio 2015 11:46 pm, Torbjörn Granlund ha scritto:
Unfortunately, it has now become obvious to me that symbol hiding
conflicts with unit testing. :-(
This can be handled either by
1. hiding (much!) fewer internal symbols, or by
I agree with starting to hide some symbols.
2. linking each unit test to the needed PIC objects instead of the ,so
file.
The latter is a major task, but the dependencies could presumably be
done with some clever scripts.
Writing a test_wrapper function is too messy?
void test_wrapper (int index, void *retval, ...)
{
switch (index)
{
case 1:
*retval = toomxy...
..
Regards,
m
--
http://bodrato.it/
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: Anomaly in mpn_sqrtrem and mpn_rootrem
Ciao, Il Lun, 6 Luglio 2015 11:28 pm, Torbjörn Granlund ha scritto: bodr...@mail.dm.unipi.it writes: ... yes, I know, we really need to improve also odd sizes... Perhaps one could simply wrap the current function in code which appends a zero limbs, calls the current code, and then right-shift the root by half the limb bitcount? This is a description of the patch I pushed yesterday: https://gmplib.org/repo/gmp/rev/87ba695c8878 But I do not really like it. We alloc-copy-shift to add a dummy limb, then we call a code that allocs-copies-shifts to (virtually) add two more dummy limbs... Anyway, in general the code for sqrt (no-remainder) is faster now than it was before. With code from revision 16716 (3 weeks ago) we got time tests/devel/try mpn_sqrt [...] user0m25.299s Now we get: time tests/devel/try mpn_sqrt [...] user0m23.300s (One would possibly need to suppress such code for operands below a certain size, to avoid slowdowns.) There are some slowdown only for sizes 15,16,31,32, i.e. when the size is near a small power of 2. Now, for small sizes, computing the 4th root with mpn_rootrem is slower than calling mpn_sqrtrem twice. Maybe we should improve mpn_rootrem for small sizes in general... Regards, m -- http://bodrato.it/papers/ ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: Anomaly in mpn_sqrtrem and mpn_rootrem
bodr...@mail.dm.unipi.it writes: https://gmplib.org/repo/gmp/rev/87ba695c8878 But I do not really like it. We alloc-copy-shift to add a dummy limb, then we call a code that allocs-copies-shifts to (virtually) add two more dummy limbs... There is still a very noticeable difference between even and odd sizes: mpn_sqrtmpn_root.2 mpn_sqrtrem 4090 #1701239.982159255.232270148.03 4091 #1717724.102161403.542314530.39 4092 #1677835.052156978.062263015.48 4093 #1713743.032164690.062306523.04 4094 #1689689.172192785.722302479.92 4095 #1733267.802193850.692301651.07 4096 #1702328.082193558.182254053.40 4097 #1742066.352267900.342321820.79 4098 #1699858.762186774.592269899.77 4099 #1734269.702195714.072331587.32 4100 #1712964.012195057.782293181.09 Now, for small sizes, computing the 4th root with mpn_rootrem is slower than calling mpn_sqrtrem twice. Maybe we should improve mpn_rootrem for small sizes in general... Indeed. We start with a single-bit approximation, then initially make very little progress in the first steps (one bit for higher-order roots). Tabling start values is hard, but we should consider doing it for k some limit, and perhaps provide just 4 bits. Another great speedup would be to use special code for the single-limb iterating. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
