[QUOTE=lorgix;402904 but I think you should be using either -gpucurves 48 or 96.[/QUOTE]

Thank you for your answer, why are those two values the only one I should be using ? I thought the program automatically selects the maximum that the card can handle. On your hardware it may well be 96, but on mine it seems to be 64 and as I said any curve number below 32 gets adjusted to 32. Any number strictly above 32 gets adjusted to 64, so I guess those two values are the only possible ones for me.

Regardless, I would be very glad for information with which I could diagnose the problem further, if there is a problem at all (maybe my card can't handle the provided cudakernel and this behaviour is expected).

I could write to the dedicated mailing list at gforge.inria.fr but I don't want to bother developers if the issue is trivial and an answer can be found here.

[QUOTE=Singularity;403250]Thank you for your answer, why are those two values the only one I should be using ? I thought the program automatically selects the maximum that the card can handle. On your hardware it may well be 96, but on mine it seems to be 64 and as I said any curve number below 32 gets adjusted to 32. Any number strictly above 32 gets adjusted to 64, so I guess those two values are the only possible ones for me.

Regardless, I would be very glad for information with which I could diagnose the problem further, if there is a problem at all (maybe my card can't handle the provided cudakernel and this behaviour is expected).

I could write to the dedicated mailing list at gforge.inria.fr but I don't want to bother developers if the issue is trivial and an answer can be found here.[/QUOTE]
It should select the maximum if you don't tell it otherwise.
I thought GT525M had two "blocks" of 48 cores, but maybe it has three "blocks" of 32 like you say.
From what I can see it has 48 cores per SM, and in my experience that decides what number of concurrent curves makes the most sense. But I'm not 100% on this.

Anybody know how to resolve this error:

[CODE]unresolved external symbol mpn_mul_fft referenced in function __ecm_mpres_mul[/CODE]

It seems to be caused by MPIR not having "mpn_mul_fft" defined or mapped or something. But MPIR works so well on windows.

[QUOTE=wombatman;403386]Anybody know how to resolve this error:

[CODE]unresolved external symbol mpn_mul_fft referenced in function __ecm_mpres_mul[/CODE]

It seems to be caused by MPIR not having "mpn_mul_fft" defined or mapped or something. But MPIR works so well on windows.[/QUOTE]


MPIR does have this function and, since GMP-ECM builds fine with MSVC, this seems to be a problem specific to your build environment. How are you building GMP-ECM?

Building in VS 2012 with MPIR 2.7.0 (also built in VS 2012) as 64-bit using CUDA 7.0.

The definition is supposed to be here: [CODE]#if defined( __MPIR_RELEASE ) && __MPIR_RELEASE >= 20600

#if __MPIR_RELEASE == 20600
#error MPIR 2.6 does not support GMP-ECM, please use an alternative version
#endif
/* WARNING - the following two defintions map the internal interface
of the new FFT in MPIR 2.6 (and later) to the GMP FFT interface -
they work in this context but the parameters for mpn_fft_next_size
and fft_adjust_limbs have different semantics, which means that
these definitions may fail if used in other circumstances
*/
# define mpn_fft_best_k(n, k) (0)
# define mpn_fft_next_size(n, k) fft_adjust_limbs(n)

#else

#define mpn_mul_fft __gmpn_mul_fft
mp_limb_t __gmpn_mul_fft (mp_ptr, mp_size_t, mp_srcptr, mp_size_t, mp_srcptr,
mp_size_t, int);

#define mpn_mulmod_bnm1 __gmpn_mulmod_bnm1
void mpn_mulmod_bnm1 (mp_ptr, mp_size_t, mp_srcptr, mp_size_t, mp_srcptr,
mp_size_t, mp_ptr);

#define mpn_mul_fft_full __gmpn_mul_fft_full
void __gmpn_mul_fft_full (mp_ptr, mp_srcptr, mp_size_t, mp_srcptr, mp_size_t);

#define mpn_fft_next_size __gmpn_fft_next_size
mp_size_t __gmpn_fft_next_size (mp_size_t, int);

#define mpn_mulmod_bnm1_next_size __gmpn_mulmod_bnm1_next_size
mp_size_t mpn_mulmod_bnm1_next_size (mp_size_t);

#define mpn_fft_best_k __gmpn_fft_best_k
int __gmpn_fft_best_k (mp_size_t, int);

#endif[/CODE]

But I think it's not hitting the else like it should?

[QUOTE=wombatman;403536]Building in VS 2012 with MPIR 2.7.0 (also built in VS 2012) as 64-bit using CUDA 7.0.

The definition is supposed to be here: [CODE]#if defined( __MPIR_RELEASE ) && __MPIR_RELEASE >= 20600

#if __MPIR_RELEASE == 20600
#error MPIR 2.6 does not support GMP-ECM, please use an alternative version
#endif
/* WARNING - the following two defintions map the internal interface
of the new FFT in MPIR 2.6 (and later) to the GMP FFT interface -
they work in this context but the parameters for mpn_fft_next_size
and fft_adjust_limbs have different semantics, which means that
these definitions may fail if used in other circumstances
*/
# define mpn_fft_best_k(n, k) (0)
# define mpn_fft_next_size(n, k) fft_adjust_limbs(n)

#else

#define mpn_mul_fft __gmpn_mul_fft
mp_limb_t __gmpn_mul_fft (mp_ptr, mp_size_t, mp_srcptr, mp_size_t, mp_srcptr,
mp_size_t, int);

#define mpn_mulmod_bnm1 __gmpn_mulmod_bnm1
void mpn_mulmod_bnm1 (mp_ptr, mp_size_t, mp_srcptr, mp_size_t, mp_srcptr,
mp_size_t, mp_ptr);

#define mpn_mul_fft_full __gmpn_mul_fft_full
void __gmpn_mul_fft_full (mp_ptr, mp_srcptr, mp_size_t, mp_srcptr, mp_size_t);

#define mpn_fft_next_size __gmpn_fft_next_size
mp_size_t __gmpn_fft_next_size (mp_size_t, int);

#define mpn_mulmod_bnm1_next_size __gmpn_mulmod_bnm1_next_size
mp_size_t mpn_mulmod_bnm1_next_size (mp_size_t);

#define mpn_fft_best_k __gmpn_fft_best_k
int __gmpn_fft_best_k (mp_size_t, int);

#endif[/CODE]

But I think it's not hitting the else like it should?[/QUOTE]

No, that is not the problem, as it shouold NOT take the else branch for MPIR 2.6 and later versions. The missing function declaration (mpn_mul_fft) should be picked up from gmp.h here: [CODE]
#define mpn_mul_fft __MPN(mul_fft)
__GMP_DECLSPEC int mpn_mul_fft __GMP_PROTO((mp_ptr rp, mp_size_t rn, mp_srcptr ap, mp_size_t an, mp_srcptr bp, mp_size_t bn, int k));
[/CODE]

so we need to work out why this declaration is not being seen (or is failing in some way) during the build of GMP-ECM.

I went into my MPIR 2.7.0 folder and found gmp.h. I removed the one in the GMP-ECM VS solution and added that one. That gmp.h doesn't have mpn_mul_fft either.

This is the only bit found when searching gmp.h for "mpn_mul_fft":
[CODE]/**************** MPN API for FFT ****************/
#define mpn_mul_fft_main __MPN(mul_fft_main)
__GMP_DECLSPEC void mpn_mul_fft_main __GMP_PROTO ((mp_ptr r1, mp_srcptr i1, mp_size_t n1, mp_srcptr i2, mp_size_t n2));[/CODE]

[QUOTE=wombatman;403572]I went into my MPIR 2.7.0 folder and found gmp.h. I removed the one in the GMP-ECM VS solution and added that one. That gmp.h doesn't have mpn_mul_fft either.

This is the only bit found when searching gmp.h for "mpn_mul_fft":
[CODE]/**************** MPN API for FFT ****************/
#define mpn_mul_fft_main __MPN(mul_fft_main)
__GMP_DECLSPEC void mpn_mul_fft_main __GMP_PROTO ((mp_ptr r1, mp_srcptr i1, mp_size_t n1, mp_srcptr i2, mp_size_t n2));[/CODE][/QUOTE]

If gmp.h doesn't have a declaration of mpn_mul_fft, something has gone wrong when MPIR was built. During an MPIR build, the files mpir.h and gmp.h are automatically generated from the file gmp_h.in in the MPIR root directory. If gmp_h.in includes the declaation of mpn_mul_fft, (check this, as it should do so), then it seems that the gmp.h and mpir.h files are not being written correctly when MPIR is built. It would make sense to do a completely clean build of MPIR to see if these files are being generated properly.

Will do, and I'll post again when I've had time to do it and see if it works. Thanks for the suggestions.

[STRIKE]Edit: Just checked gmp_h.in from my MPIR 2.7.0 source folder, and it only has the "mpn_mul_fft_main" definition as posted above. The file is showing a last modified date of 4-2-2014. Here's the header:[/STRIKE]

Edit 2: Seems I didn't have a recent enough version. I downloaded the alpha 12 version of 2.7.0 and it has the mpn_mul_fft defined in gmp_h.in. I'll work on rebuilding the GPU-ECM and see it finds everything now.

Edit 3: The mpn_mul_fft unresolved symbols are taken care of. Now I've got [CODE]LNK2001: unresolved external symbol __gmp_bits_per_limb[/CODE] This exists in the gmp.h that's being included, so I'm not sure what the issue is.

[QUOTE=wombatman;403594]Will do, and I'll post again when I've had time to do it and see if it works. Thanks for the suggestions.

[STRIKE]Edit: Just checked gmp_h.in from my MPIR 2.7.0 source folder, and it only has the "mpn_mul_fft_main" definition as posted above. The file is showing a last modified date of 4-2-2014. Here's the header:[/STRIKE]

Edit 2: Seems I didn't have a recent enough version. I downloaded the alpha 12 version of 2.7.0 and it has the mpn_mul_fft defined in gmp_h.in. I'll work on rebuilding the GPU-ECM and see it finds everything now.

Edit 3: The mpn_mul_fft unresolved symbols are taken care of. Now I've got [CODE]LNK2001: unresolved external symbol __gmp_bits_per_limb[/CODE] This exists in the gmp.h that's being included, so I'm not sure what the issue is.[/QUOTE]

The symbol mp_bits_per_limb is redfined as __gmp_bits_per_limb and is supplied in the MPIR file mp_bpl.c The link failure is odd since I don't think this symbol is used by GMP-ECM anyway (maybe I am wrong about this). If It is used it should be possible to use GMP_LIMB_BITS instead.

So to be clear, anywhere "mp_bits_per_limb" is used, I should try substituting GMP_LIMB_BITS? It looks like mp_bits_per_limb only shows up once.

Edit: Felt saucy, so I went ahead and changed the one line where mp_bits_per_limb shows up from [CODE]if (mp_bits_per_limb != GMP_NUMB_BITS)[/CODE] to [CODE]if (GMP_LIMB_BITS != GMP_NUMB_BITS)[/CODE]

This allows it to compile, although it now needs mpir.dll to be present, which I don't remember needing before. Regardless, it also throws a c0000005 exception when trying to use test.gpuecm. Some progress, though!