From info at mobile-stream.com Wed Nov 6 15:50:56 2019 From: info at mobile-stream.com (info at mobile-stream.com) Date: Wed, 06 Nov 2019 15:50:56 +0000 Subject: [PATCH 3 of 3][v2] Add RDHWR-based cycle counter module for MIPS32R2 In-Reply-To: <16691e684a95c822e376.1572796254@p5600> References: <16691e684a95c822e376.1572796254@p5600> Message-ID: Add RDHWR-based cycle counter module for MIPS32R2. OS must enable CC/CCRes bits for user-mode RDHWR to work so the code path is available on Linux only for now. NetBSD should be usable as well though. MIPS32R6 is omitted (though certainly compatible) as no testing was performed there. v2 limits the counter to linux as per mailing list discussion. diff -r 7423efa39db8 -r dcd5adde7731 configure.ac --- a/configure.ac +++ b/configure.ac @@ -1057,6 +1057,12 @@ esac ;; + mipsisa32r2*-*-linux*) + SPEED_CYCLECOUNTER_OBJ=mips32r2.lo + cyclecounter_size=1 + path="mips32/r1 mips32" + ;; + mipsisa32*-*-*) path="mips32/r1 mips32" ;; diff -r 7423efa39db8 -r dcd5adde7731 tune/Makefile.am --- a/tune/Makefile.am +++ b/tune/Makefile.am @@ -33,7 +33,7 @@ AM_LDFLAGS = -no-install EXTRA_DIST = alpha.asm pentium.asm sparcv9.asm hppa.asm hppa2.asm hppa2w.asm \ - ia64.asm powerpc.asm powerpc64.asm x86_64.asm many.pl + ia64.asm powerpc.asm powerpc64.asm x86_64.asm mips32r2.asm many.pl noinst_HEADERS = speed.h # Prefer -static on the speed and tune programs, since that can avoid diff -r 7423efa39db8 -r dcd5adde7731 tune/mips32r2.asm --- /dev/null +++ b/tune/mips32r2.asm @@ -0,0 +1,12 @@ +include(`../config.m4') + +ASM_START() +PROLOGUE(speed_cyclecounter) + rdhwr $2,$2 + slti $3,$2,0 + sll $2,$2,1 C save multiply and assume CCRes is 2 + sw $3,4($4) + jr $ra + sw $2,0($4) +EPILOGUE(speed_cyclecounter) +ASM_END() From info at mobile-stream.com Wed Nov 6 15:50:54 2019 From: info at mobile-stream.com (info at mobile-stream.com) Date: Wed, 06 Nov 2019 15:50:54 +0000 Subject: [PATCH 1 of 3][v2] Provide c/l table for some MIPS32 CPUs Message-ID: <16691e684a95c822e376.1572796254@p5600> Provide c/l table for some MIPS32 CPUs. v2 adds 74Kc results. diff -r 688b91c9b765 -r 16691e684a95 mpn/mips32/addmul_1.asm --- a/mpn/mips32/addmul_1.asm +++ b/mpn/mips32/addmul_1.asm @@ -31,6 +31,14 @@ include(`../config.m4') +C cycles/limb +C 4KEc 16.33 +C 24Kc 18.04 +C 24KEc 18.05 +C 74Kc 12.04 +C P5600 9.05 +C XBurst 17.05 + C INPUT PARAMETERS C res_ptr $4 C s1_ptr $5 diff -r 688b91c9b765 -r 16691e684a95 mpn/mips32/mul_1.asm --- a/mpn/mips32/mul_1.asm +++ b/mpn/mips32/mul_1.asm @@ -31,6 +31,14 @@ include(`../config.m4') +C cycles/limb +C 4KEc 12.22 +C 24Kc 14.03 +C 24KEc 14.05 +C 74Kc 9.04 +C P5600 7.05 +C XBurst 13.05 + C INPUT PARAMETERS C res_ptr $4 C s1_ptr $5 diff -r 688b91c9b765 -r 16691e684a95 mpn/mips32/submul_1.asm --- a/mpn/mips32/submul_1.asm +++ b/mpn/mips32/submul_1.asm @@ -31,6 +31,14 @@ include(`../config.m4') +C cycles/limb +C 4KEc 16.33 +C 24Kc 18.04 +C 24KEc 18.05 +C 74Kc 12.04 +C P5600 9.05 +C XBurst 17.05 + C INPUT PARAMETERS C res_ptr $4 C s1_ptr $5 From info at mobile-stream.com Wed Nov 6 15:50:55 2019 From: info at mobile-stream.com (info at mobile-stream.com) Date: Wed, 06 Nov 2019 15:50:55 +0000 Subject: [PATCH 2 of 3][v2] Add MADDU-based *mul_1.asm functions for MIPS32R1+ In-Reply-To: <16691e684a95c822e376.1572796254@p5600> References: <16691e684a95c822e376.1572796254@p5600> Message-ID: <7423efa39db80f53c523.1572796255@p5600> Add MADDU-based *mul_1.asm implementation for MIPS32R1. It is faster on all tried MIPS32R1/R2/R5 CPUs (see the c/l table) and is expected to be fast with any pipelined MDU. Note the Area-Efficient MDU (an optional non-pipelined Multiply-Divide Unit available for some MIPS cores and MCUs) will run it much slower though (~3x for addmul_1). The code tries to keep the [accidental] property of MIPS-II counterparts: constant-time operation on 32x16 MDUs as found on e.g. 4KEc and some low- end MCUs. Even if this is unimportant, the performance cost is invisible. While functions look similar (especially mul_1 and addmul_1), they are kept separate due to corner-case (N=1,2,3) tweaks for P5600 without any ill effect on 4KEc or 24KEc at least. v2 improves addmul_1 on P5600 to more natural ~7.5 c/l and adds 74Kc c/l. diff -r 16691e684a95 -r 7423efa39db8 configure.ac --- a/configure.ac +++ b/configure.ac @@ -1055,7 +1055,10 @@ path_64="mips64/hilo mips64" ;; esac - + ;; + + mipsisa32*-*-*) + path="mips32/r1 mips32" ;; esac ;; diff -r 16691e684a95 -r 7423efa39db8 mpn/mips32/r1/addmul_1.asm --- /dev/null +++ b/mpn/mips32/r1/addmul_1.asm @@ -0,0 +1,80 @@ +include(`../config.m4') + +C cycles/limb +C 4KEc 9.68 +C 24Kc 9.52 +C 24KEc 9.55 +C 74Kc 7.05 +C P5600 7.57 +C XBurst 13.55 + +C INPUT PARAMETERS +C rp $a0 +C up $a1 +C n $a2 +C vl $a3 + +ASM_START() + .set noat +PROLOGUE(mpn_addmul_1) + lw $v1,0($a1) C L0 + ori $at,$zero,1 + multu $v1,$a3 C M0 + lw $t0,0($a0) C L1, 32x16 MDU stall + addiu $t1,$a2,-2 + beq $at,$a2,1f + maddu $t0,$at C M0 + mfhi $v0 C M0 carry + lw $t2,4($a1) C L1 + beqz $t1,23f + lw $v1,4($a0) C L1 + mflo $t0 C M0 + andi $t3,$t1,1 + sll $a2,$t1,2 + beqz $t3,0f + addu $a2,$a2,$a1 + multu $t2,$a3 C M1 + lw $t2,8($a1) C L2, 32x16 MDU stall + maddu $v1,$at C M1 + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + lw $v1,8($a0) C L2 + sw $t0,0($a0) C S0 + beq $at,$t1,23f + addiu $a0,$a0,4 + addiu $a1,$a1,4 + mflo $t0 C M1 +0: addiu $a1,$a1,8 + addiu $a0,$a0,8 + multu $t2,$a3 C M1 + lw $t3,0($a1) C L2, 32x16 MDU stall + maddu $v1,$at C M1 + lw $t4,0($a0) C L2 + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,-8($a0) C S0 + mflo $t1 C M1 + multu $t3,$a3 C M2 + lw $t2,4($a1) C L3, 32x16 MDU stall + maddu $t4,$at C M2 + lw $v1,4($a0) C L3 + maddu $v0,$at C M2 + sw $t1,-4($a0) C S1 + mfhi $v0 C M2 carry + bne $a1,$a2,0b +23: mflo $t0 C M2 + multu $t2,$a3 C M3 + nop C 32x16 MDU stall + maddu $v1,$at C M3 + maddu $v0,$at C M3 + mflo $at C M3 + mfhi $v0 C M3 carry + sw $t0,0($a0) C S2 + jr $ra + sw $at,4($a0) C S3 +1: mflo $at + mfhi $v0 + jr $ra + sw $at,0($a0) +EPILOGUE(mpn_addmul_1) +ASM_END() diff -r 16691e684a95 -r 7423efa39db8 mpn/mips32/r1/mul_1.asm --- /dev/null +++ b/mpn/mips32/r1/mul_1.asm @@ -0,0 +1,70 @@ +include(`../config.m4') + +C cycles/limb +C 4KEc 7.66 +C 24Kc 7.54 +C 24KEc 7.55 +C 74Kc 7.04 +C P5600 7.04 +C XBurst 10.54 + +C INPUT PARAMETERS +C rp $a0 +C up $a1 +C n $a2 +C vl $a3 + +ASM_START() + .set noat +PROLOGUE(mpn_mul_1) + lw $v1,0($a1) C L0 + ori $at,$zero,1 + multu $v1,$a3 C M0 + beq $at,$a2,1f C 32x16 MDU stall + addiu $t1,$a2,-2 + mfhi $v0 C M0 carry + beqz $t1,23f + lw $t2,4($a1) C L1 + mflo $t0 C M0 + andi $t3,$t1,1 + sll $a2,$t1,2 + beqz $t3,0f + addu $a2,$a2,$a1 + multu $t2,$a3 C M1 + lw $t2,8($a1) C L2, 32x16 MDU stall + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,0($a0) C S0 + beq $at,$t1,23f + addiu $a0,$a0,4 + addiu $a1,$a1,4 + mflo $t0 C M1 +0: addiu $a1,$a1,8 + addiu $a0,$a0,8 + multu $t2,$a3 C M1 + lw $t3,0($a1) C L2, 32x16 MDU stall + maddu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,-8($a0) C S0 + mflo $t1 C M1 + multu $t3,$a3 C M2 + lw $t2,4($a1) C L3, 32x16 MDU stall + maddu $v0,$at C M2 + mfhi $v0 C M2 carry + sw $t1,-4($a0) C S1 + bne $a1,$a2,0b +23: mflo $t0 C M2 + multu $t2,$a3 C M3 + nop C 32x16 MDU stall + maddu $v0,$at C M3 + mflo $at C M3 + mfhi $v0 C M3 carry + sw $t0,0($a0) C S2 + jr $ra + sw $at,4($a0) C S3 +1: mflo $at + mfhi $v0 + jr $ra + sw $at,0($a0) +EPILOGUE(mpn_mul_1) +ASM_END() diff -r 16691e684a95 -r 7423efa39db8 mpn/mips32/r1/submul_1.asm --- /dev/null +++ b/mpn/mips32/r1/submul_1.asm @@ -0,0 +1,86 @@ +include(`../config.m4') + +C cycles/limb +C 4KEc 10.72 +C 24Kc 10.54 +C 24KEc 10.55 +C 74Kc 9.04 +C P5600 8.07 +C XBurst 13.55 + +C INPUT PARAMETERS +C rp $a0 +C up $a1 +C n $a2 +C vl $a3 + +ASM_START() + .set noat +PROLOGUE(mpn_submul_1) + lw $v1,0($a0) C L1 + ori $at,$zero,1 + lw $t0,0($a1) C L0 + multu $v1,$at C M0 + msubu $t0,$a3 C M0 + beq $at,$a2,1f C 32x16 MDU stall + addiu $t1,$a2,-2 + mfhi $v0 C M0 carry + lw $v1,4($a0) C L1 + beqz $t1,23f + lw $t2,4($a1) C L1 + mflo $t0 C M0 + andi $t3,$t1,1 + sll $a2,$t1,2 + beqz $t3,0f + addu $a2,$a2,$a1 + negu $v0 C M1 + multu $v1,$at C M1 + msubu $t2,$a3 C M1 + addiu $a0,$a0,4 C 32x16 MDU stall + msubu $v0,$at C M1 + mfhi $v0 C M1 carry + lw $v1,4($a0) C L2 + lw $t2,8($a1) C L2 + beq $at,$t1,23f + sw $t0,-4($a0) C S0 + addiu $a1,$a1,4 + mflo $t0 C M1 +0: addiu $a0,$a0,8 + addiu $a1,$a1,8 + multu $v1,$at C M1 + lw $t4,0($a0) C L2 + lw $t3,0($a1) C L2 + msubu $t2,$a3 C M1 + negu $v0 C M1, 32x16 MDU stall + msubu $v0,$at C M1 + mfhi $v0 C M1 carry + sw $t0,-8($a0) C S0 + mflo $t1 C M1 + multu $t4,$at C M2 + lw $v1,4($a0) C L3 + lw $t2,4($a1) C L3 + msubu $t3,$a3 C M2 + negu $v0 C M2, 32x16 MDU stall + msubu $v0,$at C M2 + mfhi $v0 C M2 carry + sw $t1,-4($a0) C S1 + bne $a1,$a2,0b +23: mflo $t0 C M2 + multu $v1,$at C M3 + msubu $t2,$a3 C M3 + negu $v0 C M3, 32x16 MDU stall + sw $t0,0($a0) C S2 + msubu $v0,$at C M3 + mflo $at C M3 + mfhi $v0 C M3 carry + sw $at,4($a0) C S3 + jr $ra + negu $v0 +1: mflo $at + mfhi $v0 + sw $at,0($a0) + jr $ra + negu $v0 +EPILOGUE(mpn_submul_1) + +ASM_END() From borucki.andrzej at gmail.com Sat Nov 9 14:34:57 2019 From: borucki.andrzej at gmail.com (Andy) Date: Sat, 9 Nov 2019 15:34:57 +0100 Subject: odd using of macro MODLIMB_INVERSE_3 Message-ID: In file toom_interpolate_6pts.c is: /* For odd divisors, mpn_divexact_1 works fine with two's complement. */ #ifndef mpn_divexact_by3 #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && MODLIMB_INVERSE_3 #define mpn_divexact_by3(dst,src,size) mpn_pi1_bdiv_q_1(dst,src,size,3,MODLIMB_INVERSE_3,0) #else #define mpn_divexact_by3(dst,src,size) mpn_divexact_1(dst,src,size,3) #endif #endif This can make some problems on some compilers. if I have correctly guessed the intentions of this conditional, it doesn't matter what the value is MODLIMB_INVERSE_3 but if is defined, should be . #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && defined MODLIMB_INVERSE_3 ? From bodrato at mail.dm.unipi.it Sat Nov 9 16:32:08 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 09 Nov 2019 17:32:08 +0100 Subject: odd using of macro MODLIMB_INVERSE_3 In-Reply-To: References: Message-ID: <1f44db2141ce4f0630d30f101ece5633@student.dm.unipi.it> Ciao, Il 2019-11-09 15:34 Andy ha scritto: > In file toom_interpolate_6pts.c is: > #ifndef mpn_divexact_by3 > #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && MODLIMB_INVERSE_3 > This can make some problems on some compilers. > if I have correctly guessed the intentions of this conditional, it > doesn't > matter what the value is MODLIMB_INVERSE_3 but if is defined, Currently, MODLIMB_INVERSE_3 is always defined, so we shall get rid of the && MODLIMB_INVERSE_3 condition. I believe that also mpn_divexact_by3 is always defined with the current library. So we should probably get rid of all the #ifndef ... ?is, m -- http://bodrato.it/papers/ From bodrato at mail.dm.unipi.it Sat Nov 9 17:22:56 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 09 Nov 2019 18:22:56 +0100 Subject: odd using of macro MODLIMB_INVERSE_3 In-Reply-To: <1f44db2141ce4f0630d30f101ece5633@student.dm.unipi.it> References: <1f44db2141ce4f0630d30f101ece5633@student.dm.unipi.it> Message-ID: <2ed6a5c2fe105b276b841b05f26b4642@student.dm.unipi.it> Ciao, > Il 2019-11-09 15:34 Andy ha scritto: >> In file toom_interpolate_6pts.c is: > >> #ifndef mpn_divexact_by3 >> #if HAVE_NATIVE_mpn_pi1_bdiv_q_1 && MODLIMB_INVERSE_3 > >> This can make some problems on some compilers. I decided for the easiest solution: using in _6pts the same code used by _7pts and _8pts. https://gmplib.org/repo/gmp/rev/dc44b59ee8db ?is, m From nisse at lysator.liu.se Sun Nov 10 08:43:10 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Sun, 10 Nov 2019 09:43:10 +0100 Subject: Small limb-size in mini-gmp? Message-ID: Hi, I noticed the recent change https://gmplib.org/repo/gmp/rev/d5f4f8640be9, "mini-gmp: Avoid undefined behaviour with small limb sizes." Currently, mini-gmp.h makes mp_limb_t an alias for unsigned long, which by the C spec ought to be at least 32 bits. And then, e.g., int LOCAL_SHIFT_BITS = 16; ... if (sizeof(mp_limb_t) * CHAR_BIT > LOCAL_SHIFT_BITS) ought to be always true. Are you planning to do something like artificial-small-limbs for mini-gmp, suggested on the list a while ago? Also, if (GMP_LIMB_BITS > LOCAL_SHIFT_BITS) should be equivalent, and slightly more readable, imo. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Sun Nov 10 11:02:07 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 10 Nov 2019 12:02:07 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: Message-ID: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> Ciao Niels! Il 2019-11-10 09:43 nisse at lysator.liu.se ha scritto: > I noticed the recent change > https://gmplib.org/repo/gmp/rev/d5f4f8640be9, "mini-gmp: Avoid > undefined > behaviour with small limb sizes." > Are you planning to do something like artificial-small-limbs > for mini-gmp, suggested on the list a while ago? The current code should work smoothly if you change mini-gmp.h and typedef unsigned char mp_limb_t; or use others unsigned types. Hopefully, both larger and smaller than the default unsigned long should work. It works thanks to the last corrections and to the work done last year after the discussion on Paul's micro-gmp. Paul also asked us "to indicate in mini-gmp.h the places to modify" (https://gmplib.org/list-archives/gmp-devel/2018-December/005123.html) and you proposed a possible syntax in https://gmplib.org/list-archives/gmp-devel/2018-December/005126.html But I'm not sure we should officially document this feature, for the simple reason that... it is not currently tested by our great testing framework. So, I'm not "planning" anything more that what was already done. Except possibly enabling an easy way to test the code with 8, 16, 32-bits types... But it is not a priority for me, at the moment. Maybe it works also for artificialy-small-limbs, maybe not. I did not try, and I'm not planning any other change to support them. > Also, > > if (GMP_LIMB_BITS > LOCAL_SHIFT_BITS) > > should be equivalent, and slightly more readable, imo. I agree! Adopted. ?is, m From bodrato at mail.dm.unipi.it Sun Nov 10 11:32:20 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 10 Nov 2019 12:32:20 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> Message-ID: <3a2e64d4f0903b231c44b8a740260f14@student.dm.unipi.it> PS: Il 2019-11-10 12:02 Marco Bodrato ha scritto: > It works thanks to the last corrections and to the work done last year > after the discussion on Paul's micro-gmp. e.g.: https://gmplib.org/repo/gmp/rev/3f1afa83957e ?is, m From borucki.andrzej at gmail.com Sat Nov 9 16:49:43 2019 From: borucki.andrzej at gmail.com (Andy) Date: Sat, 9 Nov 2019 17:49:43 +0100 Subject: #ifdef HAVE_NATIVE_NNN Message-ID: Small note and fast applicable: Mabe better than "#ifdef HAVE_NATIVE" always should be "#if HAVE_NATIVE" because user can freely in this case for example #define HAVE_NATIVE_mpn_rsh1sub_n 0 without delete this line? From borucki.andrzej at gmail.com Sun Nov 10 17:04:34 2019 From: borucki.andrzej at gmail.com (Andy) Date: Sun, 10 Nov 2019 18:04:34 +0100 Subject: Half of limb works only in 64 limb in divexact? Message-ID: In mpn_divexact_1 and umul_ppmm_lowequal is constant 32 bits instead of half bits. From tg at gmplib.org Tue Nov 12 13:05:22 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 12 Nov 2019 14:05:22 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> (Marco Bodrato's message of "Sun, 10 Nov 2019 12:02:07 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> Message-ID: <868sol6y99.fsf@shell.gmplib.org> Marco Bodrato writes: But I'm not sure we should officially document this feature, for the simple reason that... it is not currently tested by our great testing framework. I'd be willing to add whatever test is desirable. (Editing the mp_limb_t declaration from within the test drivers might be a poor approach, though, so I'll wait until there is a defined method of controlling its declaration.) -- Torbj?rn Please encrypt, key id 0xC8601622 From nisse at lysator.liu.se Tue Nov 12 15:25:54 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Tue, 12 Nov 2019 16:25:54 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <868sol6y99.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Tue, 12 Nov 2019 14:05:22 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> Message-ID: tg at gmplib.org (Torbj?rn Granlund) writes: > (Editing the mp_limb_t declaration from within the test drivers might be > a poor approach, though, so I'll wait until there is a defined method of > controlling its declaration.) Then we'd need something like #ifndef MINI_GMP_LIMB_TYPE #define MINI_GMP_LIMB_TYPE unsigned long #endif typedef MINI_GMP_LIMB_TYPE mp_limb_t in mini-gmp.h. Is there any simpler or prettier way? One could do it in two lines less as #ifndef mp_limb_t typedef unsigned long mp_limb_t #endif (leaving to the overriding code to define the type) but I'm not sure I like that better. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Tue Nov 12 21:22:00 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Tue, 12 Nov 2019 22:22:00 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> Message-ID: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> Il 2019-11-12 16:25 nisse at lysator.liu.se ha scritto: > tg at gmplib.org (Torbj?rn Granlund) writes: >> so I'll wait until there is a defined method of >> controlling its declaration.) > Then we'd need something like > > #ifndef MINI_GMP_LIMB_TYPE > #define MINI_GMP_LIMB_TYPE unsigned long > #endif > > typedef MINI_GMP_LIMB_TYPE mp_limb_t > > in mini-gmp.h. Seems clean and straightforward. Is something like the following too tricky? #ifndef MINI_GMP_LIMB_TYPE #define MINI_GMP_LIMB_TYPE long #endif typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t As only unsigned types are supported... Then, should we adapt the Makefile target check-mini-gmp in such a way that it can handle make MINI_GMP_LIMB_TYPE=char check-mini-gmp ? ?is, m From tg at gmplib.org Tue Nov 12 21:23:45 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 12 Nov 2019 22:23:45 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> (Marco Bodrato's message of "Tue, 12 Nov 2019 22:22:00 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> Message-ID: <8636eseqla.fsf@shell.gmplib.org> Marco Bodrato writes: Seems clean and straightforward. Is something like the following too tricky? #ifndef MINI_GMP_LIMB_TYPE #define MINI_GMP_LIMB_TYPE long #endif typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t As only unsigned types are supported... Then, should we adapt the Makefile target check-mini-gmp in such a way that it can handle make MINI_GMP_LIMB_TYPE=char check-mini-gmp Avoiding a space in the type would help. :-) -- Torbj?rn Please encrypt, key id 0xC8601622 From vincent at vinc17.net Wed Nov 13 15:28:46 2019 From: vincent at vinc17.net (Vincent Lefevre) Date: Wed, 13 Nov 2019 16:28:46 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> Message-ID: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> On 2019-11-12 22:22:00 +0100, Marco Bodrato wrote: > Is something like the following too tricky? > > #ifndef MINI_GMP_LIMB_TYPE > #define MINI_GMP_LIMB_TYPE long > #endif > > typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t > > As only unsigned types are supported... Unsigned types do not necessarily start with "unsigned". Example: uint128_t -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From bodrato at mail.dm.unipi.it Wed Nov 13 16:41:47 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Wed, 13 Nov 2019 17:41:47 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> Message-ID: Il 2019-11-13 16:28 Vincent Lefevre ha scritto: > On 2019-11-12 22:22:00 +0100, Marco Bodrato wrote: >> Is something like the following too tricky? >> >> #ifndef MINI_GMP_LIMB_TYPE >> #define MINI_GMP_LIMB_TYPE long >> #endif >> >> typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t >> >> As only unsigned types are supported... > > Unsigned types do not necessarily start with "unsigned". > Example: uint128_t I know. I did hope that "unsigned" were just a modifier... But it seems that a line like the following is not allowed typedef unsigned uint128_t mp_limb_t I do not understand why... ?is, m From vincent at vinc17.net Wed Nov 13 19:01:29 2019 From: vincent at vinc17.net (Vincent Lefevre) Date: Wed, 13 Nov 2019 20:01:29 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> Message-ID: <20191113190129.GA11971@joooj.vinc17.net> On 2019-11-13 17:41:47 +0100, Marco Bodrato wrote: > I did hope that "unsigned" were just a modifier... > > But it seems that a line like the following is not allowed > > typedef unsigned uint128_t mp_limb_t > > I do not understand why... If it were a modifier, then I suppose that "signed" would be too. Then, what would "signed mp_limb_t" mean when mp_limb_t is "unsigned ..."? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From tg at gmplib.org Wed Nov 13 20:17:53 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Wed, 13 Nov 2019 21:17:53 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Wed, 13 Nov 2019 17:41:47 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> Message-ID: <867e43pm32.fsf@shell.gmplib.org> Let's not make the best is the enemy of the good! I suggest that we either, 1. do nothing now, or 2. follow Marco's proposal allowing "char", "short", "int", "long", and perhaps the spacey "long long" as overriding types, or 3. allow the use of asl.h. I am not sure we should support that with conditional inclusion in mini-gmp.h, as people might see it and wonder what that file might do. We might resort to cruder tricks. -- Torbj?rn Please encrypt, key id 0xC8601622 From nisse at lysator.liu.se Wed Nov 13 21:20:18 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Wed, 13 Nov 2019 22:20:18 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <867e43pm32.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Wed, 13 Nov 2019 21:17:53 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> Message-ID: tg at gmplib.org (Torbj?rn Granlund) writes: > 2. follow Marco's proposal allowing "char", "short", "int", "long", and > perhaps the spacey "long long" as overriding types, or I guess that's good enough for now. But is it that difficult to do quoting of "unsigned char"? Something like make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"' (I don't remember trying to use -D with spaces in the expansion, but it can't be unheard of). > 3. allow the use of asl.h. I am not sure we should support that with > conditional inclusion in mini-gmp.h, as people might see it and wonder > what that file might do. We might resort to cruder tricks. Not in mini-gmp.h. Using asl.h could be something like #include "asl.h" #define MINI_GMP_LIMB_TYPE mp_limb_t #include "mini-gmp.h" somewhere in mini-gmp/test/. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From vincent at vinc17.net Thu Nov 14 02:06:19 2019 From: vincent at vinc17.net (Vincent Lefevre) Date: Thu, 14 Nov 2019 03:06:19 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> Message-ID: <20191114020619.GC14707@zira.vinc17.org> On 2019-11-13 22:20:18 +0100, Niels M?ller wrote: > tg at gmplib.org (Torbj?rn Granlund) writes: > > > 2. follow Marco's proposal allowing "char", "short", "int", "long", and > > perhaps the spacey "long long" as overriding types, or > > I guess that's good enough for now. But is it that difficult to do > quoting of "unsigned char"? Something like > > make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"' > > (I don't remember trying to use -D with spaces in the expansion, but it > can't be unheard of). How about using uint8_t instead? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From borucki.andrzej at gmail.com Sun Nov 10 23:39:20 2019 From: borucki.andrzej at gmail.com (Andy) Date: Mon, 11 Nov 2019 00:39:20 +0100 Subject: Significant speedup divrem of very short numbers Message-ID: Although GMP is designed for very long numbers, sometimes systems using it would have task divide amd mod very short numbers : one limb by one limb. For example if we factor this number. My suggestion (is has correct values?) is: void mpn_tdiv_qr (mp_ptr qp, mp_ptr rp, mp_size_t qxn, mp_srcptr np, mp_size_t nn, mp_srcptr dp, mp_size_t dn) .......................... ......................... case 1: { if (nn = 1) <---------------- { qp[0] = *np / *dp; rp[0] = *np % *dp; } else rp[0] = mpn_divrem_1 (qp, (mp_size_t) 0, np, nn, dp[0]); return; } is called twice machine divrem but is I add assignment to limbs, it is speedup, because doesn't careof memory changes. Better than using div structure from because this structure is signed. Finally: if (nn = 1) { mp_limb_t n = *np; mp_limb_t d = *dp; qp[0] = n / d; rp[0] = n % d; } VisualC++ give mp_limb_t n = *np; mp_limb_t d = *dp; qp[0] = n / d; 00007FF75A0727B0 mov rax,qword ptr [r9] 00007FF75A0727B3 mov r10,rdx 00007FF75A0727B6 mov r8,qword ptr [dp] 00007FF75A0727BB xor edx,edx 00007FF75A0727BD div rax,qword ptr [r8] 00007FF75A0727C0 mov qword ptr [rcx],rax rp[0] = n % d; It is correct? These values must return mpn_tdiv_qr? It is possible also sppedup larger (more complicated) 2limbs/1limb ? My bench for million (1 to 1000000) loop and 10 measurement, choosing best on i3 4160, 3.60 GHz machine: 7.9392 ms boost cpp_int: 21.7078 ms gmp: 33.8823 ms gmp with change 8.7771 Speedup 3.86 x From borucki.andrzej at gmail.com Tue Nov 12 19:56:52 2019 From: borucki.andrzej at gmail.com (Andy) Date: Tue, 12 Nov 2019 20:56:52 +0100 Subject: Dividing 2 limbs by one limb saving 30% of time ? Message-ID: void mpn_tdiv_qr (mp_ptr qp, mp_ptr rp, mp_size_t qxn, mp_srcptr np, mp_size_t nn, mp_srcptr dp, mp_size_t dn) ................................ case 1: { if (nn == 1) { mp_limb_t n = *np; mp_limb_t d = *dp; qp[0] = n / d; rp[0] = n % d; } else if (nn == 2 && np[1] < *dp) { udiv_qrnnd(qp, rp, np[1], np[0], *dp); } else rp[0] = mpn_divrem_1 (qp, (mp_size_t) 0, np, nn, dp[0]); Test ( np[1] < *dp ) (but not <=) is necessary and sufficient to fit result in one limb and not throw integer exception. The whole 50% of the random cases satisfy this test. Condition saved time 1.3 x Will udiv_qrnnd give the right result in this case, or is it not possible to do right? From nisse at lysator.liu.se Fri Nov 15 19:23:33 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Fri, 15 Nov 2019 20:23:33 +0100 Subject: Significant speedup divrem of very short numbers In-Reply-To: (Andy's message of "Mon, 11 Nov 2019 00:39:20 +0100") References: Message-ID: Andy writes: > Although GMP is designed for very long numbers, sometimes systems using it > would have task divide amd mod very short numbers : one limb by one > limb. If you use the mpn-level functions of gmp, and have divisors that are always or usually single limb numbers, you'll get less overhead if you call mpn_divrem_1 rather than mpn_tdiv_qr. > For example if we factor this number. For factoring single limb numbers, the factor program from GNU coreutils is likely much faster than anything using mpn_tdiv_qr. It uses trial division with precomputed p-adic inverses of primes up to some limit, followed by Pollard-Brent rho using Montgomery redc rather than plain division. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Sat Nov 16 08:24:33 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 16 Nov 2019 09:24:33 +0100 Subject: mpz_perfect_power companion In-Reply-To: References: Message-ID: <16b91f92f241cabf1bc1d5cde80570bd@student.dm.unipi.it> Ciao, Il 2019-08-19 19:39 Seth Troisi ha scritto: >>>> I thought a good first step would be to add support for the two >>> related >>>> functions (mpz_perfect_power_p, mpz_perfect_square_p) in >>> tune/speed which >>>> I already started on. >> Yes that seems more correct. Updated (see >> https://github.com/sethtroisi/libgmp/pull/1 [6]) Ok, I pushed your patch to the repository. https://gmplib.org/repo/gmp/rev/e125bf760fdd ?is, m From bodrato at mail.dm.unipi.it Sat Nov 16 09:09:18 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 16 Nov 2019 10:09:18 +0100 Subject: mpz_prevprime In-Reply-To: References: <69466e3f87f9aa06cdbf61063c5e8dd6.squirrel@student-web1.dm.unipi.it> <0e32e0f4c221588433931eb51090608b.squirrel@student-web1.dm.unipi.it> Message-ID: <5386c6153faca0ac37c237e7463e7f01@student.dm.unipi.it> Ciao, Il 2019-09-03 08:41 Seth Troisi ha scritto: > 1. s->reps next_primes chained (next_prime(p, p); next_prime(p, p);) > Currently it takes about 20 seconds to test -s 16-128, and 15 minutes > to test -s 16-1028 > with -t 1.04 the resulting graph is much smoother than the old graph. Also your proposed patch for tune/speed, to support mpz_nextprime, was committed. https://gmplib.org/repo/gmp/rev/8aa3b936c707 ?is, m From bodrato at mail.dm.unipi.it Sat Nov 16 15:42:04 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sat, 16 Nov 2019 16:42:04 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> Message-ID: <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> Il 2019-11-13 22:20 nisse at lysator.liu.se ha scritto: > tg at gmplib.org (Torbj?rn Granlund) writes: > >> 2. follow Marco's proposal allowing "char", "short", "int", "long", >> and >> perhaps the spacey "long long" as overriding types, or > > I guess that's good enough for now. But is it that difficult to do > quoting of "unsigned char"? Something like > > make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"' With the patch below applied, the following line works on shell: gmake CPPFLAGS='-DMINI_GMP_LIMB_TYPE=unsigned\ char' check-mini-gmp And also on my Debian... diff -r 0a7bccdcda14 Makefile.am --- a/Makefile.am Sat Nov 16 08:48:59 2019 +0100 +++ b/Makefile.am Sat Nov 16 11:52:46 2019 +0100 @@ -442,7 +442,7 @@ MINI_GMP_DIR="$$abs_srcdir/mini-gmp" \ LDFLAGS="-L../../.libs" \ LIBS="-lgmp -lm" \ - CC="$(CC)" CFLAGS="$(CFLAGS)" CPPFLAGS="-I../.." check + CC="$(CC)" CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS) -I../.." check clean-mini-gmp: if [ -d mini-gmp/tests ] ; then \ diff -r 0a7bccdcda14 mini-gmp/mini-gmp.h --- a/mini-gmp/mini-gmp.h Sat Nov 16 08:48:59 2019 +0100 +++ b/mini-gmp/mini-gmp.h Sat Nov 16 11:52:46 2019 +0100 @@ -53,7 +53,11 @@ void *(**) (void *, size_t, size_t), void (**) (void *, size_t)); -typedef unsigned long mp_limb_t; +#ifndef MINI_GMP_LIMB_TYPE +#define MINI_GMP_LIMB_TYPE unsigned long +#endif + +typedef MINI_GMP_LIMB_TYPE mp_limb_t; typedef long mp_size_t; typedef unsigned long mp_bitcnt_t; ?is, m -- http://bodrato.it/papers/ From tg at gmplib.org Sat Nov 16 20:49:15 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Sat, 16 Nov 2019 21:49:15 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> (Marco Bodrato's message of "Sat, 16 Nov 2019 16:42:04 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> Message-ID: <86imnjmtro.fsf@shell.gmplib.org> Marco Bodrato writes: Il 2019-11-13 22:20 nisse at lysator.liu.se ha scritto: > tg at gmplib.org (Torbj?rn Granlund) writes: > >> 2. follow Marco's proposal allowing "char", "short", "int", "long", >> and >> perhaps the spacey "long long" as overriding types, or > > I guess that's good enough for now. But is it that difficult to do > quoting of "unsigned char"? Something like > > make check-mini-gmp CPPFLAGS='-D"MINI_GMP_LIMB_TYPE=unsigned char"' With the patch below applied, the following line works on shell: gmake CPPFLAGS='-DMINI_GMP_LIMB_TYPE=unsigned\ char' check-mini-gmp And also on my Debian... As soon as that is committed, I will config a nightly build to exercise it. -- Torbj?rn Please encrypt, key id 0xC8601622 From bodrato at mail.dm.unipi.it Sat Nov 16 23:26:19 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 17 Nov 2019 00:26:19 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86imnjmtro.fsf@shell.gmplib.org> References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> Message-ID: Ciao, Il Sab, 16 Novembre 2019 9:49 pm, Torbj?rn Granlund ha scritto: > Marco Bodrato writes: > With the patch below applied, the following line works on shell: > gmake CPPFLAGS='-DMINI_GMP_LIMB_TYPE=unsigned\ char' check-mini-gmp > As soon as that is committed, I will config a nightly build to exercise > it. Committed. ?is, m From tg at gmplib.org Sat Nov 16 23:41:17 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Sun, 17 Nov 2019 00:41:17 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Sun, 17 Nov 2019 00:26:19 +0100") References: <7fd2293a0c15cf402363223fe22daa44@student.dm.unipi.it> <868sol6y99.fsf@shell.gmplib.org> <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> Message-ID: <86d0drmlsy.fsf@shell.gmplib.org> "Marco Bodrato" writes: Committed. The needed space causes problems as this needs to go through several scripts and evaluations. I am not sure how to get it working, actually. I think the original proposal to have the word unsigned already in the file was better. -- Torbj?rn Please encrypt, key id 0xC8601622 From vincent at vinc17.net Sat Nov 16 23:44:31 2019 From: vincent at vinc17.net (Vincent Lefevre) Date: Sun, 17 Nov 2019 00:44:31 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86d0drmlsy.fsf@shell.gmplib.org> References: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> Message-ID: <20191116234431.GB11971@joooj.vinc17.net> On 2019-11-17 00:41:17 +0100, Torbjorn Granlund wrote: > "Marco Bodrato" writes: > > Committed. > > The needed space causes problems as this needs to go through several > scripts and evaluations. I am not sure how to get it working, actually. > > I think the original proposal to have the word unsigned already in the > file was better. Not using a space is better. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From tg at gmplib.org Sun Nov 17 00:00:14 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Sun, 17 Nov 2019 01:00:14 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <20191116234431.GB11971@joooj.vinc17.net> (Vincent Lefevre's message of "Sun, 17 Nov 2019 00:44:31 +0100") References: <70e5629dcc0dadd692ecf5f17b88ecd0@student.dm.unipi.it> <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> Message-ID: <868sofmkxd.fsf@shell.gmplib.org> > The needed space causes problems as this needs to go through several > scripts and evaluations. I am not sure how to get it working, actually. > > I think the original proposal to have the word unsigned already in the > file was better. Not using a space is better. Unfortunately unsignedchar is not an allowed type. Or what do you mean? We cannot use uint8_t as it is not a builtin type, as you know. I believe you made Marco omit the "unsigned" in the decl itself and made this change close-to-impossible to use from scripts. -- Torbj?rn Please encrypt, key id 0xC8601622 From vincent at vinc17.net Sun Nov 17 00:43:02 2019 From: vincent at vinc17.net (Vincent Lefevre) Date: Sun, 17 Nov 2019 01:43:02 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <868sofmkxd.fsf@shell.gmplib.org> References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> Message-ID: <20191117004302.GA27349@zira.vinc17.org> On 2019-11-17 01:00:14 +0100, Torbjorn Granlund wrote: > We cannot use uint8_t as it is not a builtin type, as you know. I don't understand why you need a builtin type. It should work by conditionally including . Alternatively, you can predefine some types, e.g.: typedef unsigned char gmp_uchar_t; then one could use -DMINI_GMP_LIMB_TYPE=gmp_uchar_t -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From bodrato at mail.dm.unipi.it Sun Nov 17 09:00:23 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 17 Nov 2019 10:00:23 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <20191117004302.GA27349@zira.vinc17.org> References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> Message-ID: <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> Ciao, Il Dom, 17 Novembre 2019 1:43 am, Vincent Lefevre ha scritto: > It should work by conditionally including . > > Alternatively, you can predefine some types, e.g.: > > typedef unsigned char gmp_uchar_t; I think that mini-gmp should not contain too many types, symbols, definitions, includes that are not used by the header of the main library. The priority now is to actively and widely test a feature: support for different (smaller) sizes of limbs in mini-gmp. That's why: https://gmplib.org/repo/gmp/rev/8e6f40b1f0a9 Someone needs to test with different types? Well, no problem. mini-gmp.[ch] are just two files, and the header is not difficult to read and adapt... is it? ?is, m -- http://bodrato.it/papers/ From tg at gmplib.org Sun Nov 17 16:29:55 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Sun, 17 Nov 2019 17:29:55 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> (Marco Bodrato's message of "Sun, 17 Nov 2019 10:00:23 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> Message-ID: <86o8xav530.fsf@shell.gmplib.org> I've run a test round for 8-bit and 16-bit limbs now, on the system shell. The automated tests will however be run on the system mati, as that system is many times faster than the hardware which runs shell. -- Torbj?rn Please encrypt, key id 0xC8601622 From tg at gmplib.org Mon Nov 18 12:06:59 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Mon, 18 Nov 2019 13:06:59 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86o8xav530.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Sun, 17 Nov 2019 17:29:55 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> Message-ID: <86ftil8k2k.fsf@shell.gmplib.org> tg at gmplib.org (Torbj?rn Granlund) writes: I've run a test round for 8-bit and 16-bit limbs now, on the system shell. The automated tests will however be run on the system mati, as that system is many times faster than the hardware which runs shell. The build on maticrunch under the 32-bit ABI using "unsigned short" for mp_limb_t failed. https://gmplib.org/devel/tm/gmp/date.html -- Torbj?rn Please encrypt, key id 0xC8601622 From bodrato at mail.dm.unipi.it Tue Nov 19 06:18:02 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Tue, 19 Nov 2019 07:18:02 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86ftil8k2k.fsf@shell.gmplib.org> References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> Message-ID: Ciao, Il Lun, 18 Novembre 2019 1:06 pm, Torbj?rn Granlund ha scritto: > tg at gmplib.org (Torbj?rn Granlund) writes: > The build on maticrunch under the 32-bit ABI using "unsigned short" for > mp_limb_t failed. Ok, I'll investigate! ?is, m From tg at gmplib.org Tue Nov 19 08:50:06 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 19 Nov 2019 09:50:06 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Tue, 19 Nov 2019 07:18:02 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> Message-ID: <86wobwxnb5.fsf@shell.gmplib.org> "Marco Bodrato" writes: Il Lun, 18 Novembre 2019 1:06 pm, Torbj?rn Granlund ha scritto: > tg at gmplib.org (Torbj?rn Granlund) writes: > The build on maticrunch under the 32-bit ABI using "unsigned short" for > mp_limb_t failed. Ok, I'll investigate! It might be easier to either do a local build or a build on e.g. ivygentoo32. (The build farm machines, like mati, now only start their ${hostname}gentoo64 guest automatically at boot.) -- Torbj?rn Please encrypt, key id 0xC8601622 From bodrato at mail.dm.unipi.it Tue Nov 19 15:46:56 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Tue, 19 Nov 2019 16:46:56 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86wobwxnb5.fsf@shell.gmplib.org> References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> Message-ID: <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> Ciao, Il Mar, 19 Novembre 2019 9:50 am, Torbj?rn Granlund ha scritto: > "Marco Bodrato" writes: > Il Lun, 18 Novembre 2019 1:06 pm, Torbj?rn Granlund ha scritto: > > tg at gmplib.org (Torbj?rn Granlund) writes: > > > The build on maticrunch under the 32-bit ABI using "unsigned short" > > for mp_limb_t failed. I added another shortcut for the mpn_invert_3by2 function: https://gmplib.org/repo/gmp/rev/500a0b8a9ff1 Now the ABI=32 -asl16 issue should be healed. The generic code (for mpn_invert_3by2) works only when "unsigned" is half the size of "mp_limb_t" or has the same size... this means that large types for mp_limb_t are not supported (e.g. no uint128_t). Smaller types should be handled by some of the shortcuts. Is the ABI=64 -asl32 case tested? It should work, and it should not even be too slow. ?is, m From tg at gmplib.org Tue Nov 19 16:02:48 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 19 Nov 2019 17:02:48 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> (Marco Bodrato's message of "Tue, 19 Nov 2019 16:46:56 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> Message-ID: <86r223g8gn.fsf@shell.gmplib.org> "Marco Bodrato" writes: Now the ABI=32 -asl16 issue should be healed. I will whack it soon. The generic code (for mpn_invert_3by2) works only when "unsigned" is half the size of "mp_limb_t" or has the same size... this means that large types for mp_limb_t are not supported (e.g. no uint128_t). Smaller types should be handled by some of the shortcuts. If soo, why did asl8 work? Is the ABI=64 -asl32 case tested? It should work, and it should not even be too slow. Not tested, but will do. -- Torbj?rn Please encrypt, key id 0xC8601622 From bodrato at mail.dm.unipi.it Tue Nov 19 17:10:04 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Tue, 19 Nov 2019 18:10:04 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86r223g8gn.fsf@shell.gmplib.org> References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> Message-ID: Ciao, Il Mar, 19 Novembre 2019 5:02 pm, Torbj?rn Granlund ha scritto: > "Marco Bodrato" writes: > The generic code (for mpn_invert_3by2) works only when "unsigned" is > half > the size of "mp_limb_t" or has the same size... this means that large > types for mp_limb_t are not supported (e.g. no uint128_t). Smaller types > should be handled by some of the shortcuts. > > If soo, why did asl8 work? For asl8, one of the existing shortcuts is used, not the generic code. In particular, mpn_invert_3by2 (mp_limb_t u1, mp_limb_t u0) reduces to: return (((unsigned) 1 << 24) - 1) / (((unsigned) u1 << 8) + u0); ?is, m -- http://bodrato.it/papers/ From tg at gmplib.org Tue Nov 19 18:50:20 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Tue, 19 Nov 2019 19:50:20 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Tue, 19 Nov 2019 18:10:04 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> Message-ID: <86ftijsntf.fsf@shell.gmplib.org> "Marco Bodrato" writes: For asl8, one of the existing shortcuts is used, not the generic code. In particular, mpn_invert_3by2 (mp_limb_t u1, mp_limb_t u0) reduces to: return (((unsigned) 1 << 24) - 1) / (((unsigned) u1 << 8) + u0); If there is special code for several asl cases, doesn't that defeat the purpose of asl, at least to some extent? (Testing was successful now. Let me know if mati's weekly testing is sufficient or if additional or more frequent testing would be desirable.) -- Torbj?rn Please encrypt, key id 0xC8601622 From bodrato at mail.dm.unipi.it Tue Nov 19 19:57:14 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Tue, 19 Nov 2019 20:57:14 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86ftijsntf.fsf@shell.gmplib.org> References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> <86ftijsntf.fsf@shell.gmplib.org> Message-ID: Ciao, Il Mar, 19 Novembre 2019 7:50 pm, Torbj?rn Granlund ha scritto: > If there is special code for several asl cases, doesn't that defeat the > purpose of asl, at least to some extent? Of course, to some extent you are right. There are two functions that contain really special code for smaller sizes: the gmp_umul_ppmm macro, and the function mpn_invert_3by2. It is possible (and not really difficult, I think) to adapt the default code and remove any special shortcut from both those functions too. The price would be to slow down both the asl version and the default (mp_limb_t = unsigned long) one. I think that special code to use plain unsigned long multiplication and plain unsigned long division for those two critical macros, when limbs are small enough, is a reasonable compromise. > (Testing was successful now. Let me know if mati's weekly testing is > sufficient or if additional or more frequent testing would be I think it is sufficient. We will decide if the testing was enough before releasing... In the yes case, we will document the feature; in the no case, we will not :-) ?is, m From nisse at lysator.liu.se Tue Nov 19 21:20:51 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Tue, 19 Nov 2019 22:20:51 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Tue, 19 Nov 2019 20:57:14 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> <86ftijsntf.fsf@shell.gmplib.org> Message-ID: "Marco Bodrato" writes: > Ciao, > > Il Mar, 19 Novembre 2019 7:50 pm, Torbj?rn Granlund ha scritto: >> If there is special code for several asl cases, doesn't that defeat the >> purpose of asl, at least to some extent? I think it defeats small-limb testing of mini-gmp. If it makes mini-gmp with small limbs much faster, it might aid small-limb tests of mpfr. > It is possible (and not really difficult, I think) to adapt the default > code and remove any special shortcut from both those functions too. When the special code was added (about a year ago, 2018-12-21), was that as an optimization, or because the original code didn't work properly for small limb size? I think there are assumptions at some places that unsigned int is large enough to hold half a limb (e.g., temporaries in umul_ppmm). Should be no problem for unusually *small* limb size, but might make sense to use mp_limb_t for all variables representing half limbs. Should also make some of the casts unnecessary. > I think that special code to use plain unsigned long multiplication and > plain unsigned long division for those two critical macros, when limbs are > small enough, is a reasonable compromise. Maybe for umul_ppmm, but I disagree about mpn_invert_3by2. The latter function isn't used in any inner loops. >> (Testing was successful now. Let me know if mati's weekly testing is >> sufficient or if additional or more frequent testing would be I think weekly tests should be adequate for now. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From tg at gmplib.org Wed Nov 20 11:06:37 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Wed, 20 Nov 2019 12:06:37 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Tue, 19 Nov 2019 20:57:14 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> <86ftijsntf.fsf@shell.gmplib.org> Message-ID: <86o8x624ea.fsf@shell.gmplib.org> This mini-GMP semi-asl project makes me eager to get full asl to work for the full GMP. I think we could make it work for limbs down to 4 bits, perhaps even 2 bits. IIRC, one issue which needs resolving is our occasional use of some limb macros for sizes. Would it be feasible to use asl.h instead of the new coarse typing in mini-GMP? I think we should then conditionally #include asl.h from each test case, but leave mini-gmp.{c,h} alone. Note that asl.h requires a C++ compiler. The nightly builds ensures that that works already. -- Torbj?rn Please encrypt, key id 0xC8601622 From nisse at lysator.liu.se Wed Nov 20 11:56:04 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Wed, 20 Nov 2019 12:56:04 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: <86o8x624ea.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Wed, 20 Nov 2019 12:06:37 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> <86ftijsntf.fsf@shell.gmplib.org> <86o8x624ea.fsf@shell.gmplib.org> Message-ID: tg at gmplib.org (Torbj?rn Granlund) writes: > Would it be feasible to use asl.h instead of the new coarse typing in > mini-GMP? I think we should then conditionally #include asl.h from each > test case, but leave mini-gmp.{c,h} alone. Or maybe it's sufficient to add "-include .../asl.h" to CPPFLAGS ? Plus whatever is needed to force mini-gmp.h to use asl's definition of mp_limb_t. Hmm, one would also need to define GMP_LIMB_BITS differently, mini-gmp.c currently uses sizeof(mp_limb_t) * CHAR_BIT, which will will not be correct with asl.h. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Wed Nov 20 14:48:21 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Wed, 20 Nov 2019 15:48:21 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <867e43pm32.fsf@shell.gmplib.org> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> <86ftijsntf.fsf@shell.gmplib.org> Message-ID: Ciao, Il 2019-11-19 22:20 nisse at lysator.liu.se ha scritto: > "Marco Bodrato" writes: >> Il Mar, 19 Novembre 2019 7:50 pm, Torbj?rn Granlund ha scritto: >>> If there is special code for several asl cases, doesn't that defeat >>> the >>> purpose of asl, at least to some extent? > > I think it defeats small-limb testing of mini-gmp. If it makes mini-gmp > with small limbs much faster, it might aid small-limb tests of mpfr. Not only, it also aid small-limb testing of the implementations in mini-gmp of gcd, primality testing, combinatorics, modular exponentiation... >> It is possible (and not really difficult, I think) to adapt the >> default >> code and remove any special shortcut from both those functions too. > > When the special code was added (about a year ago, 2018-12-21), was > that > as an optimization, or because the original code didn't work properly > for small limb size? The special code for umul_ppmm was added for speed. The generic code works also for smaller limbs. On the invert_3by2 side, the same kind of optimisation was used. Not only for speed, I have to admit, but also because the code could get simpler. I was thinking also to some embedded systems I used some years ago, where "unsigned long" was supported by the compiler, but slow on the hardware... But currently also those embedded systems are probably obsolete. >> I think that special code to use plain unsigned long multiplication >> and >> plain unsigned long division for those two critical macros, when limbs >> are >> small enough, is a reasonable compromise. > > Maybe for umul_ppmm, but I disagree about mpn_invert_3by2. The latter > function isn't used in any inner loops. Ok. We can decide to keep a single variant for mpn_invert_3by2. Will changing the type currently used for "half limbs", taking care of negations and carry detection... be enough? We should try. ?is, m From tg at gmplib.org Wed Nov 20 16:08:02 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Wed, 20 Nov 2019 17:08:02 +0100 Subject: Small limb-size in mini-gmp? In-Reply-To: (Marco Bodrato's message of "Wed, 20 Nov 2019 15:48:21 +0100") References: <20191113152846.GB2656@cventin.lip.ens-lyon.fr> <89c12c2dfa896ed42cc7215c019f82ee@student.dm.unipi.it> <86imnjmtro.fsf@shell.gmplib.org> <86d0drmlsy.fsf@shell.gmplib.org> <20191116234431.GB11971@joooj.vinc17.net> <868sofmkxd.fsf@shell.gmplib.org> <20191117004302.GA27349@zira.vinc17.org> <32293c15dc418f04c4ec4a27f86847fa.squirrel@student-web1.dm.unipi.it> <86o8xav530.fsf@shell.gmplib.org> <86ftil8k2k.fsf@shell.gmplib.org> <86wobwxnb5.fsf@shell.gmplib.org> <4923e8d235b40d3aa948d73a7f778fae.squirrel@student-web1.dm.unipi.it> <86r223g8gn.fsf@shell.gmplib.org> <86ftijsntf.fsf@shell.gmplib.org> Message-ID: <86lfsay1i5.fsf@shell.gmplib.org> Marco Bodrato writes: I was thinking also to some embedded systems I used some years ago, where "unsigned long" was supported by the compiler, but slow on the hardware... But currently also those embedded systems are probably obsolete. Not obsolete at all! I program a 80251 at work, where 8-bit and 16-bit plain arithmetic take a single cycle, while 32-bit ops need two cycles. (But I don't intend to run GMP on that hardware.) Ok. We can decide to keep a single variant for mpn_invert_3by2. Will changing the type currently used for "half limbs", taking care of negations and carry detection... be enough? We should try. With asl.h intermediates will get truncated to the size of mp_limb_t. With (unsigned) char or (unsigned) short intermediates will have the type (unsigned) int. -- Torbj?rn Please encrypt, key id 0xC8601622 From nisse at lysator.liu.se Sun Nov 24 14:18:45 2019 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Sun, 24 Nov 2019 15:18:45 +0100 Subject: Small gcdext_1 In-Reply-To: <86y2x0dhw1.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Thu, 31 Oct 2019 17:00:46 +0100") References: <865zkynnd4.fsf@shell.gmplib.org> <86y2x0dhw1.fsf@shell.gmplib.org> Message-ID: tg at gmplib.org (Torbj?rn Granlund) writes: > How far did you come with gcdext_1? Do you have any timing improvements > to report? :-) Not so far. But to start with very easy improvements, any objections to deleting the #if USE_ZEROTAB things from gcdext_1.c ? BTW, looking at recent changes to that file, a ? character (plus/minus, unicode 0xb1, TeX \pm) was deleted in 46b4c2e7f148. Is it important to avoid non-ascii, and if so, what's the preferred way to write this symbol? "+/-" ? Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. From tg at gmplib.org Sun Nov 24 19:41:00 2019 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Date: Sun, 24 Nov 2019 20:41:00 +0100 Subject: Small gcdext_1 In-Reply-To: ("Niels =?utf-8?Q?M?= =?utf-8?Q?=C3=B6ller=22's?= message of "Sun, 24 Nov 2019 15:18:45 +0100") References: <865zkynnd4.fsf@shell.gmplib.org> <86y2x0dhw1.fsf@shell.gmplib.org> Message-ID: <86r21xdpv7.fsf@shell.gmplib.org> nisse at lysator.liu.se (Niels M?ller) writes: Not so far. But to start with very easy improvements, any objections to deleting the #if USE_ZEROTAB things from gcdext_1.c ? None whatsoever. (We have a few such tables of varying sizes. The top level x86_64/gcd_11 and gcd_22 have one each, since count_*_zeros are slow for older x86_64 CPUs.) BTW, looking at recent changes to that file, a ? character (plus/minus, unicode 0xb1, TeX \pm) was deleted in 46b4c2e7f148. Is it important to avoid non-ascii, and if so, what's the preferred way to write this symbol? "+/-" ? Ask the perpetrator. :-) -- Torbj?rn Please encrypt, key id 0xC8601622 From bodrato at mail.dm.unipi.it Sun Nov 24 22:08:15 2019 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Sun, 24 Nov 2019 23:08:15 +0100 Subject: Small gcdext_1 In-Reply-To: <86r21xdpv7.fsf@shell.gmplib.org> References: <865zkynnd4.fsf@shell.gmplib.org> <86y2x0dhw1.fsf@shell.gmplib.org> <86r21xdpv7.fsf@shell.gmplib.org> Message-ID: <076d074e36977850ed16ef5cd8c7c78e.squirrel@student-web1.dm.unipi.it> Ciao, Il Dom, 24 Novembre 2019 8:41 pm, Torbj?rn Granlund ha scritto: > nisse at lysator.liu.se (Niels M?ller) writes: > BTW, looking at recent changes to that file, a ? character (plus/minus, > unicode 0xb1, TeX \pm) was deleted in 46b4c2e7f148. Is it important to > avoid non-ascii, and if so, what's the preferred way to write this > symbol? "+/-" ? > > Ask the perpetrator. :-) Uhm, I removed it because I got a warning on some platform... but I do not even remember which one... On the terminal I was using, it was printed as a question mark "?", I did not notice it was an intentional plus/minus "?" character! You can write it as "+/-", as you like. Or you can also reinsert the unicode character, I'll try to remember to ignore any warning I may see about it. ?is, m