[QUOTE=Madpoo;379942]George and I are still working through some migration things like making sure the msieve thing runs when a client reports a factor found (that's on my todo list for today), but so far things are going pretty well.[/QUOTE]

What I mean there was the "IsFactor" thing that runs, not MSieve.

Anyway... turns out that there are a set of 3 DLL's on the old server that are setup as extended procedures...

Unfortunately they are 32-bit DLL's which can't be called from 64-bit SQL. I have the source code but honestly, I'm no programmer. I've tried bringing them in to my Visual Studio 2013 and converting them to a more modern VS solution file... all of that goes fine, but I'm having trouble on the dependencies.

There's one regarding a opends60.lib file that's part of the SQL SDK ,so I grabbed that from 64-bit SQL but I seem to be banging my head against the wall with an error, like I'm just not linking it right.

Any C++ programmers out there want to take a crack at it and help compile three 64-bit DLLs? :smile:

Otherwise my only option is to setup a tiny SQL Express 32-bit version just to host these DLL's, called via a linked server connection on the same box. Kind of messy but it should work in theory.

Or if this is just needed to validate a submitted factor I can give you the cross-platform code that mersenne.ca uses to validate submitted factors. It runs on both Windows and *nix, and supports calling either PARI (and/or yafu on Windows) to validate the factor.

[QUOTE=James Heinrich;380007]Or if this is just needed to validate a submitted factor I can give you the cross-platform code that mersenne.ca uses to validate submitted factors. It runs on both Windows and *nix, and supports calling either PARI (and/or yafu on Windows) to validate the factor.[/QUOTE]

If it helps, this is what the 3 extended procs are:

- "IsFactor" seems to just take the exponent and potential factor as arguments and they're passed into a UDF which just calls the extended proc without doing anything else. Returns 1 if the factor is correct, 0 if not, or -1 if there was an error

- "IsFactorOk" takes other arguments and it's also done on the site through a function that calls the XP. I'm ignorant enough to not know what it's checking, but it's called like this to see, as the comment in the code says, if the factor is P=1195 for example is consistent with 1.0, 2 and 1 in the arguments. :)
exec master..XP_IsFactorOK 1.0, 2, 1195, 1, '26537037220992112785174856161239437662001'

- "MSieve" is apparently a wrapper for Msieve factoring code ... pass in a number and it'll spit back 1 if prime, 0 if composite, or -1 if error. The UDF the site uses to call it has logic to call it in a loop, so the UDF there does make good sense as opposed to calling the XP directly.

I mention the use of UDF calling the XPs because... I went ahead and setup a 32-bit install of SQL Express and put the extended procs on there, and created a linked server. From the main SQL server I can call the remote XP just fine and it works. But if I adjust the UDF to call a remote function... SQL doesn't allow that. Says "Remote function calls are not allowed within a function."

So at this point I could use this hacky 32-bit thing and update the way the website checks by making it directly call the remote XP instead of using the UDF, but that wouldn't work so well for the msieve function with it's other block of logic...

