Menu
▾
▴
ggnfs-devel — GGNFS Developers list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(39) |
Sep
(27) |
Oct
(2) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
| 2008 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Anton K. <as...@ma...> - 2005-09-06 22:28:56
|
Hello, Brian. You wrote Tuesday, September 6, 2005, 12:56:36 PM: BG> 64-bit limbs) and its performance is really quite good. Really good news! BG> If anyone has an idea of the most critical GMP routines from the GGNFS BG> point of view, I would be pleased to hear what they are since this will BG> help to set my priorities. Maybe, it will be usefull to look into present amd64 patch? -- With best regards, Anton mailto:as...@ma... Wednesday, September 7, 2005 2:34:19 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Jason P. <ja...@bo...> - 2005-09-06 21:48:01
|
> - added comments to the mpqs_choose_parameter() function and it's syntax > changed slightly. > - some unused code has been thrown out. If we're starting to untangle mpqs.c, I've studied it quite a bit and have a few optimizations that would be nice if anyone's interested. This is remarkable (if obscure) code, and I think it can be made better. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Brian G. <br...@gl...> - 2005-09-06 08:56:39
|
Hi All,
This is by way of a progress report on moving the VC++ build of GGNFS
from 32 to 64 bits. Getting GMP to work on 64-bit systems and adding
assembler support is a bigger job than moving GGNFS itself and I have
now made a start on this.
I have a good generic C build of GMP using VC8 in 64-bit mode (i.e using
64-bit limbs) and its performance is really quite good. I also have two
YASM based assembler subroutines working and these give a good speed
increase. I am now working to convert further critical GMP routines into
YASM assembler.
If anyone has an idea of the most critical GMP routines from the GGNFS
point of view, I would be pleased to hear what they are since this will
help to set my priorities.
I apologise to users of VC6 and VC7 since I won't be able to offer any
direct support for 64-bit GMP in these versions of Visual Studio. But
if anyone is determined to use these environemnts for 64-bit Microsoft
based development, I am willing to offer advice on what I have had to do
to get GMP working on the Microsoft compiler for AMD64 and EM64T
systems. This is not straightforward if assembler code is being used as
the calling conventions for the Microsft compiler have to be observed
(which are not the same as those used by GCC on 64-bit systems).
I aim to continue converting more routines into 64-bit assembler over
the next few days and hope to have a VC8 build project for 64-bit GMP
with assembler support available within a week or so.
best regards,
Brian
|
|
From: Anton K. <as...@ma...> - 2005-09-04 09:53:59
|
Hello, everyone. As current CVS version of lattice siever is broken, I'm thinking to introduce "branching". This would be much natural CVS way to operate. New development branch will be created with every new GGNFS snapshot. So, we can easily track, what had been broken, and, even more, always have *confirmed* working code snapshot. Maybe, new branch also should be created while updating some important parts of code (lasieve4, pol5, etc.). Any ideas about all this? -- With best regards, Anton mailto:as...@ma... Sunday, September 4, 2005 1:57:05 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Anton K. <as...@ma...> - 2005-09-03 14:38:36
|
Hello, Everyone. A couple of days ago I've asked SF.net support team to remove some directories in order to reorganize vc build. Unfortunately, "build.vc" directory was wrongly deleted. Please, don't re-create it until I recieve response from SF team. -- With best regards, Anton mailto:as...@ma... Saturday, September 3, 2005 6:43:08 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Brian G. <br...@gl...> - 2005-08-31 16:25:23
|
Hi All, Over the last few days, with help from Sten and Anton, I have been tidying up the VC++ build projects for VC++. The ggnfs builds for VC7 and VC8 (beta) are now in pretty good shape but it has not proved possible to obtain a good build for VC6 because this compiler lacks support for features that many of the GGNFS source files now take for granted. I have not run VC6 for several years and have only been able to support this build by translating the VC7 build files into VC6 format. Sten has VC6 installed but he has not been able to obtain a working build and feels that this is not something that he can afford to invest time in. Hence we either need to drop the VC6 build or find someone who still wants this build and is prepared to repair and maintain it. If there are no volunteers over the next few days, the maintenance of this build project will have to be dropped. The VC++ v7 build is up to date but I will shortly be moving to a new development platform that will not have VC7 installed. Again, therefore, we need volunteers who wish to use the VC7 build of GGNFS to volunteer to maintain it. The mainline development for VC++ GGNFS builds from my perspective will in future be on VC8, where I hope to be able to maintain both win32 and the x64 support. I intend to use YASM as my assembler as this has support for 64-bit architectures. http://www.tortall.net/projects/yasm/ Since this is also NASM compatible the existing NASM based assembler code source files work with no problems. I also intend to take a look at FASM, which also has 64-bit support. http://flatassembler.net/ Both these assemblers have Windows and Linux versions and this means that any dedicated assembler code that is written using these assemblers will be widely available (which is not true if GAS is used). Please let me know if you have any observations on these issues. best regards to all, Brian Gladman |
|
From: Greg C. <jgc...@uk...> - 2005-08-30 17:19:14
|
Hi, I posted this on the Yahoo group, but probably more of the developers are checking this list now. There seems to be a problem with the x86_64 build. snfs_small works, but I get this error when I try to do both tstS1 and rsa100: =>nice -n 19 "/home/childers/ggnfs-amd64/branch_0/bin/procrels" -fb s1.fb -prel rels.bin -newrel spairs.out __________________________________________________________ | This is the procrels program for GGNFS. | | Version: 0.77.1-20050824-k8 | | This program is copyright 2004, Chris Monico, and subject| | to the terms of the GNU General Public License version 2.| |__________________________________________________________| It appears this is not the first run. Setting discFact=-1. done. Monic polynomial: T=-539 + 1X^4 Obtained integral basis: W = 7 0 0 0 0 7 0 0 0 0 1 0 0 0 0 1 denominator = 7 Checking file rels.bin.0 ... Checking file rels.bin.1 ... Largest prel file size is 14545972 versus max allowed of 128000000. Existing file rels.bin.0 13.87MB. New file is 7.69651MB. New file appears to have 94759 relations. Building (a,b) hash table...0.. readRelList : [ 100% done] makeABLookup() : Sorting abList...Done. Before processing new relations, there are 102017 total. Return value 8. Terminating... Unfortunately, I don't have time to diagnose it right now, but I did want to report it. Greg |
|
From: Sten <St...@ma...> - 2005-08-28 18:16:59
|
Hi, Max.
Thank you for the information. I'm not able currently to look at the
thread you pointed as SourgeForge server is down. I'll do it later.
I've done nessesary modifications to the siever-config.h file and now
gnfs-sievers compiles without assembly code.
I have another question related to the 64-bit binaries. First, I'm glad to
announce I've completed the initial steps of converting code so that it can
be compiled under VS 2005 x64 target. I've succeded in factoring snfs_small
number with help of the Win64 binaries.
However, now I'm trying to factor tstS1 number, and I see something
odd. gnfs-lasieve4I12e reports very many warning messages like this:
warning: not enough polynomials in mpqs with <some-big-number>
Is it normal for 64-bit binaries? Have this problem been ever observed
under 64-bit linux compilations or not?
You know, Microsoft's 64-bit compiler is slightly different from Unix
ones - they decided to leave the 'int' type 4 bytes long. And make 'long'
type 8 bytes long. This can lead for us to some unexpected behaviour,
however the problem can be easily avoided by fixed all warning
messaged compilers prints related to inappropriate types convertion
(I'll try to do it later).
And at last, is it worth trying to continue tstS1 factorization or the
warning above points something went wrong?
Sten
M> See thread " [Ggnfs-devel] gnfs-lasieve4e.c: is there a need in asm code?" about this code. It seems to be completely useless.
M> A proper way to disable it is to alter the following block in ppc32/siever-config.h
M> #ifdef __x86_64__
M> #define HAVE_SSIMD
M> #endif
M> Max
M> Sten wrote:
>> There is the following piece of assembly code in the gnfs-lasieve4e.c
>> file. I found I need to convert it to the format compatible with Win64
>> platform. As MS VC 64 bit compiler doesn't support inline assembler,
>> I'm going to place this code into separate file and rewrite it in yasm
>> syntax as Brian suggested.
>>
>> It's not a trouble to convert the code itself, but I need to make a
>> subroutine from it and give it a name. Does anyone happen to know what
>> this code does or at least how should I name it?
>>
>> It seems the code searches for the vector of bytes with every coefficient
>> greater or equar to x_i. May be, some polinominal comparitions?
>>
>> #elif defined(__x86_64__)
>> asm volatile (
>> "movq (%%rax),%%mm7\n"
>> ".align 32\n"
>> "1:\n"
>> "movq (%%rsi),%%mm1\n"
>> "movq 8(%%rsi),%%mm0\n"
>> "pmaxub 16(%%rsi),%%mm1\n"
>> "pmaxub 24(%%rsi),%%mm0\n"
>> "pmaxub %%mm7,%%mm1\n"
>> "pmaxub %%mm1,%%mm0\n"
>> "pcmpeqb %%mm7,%%mm0\n"
>> "pmovmskb %%mm0,%%rax\n"
>> "cmpq $255,%%rax\n"
>> "jnz 2f\n"
>> "leaq 32(%%rsi),%%rsi\n"
>> "cmpq %%rsi,%%rdi\n"
>> "ja 1b\n"
>> "2:\n"
>> "emms":"=S" (i_o):"a"(&x),
>> "S"(i_o), "D"(i_max)
>> );
>>
>> Sten
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Ggnfs-devel mailing list
>> Ggn...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggnfs-devel
>>
>>
|
|
From: Max <re...@un...> - 2005-08-28 07:27:59
|
See thread " [Ggnfs-devel] gnfs-lasieve4e.c: is there a need in asm code?" about this code. It seems to be completely useless. A proper way to disable it is to alter the following block in ppc32/siever-config.h #ifdef __x86_64__ #define HAVE_SSIMD #endif Max Sten wrote: > There is the following piece of assembly code in the gnfs-lasieve4e.c > file. I found I need to convert it to the format compatible with Win64 > platform. As MS VC 64 bit compiler doesn't support inline assembler, > I'm going to place this code into separate file and rewrite it in yasm > syntax as Brian suggested. > > It's not a trouble to convert the code itself, but I need to make a > subroutine from it and give it a name. Does anyone happen to know what > this code does or at least how should I name it? > > It seems the code searches for the vector of bytes with every coefficient > greater or equar to x_i. May be, some polinominal comparitions? > > #elif defined(__x86_64__) > asm volatile ( > "movq (%%rax),%%mm7\n" > ".align 32\n" > "1:\n" > "movq (%%rsi),%%mm1\n" > "movq 8(%%rsi),%%mm0\n" > "pmaxub 16(%%rsi),%%mm1\n" > "pmaxub 24(%%rsi),%%mm0\n" > "pmaxub %%mm7,%%mm1\n" > "pmaxub %%mm1,%%mm0\n" > "pcmpeqb %%mm7,%%mm0\n" > "pmovmskb %%mm0,%%rax\n" > "cmpq $255,%%rax\n" > "jnz 2f\n" > "leaq 32(%%rsi),%%rsi\n" > "cmpq %%rsi,%%rdi\n" > "ja 1b\n" > "2:\n" > "emms":"=S" (i_o):"a"(&x), > "S"(i_o), "D"(i_max) > ); > > Sten > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Ggnfs-devel mailing list > Ggn...@li... > https://lists.sourceforge.net/lists/listinfo/ggnfs-devel > > |
|
From: Sten <St...@ma...> - 2005-08-28 07:18:42
|
There is the following piece of assembly code in the gnfs-lasieve4e.c
file. I found I need to convert it to the format compatible with Win64
platform. As MS VC 64 bit compiler doesn't support inline assembler,
I'm going to place this code into separate file and rewrite it in yasm
syntax as Brian suggested.
It's not a trouble to convert the code itself, but I need to make a
subroutine from it and give it a name. Does anyone happen to know what
this code does or at least how should I name it?
It seems the code searches for the vector of bytes with every coefficient
greater or equar to x_i. May be, some polinominal comparitions?
#elif defined(__x86_64__)
asm volatile (
"movq (%%rax),%%mm7\n"
".align 32\n"
"1:\n"
"movq (%%rsi),%%mm1\n"
"movq 8(%%rsi),%%mm0\n"
"pmaxub 16(%%rsi),%%mm1\n"
"pmaxub 24(%%rsi),%%mm0\n"
"pmaxub %%mm7,%%mm1\n"
"pmaxub %%mm1,%%mm0\n"
"pcmpeqb %%mm7,%%mm0\n"
"pmovmskb %%mm0,%%rax\n"
"cmpq $255,%%rax\n"
"jnz 2f\n"
"leaq 32(%%rsi),%%rsi\n"
"cmpq %%rsi,%%rdi\n"
"ja 1b\n"
"2:\n"
"emms":"=S" (i_o):"a"(&x),
"S"(i_o), "D"(i_max)
);
Sten
|
|
From: Anton K. <as...@ma...> - 2005-08-27 16:06:21
|
Hello, Brian. You wrote Thursday, August 25, 2005, 3:28:14 PM: BG> If we are going to have a configuration include file that is pulled in BG> by ALL source files, which then pulls in system specific include files, BG> I can then abandon this special unistd.h and put all this stuff in the BG> VC++ specific configuration include file. I think, before will be much metter. Also HAVE_DUMMY_H technique can be used. This seems to be necessary, because we have some *.h files (mainly in pol5 and lasieve4 directories) depending on defines. BG> new platforms. I really don't mind which we use but I just hope we agree BG> to use only one of these! Seems, almost everywhere #ifdef is used. So, it will good to continue such use ;) -- With best regards, Anton mailto:as...@ma... Saturday, August 27, 2005 8:09:34 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Dmitri G. <gri...@gm...> - 2005-08-27 12:26:47
|
Max wrote:
>> One of the relations, produced by siever gnfs-lasieve4I13e, crashed
>> procrels. I've tracked that offending relation:
>
> Can you provide input files and commandline options of gnfs-lasieve4I13e
> to reproduce such relation?
Here's the .poly file:
$ cat 2477_53_m1.poly
name: 2477_53_m1
type: gnfs
n:
80007263903506487447161993313547932724114807784403696322198638675441676107547267577660873817684259767120370628188429458260487
#BEGIN POLY #skewness 25782.74 norm 2.07e+17 alpha -6.24 Murphy_E 1.46e-10
c5: 2196720
c4: -160464415860
c3: -4478623061393070
c2: -91163266706857206092
c1: 695557752224275062617159
c0: 12308290508356251800631443196
Y1: 6844409343277
Y0: -515550280094617585982579
M:
37777036912967531453775466117117435224774506481506595142396580653722958894302489872668452597449030896196639247567811032459867
#END POLY
skew: 25782.74
rlim: 5400000
alim: 5400000
lpbr: 27
lpba: 27
mfbr: 51
mfba: 51
rlambda: 2.5
alambda: 2.5
q0: 6025681
qintsize: 100
How to invoke siever:
$ ../../bin/gnfs-lasieve4I13e -k -o spairs_ath.add -v -a 2477_53_m1.poly
FBsize 375096+0 (deg 5), 374361+0 (deg 1)
total yield: 223, q=6025693 (0.04314 sec/rel)
warning: too many relations in mpqs
total yield: 349, q=6025741 (0.04360 sec/rel)
total yield: 480, q=6025777 (0.04387 sec/rel)
0 Special q, 36 reduction iterations
reports: 3098642->463500->410480->85021->48950->33552
Number of relations with k rational and l algebraic primes for (k,l)=:
Total yield: 480
0/0 mpqs failures, 36/17 vain mpqs
milliseconds total: Sieve 7540 Sched 0 medsched 1360
TD 2960 (Init 100, MPQS 140) Sieve-Change 6540
TD side 0: init/small/medium/large/search: 70 460 50 330 550
sieve: init/small/medium/large/search: 230 980 60 2130 570
TD side 1: init/small/medium/large/search: 50 250 100 220 780
sieve: init/small/medium/large/search: 140 790 150 2020 470
The relation is there:
$ grep ,0 spairs_ath.add
204786795,12592:efbbfd,3235,46C9,560F,484727,11:18a01ab,0,1572E5,611,38F,377,335,32B,3,7,B,B,2F,2,2,2,2,5BF1EF
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/
|
|
From: Max <re...@un...> - 2005-08-27 04:43:42
|
Dmitri Gribenko wrote: > One of the relations, produced by siever gnfs-lasieve4I13e, crashed > procrels. I've tracked that offending relation: Can you provide input files and commandline options of gnfs-lasieve4I13e to reproduce such relation? Max |
|
From: Max <re...@un...> - 2005-08-26 20:04:32
|
Dmitri Gribenko wrote:
> Program received signal SIGFPE, Arithmetic exception.
> 0x000000000040703f in addNewRelations5 (prelF=0x7ffffffe8800,
> fName=0x7fffffffe690 "spairs.crash", N=0x7ffffffe8890)
> at procrels.c:1173
> 1173 if (R.b % p) { /* p is always non-zero? */
Ironically we discussed this bug with Anton a couple of days ago. But we didn't decided yet how to handle it.
As a quick fix I suggest to change the "if" above to
if (p && R.b%p)
But I would prefer first to understand a reason of the bug. It may happen that a factor is being found on the stage of sieving.
Max
|
|
From: Dmitri G. <gri...@gm...> - 2005-08-26 16:56:43
|
Hello,
I'm doing GNFS factorization on C125. I'm using Athlon 64 3000+. ggnfs
is from today's CVS.
$ uname -a
Linux gribozavr 2.6.11-custom17aug2005 #1 Wed Aug 17 19:43:04 EEST 2005
x86_64 GNU/Linux
$ cat 2477_53_m1.poly
name: 2477_53_m1
type: gnfs
n:
80007263903506487447161993313547932724114807784403696322198638675441676107547267577660873817684259767120370628188429458260487
#BEGIN POLY #skewness 25782.74 norm 2.07e+17 alpha -6.24 Murphy_E 1.46e-10
c5: 2196720
c4: -160464415860
c3: -4478623061393070
c2: -91163266706857206092
c1: 695557752224275062617159
c0: 12308290508356251800631443196
Y1: 6844409343277
Y0: -515550280094617585982579
M:
37777036912967531453775466117117435224774506481506595142396580653722958894302489872668452597449030896196639247567811032459867
#END POLY
skew: 25782.74
rlim: 5400000
alim: 5400000
lpbr: 27
lpba: 27
mfbr: 51
mfba: 51
rlambda: 2.5
alambda: 2.5
q0: 6800000
qintsize: 200000
One of the relations, produced by siever gnfs-lasieve4I13e, crashed
procrels. I've tracked that offending relation:
$ cat spairs.crash
204786795,12592:efbbfd,3235,46C9,560F,484727,11:18a01ab,0,1572E5,611,38F,377,335,32B,3,7,B,B,2F,2,2,2,2,5BF1EF
$ ../../bin/makefb -rl 5400000 -al 5400000 -lpbr 27 -lpba 27 -3p -of
2477_53_m1.fb -if 2477_53_m1.poly
Making factor base...Generating AFB with norms upto 5400000...
Making algebraic factor base.
Checking p=5321891...(total=370000)
Elapsed time: 104 seconds.
Factor base sucessfully created.
$ ../../bin/procrels -fb 2477_53_m1.fb -newrel spairs.crash -nodfactor
-maxrelsinff 20
__________________________________________________________
| This is the procrels program for GGNFS. |
| Version: 0.77.1-20050824-k8 |
| This program is copyright 2004, Chris Monico, and subject|
| to the terms of the GNU General Public License version 2.|
|__________________________________________________________|
done.
Monic polynomial:
T=286613441869833117932405525655661797422703089909760000 +
7373221954239460177337609488849690655232000X-439915523366964053339526276172800X^2-9838280851423384730400X^3-160464415860X^4
+ 1X^5
Obtained integral basis:
W =
816234293501738496000 0 0 0 148406235182134272000
0 22673174819492736000 7568872026762816000 1259620823305152000
15551334757750579200
0 0 61928260732800 20673200116800 37337540004000
0 0 0 169147440 118012860
0 0 0 0 1
denominator = 816234293501738496000
Checking file rels.bin.0 ...
Largest prel file size is 0 versus max allowed of 128000000.
Warning: Could not stat processed file rels.bin.0. Is this the first run?.
New file is 0.00011MB.
New file appears to have 2 relations.
Building (a,b) hash table...0..makeABList() Failed to open rels.bin.0
for read!
makeABLookup() : Sorting abList...Done.
Before processing new relations, there are 0 total.
Floating point exception
Let's look into it:
$ gdb ../../bin/procrels
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) set args -fb 2477_53_m1.fb -newrel spairs.crash -nodfactor
-maxrelsinff 20
(gdb) r
Starting program: /home/grib/tmp_/ggnfs/bin/procrels -fb 2477_53_m1.fb
-newrel spairs.crash -nodfactor -maxrelsinff 20
__________________________________________________________
| This is the procrels program for GGNFS. |
| Version: 0.77.1-20050824-k8 |
| This program is copyright 2004, Chris Monico, and subject|
| to the terms of the GNU General Public License version 2.|
|__________________________________________________________|
done.
Monic polynomial:
T=286613441869833117932405525655661797422703089909760000 +
7373221954239460177337609488849690655232000X-439915523366964053339526276172800X^2-9838280851423384730400X^3-160464415860X^4
+ 1X^5
Obtained integral basis:
W =
816234293501738496000 0 0 0 148406235182134272000
0 22673174819492736000 7568872026762816000 1259620823305152000
15551334757750579200
0 0 61928260732800 20673200116800 37337540004000
0 0 0 169147440 118012860
0 0 0 0 1
denominator = 816234293501738496000
Checking file rels.bin.0 ...
Largest prel file size is 0 versus max allowed of 128000000.
Warning: Could not stat processed file rels.bin.0. Is this the first run?.
New file is 0.00011MB.
New file appears to have 2 relations.
Building (a,b) hash table...0..makeABList() Failed to open rels.bin.0
for read!
makeABLookup() : Sorting abList...Done.
Before processing new relations, there are 0 total.
Program received signal SIGFPE, Arithmetic exception.
0x000000000040703f in addNewRelations5 (prelF=0x7ffffffe8800,
fName=0x7fffffffe690 "spairs.crash", N=0x7ffffffe8890)
at procrels.c:1173
1173 if (R.b % p) { /* p is always non-zero? */
(gdb) bt
#0 0x000000000040703f in addNewRelations5 (prelF=0x7ffffffe8800,
fName=0x7fffffffe690 "spairs.crash", N=0x7ffffffe8890)
at procrels.c:1173
#1 0x0000000000408c43 in main (argC=8, args=0x7fffffffe848) at
procrels.c:1575
(gdb) p p
$1 = 0
(gdb) quit
The program is running. Exit anyway? (y or n) y
If I remove that relation from spairs.add and reprocess all 3.5M of
relations collected so far, everything works fine.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/
|
|
From: Max <re...@un...> - 2005-08-26 14:02:29
|
Please take into account that I've just renamed all __ppc__ ifdef's (except one truly ppc-specific) to GGNFS_HOST_GENERIC Max Sten wrote: > Hi, Max. > > That is exactly what I'm doing now. I think, if everything goes right > we'll have Win64 binaries soon. > > Sten > >>> I also have ggnfs compiling under VS 2005. Sadly the inline assembler >>> code only handles 32-bit instructions so it is necessary to use a 64-bit >>> assembler to get full 64-bit assembler support. > > M> Generic code (which currently used by ppc and x86_64 builds) > M> does not contain any inline assembler. > M> You can try to compile it first. > > > > |
|
From: Max <re...@un...> - 2005-08-26 13:27:53
|
Brian Gladman wrote: > I also have ggnfs compiling under VS 2005. Sadly the inline assembler > code only handles 32-bit instructions so it is necessary to use a 64-bit > assembler to get full 64-bit assembler support. Generic code (which currently used by ppc and x86_64 builds) does not contain any inline assembler. You can try to compile it first. Max |
|
From: Brian G. <br...@gl...> - 2005-08-26 13:17:11
|
Sten wrote: > I've just added VS 2005 Beta project files to the CVS tree. > These are derived from Brian's VS 2003 solutions files with > some minor modifications. > > VS 2005 has one creat advantage - it does support x64 platform > (unlike MinGW & Cygwin). So, I'm going to investigate how hard > it will be to make ggnfs work on Win64 platform. Hi to All, I also have ggnfs compiling under VS 2005. Sadly the inline assembler code only handles 32-bit instructions so it is necessary to use a 64-bit assembler to get full 64-bit assembler support. The bad news is that MASM64 - the 64bit assembler in VS 2005 - is Microsoft specific and NASM is only 32-bit so neither of these provide support on both VS and GCC platforms. But the good news is that YASM, here: http://www.tortall.net/projects/yasm/ has full 64-bit support. Hence all my VS2005 project files are now based on YASM rather than NASM to help the move to 64-bits. YASM is also available for use with GCC so it will provide a good basis on which to build our 64-bit assembler code that can be used when MinGW and CygWin are ready for this. best regards, Brian |
|
From: Sten <st...@ma...> - 2005-08-26 12:17:01
|
I've just added VS 2005 Beta project files to the CVS tree. These are derived from Brian's VS 2003 solutions files with some minor modifications. VS 2005 has one creat advantage - it does support x64 platform (unlike MinGW & Cygwin). So, I'm going to investigate how hard it will be to make ggnfs work on Win64 platform. Sten |
|
From: Dmitri G. <gri...@gm...> - 2005-08-25 19:11:09
|
Sten wrote:
> I've just commited serveral changes to sqrt sources. Some
> warning messages were eliminated. Also I changed several s32 to s64
> variable definitions to deal with 64-bit portability warnings.
>
> So, it's would be good idea to test new sqrt under 64-bit platform.
> Also, it's worth to try to build sqrt with Cygwin..
I've checked out the latest version from CVS.
$ make x86_64
make[1]: Entering directory `/home/grib/tmp_/ggnfs.orig'
echo "#define GGNFS_VERSION \"0.77.1-20050824-k8\"" > include/version.h
make[2]: Entering directory `/home/grib/tmp_/ggnfs.orig/src'
gcc-3.4 -I. -I.. -I../include -I/usr/local/include -O3 -ffast-math
-funroll-loops -finline-functions -ftracer -fomit-frame-pointer -W -Wall
-march=k8 -mtune=k8 -ftracer -pipe -D__ppc__ -c getprimes.c
getprimes.c: In function `pSieve':
getprimes.c:175: warning: comparison between signed and unsigned
getprimes.c: At top level:
getprimes.c:158: warning: unused parameter 'Psize'
../include/ggnfs.h:586: warning: 'forceStop' defined but not used
gcc-3.4 -I. -I.. -I../include -I/usr/local/include -O3 -ffast-math
-funroll-loops -finline-functions -ftracer -fomit-frame-pointer -W -Wall
-march=k8 -mtune=k8 -ftracer -pipe -D__ppc__ -c fbmisc.c -o fbmisc.o
fbmisc.c: In function `readPoly':
fbmisc.c:88: warning: comparison between signed and unsigned
fbmisc.c: In function `isSmooth_rat':
fbmisc.c:287: warning: comparison between signed and unsigned
fbmisc.c: In function `isSmooth_alg':
fbmisc.c:335: warning: comparison between signed and unsigned
fbmisc.c: In function `generateAFB':
fbmisc.c:378: warning: comparison between signed and unsigned
fbmisc.c: In function `loadFB':
fbmisc.c:581: warning: comparison between signed and unsigned
fbmisc.c:594: warning: comparison between signed and unsigned
fbmisc.c: In function `isSmooth_rat_withInfo_par':
fbmisc.c:711: warning: comparison between signed and unsigned
fbmisc.c: In function `isSmooth_alg_withInfo_par':
fbmisc.c:803: warning: comparison between signed and unsigned
fbmisc.c: At top level:
fbmisc.c:194: warning: unused parameter 'b0'
as -o mulmod32.o mulmod32.s
mulmod32.s: Assembler messages:
mulmod32.s:29: Error: `4(%esp)' is not a valid 64 bit base/index expression
mulmod32.s:30: Error: `8(%esp)' is not a valid 64 bit base/index expression
mulmod32.s:32: Error: `12(%esp)' is not a valid 64 bit base/index expression
make[2]: *** [mulmod32.o] Error 1
make[2]: Leaving directory `/home/grib/tmp_/ggnfs.orig/src'
make[1]: *** [common] Error 2
make[1]: Leaving directory `/home/grib/tmp_/ggnfs.orig'
make: *** [x86_64] Error 2
I looked at the first working x86_64 version and mulmod32.s wasn't
compiled then. I removed mulmod32.o from OBJS in src/Makefile and added
it to OBJS for $(HOST)=x86. All in all, here's a patch. I have
*compiled* (didn't test) `athlon' and `pentium4'.
begin 644 ggnfs_makefile_x86_64_mulmod32.patch
M9&EF9B`M=7(@9V=N9G,N;W)I9R]S<F,O36%K969I;&4@9V=N9G,O<W)C+TUA
M:V5F:6QE"BTM+2!G9VYF<RYO<FEG+W-R8R]-86ME9FEL90DR,#`U+3`X+3(U
M(#$Y.C$T.C0Q+C`P,#`P,#`P,"`K,#,P,`HK*RL@9V=N9G,O<W)C+TUA:V5F
M:6QE"3(P,#4M,#@M,C4@,C$Z,CDZ-3(N,#`P,#`P,#`P("LP,S`P"D!`("TS
M,RPQ,"`K,S,L.2!`0`H@"B!E>'!O<G0@05)#2"!(3U-4($%,3$]05"!#1DQ!
M1U,@1$5"54=/4%0*(`HM3T)*4SUG971P<FEM97,N;R!F8FUI<V,N;R!M=6QM
M;V0S,BYO('-Q=69O9BYO(')E;',N;R!<"BT@("`@("0H3$%.0UI/4RDN;R!P
M;VQY+F\@;7!Z7W!O;'DN;R!M<'I?;6%T+F\@<VUI;G1F86-T+F\@7`HM("`@
M("!M:7-C+F\@96-M-&,N;R!N9FUI<V,N;R!M;VYT9V]M97)Y7W-Q<G0N;R!M
M871S='5F9BYO(%P*+2`@("`@9&EC:VUA;BYO(&9B9V5N+F\@;&QI<W0N;R!I
M9BYO"BM/0DI3/6=E='!R:6UE<RYO(&9B;6ES8RYO('-Q=69O9BYO(')E;',N
M;R`D*$Q!3D-:3U,I+F\@<&]L>2YO(&UP>E]P;VQY+F\@7`HK("`@("!M<'I?
M;6%T+F\@<VUI;G1F86-T+F\@;6ES8RYO(&5C;31C+F\@;F9M:7-C+F\@;6]N
M=&=O;65R>5]S<7)T+F\@7`HK("`@("!M871S='5F9BYO(&1I8VMM86XN;R!F
M8F=E;BYO(&QL:7-T+F\@:68N;PH@"B!"24Y3/20H0DE.1$E2*2]S:65V92`D
M*$))3D1)4BDO<')O8W)E;',@)"A"24Y$25(I+W-Q<G0@)"A"24Y$25(I+W!O
M;'ES96QE8W0@7`H@("`@("`D*$))3D1)4BDO;6%K969B("0H0DE.1$E2*2]M
M871S;VQV92`D*$))3D1)4BDO;6%T8G5I;&0*0$`@+30U+#<@*S0T+#<@0$`*
M(`H@:69E<2`H)"A(3U-4*2QX.#8I"B`@($Q!3D-:3U,]8FQA;F-Z;W,V-`HM
M("!/0DI3*SUM;V1I;G8Q,#`R+E,**R`@3T)*4RL];6]D:6YV,3`P,BYO(&UU
M;&UO9#,R+F\*(&5L<V4*("`@3$%.0UI/4SUB;&%N8WIO<S8T+6YO+6UM>`H@
3("!/0DI3*SUM;V1I;G8S,BYO"@``
`
end
After applying this patch ggnfs compiled and snfs_small factored OK.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/
|
|
From: Sten <st...@ma...> - 2005-08-25 13:27:30
|
I've just commited serveral changes to sqrt sources. Some
warning messages were eliminated. Also I changed several s32 to s64
variable definitions to deal with 64-bit portability warnings.
So, it's would be good idea to test new sqrt under 64-bit platform.
Also, it's worth to try to build sqrt with Cygwin..
I myself compiled sqrt under MinGW and tested it with snfs_small and
tstS1 numbers. It works. So I hope I haven't broken anything. :)
Sten
|
|
From: Brian G. <br...@gl...> - 2005-08-25 11:28:15
|
Sam Chong wrote:
[snip]
> I have been starting to look at what is involved in tidying up all the
> VC++ defines throughout GGNFS and replacing them, where possible, with a
> configuration file of some kind.
>
> But I have run into the issue I mentioned recently, namely that
> _MSC_VER
> is defined in ggnfs.h:
>
> #if defined (__MINGW32__) || defined (MINGW32)
> #define _MSC_VER 1300
> #endif
[snip]
> I asked about this issue on the Yahoo group and no one volunteered any
> information. So I just went ahead and got rid of it. Really the only
> motivation there seemed to be was so that sTime() in src/misc.c would
> compile. <shrug> As a bonus, including gmp.h doesn't emit redefinition
> warnings anymore (it assumes _MSC_VER and __GNUC__ are not both defined).
>
> I've cleaned up the other MINGW32/_MSC_VER linked ifdefs as best as I
> knew how. The snfs_small example still ran, and the non-monic still
> fails the same way, so I think we're good. If I broke anything for
> other platforms I guess we'll find out real soon. :)
Thanks for this Sam (and also Max for a subsequent fix). This is a
great help since I don't now have to worry about breaking other code
when I change code sequences guarded only by _MSC_VER conditionals.
Turning to other things in tidying up, right now I have a 'special'
unistd.h file in the ggnfs.vc build directory that I pull in for the
VC++ build. This contains a series of name changes and includes that are
different on VC++ and Unix/Linux systems. THis is as follows right now:
-------------------------------------------
#ifndef UNISTD_H
#define UNISTD_H
#include "getopt.h"
#define _USE_MATH_DEFINES
#define strtoull _strtoui64
#define popen _popen
#define pclose _pclose
#define vsnprintf _vsnprintf
#define strcasecmp _strcmpi
#ifndef inline
#define inline __inline
#endif
#define asm(x)
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
#endif
-------------------------------------------
If we are going to have a configuration include file that is pulled in
by ALL source files, which then pulls in system specific include files,
I can then abandon this special unistd.h and put all this stuff in the
VC++ specific configuration include file.
This will be good news but we need to set out some names and some
policies for these configuration include files. In particular we need
to decide whether this will always be included before all standard
include files or whether it will be after them.
If it is before them then we can conditionally include or exculde
standard include files based on defines in the config file(s) so that,
for example:
#if !defined(_MSC_VER)
#include <sys/time.h>
#endif
can become:
#if defined(HAVE_SYS_TIME)
#include <sys/time.h>
#endif
If the config file is after the standard includes we can't do this. But
if it is before the standard includes, I frequently then find that
something that needs to be done that mess up the standard include files :-(
The other thing we REALLY need to avoid is the mess seen in GMP in mixing:
#ifdef SYMBOL
...
#endif
and
#if SYMBOL
...
#endif
one being based on symbol definition and the other on its non-zero
value. This causes no end of subtle problems in getting GMP to work on
new platforms. I really don't mind which we use but I just hope we agree
to use only one of these!
best regards to all,
Brian
|
|
From: Max <re...@un...> - 2005-08-25 09:28:18
|
Sam Chong wrote: > If I broke anything for other platforms I guess we'll find out real soon. :) You did actually. Fixed now ;) Max |
|
From: Anton K. <as...@ma...> - 2005-08-25 08:30:55
|
Hello, Max.
You wrote Thursday, August 25, 2005, 6:18:53 AM:
M> I've tested this with gcc and mingw32. Works great.
Yes. Seems so. But there exists some other problem, for example in
modinv1002.S we have:
#if defined (__CYGWIN__) || defined (__MINGW32__) || defined (MINGW32)
call _printf
#else
call printf
#endif
How it can be resolved in the simular way?
--
With best regards,
Anton mailto:as...@ma...
Thursday, August 25, 2005 12:34:59 PM
Faculty of Mathematics & Mechanics, Saint-Petersburg State University
|
|
From: Sam C. <tri...@gm...> - 2005-08-25 07:52:07
|
On 8/24/05, ggn...@li... < ggn...@li...> wrote: > Message: 4 > Date: Wed, 24 Aug 2005 22:36:04 +0100 > From: Brian Gladman <br...@gl...> > Reply-To: br...@gl... > CC: ggn...@li... > Subject: Re: [Ggnfs-devel] Tidying Up the Code >=20 > Hi All, >=20 > I have been starting to look at what is involved in tidying up all the > VC++ defines throughout GGNFS and replacing them, where possible, with a > configuration file of some kind. >=20 > But I have run into the issue I mentioned recently, namely that _MSC_VER > is defined in ggnfs.h: >=20 > #if defined (__MINGW32__) || defined (MINGW32) > #define _MSC_VER 1300 > #endif >=20 > It is also defined at one other point but this one is easy to remove. >=20 > In order to tidy up all the _MSC_VER defines without messing up the > MINGW build, I need understand why this define is needed for MINGW. > Does anyone know specifically why it has to be present? >=20 > I would be most grateful if anyone who uses the MINGW build could > explain this. If not it would be helpful to know what happens on a > MINGW build if this define is removed. >=20 > I need to find and eliminate the reason for this define so that I can be > certain that the ONLY compiler that sees things guarded by _MSC_VER is > the VC++ compiler. Once this has been established I can then start to > tidy up this aspect of the code. >=20 > with best regards, >=20 > Brian >=20 I asked about this issue on the Yahoo group and no one volunteered any=20 information. So I just went ahead and got rid of it. Really the only=20 motivation there seemed to be was so that sTime() in src/misc.c would=20 compile. <shrug> As a bonus, including gmp.h doesn't emit redefinition=20 warnings anymore (it assumes _MSC_VER and __GNUC__ are not both defined). I've cleaned up the other MINGW32/_MSC_VER linked ifdefs as best as I knew= =20 how. The snfs_small example still ran, and the non-monic still fails the=20 same way, so I think we're good. If I broke anything for other platforms I= =20 guess we'll find out real soon. :) --=20 Sam |
