CADO-NFS on windows

[bsquared]

Originally Posted by jux

I agree with henryzz. CADO lists significant speed increases (2x faster) on their website from version 1.1 to 2.1.

I tested CADO version 2.1.1 last May (scroll down a bit in the thread I linked).

[jux]

Originally Posted by LaurV

It may be normal, depending on the CPU. I had that case on a computer with an i7-2600. Did you run "-tune" command? If not, please do! Usually the crossover is under 105 digits. Running the "-tune" can make the things faster around that point. If the nfs sieving is slow, due to whatever reasons, memory, etc., then the QS became comparatively faster and the crossover point is pushed higher.

You may need to delete the old tuning info from the ini file, before running the new tune.

Also, yafu may revert to SIQS if something wrong with external GNFS files (did you add the correct path to ggnfs executables in yafu.ini?) etc. or if a small factor pops up (which decreases the remaining composite length)

Yes I ran tune(), but I'll run it again just to be safe. I left files from an old factorization in the folder and the number I started with was initially 154 digits but leftover a 113 digit semiprime, so that might have something to do with it.

Edit: tune listed QS/NFS crossover point at 116.5 digits, which doesn't seem right to me. It also crashed with the error "invalid character in str2hexz"

[LaurV]

No, it is not right. A 5-6 digits about doubles the time for QS, and that can't be right. Your NFS is too slow for whatever reason (no idea why, sorry )

[jux]

I suppose I can just change the ini file (I think the second to last number is the crossover point?)

[LaurV]

This will not solve your problem, in case you have one, with the NFS. You will just chose the slower method, in case SIQS is indeed faster in your system. The "-tune" command does not lie, your QS is faster than the NFS at that size. Only I have no freaking idea why.
Maybe heavier guns can ponder here? BB?

[jux]

The tune command may not lie purposely...but a 113 digit number with QS took an hour longer than a 120 digit number with NFS

[LaurV]

Oh...

[jux]

I downloaded the newest version of YAFU and now it lists a more realistic 106.6 digit crossover point.

[Dubslow]

Oh my, yes. Lots of things make more sense now I imagine

[bsquared]

Originally Posted by jux

Yes I ran tune(), but I'll run it again just to be safe. I left files from an old factorization in the folder and the number I started with was initially 154 digits but leftover a 113 digit semiprime, so that might have something to do with it.

Edit: tune listed QS/NFS crossover point at 116.5 digits, which doesn't seem right to me. It also crashed with the error "invalid character in str2hexz"

tune() runs a series of hardcoded numbers and times how long it takes to gather a certain number of relations. Ideally it should be run in a clean folder, or you run the risk of it picking up partial results from previous tune() attempts, which would throw the timing way off and thus skew the regression analysis that is performed at the end.

I can say if that's what happened here, but I would agree that 116 digits seems too high.

[mancoast]

Hello all,

Greetings, this is actually my second post.
I made an account here [mancoast] back in July, but got banned for something?

Originally Posted by jux

Does anyone have pre-compiled binaries for x86-64?

Do you have access to the Intel Compiler?
Using ICC 16 for windows, it is really close!
For a hobby project I required cado-nfs compiled with ICC16 for Xeon Phi operation.
Now with revision 2.2.0 all cado-nfs binaries can be compiled with Intel Compiler 16 on linux for both intel64 and MIC.
This led me to identify gaps including but not limited to:
linux specific threads dependency
linux specific time dependency

I believe that supplying the proper pthreads library will solve that dependency.
the linux specific time dependency will require changes to the code-base.