I could also try turning those into sprocs instead of udfs which I think can do the remote call (haven't tried though).

My best bet would be getting these things compiled for 64-bit and call it good. I may take a fresh look today now that I'm rested... you know how it is when it's late and the code just won't make sense. :smile:

[QUOTE=James Heinrich;380007]Or if this is just needed to validate a submitted factor I can give you the cross-platform code that mersenne.ca uses to validate submitted factors. It runs on both Windows and *nix, and supports calling either PARI (and/or yafu on Windows) to validate the factor.[/QUOTE]


[strike]Is this portable code callable from PHP? If so, please send it in case we can't get the SQLServer function code working.[/strike] Nevermind: I've got a simple bc replacement.

Any ideas for a PHP interface to msieve (returning an array of factors)?

[QUOTE=Prime95;380020]Is this portable code callable from PHP? If so, please send it in case we can't get the SQLServer function code working.[/quote]It is. I actually already sent the code snippet to [i]Madpoo[/i], I can send it to you as well, although the unedited version is available [url=http://www.mersenne.ca/factorize.inc.php?showsource=1]here[/url] (this version does a quick check of small primes using my SQL table of all primes < 2[sup]32[/sup] but that part is easily deleted).

[QUOTE=Prime95;380020]Nevermind: I've got a simple bc replacement.[/quote]What do you mean by "bc replacement"? Do you mean like a PHP implementation using [url=http://ca1.php.net/manual/en/function.bcmul.php]bcmul[/url] and friends? I'd be curious to see how that compares to my own similar code (that I abandoned due to it being slow and using a ton of memory).

[QUOTE=Prime95;380020]Any ideas for a PHP interface to msieve (returning an array of factors)?[/QUOTE]My code will return an array of factors using PARI/GP. I haven't played with msieve but I suspect my code would be easily adapted to call that instead. I can look into it if you want.

[QUOTE=James Heinrich;380029]What do you mean by "bc replacement"? Do you mean like a PHP implementation using [url=http://ca1.php.net/manual/en/function.bcmul.php]bcmul[/url] and friends?[/quote]

Yes. I replaced the SQL extended proc that validates a reported factor actually divides the Mersenne number. Little more than a simple powmod and compare.


[quote]My code will return an array of factors using PARI/GP. I haven't played with msieve but I suspect my code would be easily adapted to call that instead. I can look into it if you want.[/QUOTE]

I got your yafu and pari examples. Thanks. This can replace the SQL extended proc that uses msieve to factor the occasional composite P-1 factor. Since I am not familiar with either PARI or YAFU, do you recommend one over the other?

[QUOTE=Prime95;380030]Yes. I replaced the SQL extended proc that validates a reported factor actually divides the Mersenne number. Little more than a simple powmod and compare.

I got your yafu and pari examples. Thanks. This can replace the SQL extended proc that uses msieve to factor the occasional composite P-1 factor. Since I am not familiar with either PARI or YAFU, do you recommend one over the other?[/QUOTE]

I'm glad George is on to some alternatives... I got some schooling in Visual Studio beyond the normal plinking around I normally do for my job but wasn't any closer to getting it to compile in 64-bit. Some of that was due to other code that ties into it which would have to have been recompiled at 64-bit as well.

Part of all that was digging through old SQL sdks to get the old, unsupported, includes for extended procedures.

Doing these checks in a way that doesn't involve SQL at all is ideal, and really makes it that much more portable to future SQL editions, MySQL, or whatever.

With the implementation of PrimeNet v6, perhaps it might also be a good time to re-benchmark the GHz-day unit to a more modern CPU architecture.

Also, I would assume this probably will spell the end of the v4_computers, if indeed any are still contributing on a regular basis.

[QUOTE=James Heinrich;380029]My code will return an array of factors using PARI/GP. I haven't played with msieve but I suspect my code would be easily adapted to call that instead. I can look into it if you want.[/QUOTE]

I'm 99% there. Thanks, James. The only remaining issue is generating a unique filename for YAFU to write to instead of the fixed siqs.dat.

[QUOTE=NBtarheel_33;380036]With the implementation of PrimeNet v6, perhaps it might also be a good time to re-benchmark the GHz-day unit to a more modern CPU architecture.

Also, I would assume this probably will spell the end of the v4_computers, if indeed any are still contributing on a regular basis.[/QUOTE]

People fought replacing P95-years for a long, long time. I suspect they'd fight changing GHZ-days too.

I'm still getting several DCs a day from v4 computers. It turns out people are still downloading v24 prime95. Apparently, one can still create new v4 user IDs, get work, and report results. There is a PHP script that turns v4 requests into v5 requests, so there is no reason not to continue supporting v4 computers.

[QUOTE=NBtarheel_33;380036]With the implementation of PrimeNet v6, perhaps it might also be a good time to re-benchmark the GHz-day unit to a more modern CPU architecture.

Also, I would assume this probably will spell the end of the v4_computers, if indeed any are still contributing on a regular basis.[/QUOTE]

Apparently there are still V4 results coming in on a daily basis... go figure. There's a PHP script that takes those old incoming calls and converts them or whatever to the correct V5 looking stuff.

That's actually one of the things we need to test out and make sure I set it up correctly.

I wouldn't call this upgrade V6, it's more like V5.5. The client/server communications are unchanged after all. :smile: