The poly selection has always behaved this way; if you only wanted poly selection and there is already a poly in the .fb file, then you're done :)

Printing a warning to that effect is a good idea though.

Proposed trivial patch for printing the target density right at the beginning of the filtering stage, which makes it quicker to check after the fact, in the logs, what target density was used:
[code]Index: gnfs/filter/filter.c
===================================================================
--- gnfs/filter/filter.c (révision 640)
+++ gnfs/filter/filter.c (copie de travail)
@@ -158,6 +158,12 @@

#define DEFAULT_TARGET_DENSITY 70.0

+/* helper function */
+static double get_target_density(msieve_obj *obj) {
+ return ((obj->target_density != 0) ? obj->target_density :
+ DEFAULT_TARGET_DENSITY);
+}
+
static uint32 do_merge(msieve_obj *obj, filter_t *filter, merge_t *merge) {

uint32 relations_needed;
@@ -179,9 +185,7 @@

merge->num_extra_relations = NUM_EXTRA_RELATIONS;

- merge->target_density = DEFAULT_TARGET_DENSITY;
- if (obj->target_density != 0)
- merge->target_density = obj->target_density;
+ merge->target_density = get_target_density(obj);

filter_make_relsets(obj, filter, merge, extra_needed);
return 0;
@@ -244,7 +248,8 @@
char lp_filename[256];

logprintf(obj, "\n");
- logprintf(obj, "commencing relation filtering\n");
+ logprintf(obj, "commencing relation filtering with target density %02.02f\n",
+ get_target_density(obj));

if (ram_size == 0)
ram_size = get_ram_size();
[/code]

Jeff,

Can't run msieve149_win64.zip under Win 7 but msieve148_win64.zip works.
I get error: The application was unable to start correctly (0xc000007b)

Carlos

[QUOTE=em99010pepe;275805]Can't run msieve149_win64.zip under Win 7 but msieve148_win64.zip works.
I get error: The application was unable to start correctly (0xc000007b)[/QUOTE]

The only thing I can think of is maybe you don't have SP1 of the redistributable package for VS2010?

Try downloading and installing this:
[url]http://www.microsoft.com/download/en/details.aspx?id=13523[/url]

[QUOTE=Jeff Gilchrist;275812]The only thing I can think of is maybe you don't have SP1 of the redistributable package for VS2010?

Try downloading and installing this:
[URL]http://www.microsoft.com/download/en/details.aspx?id=13523[/URL][/QUOTE]

That was the issue, thank you.

Under Win 7 64 bits msieve always gets stuck between LA and square root phase. I really don't know what's going on. It's the second time this happens on 30 bits task factorization.

[code]Fri Nov 04 13:15:56 2011 lanczos halted after 125988 iterations (dim = 7966905)
Fri Nov 04 13:16:07 2011 recovered 36 nontrivial dependencies
Fri Nov 04 13:16:10 2011 BLanczosTime: 82620
Fri Nov 04 13:16:10 2011
Fri Nov 04 13:16:10 2011 commencing square root phase
Fri Nov 04 13:16:10 2011 reading relations for dependency 1
Fri Nov 04 13:17:20 2011 read 3982083 cycles
Fri Nov 04 13:17:26 2011 cycles contain 10871416 unique relations
Fri Nov 04 13:56:21 2011 [B](here I restarted msieve because no processing time was used until this time)[/B]
Fri Nov 04 13:56:21 2011
Fri Nov 04 13:56:21 2011 Msieve v. 1.49 (SVN unknown)[/code]

In -nc3, the line which follows "cycles contain X unique relations" is, after a while, "read X relations". And reading relations can take quite a while :smile:
Especially so if your version of msieve was compiled with ZLIB support: this heavily slows down reads and writes of uncompressed data. I recently witnessed a -nc1 run take 1h30' when compiled without NO_ZLIB=1, but only 50' when compiled with NO_ZLIB=1.

If your computer is a laptop, is it a model which has the distinctive absurdity of not providing an HDD activity LED ?

The latter happens when while running last minutes from LA I start a second factorization. When LA finishes msieve behaves like it can't grab the core power. If then I shutdown both factorizations and only start the former by -nc3 msieve can't start either, msieve stays open but nothing happens.

Look at this:

Problem...
[code]Fri Nov 04 13:16:10 2011 commencing square root phase
Fri Nov 04 13:16:10 2011 reading relations for dependency 1
Fri Nov 04 13:17:20 2011 read 3982083 cycles
Fri Nov 04 [B]13:17:26 2011[/B] cycles contain 10871416 unique relations
Fri Nov 04 [B]13:56:21 2011[/B] (here I restarted msieve because no processing time was used until this time)
Fri Nov 04 13:56:21 2011
[/code]After rebooting machine after last checkpoint saved (with last LA minutes to run).
[code]Fri Nov 04 14:37:18 2011 commencing square root phase
Fri Nov 04 14:37:18 2011 reading relations for dependency 1
Fri Nov 04 14:37:21 2011 read 3982083 cycles
Fri Nov 04 [B]14:37:26[/B] 2011 cycles contain 10871416 unique relations
Fri Nov 04 [B]14:40:56[/B] 2011 read 10871416 relations
Fri Nov 04 14:41:43 2011 multiplying 10871416 relations
Fri Nov 04 14:54:13 2011 multiply complete, coefficients have about 390.64 million bits
Fri Nov 04 14:54:16 2011 initial square root is modulo 10216981
Fri Nov 04 15:10:31 2011 sqrtTime: 1993[/code]Between lines "cycles contain" and read xxxx relations" I get nothing for 40 minutes but after rebooting I get a reaction after 3 minutes, strange?!

I think I can only start a second factorization in parallel after the first one reaches square root phase but I hope msieve is not behaving like yafu when loses cores.

[QUOTE=em99010pepe;277118]The latter happens when while running last minutes from LA I start a second factorization...[/QUOTE]
Sounds like disk thrashing. Letting two processes read a gigabyte of data each, one would expect large delays (the disk head will try to keep both processes happy and will be flying between sectors for 99% of the time and do actual reading for 1%).
[QUOTE=em99010pepe;277118]...I think I can only start a second factorization in parallel after the first one reaches square root phase but I hope msieve is not behaving like yafu when loses cores.[/QUOTE]
Right!
_______

I've checked Lionel's observation, and it appears that gzread is implemented unexpectedly slow [B]if zlib version is 1.2.3 (which is supplied with many old systems)[/B]. Advice: Build zlib 1.2.5 from source and link it statically to msieve and you will see huge difference. (see [URL="http://stackoverflow.com/questions/2832485/zlib-gzgets-extremely-slow"]also[/URL])

Clarification: I did link to 1.2.3 and observed Lionel's effect, and I also did link to 1.2.5 as well as used NO_ZLIB=1. Ran a not-so-small filtering job 5 times for each scenario. (If you are using a NAS drive, do that too, to remove variability.) Ran valgrind (callgrind) for a while only to see that gzread was called an inordinate amount of times (see the quoted [URL="http://stackoverflow.com/questions/2832485/zlib-gzgets-extremely-slow"]answer[/URL], it is indeed one gzread call per byte! He's right!)

Result: 1.2.3 is bad (about as bad as Lionel described - almost 2 times slower), but 1.2.5 has the same speed as NO_ZLIB=1 for plain files and negligible overhead on gzipped .dat file (which on systems may actually be a negative overhead, not to mention smaller footprint). Use zlib 1.2.5.

[QUOTE=em99010pepe;277107]Under Win 7 64 bits msieve always gets stuck between LA and square root phase. I really don't know what's going on. It's the second time this happens on 30 bits task factorization.[/QUOTE]

Are you using my binary when you are seeing this? I didn't think zlib support was part of the Windows visual studio build.