Search Criteria
Package Details: cado-nfs-git 20240318.a24829267-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/cado-nfs-git.git (read-only, click to copy) |
---|---|
Package Base: | cado-nfs-git |
Description: | Implementation of the Number Field Sieve (NFS) algorithm for factoring integers |
Upstream URL: | http://cado-nfs.gforge.inria.fr/ |
Licenses: | LGPL2 |
Conflicts: | cado-nfs |
Provides: | cado-nfs |
Submitter: | jdetrey |
Maintainer: | AquilaIrreale |
Last Packager: | AquilaIrreale |
Votes: | 4 |
Popularity: | 0.100259 |
First Submitted: | 2015-12-07 12:57 (UTC) |
Last Updated: | 2024-04-04 17:37 (UTC) |
Dependencies (12)
- gmp (gmp-hgAUR)
- hwloc
- python (python37AUR, python311AUR, python310AUR)
- sqlite (sqlite-fossilAUR)
- cmake (cmake-gitAUR) (make)
- curl (curl-quiche-gitAUR, curl-http3-ngtcp2AUR, curl-c-aresAUR, curl-gitAUR) (make)
- git (git-gitAUR) (make)
- gmp-ecm (make)
- inetutils (inetutils-gitAUR, busybox-coreutilsAUR) (make)
- curl (curl-quiche-gitAUR, curl-http3-ngtcp2AUR, curl-c-aresAUR, curl-gitAUR) (optional) – for cado-nfs-client.py
- gmp-ecm (optional) – for JL DLP polynomial selection
- perl (perl-gitAUR) (optional) – for bwc.pl
Latest Comments
« First ‹ Previous 1 2 3 4 Next › Last »
gilcu3 commented on 2022-09-24 09:44 (UTC) (edited on 2022-09-24 09:44 (UTC) by gilcu3)
@AquilaIrreale Thank for the fix.
In the current version of the package you are running make install, but not the specific install commands for the executables, so the cado-nfs.py file is not ending up in the global path.
AquilaIrreale commented on 2022-09-23 18:27 (UTC)
@gilcu3 fixed it as you suggested by adding a patch to disable detection of system-installed
fmt
version.I did not have Arch's
fmt
on my system so for me it was already using its own bundled version automatically and I never noticed the incompatibility, so thank you for reporting the issue.gilcu3 commented on 2022-09-21 08:14 (UTC) (edited on 2022-09-21 09:21 (UTC) by gilcu3)
Currently, the package is not building due to an error. A patch like the one mentioned in here It seems to be related to incompatibility with the current version of fmt. Using the bundled one is an option in the original package, so we could take that path
ccorn commented on 2021-08-15 23:16 (UTC) (edited on 2021-08-15 23:17 (UTC) by ccorn)
From what I get to see of CMake files like avx2.cmake, the configuration goes as follows:
-march
.-march
is specified, try adding flags like-mavx2
.HAVE_AVX2
.Thus, Haswell users should find
HAVE_AVX2
defined in theircado_config.h
, but Sandybridge users not.To conclude, both the specified
-march
and the capabilities of the build system limit the available SIMD features: You cannot activate code paths meant for a target architecture more recent than that of your build system.Worse, if you specify an architecture that is incompatible with your build system, then those incompatibilities may lead to failure of the autodetection of even those SIMD features that your build machine actually supports.
Thus, the only safe choices are
-march=sandybridge
,-march=native
for the feature set of the build machine,-march
at all. Compared to-march=native
, this adds more detailed compiler flags, but theHAVE_*
definitions are identical.ccorn commented on 2021-08-15 19:07 (UTC)
I wonder why
_march=haswell
does not result in the definition ofHAVE_AVX2
in (my)cado_config.h
. Does anyone achieveHAVE_AVX2
with_march=native
?ccorn commented on 2021-08-15 18:48 (UTC)
Yes, that matches mine. Interestingly, setting
_march=haswell
on mysandybridge
produces the samecado_config.h
(except for theC*FLAGS
strings of course), but results in incompatible binaries.AquilaIrreale commented on 2021-08-15 18:04 (UTC) (edited on 2021-08-15 18:04 (UTC) by AquilaIrreale)
Ok, so...
x86-64-v4
is clearly too high a target to run on sandybridge CPUs, but on the other hand when I tried to compile it with the lowerx86-64-v2
andx86-64-v3
it just wouldn't build... neither would it if I set the various-msse4.2
,-mavx
etc. manually with the basic-march=x86-64
. From what I readv2
is very similar in terms of capabilities tosandybridge
, andv3
is tohaswell
.About SIMD instructions,
-march=x86-64
does have-msse2
but it seems cado wants the higher stuff. In my trials, it always failed trying to compile intrinsics that relate to the AVX instruction set. Of course as I said, manually enabling-msse4.2
and-mavx
proved no solution.It does compile (and work) with
-march=sandybridge
on my i7 4790K which should be ahaswell
, being the next major architecture right aftersandybridge
it would be strange otherwise... but still... it may be thatsandybridge
is the baseline architecture for this package, being the lowest "phisical" architecture to have AVX andx86-64-v2
not working for some reason.Anyhow, this is the resulting
cado_config.h
, looking about right I thinkccorn commented on 2021-08-15 16:41 (UTC) (edited on 2021-08-15 17:03 (UTC) by ccorn)
They are set somewhere, though the patch superficially suggests otherwise. The configuration produces a file
$srcdir/cado-nfs/build/$USER/cado_config.h
. If you inspect that, you will find that theHAVE_*
macros are set according to your-march
spec. Which is why building with-march=x86-64-v4
can be done on mysandybridge
platform, except that the produced binaries cannot be run there. However, CADO-NFS seems to require some form of SIMD datatype, and themakepkg
default-march=x86-64
apparently provides none, which causes build attempts to fail.Out of curiosity, I'd like to know whether anyone of you can build with
-march=sandybridge
, and how this would change yourcado_config.h
.« First ‹ Previous 1 2 3 4 Next › Last »