tuneup: speed_measure() could not get 4 results within 1.0%
There is issue with tune system. I tried to compile from sources and
tune on two laptops, one with intel b950, seconf - i5 (don't remember
exact cpu number), both sandybridge (i5 - with avx).
./configure --enable-cxx
make
make -j1 -C tune tuneup
./tune/tuneup | tee gmp.mparam.h.new
In all cases, when i could see log, when it completes there is some
diagnostic message:
speed_measure() could not get 4 results within 1.0%
$? is usually 0, but...
$ echo ${PIPESTATUS[*]/#/+}
prints +134 +0
second test is found in gentoo gmp ebuild after tuneup; is it really
critical, or rebuilding with such result is still not bad?
Test usually completes in different point, sometimes too close, so one
need to keep all logs together to see the difference.
Last attemt is made with hg clone from 6.1.2 branch (in main branch
tuneup doesn't even build). Last log:
#define GET_STR_PRECOMPUTE_THRESHOLD24
#define SET_STR_DC_THRESHOLD 1391
#define SET_STR_PRECOMPUTE_THRESHOLD 2404
#define FAC_DSC_THRESHOLD 557
#define FAC_ODD_THRESHOLD 24
#define MATRIX22_STRASSEN_THRESHOLD 23
#define HGCD_THRESHOLD speed_measure() could not get
4 results within 1.0% unsorted sorted
0.002976440.00147974is about 0.5%
0.29764 0.14797
0.25665 0.14848
(TL;DR)
Resulting file (gmp.mparam.h.new) doesn't have any diag messages at the
end - last line is just: #define HGCD_THRESHOLD
Previous test is done with release - before to try it, i rebooted,
stoped everything not necessary (DM, cups, NetworkManager, gpm)
It proceeded few more lines before to fail, yet it ends with something
new:
#define MATRIX22_STRASSEN_THRESHOLD 17
#define HGCD_THRESHOLD 112
#define HGCD_APPR_THRESHOLD104
#define HGCD_REDUCE_THRESHOLD 4633
#define GCD_DC_THRESHOLD 492
#define GCDEXT_DC_THRESHOLD379
Oops, can't measure all mpn_jacobi_base methods at 48
System: gentoo (from calculate distro), linux 4.14.19, gcc-6.4.0,
binutils-2.19.1, glibc-2.25.
$ cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 2.10 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 2.10 GHz.
The governor "performance" may decide which speed to
use within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 2.08 GHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
25500 MHz max turbo 4 active cores
25500 MHz max turbo 3 active cores
25500 MHz max turbo 2 active cores
25500 MHz max turbo 1 active cores
Some fields from /proc/cpuinfo:
cpu family : 6
model : 42
model name : Intel(R) Pentium(R) CPU B950 @ 2.10GHz
stepping: 7
microcode : 0x25
cpu MHz : 2023.712
cache size : 2048 KB
...
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Configure unable to recognize mipsisa64r2el triplets
Hi GMP developers:
I'm trying to cross-compile GMP for a MIPS64r2 target. The triple is
mipsisa64r2el-unknow-linux-gnu witch get from config.guess. And the
expected ABI should be ABI=64. However, the ./configure told me that
the only choice of ABI is o32.
After investigate, I discovered that it was caused by ./configure Line
: 4464 mips64*-*-* | mips*-*-irix[6789]*)
Probably it should be mips*64*-*-* | mips*-*-irix[6789]*)
The config.log is attached for reference.
Thanks
--
Jiaxun Yang This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by GNU MP configure 6.1.2, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --prefix=/usr --build=x86_64-aosc-linux-gnu --host=mipsisa64r2el-aosc-linux-gnuabi64 --enable-cxx
## - ##
## Platform. ##
## - ##
hostname = Ry1800X
uname -m = x86_64
uname -r = 4.15.7-aosc-main
uname -s = Linux
uname -v = #1 SMP PREEMPT Mon Mar 5 16:23:37 UTC 2018
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/bin
PATH: /usr/local/sbin
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /usr/bin/site_perl
PATH: /usr/bin/vendor_perl
PATH: /usr/bin/core_perl
PATH: /root/x-tools/mipsisa64r2el-aosc-linux-gnuabi64/bin
## --- ##
## Core tests. ##
## --- ##
configure:3055: checking build system type
configure:3069: result: x86_64-aosc-linux-gnu
configure:3089: checking host system type
configure:3102: result: mipsisa64r2el-aosc-linux-gnuabi64
configure:3139: checking for a BSD-compatible install
configure:3207: result: /bin/install -c
configure:3218: checking whether build environment is sane
configure:3273: result: yes
configure:3332: checking for mipsisa64r2el-aosc-linux-gnuabi64-strip
configure:3359: result: mipsisa64r2el-aosc-linux-gnuabi64-strip
configure:3424: checking for a thread-safe mkdir -p
configure:3463: result: /bin/mkdir -p
configure:3470: checking for gawk
configure:3486: found /bin/gawk
configure:3497: result: gawk
configure:3508: checking whether make sets $(MAKE)
configure:3530: result: yes
configure:3559: checking whether make supports nested variables
configure:3576: result: yes
configure:3705: checking whether to enable maintainer-specific portions of Makefiles
configure:3714: result: no
User:
ABI=64
CC=mipsisa64r2el-aosc-linux-gnuabi64-gcc
CFLAGS=(unset)
CPPFLAGS=-fexceptions
MPN_PATH=
GMP:
abilist=o32
cclist=gcc cc
configure:5689: error: ABI=64 is not among the following valid choices: o32
## ##
## Cache variables. ##
## ##
ac_cv_build=x86_64-aosc-linux-gnu
ac_cv_env_ABI_set=set
ac_cv_env_ABI_value=64
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CC_FOR_BUILD_set=
ac_cv_env_CC_FOR_BUILD_value=
ac_cv_env_CC_set=set
ac_cv_env_CC_value=mipsisa64r2el-aosc-linux-gnuabi64-gcc
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=-fexceptions
ac_cv_env_CPP_FOR_BUILD_set=
ac_cv_env_CPP_FOR_BUILD_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=set
ac_cv_env_CXX_value=mipsisa64r2el-aosc-linux-gnuabi64-g++
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_LT_SYS_LIBRARY_PATH_set=
ac_cv_env_LT_SYS_LIBRARY_PATH_value=
ac_cv_env_M4_set=
ac_cv_env_M4_value=
ac_cv_env_YACC_set=
ac_cv_env_YACC_value=
ac_cv_env_YFLAGS_set=
ac_cv_env_YFLAGS_value=
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=x86_64-aosc-linux-gnu
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=mipsisa64r2el-aosc-linux-gnuabi64
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=mipsisa64r2el-aosc-linux-gnuabi64
ac_cv_path_install='/bin/install -c'
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=gawk
ac_cv_prog_STRIP=mipsisa64r2el-aosc-linux-gnuabi64-strip
ac_cv_prog_make_make_set=yes
am_cv_make_support_nested_variables=yes
## - ##
## Output variables. ##
## - ##
ABI='64'
ACLOCAL='${SHELL} /root/build/gmp-6.1.2/missing aclocal-1.15'
AMTAR='$${TAR-tar}'
AM_BACKSLASH='\'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
AM_DEFAULT_VERBOSITY='1'
AM_V='$(V)'
AR='mipsisa64r2el-aosc-linux-gnuabi64-ar'
AS='mipsisa64r2el-aosc-linux-gnuabi64-as'
ASMFLAGS=''
AUTOCONF='${SHELL} /root/build/gmp-6.1.2/missing autoconf'
AUTOHEADER='${SHELL} /root/build/gmp-6.1.2/missing autoheader'
AUTOMAKE='${SHELL} /root/build/gmp-6.1.2/missing automake-1.15'
AWK='gawk'
CALLING_CONVENTIONS_OBJS=''
CC='mipsisa64r2el-aosc-linux-gnuabi64-gcc'
CCAS=''
CC_FOR_BUILD=''
CFLAGS=''
CPP=''
CPPFLAGS='-fexceptions'
CPP_FOR_BUILD=''
CXX='mipsisa6
Codelets for ToomN1 (for N=2, 3, 4, 6, 8) should be added and here's why. (Also: a significant non-triviality on where cut-off points should be).
It may be possible to eliminate the need for a "basecase" (except for 1x1 limb multiplication, of course) by including codelets for Toom21, Toom31, Toom41, Toom61, Toom81, etc. In many cases, the recursive decompositions done through these codelets will end up falling *back* into the other codelets! A method based on thresholding completely misses both of these features. I included an ASCII picture showing the cut-off points for multiplication that uses Toom11 (O) Toom21 (.) and Toom22 (o). Hopefully the mailer will not cut off the diagram. In some places (:), a balance point between Toom21 and Toom22 is reached. This optimum is taken over *all* splitting points for Toom21 and Toom22, not just midpoints. This diagram is relatively invariant with respect to changes in the cost ratio for addition versus multiplication. Generally it only affects what the cutoff for Toom22 is, not where the thresold between Toom21 and Toom22 lies. You should run a dynamic programming algorithm to compile a table over all of your codelets, just to see where the optimal splits occur. For the cases examined here: all cases of Toom21 optimally cut off at the largest power of 2 smaller than the digit size of the larger numeral. Many cases of Toom22 optimally cut off at a power of 2 or places other than expected; although I didn't indicate in the diagram below where it is. There is some dependency on how the dataflow is carried out with the recursion (particularly the moving back and forth between the numerals and the temporary workspace) but it should not affect the results below significantly. This is something I will try to check against your implementations. The pattern is fractal. The "seeds" of the islands in the diagram below all grow to larger sizes, for each power of 2 size you scale the diagram up by. This picture will get far more complex when the other Toom codelets are added in This should come out as a 128 x 128 table. You may need to run a script to lay it out as such, if the e-mailer messes it up. -- Rock Brentwood O... .o.. ..oo..:. ..oo:... ...::... :... ..:.o... o:.. .:ooo...:... ...:o...:... o... o:.. :...oo.. oo:. ooo. ooo: oo..::...::. ...:oo..::.. .:..:... ...:oo:. ooo. ooo.:... ooo..
Re: Configure unable to recognize mipsisa64r2el triplets
Jiaxun Yang writes: I'm trying to cross-compile GMP for a MIPS64r2 target. The triple is mipsisa64r2el-unknow-linux-gnu witch get from config.guess. And the expected ABI should be ABI=64. However, the ./configure told me that the only choice of ABI is o32. I've never seen "mipsisa64r2el" before. Where do you run config.guess given that you are cross compiling? -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Configure unable to recognize mipsisa64r2el triplets
在 2018-03-28三的 13:04 +0200，Torbjörn Granlund写道： > > > I've never seen "mipsisa64r2el" before. Yes, it's rare. However, according to config.sub from GCC [1], it's not illegal. > > Where do you run config.guess given that you are cross compiling? > I ran it on a LFS rootfs provided by Loongson (A Chinese MIPS64r2 processor). [1]https://github.com/gcc-mirror/gcc/blob/master/config.sub Thanks. -- Jiaxun Yang ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Configure unable to recognize mipsisa64r2el triplets
Jiaxun Yang writes: > I've never seen "mipsisa64r2el" before. Yes, it's rare. However, according to config.sub from GCC [1], it's not illegal. Good! We woudn't want to be gaoled for a CPU moniker! I ran it on a LFS rootfs provided by Loongson (A Chinese MIPS64r2 processor). [1]https://github.com/gcc-mirror/gcc/blob/master/config.sub It seems that GMP's configfsf.sub also has that. Now, I have no idea what it means. Is is just a novel name for mips64r2el or is it somehow a different ABI? If you make the obvious change to configure.ac, then build twice, once with --disable-shared and once with --disable-static, does make && make check run to without any errors. (OK, you told me you were cross compiling, so perhaps that will require some intermediary command. And "make check TESTS=" for just building the tests would perhaps be useful.) -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Configure unable to recognize mipsisa64r2el triplets
在 2018-03-28三的 15:54 +0200，Torbjörn Granlund写道： > Jiaxun Yang writes: > > > I've never seen "mipsisa64r2el" before. > > Yes, it's rare. However, according to config.sub from GCC [1], it's > not > illegal. > > Good! We woudn't want to be gaoled for a CPU moniker! > > I ran it on a LFS rootfs provided by Loongson (A Chinese MIPS64r2 > processor). > > [1]https://github.com/gcc-mirror/gcc/blob/master/config.sub > > It seems that GMP's configfsf.sub also has that. Now, I have no idea > what it means. Is is just a novel name for mips64r2el or is it > somehow > a different ABI? It should be a novel name of mips64r2el. I don't know if mips64r2el is illegal but it doesn't recognize by config.sub . > > If you make the obvious change to configure.ac, then build twice, > once > with --disable-shared and once with --disable-static, does > > make && make check > > run to without any errors. (OK, you told me you were cross > compiling, > so perhaps that will require some intermediary command. And "make > check > TESTS=" for just building the tests would perhaps be useful.) Yes I've tried the tests on a Loongson target system with a native build. After use mips64* instead of mips*64* in configure and set ABI to ABI=64. No error was reported. I'm not sure if this change will break other MIPS systems. But since all MIPS triplets with *64* included should support 64 o32 N32 ABIs, probably it's going to work just fine. > -- Jiaxun Yang signature.asc Description: This is a digitally signed message part ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: tuneup: speed_measure() could not get 4 results within 1.0%
Nikita Zlobin writes: There is issue with tune system. I tried to compile from sources and tune on two laptops, one with intel b950, seconf - i5 (don't remember exact cpu number), both sandybridge (i5 - with avx). We are aware of that tuning of the various GCD thresholds don't work properly. This has been broken for a very long time. I have not spent enough time on it to understand why it does not work. If somebody else could do that, it would be very good. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
