Yafu

[em99010pepe]

I have to say that the windows 32 bit version is more stable than the 64 bit version one. The latter sometimes doesn't resume work...I don't know if it is related but since I made the last updates for win 7 that the client shutdowns frequently.

[bsquared]

Originally Posted by em99010pepe

I have to say that the windows 32 bit version is more stable than the 64 bit version one. The latter sometimes doesn't resume work...I don't know if it is related but since I made the last updates for win 7 that the client shutdowns frequently.

Instability in the 64 bit version is news to me. By not resuming work do you mean you pause a factorization with cntl-c, then attempt to restart it? I assume by client shutdowns you mean that YAFU crashes randomly. Any additional info about what was going on at the time of the crash would help me.

[richs]

I have had the following occur sometimes with the version 1.19 win32 executable:

Run siqs with successful completion. Start another siqs on a different number and the application just hangs, nothing output to the screen. Have to close the command window and restart.

This never happened with version 1.17, the previous version that I was using.

[smh]

I've been using the yafu-64k-Win32 (1.19.1) for a while now with aliqueit and 3 or 4 times it just hung in the middle of a calculation. It still took it's cpu time, but no update on the screen and i've waited long enough to make sure the factorization didn't finish.

Will try the yafu-32k-x64 now, which is faster anyway.

[EdH]

Not sure if it is the same, but I just set up a Fedora machine for aliqueit with yafu-64k-linux32 (version 1.18 from the yafu-1.19.zip file) and had a SIQS appear to just sit for a long time after it had found enough relations. Of course, it may have just seemed a long time.

Anyway, when I aborted via CTRL-C, it finished:

starting SIQS on c92: 86523493544966774152939777679223520869803987562941554135903221003067914489571132488438422917

==== sieving in progress (1 thread):   73977 relations needed ====
====           Press ctrl-c to abort and save state           ====
74003 rels found: 19802 full + 54201 from 929594 partial, ( 75.15 rels/sec)

^C
Aborting...
SIQS elapsed time = 12727.3421 seconds.


***factors found***

PRP40 = 1223167716824370415194527068669101423539
PRP53 = 70737227900031573609060873252190742107456441762825703

ans = 1

 2029 .     c102 = 489223783955618674949173429381664839149549113782363685777365009475077085954437333297071352188658431030 = 2 * 3 * 5 * 188474353 * 1223167716824370415194527068669101423539 * 70737227900031573609060873252190742107456441762825703

cat /proc/cpuinfo:

processor    : 0
vendor_id    : GenuineIntel
cpu family    : 15
model        : 4
model name    : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping    : 1
cpu MHz        : 2799.930
cache size    : 1024 KB
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid xtpr
bogomips    : 5586.01
clflush size    : 64
cache_alignment    : 128
address sizes    : 36 bits physical, 32 bits virtual
power management:

Did I just time it perfect, or was it stuck?

[em99010pepe]

Originally Posted by bsquared

Instability in the 64 bit version is news to me. By not resuming work do you mean you pause a factorization with cntl-c, then attempt to restart it? I assume by client shutdowns you mean that YAFU crashes randomly. Any additional info about what was going on at the time of the crash would help me.

If you stop the client by shutting down the window and then restart the client sometimes it doesn't resume work when you are working with Yafu in batchfile mode. To restart from last point I have to edit my batch file and delete all previous work done by then.
Another issue I get is sometimes the client loses cores when sieving. My case starts with 4 and ends with 1 while sieving. I suppose this happens when you turn on another application, both fight for the cores and Yafu ends losing them. I made a test, turned on BOINC. BOINC started running with 4 instances, Yafu lost CPU, it's normal due to high priority of BOINC. After shutting down BOINC, Yafu didn't catch up with all cores, one was only active while the other three were idle.

[em99010pepe]

Originally Posted by em99010pepe

Another issue I get is sometimes the client loses cores when sieving.

This happened now with yafu-32k-x64.exe after 15 mins of run. Maybe the resume issue occurs with this version too, I still don't know, I need more time to investigate.

[bsquared]

It took a while to find one, but I now have a repeatable test case which locks up. I'll start looking into what's causing that.

I don't know what would cause yafu to lose cores. Another program running at higher priority could take them, but I would expect yafu to get them back if the other process finishes first.

[em99010pepe]

Originally Posted by bsquared

It took a while to find one, but I now have a repeatable test case which locks up. I'll start looking into what's causing that.

I don't know what would cause yafu to lose cores. Another program running at higher priority could take them, but I would expect yafu to get them back if the other process finishes first.

In all 64 bit windows version that happens even when there's no other process calling for CPU.

[em99010pepe]

Why are you still using msieve 1.38 postprocessing integration on SIQS jobs? You could update to msieve 1.45, maybe it is faster.

[bsquared]

Originally Posted by em99010pepe

Why are you still using msieve 1.38 postprocessing integration on SIQS jobs? You could update to msieve 1.45, maybe it is faster.

There is work that needs to be done to port Jason's code into YAFU. It is on the list of things to do... but I haven't got there yet. I don't think the QS postprocessing has changed much since 1.38 so I don't expect much improvement.