Sr2sieve on PPC/Linux

[BlisteringSheep]

Originally Posted by geoff

Are the sizes in bytes or kilobytes?

Do you know which compiler symbols I should test to decide whether this code should be included? I assume __linux__ and __powerpc64__ and one other for the CPU type.

The sizes are in bytes. You can check for either __PPC64__ or __powerpc64__ along with __linux__. There is no compiler symbol you can check for the specific CPU. The way that lshw does it is to look for directories in the /proc/device-tree/cpus/ directory. Any directories in there will be the CPUs. For example, my dual PowerMac has PowerPC,970@0 and PowerPC,970@1 entries. Unfortunately, I won't be able to check this on other machines until at least next week. I also don't know if a uniprocessor would have PowerPC,970@0 or PowerPC,970

[Greenbank]

Yes, Linux man pages for sysctl() do warn you away from using sysctl() in favour of scraping the info from text files in /proc.

[geoff]

Originally Posted by BlisteringSheep

The way that lshw does it is to look for directories in the /proc/device-tree/cpus/ directory. Any directories in there will be the CPUs.

Thanks. I'll make it walk the directory tree using ftw() in a future version. For now (sr2sieve 1.4.32) it just looks in /proc/device-tree/cpus/PowerPC,970@0/ and uses the defaults if that directory doesn't exist.

[geoff]

sr2sieve 1.4.34 looks for the cache size files in any directories under /proc/device-tree/cpus/, so hopefully should be able to detect the cache size for any CPU under ppc64/Linux.

[BlisteringSheep]

geoff, a couple of problems:

In the Makefile, with the comments on the ARCH= lines, just uncommenting them doesn't work. The variable gets the value of everything up to the middle-of-line #, so ARCH is "ppc64-linux ". To have inline comments on variable declaration lines you have to use the strip function ala $(strip $(ARCH)). You can do this just once with ARCH:=$(strip $(ARCH)) to get out of putting it in each if test.

cpu.c is referencing CPU_DIR_NAME in set_cache_sizes() which isn't defined anywhere. Up in read_cache_size_file() it has the hardcoded string path.

I'm sure it was just an oversight, but the tarball includes the factors.o object file.

[geoff]

Originally Posted by BlisteringSheep

geoff, a couple of problems:

In the Makefile, with the comments on the ARCH= lines, just uncommenting them doesn't work. The variable gets the value of everything up to the middle-of-line #, so ARCH is "ppc64-linux ". To have inline comments on variable declaration lines you have to use the strip function ala $(strip $(ARCH)). You can do this just once with ARCH:=$(strip $(ARCH)) to get out of putting it in each if test.

cpu.c is referencing CPU_DIR_NAME in set_cache_sizes() which isn't defined anywhere. Up in read_cache_size_file() it has the hardcoded string path.

I'm sure it was just an oversight, but the tarball includes the factors.o object file.

Thanks Ed, I'll fix these in version 1.4.35. The stray factors.o file might be the cause of some of the problems others have had with linking.

[BlisteringSheep]

Originally Posted by geoff

Thanks Ed, I'll fix these in version 1.4.35. The stray factors.o file might be the cause of some of the problems others have had with linking.

Geoff, I got a chance to compile 1.4.35 tonight & it's still failing with the undefined CPU_DIR_NAME on line 30 of cpu.c

[BlisteringSheep]

Originally Posted by BlisteringSheep

Geoff, I got a chance to compile 1.4.35 tonight & it's still failing with the undefined CPU_DIR_NAME on line 30 of cpu.c

I changed CPU_DIR_NAME to "/proc/device-tree/cpus" & it is running fine. It detected the cache sizes correctly.

[geoff]

Originally Posted by BlisteringSheep

I changed CPU_DIR_NAME to "/proc/device-tree/cpus" & it is running fine. It detected the cache sizes correctly.

Thanks. I didn't read your earlier message properly, sorry. I have added the definition of CPU_DIR_NAME in the 1.4.36 source.

[geoff]

The changes in versions 1.5.x shouldn't affect the PPC version, they are really aimed at getting around a problem with using the floating point and integer instructions together which the PPC64 code doesn't do.

However a side effect is that the x86 and x86-64 versions now do the critical loops in two passes instead of one, and it occurred to me that this could be of some benefit to the PPC even without any changes to the assembler routines.

If the attached file is appended to asm-ppc64.h in version 1.5.5, it will cause the critical loops to be done in two passes on the PPC64.

[BlisteringSheep]

geoff,
I just wanted to let you know that this did cause a good speedup, about 10% in my testing. That is enough to make the 1.5.x series faster than the later 1.4.x versions (without this addition 1.5.x runs slightly slower than 1.4.39 or 1.4.42).