make check failures: assert() and then several unable to execute bc: No such file or directory

[pulmark]

make check command fails at

addremove.c:64: main: Assertion `p == &allocation_packets[i]' failed.

There are also lot of errors as:

check/z/shift unable to execute bc: No such file or directory unable to receive result from bc: Success

Below is a copy of the make check command output:

check/alloc/addremove addremove: check/alloc/addremove.c:64: main: Assertion `p == &allocation_packets[i]' failed. runtests.sh: line 13: 17777 Aborted (core dumped) $1 check/alloc/fixed check/p/pcmp check/p/pcopy check/p/pmove check/p/pnorm check/p/pzero check/p/negnot check/p/strings check/z/getset check/z/shift unable to execute bc: No such file or directory unable to receive result from bc: Success check/z/zcmp unable to execute bc: No such file or directory unable to receive result from bc: Success check/z/zcmpmag unable to execute bc: No such file or directory unable to receive result from bc: Success ....

[suiginsoft]

Hi, thanks for trying it out. What compiler, OS, and user environment are you using to build hebimath?

bc(1) is required to run the unit tests (it uses it as a test oracle), and it looks like it's failing to find it in your PATH. Please make sure to install it through your package manager as not all distros have it available by default. I should add a check to runtests.sh for bc so that is fails more gracefully.

It's been a couple of years since I've worked on this project, but I'm looking at dedicating some time over the next couple of months to take it to the next level. A few things I have planned are to shorten the namespace prefix from hebi_ to hm_ and implement function variants using the mulx/adx instruction extensions now that I have a new workstation with a CPU that supports it. Also take care of everything on the TODO list.

[pulmark]

Hi !

Thanks for your advice! I installed bc and get rid of those 'unable to execute bc' errors. How ever I still have following assert() error:

addremove: check/alloc/addremove.c:64: main: Assertion `p == &allocation_packets[i]' failed. runtests.sh: line 13: 19251 Aborted (core dumped) $1

My computer is HP Elitebook 8460p. OS is Linux OpenSuse Tumbleweed, x86_64, Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz.

Linux kernel: 4.18.15-1-default #1 SMP PREEMPT Thu Oct 18 08:56:17 UTC 2018 (5a53676) x86_64.

Attached you will find detailed information of my system, output of uname -a, lscpu commands as well as 'make check and make bench' cmd outputs.

About the hebimath, I'm considering to test and possible use it as a replacement for GNU MP and MPIR libaries.

Do you have any experience how fast hebimath is compared to those libraries ? My app does a lot of basic bignum arithmetic with long integers like 2048 bit and it needs to be fast.

Best Regards,

• Markku

running check tests

check/alloc/valid check/alloc/query check/alloc/addremove addremove: check/alloc/addremove.c:64: main: Assertion `p == &allocation_packets[i]' failed. runtests.sh: line 13: 19251 Aborted (core dumped) $1 check/alloc/fixed check/p/pcmp check/p/pcopy check/p/pmove check/p/pnorm check/p/pzero check/p/negnot check/p/strings check/z/getset check/z/shift check/z/zcmp check/z/zcmpmag check/z/zcmpi check/z/zcmpu check/z/zabs check/z/zneg check/z/zadd check/z/zaddmag check/z/zaddi check/z/zaddu check/z/zsub check/z/zsubmag check/z/zsubi check/z/zsubu check/z/zmul check/z/zmuli check/z/zmulu check/z/zdiv check/z/zdivi check/z/zdivu check/z/zdivrem check/z/zrem check/z/zremi check/z/zremu check/z/zsqr check/z/znot check/z/zand check/z/zor check/z/zxor

all done

Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 42 Model name: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Stepping: 7 CPU MHz: 1189.409 CPU max MHz: 3400.0000 CPU min MHz: 800.0000 BogoMIPS: 5388.09 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 4096K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d

Linux linux-1hz6 4.18.15-1-default #1 SMP PREEMPT Thu Oct 18 08:56:17 UTC 2018 (5a53676) x86_64 x86_64 x86_64 GNU/Linux

running bench tests

bench/p/padd 0.49489915 seconds 1333163355 cycles bench/p/paddu 0.35208627 seconds 948452415 cycles bench/p/pclz 0.28267302 seconds 761466267 cycles bench/p/pctz 0.03130600 seconds 84331760 cycles bench/p/pcmp 0.18370391 seconds 494862011 cycles bench/p/pcopy 0.38649048 seconds 1041131476 cycles bench/p/pdivrem 9.92275814 seconds 26730045375 cycles bench/p/pdivremu 2.80525938 seconds 7556840283 cycles bench/p/pmove 0.60950455 seconds 1641888945 cycles bench/p/pmul 6.43515861 seconds 17335106304 cycles bench/p/pmul_karatsuba 1.70007787 seconds 4579688366 cycles bench/p/pmulu 0.61165674 seconds 1647686972 cycles bench/p/pnorm 0.21148709 seconds 569704590 cycles bench/p/pshl 0.64591751 seconds 1739978126 cycles bench/p/pshr 0.51904426 seconds 1398205707 cycles bench/p/psqr 6.32452144 seconds 17037070089 cycles bench/p/psqr_karatsuba 1.66059592 seconds 4473331275 cycles bench/p/psub 0.49964968 seconds 1345959757 cycles bench/p/psubu 0.36310075 seconds 978122987 cycles bench/p/pzero 0.22329756 seconds 601520304 cycles

all done

[suiginsoft]

I tried out OpenSUSE Leap, it didn't repro the issue. I then updated to Tumbleweed and suddenly got the same error as yourself, which is promising. I will attempt to debug and fix it tomorrow.

Hebimath is as fast or faster than GNU MP on most operations for large integers under 4096 bits, but GNU MP is quite a bit faster with dividing and multiplying very large integers due to it using more complex algorithms that scale more efficiently. If you're interested, the author of libzahl put together a benchmark with an older version of Hebimath, GMP and Tom's Fast Math. Since then, Hebimath has borrowed many of the tricks that libzahl used to beat GMP.

Hebimath doesn't try to be fast on older hardware or 32-bit hardware. I'm only interested in implementing modern x86-64 and ARM64 optimized assembly backends.

[suiginsoft]

Turns out the problem was a false positive and is simpler to fix than I thought it might be. Looks like GCC 8.2 now optimizes away that equality checks on return values from functions marked with the malloc function attribute, so all of the assertions on pointers returned from hebi_alloc or hebi_allocfp were being turned into false conditions. I'll get a fix for affected unit test submitted sometime soon.