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: Max <re...@un...> - 2005-08-25 02:23:16
|
Anton Korobeynikov wrote:
> Another one example - GGNFS_ASM_UL. Underscore should be used for
> *all* external names used inside inline assembler under mingw32 &
> cygwin.
Google is our friend. ;)
There is an elegant fix for this problem without introducing any defines.
mult_w (or any other function/object that is required to be accessible from asm) should be defined with asm("mult_w") directive.
So in blanczos64.c we currently have
#if defined( __GNUC__ )
ALIGNED16(u64 mult_w[2048] asm("mult_w"));
#else
ALIGNED16(u64 mult_w[2048]);
#endif
I've tested this with gcc and mingw32. Works great.
Max
|
|
From: Brian G. <br...@gl...> - 2005-08-24 21:36:05
|
Hi All,
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
It is also defined at one other point but this one is easy to remove.
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?
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.
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.
with best regards,
Brian
|
|
From: Dmitri G. <gri...@gm...> - 2005-08-24 15:49:59
|
Sten wrote:
> I've just added 'pentium-m', 'ppc_970' and 'ppc_7450' targets as you
> suggested. I was not able to test ppc_XX targets as my GCC doesn't
> support them. But it should work I hope.
Thanks.
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: Dmitri G. <gri...@gm...> - 2005-08-24 14:10:10
|
Hello,
Here's a patch which adds support for PowerPC 7450 CPU to the top-level
Makefile. I renamed ppc target to ppc_970 and added ppc_7450.
begin 644 ggnfs_makefile_powerpc.patch
M9&EF9B`M=7(@9V=N9G,N;W)I9R]-86ME9FEL92!G9VYF<R]-86ME9FEL90HM
M+2T@9V=N9G,N;W)I9R]-86ME9FEL90DR,#`U+3`X+3(T(#$W.C`S.C0U+C`P
M,#`P,#`P,"`K,#,P,`HK*RL@9V=N9G,O36%K969I;&4),C`P-2TP."TR-"`Q
M-CHU-CHQ,BXP,#`P,#`P,#`@*S`S,#`*0$`@+3<L,3(@*S<L,3,@0$`*(`H@
M8VAO;W-E=&%R9V5T(#H*(`E`96-H;R`B4&]S<VEB;&4@=&%R9V5T<R!A<F4Z
M(@HM"4!E8VAO("()<&5N=&EU;3,@("`@("`@("`@("`@(`D@26YT96P@4&5N
M=&EU;2`S(@HK"4!E8VAO("()<&5N=&EU;3,@("`@("`@("`)($EN=&5L(%!E
M;G1I=6T@,R(*(`E`96-H;R`B"7!E;G1I=6TT("`@("`@("`@("`@("`)($EN
M=&5L(%!E;G1I=6T@-"(*(`E`96-H;R`B"7!E;G1I=6TM;2`@("`@("`@("`@
M("`@"2!);G1E;"!096YT:75M($TB"B`)0&5C:&\@(@EA=&AL;VX)"0D@04U$
M($%T:&QO;B`H:S<I(@H@"4!E8VAO("()>#@V7S8T("`@("`@("`@("`@("`@
M("`@($%-1"!/<'1E<F]N+T%T:&QO;C8T("AK."DB"BT)0&5C:&\@(@EP<&,@
M("`@("`@("`@("`@("`@"2!0;W=E<E!#(@HK"4!E8VAO("()<'!C7SDW,"`@
M("`@("`@("`@("`)(%!O=V5R4$,@.3<P($-052(**PE`96-H;R`B"7!P8U\W
M-#4P("`@("`@("`@("`@(`D@4&]W97)00R`W-#4P($-052(*(`E`96-H;R`B
M"61O8PD)"2!$;V-U;65N=&%T:6]N(@H@"4!E8VAO("()<VYA<'-H;W0@("`@
M("`@"0D@4V]U<F-E<R!S;F%P<VAO="(*(`E`96-H;R`B"6EN<W1A;&P)"0D@
M26YS=&%L;&%T:6]N(@I`0"`M,S4L.2`K,S8L,3,@0$`*(`H@>#@V7S,R(#H*
M(`E!4D-(/2)A=&AL;VXB("0H34%+12D@8V]M;6]N"BUP<&,@.@HK"BMP<&-?
M.3<P(#H*(`E!4D-(/2(Y-S`B("0H34%+12D@8V]M;6]N"B`**W!P8U\W-#4P
M(#H**PE!4D-(/2(W-#4P(B`D*$U!2T4I(&-O;6UO;@HK"B!D;V,@.@H@"20H
934%+12D@+4,@9&]C+V=G;F9S+61O8PH@"@``
`
end
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: Dmitri G. <gri...@gm...> - 2005-08-24 13:24:57
|
Hello,
gcc-3.4 has -mtune=pentium-m option. Here's a patch which adds support
for it to the top-level Makefile. To build ggnfs for Pentium M use
target pentium-m:
~/ggnfs$ make pentium-m
Again, I'm not sure whether attachments are allowed.
begin 644 ggnfs_makefile_pentium_m.patch
M9&EF9B`M=7(@9V=N9G,N;W)I9R]-86ME9FEL92!G9VYF<R]-86ME9FEL90HM
M+2T@9V=N9G,N;W)I9R]-86ME9FEL90DR,#`U+3`X+3(T(#`X.C,S.C$Q+C`P
M,#`P,#`P,"`K,#,P,`HK*RL@9V=N9G,O36%K969I;&4),C`P-2TP."TR-"`Q
M-CHP.#HR-2XP,#`P,#`P,#`@*S`S,#`*0$`@+3DL-B`K.2PW($!`"B`)0&5C
M:&\@(E!O<W-I8FQE('1A<F=E=',@87)E.B(*(`E`96-H;R`B"7!E;G1I=6TS
M("`@("`@("`@("`@("`)($EN=&5L(%!E;G1I=6T@,R(*(`E`96-H;R`B"7!E
M;G1I=6TT("`@("`@("`@("`@("`)($EN=&5L(%!E;G1I=6T@-"(**PE`96-H
M;R`B"7!E;G1I=6TM;2`@("`@("`@("`@("`@"2!);G1E;"!096YT:75M($TB
M"B`)0&5C:&\@(@EA=&AL;VX)"0D@04U$($%T:&QO;B`H:S<I(@H@"4!E8VAO
M("()>#@V7S8T("`@("`@("`@("`@("`@("`@($%-1"!/<'1E<F]N+T%T:&QO
M;C8T("AK."DB"B`)0&5C:&\@(@EP<&,@("`@("`@("`@("`@("`@"2!0;W=E
M<E!#(@I`0"`M,C(L-R`K,C,L,3`@0$`*(`H@<&5N=&EU;30@.@H@"4!!4D-(
M/2)P96YT:75M-"(@)"A-04M%*2!X.#9C;VUM;VX*+0D**PHK<&5N=&EU;2UM
M(#H**PE`05)#2#TB<&5N=&EU;2UM(B`D*$U!2T4I('@X-F-O;6UO;@HK"B!A
M=&AL;VX@.@H@"4!!4D-(/2)A=&AL;VXB("0H34%+12D@>#@V8V]M;6]N"B`*
`
end
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: Anton K. <as...@ma...> - 2005-08-23 10:59:52
|
Hello, Max. You wrote Tuesday, August 23, 2005, 12:52:52 PM: M> GGNFS_x8632_ATTASM_MMX M> GGNFS_x8632_MSCASM_SSE M> GGNFS_x8664_ATTASM M> GGNFS_ppc32_ATTASM Maybe, better GGNFS_x86_32_ATTASM_MMX? -- With best regards, Anton mailto:as...@ma... Tuesday, August 23, 2005 3:04:37 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Brian G. <br...@gl...> - 2005-08-23 09:56:56
|
Anton Korobeynikov wrote:
> Hello, Brian.
>
> You wrote Tuesday, August 23, 2005, 11:06:14 AM:
>
> BG> I understand your concern - but its bad to leave errors in the code as I
> BG> might forget its there and spend time finding it again :-(
> Ah. Ok. And you also said, that the changes are quite minor.
> Please don't forget, that _MSC_VER is defined also with mingw32, so,
> your define should be something like:
> #if defined(_MSC_VER) && !defined(__MINGW32__)
The ONLY situation in which _MSC_VER should be defined is when the
Microsoft compiler is being used - there is no way I can maintain the
VC++ code effectively unless it is either (a) unique to compilation with
VC++ or (b) anyone else who uses these inserts adds a conditional so that:
#if defined( _MSC_VER )
.. MSC assembler
#endif
becomes:
#if defined( _MSC_VER ) || defined( _OTHER_USER_OF_MSC_ASSEMBLER )
.. MSC assembler
#endif
It is simply wrong to define _MSC_VER when GCC is being used since this
will inevitably break some code sooner or later. MSC_VER, _GCC_, ... are
all compiler generated defines that are intended to identify the
compiler being used. It's ok to define _MSC_VER to trick the code into
thinking is being compiled with the Microsoft compiler but its wrong to
then go on to suggest that the _MSC_VER has to be guarded to allow this
to happen!
However, if we get the reorganiation done we should be able to remove
this problem. At the moment I keep special versions of some files in
the VC++ directory and copy these over the normal ones before a VC++
build. It is possible that I will be able to avoid doing this after the
reorganisation.
> BG> You asked for help in tidying up the code. I am willing to join in but
> BG> you will need to suggest what specific things you want done.
> As Sten already written all platfrom specific defines in the source
> files should be replaced by semantics one.
> For example, inline assembler should be bounded with constrcuction
> like:
> #if defined(GGNFS_32BIT_ATT_ASSEMBLER)
> ...
> #elif defined(GGNFS_32BIT_MSC_ASSEMBLER)
> ...
> #else
> #error Unsuported assembler model!
> #endif
>
> Recently, I've done blanczos64.c. You might see it. All platform
> specific code now only in the early beginning - I can move it to
> config file later.
Ok, I'll take a look.
Brian
|
|
From: Max <re...@un...> - 2005-08-23 08:56:17
|
Anton Korobeynikov wrote: > #if defined(GGNFS_32BIT_ATT_ASSEMBLER) > ... > #elif defined(GGNFS_32BIT_MSC_ASSEMBLER) > ... > #else > #error Unsuported assembler model! > #endif I would vote for something like GGNFS_x8632_ATTASM_MMX GGNFS_x8632_MSCASM_SSE GGNFS_x8664_ATTASM GGNFS_ppc32_ATTASM i.e., GGNFS_<host>_<asm syntax>_<other requirements> Max |
|
From: Anton K. <as...@ma...> - 2005-08-23 08:45:51
|
Hello, Sten. You wrote Tuesday, August 23, 2005, 11:56:36 AM: S> Well, anyway, we discussed the problem with Anton and decided we need S> the platform dependent config.h files that should define macroses like S> ATT_ASSEBLY for AT&T syntax and MSC_ASSEMBLY - for MS VC assembler. Some small addition: GGNFS_32BIT_ATT_MSSEMBLER and GGNFS_32BIT_MSC_ASSEMBLER. Quite long, but meaningfull. GGNFS prefix *should* be used. For examples, for some time BIGENDIAN define had been used in lattice siever, but winsock2.h define BIGENDIAN as well. S> \include\config\config.h - common config file, this file is included by S> all .c files and "decides" which platform S> dependent file to include. You're absolutely right. S> Anton gave other examples of defines with "semantic meaning" but I S> forgot them. :) Another one example - GGNFS_ASM_UL. Underscore should be used for *all* external names used inside inline assembler under mingw32 & cygwin. -- With best regards, Anton mailto:as...@ma... Tuesday, August 23, 2005 12:48:45 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Anton K. <as...@ma...> - 2005-08-23 08:42:31
|
Hello, Brian.
You wrote Tuesday, August 23, 2005, 11:06:14 AM:
BG> I understand your concern - but its bad to leave errors in the code as I
BG> might forget its there and spend time finding it again :-(
Ah. Ok. And you also said, that the changes are quite minor.
Please don't forget, that _MSC_VER is defined also with mingw32, so,
your define should be something like:
#if defined(_MSC_VER) && !defined(__MINGW32__)
BG> You asked for help in tidying up the code. I am willing to join in but
BG> you will need to suggest what specific things you want done.
As Sten already written all platfrom specific defines in the source
files should be replaced by semantics one.
For example, inline assembler should be bounded with constrcuction
like:
#if defined(GGNFS_32BIT_ATT_ASSEMBLER)
...
#elif defined(GGNFS_32BIT_MSC_ASSEMBLER)
...
#else
#error Unsuported assembler model!
#endif
Recently, I've done blanczos64.c. You might see it. All platform
specific code now only in the early beginning - I can move it to
config file later.
--
With best regards,
Anton mailto:as...@ma...
Tuesday, August 23, 2005 12:41:07 PM
Faculty of Mathematics & Mechanics, Saint-Petersburg State University
|
|
From: Sten <st...@ma...> - 2005-08-23 07:59:01
|
I think this was not a personal letter from Brian - just my mailer
settings were not ajusted so Reply-To address pointed to my e-mail
box and not to ggnfs-devel group.
Well, anyway, we discussed the problem with Anton and decided we need
the platform dependent config.h files that should define macroses like
ATT_ASSEBLY for AT&T syntax and MSC_ASSEMBLY - for MS VC assembler.
It supposed to work like this:
\include\config\cygwin\config.h - platform dependent files, contains
\include\config\lnx\config.h macro definitions with "semantic
\include\config\mingw32\config.h meaning" like MSC_ASSEBMLY &
\include\config\ppc\config.h ATT_ASSEMBLY
\include\config\x86_64\config.h
\include\config\config.h - common config file, this file is included by
all .c files and "decides" which platform
dependent file to include.
Anton gave other examples of defines with "semantic meaning" but I
forgot them. :)
The _MSC_VER definition will be removed from the ggnfs.h file once these
config.h files are completed.
Sten
BG> Sten wrote:
>> Hi, All.
>>
>> There is the following definiton inside ggnfs.h file:
>>
>> #if defined (__MINGW32__) || defined (MINGW32)
>> #define _MSC_VER 1300
>> #endif
>>
>> It seems it has been done due to some portability reasons.
>> However, I found that this definitions forces blanczos64.c to
>> believe that it is being compiled under MS VC, when actually
>> compiles under MinGW. The problem arises only in Pentium4 target.
>>
>> blanczos64.c then uses some MS VC specific pieces of assembler code
>> that cann't be compiled under MinGW.
>>
>> I think we need more clever way to detect MS VC, or we have to do
>> something with _MSC_VER definition in ggnfs.h (it can not be simply
>> removed because it needed for some other .c files).
BG> As the maintainer of the VC++ port, I do think that this define is
BG> potentially dangerous since it should only really be set by the MS compiler.
BG> I don't mind other people using the VC++ parts of ggnfs provided that
BG> they don't fiddle extensively with them and break the VC++ version. But
BG> the use of this define might encourage people to do just this, which is
BG> not really desirable.
BG> In any event any definition of MSC_VER must be guarded so that it is NOT
BG> seen by the VC++ compiler since this is a Microsoft define that is only
BG> supposed to be set when code is being compiled by VC++.
BG> best regards to all,
BG> Brian Gladman
|
|
From: Brian G. <br...@gl...> - 2005-08-23 07:06:18
|
Anton Korobeynikov wrote: > Hello, Brian. > > You wrote Tuesday, August 23, 2005, 3:35:31 AM: > > BG> I have not committed this change as I am not sure whether there is a > BG> reason for this being the way it is. If so, I will have to put in an > BG> _MSC_VER conditional for this. > As I've written, now I'm trying to collect all platform-specific > defines in one place in the way of "config.h" files. I think, it will > be better to fix the tree after conversion just not to make double > job. Hi Anton I understand your concern - but its bad to leave errors in the code as I might forget its there and spend time finding it again :-( You asked for help in tidying up the code. I am willing to join in but you will need to suggest what specific things you want done. best regards, Brian |
|
From: Anton K. <as...@ma...> - 2005-08-22 23:45:35
|
Hello, Brian. You wrote Tuesday, August 23, 2005, 3:35:31 AM: BG> I have not committed this change as I am not sure whether there is a BG> reason for this being the way it is. If so, I will have to put in an BG> _MSC_VER conditional for this. As I've written, now I'm trying to collect all platform-specific defines in one place in the way of "config.h" files. I think, it will be better to fix the tree after conversion just not to make double job. -- With best regards, Anton mailto:as...@ma... Tuesday, August 23, 2005 3:49:50 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Brian G. <br...@gl...> - 2005-08-22 23:35:40
|
Hi All, The latest CVS works on Microsft VC++ except for one change in the /src/piii/lasieve-asm.h file. Instead of: #define asm_modinv32 modinv32 I have to reverse the define: #define modinv32 asm_modinv32 I have not committed this change as I am not sure whether there is a reason for this being the way it is. If so, I will have to put in an _MSC_VER conditional for this. Brian Gladman |
|
From: Anton K. <as...@ma...> - 2005-08-22 15:50:26
|
Hello, Sten. You wrote Monday, August 22, 2005, 7:36:30 PM: S> It seems it has been done due to some portability reasons. S> However, I found that this definitions forces blanczos64.c to S> believe that it is being compiled under MS VC, when actually S> compiles under MinGW. The problem arises only in Pentium4 target. As I've already said to you ;), it's normal. Yesterday, I've fixed two bad "defines". Try to update and let me know asap. When we had no lattice siever and other platfrom-specific code, it would be fine to assume, that mingw32 and ms vc are the same (Yes, mingw32 was written in the spirit of "emulating ms vc almost everywhere, even in some bugs") However, it's pretty horrible nowadays, because there are too much defines such as #if defined(_MSC_VER) && !defined(__MINGW32__). x86_64 port also shows us, that without some restructurisation of "defines", we'll have complete mess. I'm thinking about some "config" files, where all platform specific defines will be collected. Yes, it's horrible job, but it should be made in the nearest future. Any volunteers? ;))) -- With best regards, Anton mailto:as...@ma... Monday, August 22, 2005 7:50:44 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Sten <st...@ma...> - 2005-08-22 15:38:57
|
Hi, All. There is the following definiton inside ggnfs.h file: #if defined (__MINGW32__) || defined (MINGW32) #define _MSC_VER 1300 #endif It seems it has been done due to some portability reasons. However, I found that this definitions forces blanczos64.c to believe that it is being compiled under MS VC, when actually compiles under MinGW. The problem arises only in Pentium4 target. blanczos64.c then uses some MS VC specific pieces of assembler code that cann't be compiled under MinGW. I think we need more clever way to detect MS VC, or we have to do something with _MSC_VER definition in ggnfs.h (it can not be simply removed because it needed for some other .c files). Sten |
|
From: Anton K. <as...@ma...> - 2005-08-21 12:17:30
|
Hello, Max. You wrote Sunday, August 21, 2005, 9:46:55 AM: M> Could anybody confirm that there is no speed up in using M> assembler (one can switch between C/asm code by (un)defining M> HAVE_SSIMD in lasieve-asm.h)? Maybe, It will be better to perform some small-middle factorization to compare sieving times? Anyway, we should also compare not "speed" or "sieving time", but some output from the profiler. It will be better and much more accurate. -- With best regards, Anton mailto:as...@ma... Sunday, August 21, 2005 3:42:32 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
|
From: Max <re...@un...> - 2005-08-21 05:49:29
|
In last commitment I put some reused assembler code into an inline procedure optsieve() and completed it with 64-bit assembler code.
But it seems to me that assembler code is not needed there, at least on my debian-amd64 there is no difference in generic C code and assembler code: in both cases I get roughly 0.00018 sec/rel for "snfs_small" test. Moreover, the same speed I get for 32-bit athlon-optimized code for both C and assembler codes.
I've also tried to use SSE assembler code (listed below) instead of current MMX code. And again there is no difference.
Could anybody confirm that there is no speed up in using assembler (one can switch between C/asm code by (un)defining HAVE_SSIMD in lasieve-asm.h)?
Is so I would prefer to wipe out that assembler code.
Thanks,
Max
P.S. 64-bit SSE-code processing 64 bytes at once (to get 32-bit code replace "rax" with "eax", "rsi" with "esi" etc.):
inline void optsieve(uint32_t st1, uchar* i_o, uchar* i_max, size_t j) {
uint64_t x[2];
// align i_o & i_max to 64-byte boundary
for(;i_o<i_max && ((size_t)i_o & 0x3F);++i_o) {
if (*i_o >= st1) {
cand[ncand] = i_o - sieve_interval;
fss_sv[ncand++] = *i_o + horizontal_sievesums[j];
}
}
while(i_o<i_max && ((size_t)i_max & 0x3F)) {
if (*--i_max >= st1) {
cand[ncand] = i_max - sieve_interval;
fss_sv[ncand++] = *i_max + horizontal_sievesums[j];
}
}
x[0] = st1 - 1;
x[0] |= x[0] << 8;
x[0] |= x[0] << 16;
x[0] |= x[0] << 32;
x[1] = x[0];
while (i_o < i_max) {
asm volatile (
"movsd (%%rax),%%xmm7\n"
/* ".align 32\n" */
"1:\n"
"movd (%%rsi),%%xmm1\n"
"movd 16(%%rsi),%%xmm0\n"
"pmaxub 32(%%rsi),%%xmm1\n"
"pmaxub 48(%%rsi),%%xmm0\n"
"pmaxub %%xmm7,%%xmm1\n"
"pmaxub %%xmm1,%%xmm0\n"
"pcmpeqb %%xmm7,%%xmm0\n"
"pmovmskb %%xmm0,%%rax\n"
"cmpq $65535,%%rax\n"
"jnz 2f\n"
"leaq 64(%%rsi),%%rsi\n"
"cmpq %%rsi,%%rdi\n"
"ja 1b\n"
"2:\n"
"emms":"=S" (i_o):"a"(&x),
"S"(i_o), "D"(i_max)
);
if (i_o < i_max) {
uchar *i_max2 = i_o + 64;
while (i_o < i_max2) {
if (*i_o >= st1) {
cand[ncand] = i_o - sieve_interval;
fss_sv[ncand++] = *i_o + horizontal_sievesums[j];
}
i_o++;
}
}
}
}
|
|
From: Anton K. <as...@ma...> - 2005-08-20 17:31:27
|
Hello, ggnfs-devel. Subj! ;) -- With best regards, Anton mailto:as...@ma... Saturday, August 20, 2005 9:37:32 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
