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: Derkinderen B. <Bra...@st...> - 2005-12-30 19:29:19
|
Hi, =20 =20 I'm a student in informatics at the Universiteit Antwerpen. I'm working = on a thesis concerning factorization. I've been testing ggnfs, and when I ran the polynomial selection for = rsa704 I received the following error: =20 a5_begin smaller than 729873550965715782103580220063744.000000 Return value 256. Terminating... Could you tell me what this means and how I can fix this? Or is there an explanation somewhere about how to determine the = parameters for the .poly file manually? I'm not very familiar with the gnfs algorithm, so I don't really know = what these parameters mean exactly. =20 =20 yours sincerely, Bram Derkinderen |
|
From: Sam C. <tri...@gm...> - 2005-10-03 13:06:14
|
No, but it seems to be related to GCC 3.4. If HAVE_FLOAT64 and HAVE_ASM_INTEL are both defined, putting even -O1 in CFLAGS will break the compiled executable in a strange way I have not debugged, and this happens on Linux as well as MinGW. This occurs with GCC 3.4.2 and 3.4.4, and does not occur with GCC 3.3.6. And if we define HAVE_ASM_INTEL but do not use HAVE_FLOAT64, the rsa512_pol= 5 test fails. pol51m0b should find 3 polynomials: 28172400 1431689581421081 207899046817573037944003980721 28200000 14507315380338583 207858335743926583066618629796 28788360 277876585108001 207001685830582539787623092532 but instead finds only 2, omitting the one with leading coefficient 28200000. This happens to be the only polynomial that produces output in pol51opt.... -- Sam On 10/3/05, Anton Korobeynikov <as...@ma...> wrote: > > Hello, Sam. > > You wrote Saturday, October 1, 2005, 3:59:04 PM: > > SC> The most correct behavior is with HAVE_FLOAT64, and no optimization. > Ok. Lat it be so, but have you found the reason of such operation? > > -- > With best regards, > Anton mailto:as...@ma... > > Monday, October 3, 2005 10:38:12 AM > > Faculty of Mathematics & Mechanics, Saint-Petersburg State University > > > |
|
From: Sam C. <tri...@gm...> - 2005-10-02 19:14:14
|
On 9/30/05, Anton Korobeynikov <as...@us...> wrote: > > Update of /cvsroot/ggnfs/branch_0/src/pol5 > In directory > sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1006/branch_0/src/pol5 > > Modified Files: > Makefile pol51m0b.c pol51m0n.c > Log Message: > * Some small fixes for make 3.80 > * Disabled HAVE_FLOAT64 under Mingw. This problem really needs to be > investigated. > > Index: pol51m0n.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvsroot/ggnfs/branch_0/src/pol5/pol51m0n.c,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -C2 -d -r1.13 -r1.14 > *** pol51m0n.c 19 Sep 2005 09:46:16 -0000 1.13 > --- pol51m0n.c 30 Sep 2005 18:40:51 -0000 1.14 > *************** > *** 27,32 **** > /* We need to write a floorl() for Cygwin. In the meantime: */ > /* MinGW may use HAVE_FLOAT64, as long as we compile with -O0 (at least > for > ! gcc 3.4) */ > ! #if defined(__CYGWIN__) > #undef HAVE_FLOAT64 > #endif > --- 27,33 ---- > /* We need to write a floorl() for Cygwin. In the meantime: */ > /* MinGW may use HAVE_FLOAT64, as long as we compile with -O0 (at least > for > ! gcc 3.4) This needs to be investigated, so, undefined here. > ! */ > ! #if defined(__CYGWIN__) || defined(__MINGW32__) > #undef HAVE_FLOAT64 > #endif > It's actually just as much a bug to enable HAVE_INTEL_ASM and disable HAVE_FLOAT64. If you use these options, pol51m0b will not find the correct polynomials in the rsa512_pol5 test regardless of optimization level. The most correct behavior is with HAVE_FLOAT64, and no optimization. -- Sam |
|
From: Sten <st...@ma...> - 2005-09-22 09:32:55
|
Hi, Anton.
In fact, that is not strange. As far as I know, Microsoft always
optimizes it's binaries for size rather than for speed. They say,
that code smaller in size has more chances to fit into processor
cache so it runs faster in many cases.
And another point of view from John Robbins, Debugging Applications
(/O1 switch tells Microsoft's compiler to optimize for size):
"However, Microsoft builds all its commercial applications with /O1,
and that's what you should be using. What Microsoft has found is that
after picking the best algorithm and writing tight code, avoiding page
faults can help speed up your application considerably. As I've heard
it said, "Page faults can ruin your day!"
But page fauls explanation may not be applicable in our case since our
code segment size is not as big as in Microsoft applications. ;)
I tried -O2 and even -O0 but found these switches do not give the
perfomance inprovement. Certainly it worth to try another minor
switches, but I haven't yet found anything giving considerable
speedup.
Sten
S>> I found that changing the -O3 compiler switch to the -Os restores
S>> lattice siever speed to the nearby 01 Sep level.
AK> Hmm. Really strange. From gcc documentation:
AK> `-Os'
AK> Optimize for size. `-Os' enables all `-O2' optimizations that do
AK> not typically increase code size. It also performs further
AK> optimizations designed to reduce code size.
AK> `-Os' disables the following optimization flags:
AK> -falign-functions -falign-jumps -falign-loops
AK> -falign-labels -freorder-blocks -fprefetch-loop-arrays
AK> Maybe, it's worth to try -O2?
AK> Also, I want to experiment with different flags to check, which ones
AK> should be used...
|
|
From: Anton K. <as...@ma...> - 2005-09-21 12:39:29
|
Hello, Sten.
You wrote Wednesday, September 21, 2005, 4:01:48 PM:
S> I found that changing the -O3 compiler switch to the -Os restores
S> lattice siever speed to the nearby 01 Sep level.
Hmm. Really strange. From gcc documentation:
`-Os'
Optimize for size. `-Os' enables all `-O2' optimizations that do
not typically increase code size. It also performs further
optimizations designed to reduce code size.
`-Os' disables the following optimization flags:
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks -fprefetch-loop-arrays
Maybe, it's worth to try -O2?
Also, I want to experiment with different flags to check, which ones
should be used...
--
With best regards,
Anton mailto:as...@ma...
Wednesday, September 21, 2005 4:42:35 PM
Faculty of Mathematics & Mechanics, Saint-Petersburg State University
|
|
From: Sten <st...@ma...> - 2005-09-21 12:01:25
|
Hi All. I found that changing the -O3 compiler switch to the -Os restores lattice siever speed to the nearby 01 Sep level. Currently on my P4 2.6 Ghz Northwood CPU code I observe performance degradation in about 0.0005 - 0.0006 sec/rel comparated to the 01 Sep version of the siever. This is caused by new mpqs.c - maybe new variable types I assigned are reason of this slowdown, maybe some other changes. But I think this is not cricical and we can dial with mpqs.c later. It would be interesting to know how the -Os switch affects other platforms (I was testing on MinGW pentium4 target). Sten |
|
From: Sten <st...@ma...> - 2005-09-20 15:37:30
|
Hi, Anton.
It seems to me I finally tracked down performance degradation issue.
Surprisingly, it is -DNDEBUG switch in the ./src/makefile guilty. At
least on MinGW builds it slowdowns the lattice siever in 150-200%.
I made clean Sep 01 checkout and after many experiments added -DNDEBUG
switch to the make file. And found it became slower. I have no ideas
why it happens. Release builds are supposed to be faster than debug
ones.. :)
I'm going to make some experiments with latest sources - delete NDEBUG
definiton and change assert() statements to something that depents on
let's say GGNFS_NDEBUG macro.
If this is going to work I have no other objections to about new snapshot.
Sten
AK> Hello, Everyone.
AK> Some hours ago I've thought about new snapshot... But, Sam has just been
AK> pointed, that lattice siever is as half speed as Sep 01 version. Are
AK> there any other issues preventing (by your opinion) from new snapshot?
|
|
From: Anton K. <as...@ma...> - 2005-09-19 07:48:08
|
Hello, Everyone. Some hours ago I've thought about new snapshot... But, Sam has just been pointed, that lattice siever is as half speed as Sep 01 version. Are there any other issues preventing (by your opinion) from new snapshot? -- With best regards, Anton mailto:as...@ma... Monday, September 19, 2005 11:52:41 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Anton K. <as...@ma...> - 2005-09-19 07:46:02
|
Hello, Everyone. I would like to say, that new developer have just joined GGNFS development team. His name is Austin Lobo. He is an author of parallel implementation of block Wiedemann algorithm called "WLSS2". He kindly agreed to adopt his codebase to GGNFS needs, so, I hope, we'll get some improvement in the matrix step soon. -- With best regards, Anton mailto:as...@ma... Monday, September 19, 2005 11:49:02 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Anton K. <as...@se...> - 2005-09-19 07:41:56
|
Hello trilliwig, Monday, September 19, 2005, 11:30:59 AM, you wrote: t> Weren't we supposed to start different CVS branches for the stable and t> development versions of code? Keeping two codestreams is nice for t> just these situations.... I've already thought about it. And already sent e-mail to ggnfs-devel list for some 2-3 weeks ago. I'm just waiting for some "stability" in order to actually introduce branches & version tags. BTW, maybe it'w worth to isolate the code, which causes siever to degrade performance? -- Best regards, Anton mailto:as...@se... In God we trust. Everyone else we are verifying with PGP. |
|
From: Anton K. <as...@ma...> - 2005-09-17 11:10:50
|
Hello, Sam. You wrote Saturday, September 17, 2005, 11:29:55 AM: SC> Hi Tom. Could you try adding at the end of line 17 of src/if.h SC> || defined(DARWIN) Maybe, it's worth to use SF Compile Farm? Seems, PowerPC platfrom running Darwin is available there. -- With best regards, Anton mailto:as...@ma... Saturday, September 17, 2005 3:16:43 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Sam C. <tri...@gm...> - 2005-09-17 07:30:05
|
On 9/16/05, ggn...@li... < ggn...@li...> wrote: > Date: Fri, 16 Sep 2005 06:49:45 -0700 (PDT) > From: Tom Cage <k5...@ya...> > To: Sten <ggn...@li...> > Subject: [Ggnfs-devel] x86_64 success ... >=20 > Lastly, trying my Apple Titanium laptop, > first, changing src/Makefile from > ALLOPT=3D-march=3D$(ARCH) -ftracer -pipe > to > ALLOPT=3D-mtune=3D$(ARCH) -ftracer -pipe > then > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ uname -a > Darwin g4-867.local 8.2.0 Darwin Kernel Version 8.2.0: > Fri Jun 24 17:46:54 PDT 2005; > root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh > powerpc > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ make ppc_7450 > echo "#define GGNFS_VERSION \"0.77.1-20050910-7450\"" > > include/version.h > gcc -I. -I.. -I../include -I/usr/local/include -O3 > -ffast-math -funroll-loops -finline-functions > -fomit-frame-pointer -W -Wall -mtune=3D7450 -ftracer > -pipe -DGGNFS_HOST_GENERIC -o getprimes.o -c > getprimes.c > | > | > | > clsieve.c: In function 'fillSieve': > clsieve.c:1922: warning: 'new_update$logp' is used > uninitialized in this function > clsieve.c:1922: warning: 'new_update$logp' is used > uninitialized in this function > clsieve.c:1922: warning: 'new_update$logp' is used > uninitialized in this function > clsieve.c:1922: warning: 'new_update$logp' is used > uninitialized in this function > /usr/bin/ld: Undefined symbols: > _getline > collect2: ld returned 1 exit status > make[2]: *** [../bin/sieve] Error 1 > make[1]: *** [common] Error 2 > make: *** [ppc_7450] Error 2 > g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ > which failed. >=20 Hi Tom. Could you try adding at the end of line 17 of src/if.h || defined(DARWIN) ? --=20 Sam |
|
From: Tom C. <k5...@ya...> - 2005-09-16 13:49:51
|
Good Morning Sten,
>Can you look into redu2.c source file if <limits.h>
file is included
>there. May be developer CVS server and public
anominous one were not
>syncronized when you uptated GGNFS.
>
>If limits.h is not included try to update GGNFS again
or just add
>
>#include <limits.h>
I just ran cvs update and redu2.c in branch_0 is
#include <math.h>
#include "lasieve.h"
Thus, I added
#include <limits.h>
Beginning with Window2000/Cygwin current(today)
Administrator@gateway2000 /home/k5gj/ggnfs_cvs_050916
$ make pentium4
compiled correctly.
Moving to one of my Amd64 Fedora Core 4 current(today)
[root@localhost ggnfs_cvs_050916]# uname -a
Linux localhost.localdomain 2.6.12-1.1447_FC4 #1 Fri
Aug 26 20:35:25 EDT 2005 x86_64 x86_64 x86_64
GNU/Linux
[root@localhost ggnfs_cvs_050916]#
[root@localhost ggnfs_cvs_050916]# make x86_64
make[1]: Entering directory
`/home/k5gj/ggnfs_cvs_050916'
echo "#define GGNFS_VERSION \"0.77.1-20050910-k8\"" >
include/version.h
make[2]: Entering directory
`/home/k5gj/ggnfs_cvs_050916/src'
gcc -I. -I.. -I../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=k8 -ftracer -pipe
-DGGNFS_HOST_GENERIC -o getprimes.o -c getprimes.c
|
|
|
pol51opt.c:907: warning: comparison between signed and
unsigned
pol51opt.c:909: warning: comparison between signed and
unsigned
pol51opt.c:915: warning: comparison between signed and
unsigned
pol51opt.c:916: warning: comparison between signed and
unsigned
gcc -I.. -I../../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=k8 -ftracer -pipe
-DGGNFS_HOST_GENERIC -o ../../bin/pol51opt pol51opt.o
../if.o zeit.o fnmatch.o primes.o assess.o roots.o
-L/usr/local/lib -lm -lgmp
make[3]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916/src/pol5'
strip ../bin/sieve ../bin/procrels ../bin/sqrt
../bin/polyselect ../bin/makefb ../bin/matsolve
../bin/matbuild
make[2]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916/src'
make[1]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916'
[root@localhost ggnfs_cvs_050916]#
which worked correctly.
Moving to an AthlonXP Slackware-10 current(today)
system
root@xp2167:/home/k5gj/ggnfs_cvs_050916#
root@xp2167:/home/k5gj/ggnfs_cvs_050916# uname -a
Linux xp2167 2.4.31 #6 Sun Jun 5 19:04:47 PDT 2005
i686 unknown unknown GNU/Linux
root@xp2167:/home/k5gj/ggnfs_cvs_050916#
root@xp2167:/home/k5gj/ggnfs_cvs_050916#
root@xp2167:/home/k5gj/ggnfs_cvs_050916# make athlon
make[1]: Entering directory
`/home/k5gj/ggnfs_cvs_050916'
echo "#define GGNFS_VERSION
\"0.77.1-20050910-athlon-xp\"" > include/version.h
make[2]: Entering directory
`/home/k5gj/ggnfs_cvs_050916/src'
gcc -I. -I.. -I../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=athlon-xp
-ftracer -pipe -o getprimes.o -c getprimes.c
|
|
|
pol51opt.c: In function `pol_expand':
pol51opt.c:552: warning: implicit declaration of
function `__gmpz_out_str'
pol51opt.c: In function `compute_proj_alpha':
pol51opt.c:907: warning: comparison between signed and
unsigned
pol51opt.c:909: warning: comparison between signed and
unsigned
pol51opt.c:915: warning: comparison between signed and
unsigned
pol51opt.c:916: warning: comparison between signed and
unsigned
gcc -I.. -I../../include -I/usr/local/include -c -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=athlon-xp
-ftracer -pipe -O0 -DHAVE_FLOAT64 -DHAVE_ASM_INTEL
asm_rs.s
gcc -I.. -I../../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=athlon-xp
-ftracer -pipe -O0 -DHAVE_FLOAT64 -DHAVE_ASM_INTEL -o
../../bin/pol51opt pol51opt.o ../if.o zeit.o fnmatch.o
primes.o assess.o roots.o asm_rs.o -L/usr/local/lib
-lm -lgmp
make[3]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916/src/pol5'
strip ../bin/sieve ../bin/procrels ../bin/sqrt
../bin/polyselect ../bin/makefb ../bin/matsolve
../bin/matbuild
make[2]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916/src'
make[1]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916'
root@xp2167:/home/k5gj/ggnfs_cvs_050916#
which also worked correctly.
Moving to a Pentium4 Slackware-10 current(today)
system
root@gateway2000:/home/k5gj/ggnfs_cvs_050916#
root@gateway2000:/home/k5gj/ggnfs_cvs_050916# uname -a
Linux gateway2000 2.4.31 #6 Sun Jun 5 19:04:47 PDT
2005 i686 unknown unknown GNU/Linux
root@gateway2000:/home/k5gj/ggnfs_cvs_050916#
root@gateway2000:/home/k5gj/ggnfs_cvs_050916# make
pentium4
make[1]: Entering directory
`/home/k5gj/ggnfs_cvs_050916'
echo "#define GGNFS_VERSION
\"0.77.1-20050910-pentium4\"" > include/version.h
make[2]: Entering directory
`/home/k5gj/ggnfs_cvs_050916/src'
gcc -I. -I.. -I../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=pentium4 -ftracer
-pipe -DL2_CACHE_SIZE=512 -o getprimes.o -c
getprimes.c
|
|
|
pol51opt.c: In function `compute_proj_alpha':
pol51opt.c:907: warning: comparison between signed and
unsigned
pol51opt.c:909: warning: comparison between signed and
unsigned
pol51opt.c:915: warning: comparison between signed and
unsigned
pol51opt.c:916: warning: comparison between signed and
unsigned
gcc -I.. -I../../include -I/usr/local/include -c -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=pentium4 -ftracer
-pipe -DL2_CACHE_SIZE=512 -O0 -DHAVE_FLOAT64
-DHAVE_ASM_INTEL asm_rs.s
gcc -I.. -I../../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=pentium4 -ftracer
-pipe -DL2_CACHE_SIZE=512 -O0 -DHAVE_FLOAT64
-DHAVE_ASM_INTEL -o ../../bin/pol51opt pol51opt.o
../if.o zeit.o fnmatch.o primes.o assess.o roots.o
asm_rs.o -L/usr/local/lib -lm -lgmp
make[3]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916/src/pol5'
strip ../bin/sieve ../bin/procrels ../bin/sqrt
../bin/polyselect ../bin/makefb ../bin/matsolve
../bin/matbuild
make[2]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916/src'
make[1]: Leaving directory
`/home/k5gj/ggnfs_cvs_050916'
root@gateway2000:/home/k5gj/ggnfs_cvs_050916#
which also worked correctly.
Lastly, trying my Apple Titanium laptop,
first, changing src/Makefile from
ALLOPT=-march=$(ARCH) -ftracer -pipe
to
ALLOPT=-mtune=$(ARCH) -ftracer -pipe
then
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ uname -a
Darwin g4-867.local 8.2.0 Darwin Kernel Version 8.2.0:
Fri Jun 24 17:46:54 PDT 2005;
root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh
powerpc
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$ make ppc_7450
echo "#define GGNFS_VERSION \"0.77.1-20050910-7450\""
> include/version.h
gcc -I. -I.. -I../include -I/usr/local/include -O3
-ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -mtune=7450 -ftracer
-pipe -DGGNFS_HOST_GENERIC -o getprimes.o -c
getprimes.c
|
|
|
clsieve.c: In function 'fillSieve':
clsieve.c:1922: warning: 'new_update$logp' is used
uninitialized in this function
clsieve.c:1922: warning: 'new_update$logp' is used
uninitialized in this function
clsieve.c:1922: warning: 'new_update$logp' is used
uninitialized in this function
clsieve.c:1922: warning: 'new_update$logp' is used
uninitialized in this function
/usr/bin/ld: Undefined symbols:
_getline
collect2: ld returned 1 exit status
make[2]: *** [../bin/sieve] Error 1
make[1]: *** [common] Error 2
make: *** [ppc_7450] Error 2
g4-867:~/Desktop/ggnfs_cvs_050916 k5gj$
which failed.
FWIW, I am at 35N 105W, Amarillo TX USA, which puts us
on
opposite sides of the globe and probably 12 hours
apart.
Tom
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: k5gj <k5...@ya...> - 2005-09-15 20:52:47
|
Hi Sten,
I ran cvs update again this afternoon,
<branch_0/build.vc/vc7/ggnfslib ggnfslib.vcproj,1.1.1.1,1.2 BRG
<brgladman@us...> 1 2005-09-15 11:06>
This compiles correctly under Windows2000/Cygwin current
but fails with a different error under x86_64 FC4.
Tom
Script started on Thu 15 Sep 2005 03:43:09 PM CDT
[root@localhost ggnfs_cvs_050915]# make x86_64
make[1]: Entering directory `/home/k5gj/ggnfs_cvs_050915'
echo "#define GGNFS_VERSION \"0.77.1-20050910-k8\"" >
include/version.h
make[2]: Entering directory `/home/k5gj/ggnfs_cvs_050915/src'
gcc -I. -I.. -I../include -I/usr/local/include -O3 -ffast-math
-funroll-loops -finline-functions -fomit-frame-pointer -W -Wall
-march=k8 -ftracer -pipe -DGGNFS_HOST_GENERIC -o getprimes.o -c
getprimes.c
|
|
|
gnfs-lasieve4e.c: In function `lasieve':
gnfs-lasieve4e.c:652: warning: variable `lastReport' might be
clobbered by `longjmp' or `vfork'
gnfs-lasieve4e.c:662: warning: variable `nr' might be
clobbered by
`longjmp' or `vfork'
gcc -O3 -ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=k8 -ftracer -pipe
-DGGNFS_HOST_GENERIC -I.. -I../../include -I/usr/local/include -c -o
input-poly.o input-poly.c
gcc -O3 -ffast-math -funroll-loops -finline-functions
-fomit-frame-pointer -W -Wall -march=k8 -ftracer -pipe
-DGGNFS_HOST_GENERIC -I.. -I../../include -I/usr/local/include -c -o
redu2.o redu2.c
redu2.c: In function `reduce2':
redu2.c:43: error: `INT_MIN' undeclared (first use in this
function)
redu2.c:43: error: (Each undeclared identifier is reported only once
redu2.c:43: error: for each function it appears in.)
redu2.c:43: error: `INT_MAX' undeclared (first use in this
function)
make[3]: *** [redu2.o] Error 1
rm gnfs-lasieve4eI12.o input-poly.o
make[3]: Leaving directory `/home/k5gj/ggnfs_cvs_050915/src/lasieve4'
make[2]: *** [latsiever] Error 2
make[2]: Leaving directory `/home/k5gj/ggnfs_cvs_050915/src'
make[1]: *** [common] Error 2
make[1]: Leaving directory `/home/k5gj/ggnfs_cvs_050915'
make: *** [x86_64] Error 2
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]# uname -a
Linux localhost.localdomain 2.6.12-1.1447_FC4 #1 Fri Aug 26 20:35:25
EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]# exit
Script done on Thu 15 Sep 2005 03:44:31 PM CDT
|
|
From: Anton K. <as...@ma...> - 2005-09-15 19:11:48
|
Hello, k5gj. You wrote Thursday, September 15, 2005, 5:24:32 PM: k> I ran cvs update and the smintfact.c error at line 628 is still k> there. This can be easily solved by commenting out line 628. Then, k> Cygwin current will correctly compile ggnfs_cvs_current. BTW, Please note, that developers and anonymous CVS are synced within 5-6 hours... -- With best regards, Anton mailto:as...@ma... Thursday, September 15, 2005 11:17:39 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: k5gj <k5...@ya...> - 2005-09-15 13:43:20
|
Hi Sten,
I ran cvs update again,
from src/Makefile
OBJS=getprimes.o fbmisc.o squfof.o rels.o $(LANCZOS).o poly.o
mpz_poly.o \
mpz_mat.o smintfact.o misc.o ecm4c.o nfmisc.o montgomery_sqrt.o \
matstuff.o dickman.o fbgen.o llist.o if.o lasieve4/mpz-ull.o
Tom
Script started on Thu 15 Sep 2005 08:34:42 AM CDT
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]# make x86_64
make[1]: Entering directory `/home/k5gj/ggnfs_cvs_050915'
echo "#define GGNFS_VERSION \"0.77.1-20050910-k8\"" >
include/version.h
make[2]: Entering directory `/home/k5gj/ggnfs_cvs_050915/src'
gcc -I. -I.. -I../include -I/usr/local/include -O3 -ffast-math
-funroll-loops -finline-functions -fomit-frame-pointer -W -Wall
-march=k8 -ftracer -pipe -DGGNFS_HOST_GENERIC -o getprimes.o -c
getprimes.c
|
|
|
fbmisc.o(.text+0x2b9d): In function `isSmooth_rat_withInfo_par':
fbmisc.c: undefined reference to `mpz_set_sll'
fbmisc.o(.text+0x2c15):fbmisc.c: undefined reference to `mpz_set_sll'
fbmisc.o(.text+0x2c5e):fbmisc.c: undefined reference to `mpz_set_sll'
fbmisc.o(.text+0x2ca7):fbmisc.c: undefined reference to `mpz_set_sll'
fbmisc.o(.text+0x2cfd):fbmisc.c: undefined reference to `mpz_set_sll'
fbmisc.o(.text+0x2d4e):fbmisc.c: more undefined references to
`mpz_set_sll' follow
collect2: ld returned 1 exit status
make[2]: *** [../bin/sieve] Error 1
make[2]: Leaving directory `/home/k5gj/ggnfs_cvs_050915/src'
make[1]: *** [common] Error 2
make[1]: Leaving directory `/home/k5gj/ggnfs_cvs_050915'
make: *** [x86_64] Error 2
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]# uname -a
Linux localhost.localdomain 2.6.12-1.1447_FC4 #1 Fri Aug 26 20:35:25
EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
[root@localhost ggnfs_cvs_050915]#
[root@localhost ggnfs_cvs_050915]# exit
Script done on Thu 15 Sep 2005 08:35:42 AM CDT
|
|
From: k5gj <k5...@ya...> - 2005-09-15 13:24:44
|
Hi Sten,
I ran cvs update and the smintfact.c error at line 628 is still
there. This can be easily solved by commenting out line 628. Then,
Cygwin current will correctly compile ggnfs_cvs_current.
/* smintfact.c */
int smallIntFactor(u32 *factors, int *numFactors, mpz_t _t);
int factor_using_pollard_rho (u32 *factors, int *numFactors, mpz_t
n, int a_int);
/* int factor(s32 *factors, mpz_t n, int useTrialDivision); */
line 628
Administrator@gateway2000 /home/k5gj/ggnfs_cvs_050915
$ make pentium4
make[1]: Entering directory `/home/k5gj/ggnfs_cvs_050915'
echo "#define GGNFS_VERSION \"0.77.1-20050910-pentium4\"" >
include/version.h
make[2]: Entering directory `/home/k5gj/ggnfs_cvs_050915/src'
gcc -I. -I.. -I../include -I/usr/local/include -O3 -ffast-math
-funroll-loops -finline-functions -fomit-frame-pointer -W -Wall
-march=pentium4 -ftracer -pipe -DL2_CACHE_SIZE=512 -o getprimes.o -c
getprimes.c
|
|
|
smintfact.c:114: error: conflicting types for 'factor'
../include/ggnfs.h:628: error: previous declaration of 'factor' was
here
make[2]: *** [smintfact.o] Error 1
make[2]: Leaving directory `/home/k5gj/ggnfs_cvs_050915/src'
make[1]: *** [x86common] Error 2
make[1]: Leaving directory `/home/k5gj/ggnfs_cvs_050915'
make: *** [pentiur4] Error 2
Administrator@gateway2000 /home/k5gj/ggnfs_cvs050915
$
I will try x86_64 again in about 1 hour.
Thanks for all of the upgrades.
Tom
|
|
From: Jason P. <ja...@bo...> - 2005-09-12 12:57:17
|
Quoting Sten <St...@ma...>: > So, does anybody know why mpqs_kN_64 has been introduced and how large > numbers does the siever required to be factored? It's would be easy to > eliminate mpqs_kN_64 variable since it is used only in two places. But > I'm not sure if we really need it to be done (since the solution would > be to use mpz_t variable which is slower a bit). Most of the factoring code does not need to deal directly with 96-bit numbers. The sieve is for values of (a*x+b)^2 - kN, where a and b are different for every polynomial, x is the sieve offset (of size +- 2^16) and kN is the number to be factored. For typical choices of a and b this number is of size about kN. However, a and b are chosen so that all sieve values are divisible by a, so that the sieve is over a * (a*x^2+2*b*x+c), where c = (n-b^2)/a and the division is exact. The sieving code can ignore the factor of a in front, so the size of the sieve values is bounded by the size of c. The code can factor numbers for which all values of the quantity in parentheses above fit in 64 bits. The 'optimal' value of 'a' is the one that makes the largest positive sieve value approximately equal the largest negative value in size, so that a should be about sqrt(2*kN)/sieve_size. b is about the size of a, so with sieve_size = 2^16, a is of size ~2^32 if kN is of size ~2^96. This will make c of size ~2^64. So the size limit really is 2^96 for kN. It looks like mpqs_kN_64 is just a helper for the division needed to compute c. This happens once per polynomial, and should not be time-critical. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Sten <St...@ma...> - 2005-09-11 20:09:26
|
Hi All,
I'm glad to announce I finally have made a working Win64 siever.
Just one missing define in siever-config.h (ULL_NO_UL)..
Meantime I have found one strange feature (or bug?) in mpqs.c file.
There is an mpqs_kN_64 variable which is defined as
static u64_t mpqs_kN_64;
As a name suggests, this vairable holds k*N value where N is the
number we are trying to factor and k is multiplication coefficient
(see MPQS description for details).
The strange thing is while mpqs_factor0() function claims it can
factor 96-bit numbers it is obvious that we'll recieve integer
overflow in mpqs_kN_64 for numbers greater that 56-64 bits.
So, does anybody know why mpqs_kN_64 has been introduced and how large
numbers does the siever required to be factored? It's would be easy to
eliminate mpqs_kN_64 variable since it is used only in two places. But
I'm not sure if we really need it to be done (since the solution would
be to use mpz_t variable which is slower a bit).
Sten
|
|
From: Brian G. <br...@gl...> - 2005-09-10 11:29:47
|
Anton Korobeynikov wrote: > Hello, Brian. > > You wrote Saturday, September 10, 2005, 2:29:38 AM: > > BG> might be a bug in one of the routines in the patch which causes GMP to > BG> give wrong results in some fairly rare situations. > Hmm. Pretty interesting, because we have some error relations produced > by 64-bit versions of GGNFS. In fact, they're few, but they exists. > Could you say, where the bug is and we'll try to check it. Hi Anton I now think I am wrong about this. If I go back to the original AMD64 patch in AT&T syntax, the bug is not there. I think what has happened is that a bug got introduced in translating the AT&T syntax into Intel syntax for testing purposes. I will put out a note to the development list when I have double checked this. Brian |
|
From: Brian G. <br...@gl...> - 2005-09-09 22:29:41
|
Hi All, I don't know how many people who are running GGNFS are using GMP with the AMD64 patch but those who are might wish to know that I think there might be a bug in one of the routines in the patch which causes GMP to give wrong results in some fairly rare situations. I found this because I discovered during testing that my own YASM assembly code for AMD64 and the code in the patch sometimes give different results. Although my first reaction was that I must have a bug in my code, it has turned out in all the situations where I have seen different answers, my results have been correct and those from the AMD64 patch have been wrong. I am testing this further at the moment. So anyone who is using the patch and getting wrong results might consider running the generic C code to see if the error is still present. Brian Gladman |
|
From: Jason P. <ja...@bo...> - 2005-09-08 03:24:26
|
Quoting Sten <St...@ma...>: > So, the question is, does the lattice siever need to factor numbers > larger than 96 bits? Probably not. The increased range is for another project. > I do not expect great difficalties in porting the code to 64-bit > platform since it has been done already for Linux. I need to solve > some types convertion problems and that's all I hope. > > It would be nice if you helped me with optimizing/tuning/rewriting mpqs > code. Okay, then I'll do some more development locally and when you've finished the port I'll look into folding in the optimizations. Regarding the performance of my rewritten code, my standard test is the time it takes to factor 2000 random 86-bit numbers. mpqs-hack.c takes a little over 10 seconds, and my code takes 17.5 seconds. Almost 50% of the time is spent determining the factorization of relations, which is probably why using native 64-bit types instead of mpz_t is so much better. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Anton K. <as...@ma...> - 2005-09-07 20:39:14
|
Hello, Jason. You wrote Wednesday, September 7, 2005, 4:41:58 PM: JP> lasieve is the world's least portable lattice siever. ;) Actually seems so ;) JP> I avoided suggesting a rewrite, but doing one would be very satisfying. JP> mpqs implementation has all of the features in mpqs.c and yet is in such a JP> compact package. Maybe, it will be better just try to fix as much compartibility issues as possible? It's hard job, I understand, but the result should be fine. JP> in size. Unfortunately, many of the optimizations in mpqs.c depend on the JP> input being less than 96 bits, so it definitely is slower. If people don't JP> object to reinventing this code, do you want to team up doing the job? Hmm. Will you try it on average factorization in order to make time measurements? -- With best regards, Anton mailto:as...@ma... Thursday, September 8, 2005 12:43:28 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Jason P. <ja...@bo...> - 2005-09-07 12:42:10
|
Quoting Sten <St...@ma...>: > lasieve is really broken when compiled under Win64 target. > I suspend it is mpqs.c code is mainly guilty. At least this code is > known to cause some instabilities into 32-bit builds. > > The code is afwul and I'm trying to rewrite it now. I even looked for > other mpqs implementations but decided it is still easier to rewrite > mpqs.c that we have already. lasieve is the world's least portable lattice siever. I avoided suggesting a rewrite, but doing one would be very satisfying. The code *is* awful, but it's incredibly fast. I don't think any other mpqs implementation has all of the features in mpqs.c and yet is in such a compact package. I have a replacement version that includes a subset of the features in mpqs.c, as well as extensions that let it factor inputs up to about 120 bits in size. Unfortunately, many of the optimizations in mpqs.c depend on the input being less than 96 bits, so it definitely is slower. If people don't object to reinventing this code, do you want to team up doing the job? jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Anton K. <as...@ma...> - 2005-09-06 22:33:17
|
Hello, Jason. You wrote Wednesday, September 7, 2005, 1:47:46 AM: JP> If we're starting to untangle mpqs.c, I've studied it quite a bit and JP> have a few optimizations that would be nice if anyone's interested. JP> This is remarkable (if obscure) code, and I think it can be made better. As it seems to me, lasieve4 now is broken (reported by Sten) for 64-bit VC build. Sten is trying to fix it optimizing "on-the-fly". If you have any improvements, I think, it will be pretty fine to try them. BTW, As reported, we've got some 10-20% speedup comparing with older snapshots just by tuning some compiler flags.... -- With best regards, Anton mailto:as...@ma... Wednesday, September 7, 2005 2:36:15 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
