[QUOTE=Batalov;194850][B][SIZE=1]TO[/SIZE][/B] Jeff: To be on the safe side I will drop it to 15 in the trunk source.
(but it was since the dawn of time 14, except in the 16e siever, so there may be acceleration still. Could you please run some tests, old 14 vs. 15, after Win32 builds are done side-by-side; all sievers, small to big, 16e being a neutral test. If you have Win32 Athlons, try 16, too! )[/QUOTE]

Ok, gotcha. I'm super busy right now for the next week or so, but I will take a look after that. I have an older Sempron machine that I could try out I think.

Jeff.

[quote=siew;194866]is correct paths was defined in .pl files?
copy cat.exe to same directory where you unpacked ggnfs.
cat.exe can be found in ported unix utils pack.
here you can find it:
[URL]http://unxutils.sourceforge.net/[/URL]

also, .out files can be used by other application, so cant be opened/appended.
or maybe disk full...

check with some file monitor what happens in this moment[/quote]

Ya, it had been running fine until this sudden glitch and ran to completion when I restarted.

-----
I noticed in factMSieve.pl a reference to minrels.txt. I was wondering if this is a way to better specify how many relations are needed for different size numbers. Anyone know anything about it? Ideal would be a file with values already set up for GNFS (i.e. not SFNS).

[quote=Greebley;194937]I noticed in factMSieve.pl a reference to minrels.txt. I was wondering if this is a way to better specify how many relations are needed for different size numbers. Anyone know anything about it? Ideal would be a file with values already set up for GNFS (i.e. not SFNS).[/quote]
minrels is basically a way to override the default estimate
it has to be set for each number

[quote=henryzz;194946]minrels is basically a way to override the default estimate
it has to be set for each number[/quote]
So whats the format? Is it (invented numbers):

90 1939596
91 1939596
<etc>

[QUOTE=Greebley;194963]So whats the format? Is it (invented numbers):

90 1939596
91 1939596
<etc>[/QUOTE]

You create a file minrels.txt and put in a single integer for the minimum number of relations you want so:

12345678

So for any run it will wait until you have at least 12345678 relations before proceeding to post-processing.

MINRELS.txt
 

No, just a single number for the project in the [I]current[/I] directory. If you have many projects running, you may have many MINRELS.txt files in each directory. Consider it an extension to the .poly file, but the difference is that .poly file is read only once, while this file (if exists) is read before starting each filtering phase.

The idea is to edit this file between filtering cycles, without stopping the perl script. It used to be easier to adjust this number (msieve actually reported pretty accurately how many more relations if still wants, but recently it doesn't, just says a 1000000). Also, search forum.

Please, can anyone tell, how many unique relations typically needed for C154 factorizing? In general.
Tanx.

It depends on the large-prime bound.

Generally, 2^{large primes}/10 is about right.

As they said:
[CODE]For the lattice sieve, a factor base bound of 16 777 216 (2^24) was chosen,
both for the rational and for the algebraic side. Two large primes were
allowed on both sides.
Most of the line sieve was carried out with two large primes on both the
rational and the algebraic side. The rational factor base consisted of the
primes < 44 000 000 and the algebraic factor base of the primes < 110 000 000.
Some line sieving allowed three large primes instead of two on the algebraic
side. In that case the rational factor base consisted of the primes < 8 000 000
and the algebraic factor base of the primes < 25 000 000.

For both sieves the large prime bound 1 000 000 000 was used both
for the rational and for the algebraic primes.

A total of 124 722 179 relations were generated, 71% of them with lattice
sieving (L), 29% with line sieving (C). Among them, there were 39 187 441
duplicates, partially because of the simultaneous use of the two sievers.
Sieving was done at eleven different locations with the following contributions:[/CODE]
So rlim and alim was 25 000 000 and 8 000 000, and bound was 1 000 000 000 ? So nearly 100 000 000 relations?
As they said, collected 125M relations with 40M duplicates. So nearly 85M Unique relations....

For one C148 and another C154 numbers i had success with 78M relations with 30M duplicates. Similar for bot numbers. But current c155 wants more sieving after 60M. Thats why i asking.

[CODE]The relations were collected at CWI and required 3.7 Gbytes of disk space[/CODE]
I already has relation file 7.5Gbytes.

Thanks!

Also, when i running the GNFS on >1 threads the parallel jobs looks like that:
[CODE]skew: 284391.86
rlim: 18700000
alim: 9350000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6
q0: 9350000
qintsize: 50000

skew: 284391.86
rlim: 18700000
alim: 9350000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6
q0: 9400000
qintsize: 50000
#q1:9450000[/CODE]
while initial poly has:
[CODE]rlim: 18700000
alim: 18700000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6
[/CODE]
So when i changed the each job for

[CODE]alim: 18700000[/CODE]

i had 10-15% more yield than with
[CODE]alim: 9350000[/CODE]

Why it set so params limit?

[quote=Jeff Gilchrist;194836]So with the discovery of the AMD vs Intel cache sizes, what are you doing about L1_BITS, is there a way to specify that just for specific platforms or how are you doing it now?

Should I still be testing the latest SVN code or have things essentially "reverted" back to what they were before now?

Jeff.[/quote]
Jeff,
I think I've found a reasonable set of defines that should cover the 16/15 L1_BITS choice problem and added it to the SVN 382 source. (Basically, AMD K7 and above [not K6] are going to benefit most; Core2s, intermediately; old CPUs should not use the new binaries.)

These are #[FONT=Courier New]defines[/FONT] (run time CPUid discovery is not a trick we want to use; too late, all optimizations, loop unrolls are already done), so in Windows cross-builds you may want to define [FONT=Courier New]__k8__[/FONT] in the solution for one build, or not, for another, and check what happens with test sieving on various comps. If you have a pentiumIII or a [I]pentium4[/I], you may want to manually redefine L1_BITS to 14 or even [I]13[/I] (for very old CPUs; however, only sievers up to L1_BITS+1 are functional run-time. So for old CPUs, 15e can only be built with L1_BITS 14, and it will be slow, naturally, but that's the only way; and they will not afford 16e -- who want 10 sec/rel yield anyway...).

[B][SIZE=1]All[/SIZE][/B]: I've added the same to the experimental/lasieve4_64/athlon64/ but there is an additional instruction added to the INSTALL file. Read it for Core2. AMDs will fly, Opterons, Phenoms, Athlons.