Question...
 

Who compiles their own linux YAFU executables vs. using the pre-packaged binaries?

I ask because I've been running experiments on two versions I have access to and found that gcc version 3.2.3 apparently produces about 10% faster code than 4.1.2 with the same options. It is also 11-12% faster than 4.1.2 with -march=nocona -mtune=nocona, even though 3.2.3 has no knowledge of nocona and just uses generic code. Intel's C compiler (which I was shocked to find "just worked" using the existing code and makefile with CC=gcc simply replaced by CC=icc), performs approximately equivalently to gcc 3.2.3.

If you do compile your own, what are the reasons? And would you change your mind if you were leaving 10+% performance on the table?

Just curious...

[edit]
I haven't tried out the Intel compiler on windows builds yet... so don't know if its better than MSVC. I just have a trial license for the linux Intel Compiler at this point.

Will it make a difference running 64-bit version of Yafu for siqs factoring against 32-bit version?

I downloaded Yafu 1.19 version, here a few updates:

-on docfile.txt replace 1.15 version reference (Supported flags in [B]v1.15[/B] are:)
-in the factor.log file output please correct yafu version, still shows v1.18.

Jeff, could you compile Yafu for 64-bit windows? Thank you.

I have a 64 bit windows version... just never posted it :doh!::doh!:

Gimme a sec...

I've fixed the version issue in the log files, and I've fixed the docfile, thanks for finding those.

I'll post version 1.19.1 with the fixed code and docfile, along with 32 bit windows executables and linux binaries. I can post the 64 bit windows binaries that I have, but they won't have the logfile version fix.

Also, I've noticed that the 64 bit windows executables perform terribly on a nehalem based CPU (specifically a X5570). I have no idea yet why this is the case. Other than this issue, the 64 bit executables will be much faster than the 32 bit ones on modern cpus (e.g. core2, amd64).

[quote=bsquared;224740]I've fixed the version issue in the log files, and I've fixed the docfile, thanks for finding those.

I'll post version 1.19.1 with the fixed code and docfile, along with 32 bit windows executables and linux binaries. I can post the 64 bit windows binaries that I have, but they won't have the logfile version fix.

Also, I've noticed that the 64 bit windows executables perform terribly on a nehalem based CPU (specifically a X5570). I have no idea yet why this is the case. Other than this issue, the 64 bit executables will be much faster than the 32 bit ones on modern cpus (e.g. core2, amd64).[/quote]

I suppose you will be posting on your webpage, correct?

[QUOTE=bsquared;224740]

Also, I've noticed that the 64 bit [B]windows [/B]executables perform terribly on a nehalem based CPU (specifically a X5570)[/QUOTE]

Note, the linux binaries are not effected on nehalems. I have no idea yet why this is the case - something in the compiler? If anyone cares to performance test 32 bit vs. 64 bit on windows with a nehalem cpu, I'd be interested to hear the results, especially if the 64bit code is much faster as I'd normally expect. Maybe it is just my system...

[QUOTE=em99010pepe;224744]I suppose you will be posting on your webpage, correct?[/QUOTE]

[URL="https://sites.google.com/site/bbuhrow/"]Yes[/URL].

[QUOTE=bsquared;224740]
Also, I've noticed that the 64 bit windows executables perform terribly on a nehalem based CPU (specifically a X5570). [/QUOTE]

A little more info on this issue. If I set the processor affinity to a single cpu, then I get 100% of that core utilized (25% overall) and the performance is fine. If I allow any cpu to be utilized, then I get variable utilization of all 4 cores simultaneously, and performance suffers quite a bit - 52 seconds vs. 31 seconds to factor a C70.

On another system with the same OS (windows server 2003 R2), but a woodcrest 5160 cpu, cpu affinity does not matter. Either setting it to a single core or not, performance is fine.

Does windows server interpret hyperthreads as cpus? So that when it says it is distributing over 4 cores it is really 2 cores with 2 hyperthreads? That would explain the performance hit. The dialog box for setting CPU affinity under task manager only gives a choice between 4 CPUs, not 8, which seems to suggest they are referring to physical cpus... but the performance indicates otherwise.

Strange, on a core i5 I see Yafu going faster when using 8 threads when the CPU only has 4 cores/4 threads with the 64-bit version.

[QUOTE=em99010pepe;224770]Strange, on a core i5 I see Yafu going faster when using 8 threads when the CPU only has 4 cores/4 threads with the 64-bit version.[/QUOTE]

That is strange, yes. But strange seems to be the norm for windows nehalem systems.

Does anyone know if its possible to set processor affinity programmatically using windows API calls? Is that even a good idea to consider?

[QUOTE=bsquared;224864]That is strange, yes. But strange seems to be the norm for windows nehalem systems.

Does anyone know if its possible to set processor affinity programmatically using windows API calls? Is that even a good idea to consider?[/QUOTE]
Yes, it is easy to control processor affinity using CRT calls. it is often necessary to do this when timing because the time stamp counters on different processors are not synchronised. Let me know if you need more details.