A computation worthy of the name

[fivemack]

ah, sorry:

http://www.chiark.greenend.org.uk/~t.../gnfs-batalov/

is what you want, and you want lasieveAsm64latest-updated16e.zip from under that

[Andi47]

Originally Posted by fivemack

ah, sorry:

http://www.chiark.greenend.org.uk/~t.../gnfs-batalov/

is what you want, and you want lasieveAsm64latest-updated16e.zip from under that

Thanks. I will try them as soon as the postprocessing of 2,1766M finishes.

[Brian Gladman]

Originally Posted by Joe O

Will this help?
10.1 Call stubs for 64-bit conversions

I'm doubtful but it might be possible if the code was structured in a way that supports this approach. But this is unlikely unless it has been planned in advance. Agner uses this technique to write x64 assembler for both environments and I have also done this in my x64 assembler code for some crypographic algorithms.

One thing that might work is if the code was put through M4 to produce raw assembler code since this might produce code that could be converted for Windows with fewer difficulties. But I am not familiar enough with M4 to do this.

[Brian Gladman]

Originally Posted by Brian Gladman

I'm doubtful but it might be possible if the code was structured in a way that supports this approach. But this is unlikely unless it has been planned in advance. Agner uses this technique to write x64 assembler for both environments and I have also done this in my x64 assembler code for some crypographic algorithms.

One thing that might work is if the code was put through M4 to produce raw assembler code since this might produce code that could be converted for Windows with fewer difficulties. But I am not familiar enough with M4 to do this.

Answering my own post, this strategy works quite well and the YASM assembler that I use can handle the resulting code. So all that stands in the way is sorting out what stubs are needed and what other code changes are necessary (I already know that there are quite a few because YASM reports quite a few errors).

It is still a fair bit of work but a lot less than I feared. I don't have time to do it all myself but I would help out as a part of a team effort. In particular all the C prototypes for the assembler functions need to be extracted from the GGNFS code in order to change the calling conventions.

[Batalov]

I can make the .s files by m4, if it would help. I have previously unrolled the loops (which is mostly what m4 does in that code) to find the 16e dicrepancy (for 16e, the loop is unrolled once and actually some registers may be saved, but I didn't figure it out, ...but I found a wrong instruction right then). I don't really know this assembly dialect at all!

[Brian Gladman]

Originally Posted by Batalov

I can make the .s files by m4, if it would help. I have previously unrolled the loops (which is mostly what m4 does in that code) to find the 16e dicrepancy (for 16e, the loop is unrolled once and actually some registers may be saved, but I didn't figure it out, ...but I found a wrong instruction right then). I don't really know this assembly dialect at all!

Thank you for the offer, which I appreciate, but I have already done this bit, which turned out to be easy. My version of M4 does however give some errors so it may well be useful to have alternative conversions. Some of the M4 output files for unrolling loops are huge so I may ask for just a part of some of these files. A positive note is that YASM gives just one error on a 50 Mbyte source file output by M4.

The hard bit is making the changes for the different calling conventions and the bit here that is needed as a starting point is the concise documentation of all the C prototypes for every function implemented in the assembler code. Unfortunately the few I have looked at have a lot of parameters, which is the more difficult conversion scenario.

[Batalov]

Right, once you have m4, it takes no effort.
We could exclusively concentrate on 16e (.s files will be miniscule) and 15e (the prototypical small unroll for later). Then all others.
One thing that I've personally gotten to appreciate only very late was that all comments are in the .w files. I've even spent some time with 'cmagle' (or ctangle not to skip comments), but didn't get it to a good readable state.

And remember, there were the new sources contributed by Thorsten via Alex. I've decided to compile all relevant threads in one place, again:
SourceForge
http://mersenneforum.org/showthread.php?t=11660
http://mersenneforum.org/showthread.php?t=11430
http://mersenneforum.org/showthread.php?t=11160


(all divisible by 10! coincidence? I don't think so. )

[Batalov]

Originally Posted by Batalov

I figured that the deposition site is going to be the same fivemack.dyndns.org, M941/ directory.
...and there goes the first pancake.
R67-68M.bz2 2,122,258 relns (of which 3,659 are duplicates)
Sieved in 2.0Ms on Phenom940.

No problems with 16e found; there's no yield dip and there were no badscheds. Same for 67M-a which is almost finished.

Planted the A67-68M.bz2 as well. All files are raw (duplicates not removed). Local duplication (in 1Mq windows) is very low but I checked it again: in this one 2,156,943 relations (of which are 3,590 duplicates).
Note: Two raw files combined produced 18,196 duplicates (and 4.21M unique); with more data duplication starts to show.

Here's an interesting bit. When counted in 2Kq bins, we get on average 4200 relations, but look at the deviation patterns:

Algebraic side has about 2.5x rmsd of the rational side.
Just a note about difficulties of estimates in small -a intervals. (Incidentally, I am preparing an sfns project with -a side sieving and this property was important for me to remember.)

-S

[bsquared]

Originally Posted by Batalov

Algebraic side has about 2.5x rmsd of the rational side.
Just a note about difficulties of estimates in small -a intervals. (Incidentally, I am preparing an sfns project with -a side sieving and this property was important for me to remember.)

-S

I've seen this in every snfs job I've done which sieved on the algebraic side... makes for more difficult jobsize estimation, yes.

[fivemack]

61-62 finished both sides. 2212705+2127775 relations, 2.6M+2.7M seconds (1s/r on core2 hardware at around 3GHz, 1.4s/r on K8/2400 in a 2x2-core system, 1.3s/r on K8/2200 in a single-socket system)

[Batalov]

finished A68-69M, too. Again 2.0Ms on k10/3000.
The duplicates count is:
2,137,457 raw = 2,133,980 unique + 3478 duplicate.