I've found that switching of the MS error reporting often just let the program continue.

Switching of error reporting is on my todo list for every new installation.

[quote=Andi47;168782]I have seen yafu crashing a few times when factoring composites in the c40 ... c50 range. One of these was:
[/quote]

Very strange... I can't get it to crash, even with the supplied seed. I've tried on win32, linux32, and linux64 binaries, as well as the source in debug mode? Is it doing this as part of an automated aliquot sequence, or as a standalone manual command line factorization? If you catch it again, could you also capture the screen output, so I can try to estimate where in the routine it is failing? Thanks.

[QUOTE=bsquared;168984]Very strange... I can't get it to crash, even with the supplied seed. I've tried on win32, linux32, and linux64 binaries, as well as the source in debug mode? Is it doing this as part of an automated aliquot sequence, or as a standalone manual command line factorization? If you catch it again, could you also capture the screen output, so I can try to estimate where in the routine it is failing? Thanks.[/QUOTE]

This was with the win32 binary (Win XP professional on a Core2Duo) when doing aliquot sequences (with aliqueit.exe).

I will take a screenshot when it happens again, but currently I don't have a sequence with a downdriver which has a chance to reach the 40-50 digit range.

P.S.: Strange enough, when I click the windows error message away, aliqueit.exe continues properly, so the factors already seem to exist. (The only problem is that the CPU is sitting idle waiting for my click.)

[quote=Andi47;168782]I have seen yafu crashing a few times when factoring composites in the c40 ... c50 range. One of these was:

[/quote]

Well, I've done some hunting for this bug, and near as I can tell it is some sort of compiler error, or at least a compiler sensitive bug. It works for all MSVC builds and linux gcc builds, but not for mingw32 builds. Ditto for some similar problems reported by mklasson.

I may just sweep it under the rug and start providing MSVC builds for the windows 32bit version. This may not give everyone the fastest possible executable (MSVC is better, for instance, for p3 and p4 cpus, but worse for core2), but it hopefully will be more stable.

YAFU 1.09
 

YAFU 1.09 is now available [URL="http://bbuhrow.googlepages.com/home"]here[/URL].

Highlights include:
[FONT=Arial][SIZE=2]+ Lots of improvements to trial division stage of siqs (as well as other improvements), resulting in about 3% siqs speedup on core2 and as much as 25% to 30% siqs speedups on athlon64, opteron, pentium3, and pentium4 architectures.[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ Stores relations on disk rather than in memory, for all siqs factorizations[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ Does not store factors of the a-poly in each relation. [B]This means 1.09 will be incompatible with previous versions' savefiles. [/B]But it is worth it.[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ New 'sigma' command line switch, for input of a specific sigma value in ECM jobs[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ New 'session' command line switch, for input of a user defined session logfile name[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ Other small things... see the CHANGES file for details[/SIZE][/FONT]

I don't have win64 binaries or linux32 binaries yet. The former is pending Jeff G's build, the latter on some fixes I need to do in an assembly routine. Hopefully both will be done soon.

As mentioned in the previous post, the win32 binaries are as built on my express edition 2008 compiler on a Xeon/P3. I haven't seen any crashes in this version, but welcome news of any. The binaries are not optimal for all machines, but I have given up trying to provide an optimal solution for everybody (and the difference is slight, anyway). That's what the code is provided for :smile:.

Happy factoring,
- ben.

Error when compiled yafu-1.09
 

When I compiled yafu-1.09 on my core2 duo PC, there occured some error.

[code]gcc -c -O3 -march=k8 -mtune=k8 -fomit-frame-pointer -Wall relation.c -DYAFU_64K -DCACHE_LINE_64
relation.c: Assembler messages:
relation.c:1362: Error: missing ')'
relation.c:1362: Error: junk `(%rsp))' after expression
relation.c:1363: Error: junk `(56(%rsp))' after expression
make: *** [relation.o] Error 1
[/code]

The version of gcc is 4.3.2 and the OS is OpenSUSE 11.1.

Right then, some C65 timings (with internet on at same time):

[code]yafu-1.08 yafu-1.09 msieve-1.41
00:01:28 00:01:23 00:01:22[/code]

Seems it wasn't a 25-30% speedup for me :sad:

[quote=10metreh;169155]Right then, some C65 timings (with internet on at same time):

[code]yafu-1.08 yafu-1.09 msieve-1.41
00:01:28 00:01:23 00:01:22[/code]Seems it wasn't a 25-30% speedup for me :sad:[/quote]
more likely it will be 25% for larger numbers
try a 1/2 hour benchmarking job

[quote=henryzz;169158]more likely it will be 25% for larger numbers
try a 1/2 hour benchmarking job[/quote]

No real chance today :sad: Otherwise a C81 or C82 would be on the go. Of course I'd normally give it some juicy aliquot sequence composites, but the one I've got now is a C95.

[quote=10metreh;169159]No real chance today :sad: Otherwise a C81 or C82 would be on the go. Of course I'd normally give it some juicy aliquot sequence composites, but the one I've got now is a C95.[/quote]
try that:smile:

[quote=henryzz;169160]try that:smile:[/quote]

Yep, the C95 would be an ideal test, but I'd end up doing some on low priority on both yafu and msieve, distorting the runtimes. And I've started the GNFS run on the C95.