mersenneforum.org Sr2sieve on PPC/Linux
 Register FAQ Search Today's Posts Mark Forums Read

2007-03-13, 05:02   #111
BlisteringSheep

Oct 2006
On a Suzuki Boulevard C90

2·3·41 Posts

Quote:
 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

 2007-03-14, 18:57 #112 Greenbank     Jul 2005 6028 Posts Yes, Linux man pages for sysctl() do warn you away from using sysctl() in favour of scraping the info from text files in /proc.
2007-03-15, 00:46   #113
geoff

Mar 2003
New Zealand

13·89 Posts

Quote:
 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.

Last fiddled with by geoff on 2007-03-15 at 00:48 Reason: directory name

 2007-03-18, 00:40 #114 geoff     Mar 2003 New Zealand 22058 Posts 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. Last fiddled with by geoff on 2007-03-18 at 00:40 Reason: directory name
 2007-03-18, 07:02 #115 BlisteringSheep     Oct 2006 On a Suzuki Boulevard C90 2·3·41 Posts 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. Last fiddled with by BlisteringSheep on 2007-03-18 at 07:03 Reason: added location of ARCH problems
2007-03-20, 02:20   #116
geoff

Mar 2003
New Zealand

13×89 Posts

Quote:
 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.

Last fiddled with by geoff on 2007-03-20 at 02:21 Reason: version

2007-03-23, 03:21   #117
BlisteringSheep

Oct 2006
On a Suzuki Boulevard C90

111101102 Posts

Quote:
 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

2007-03-23, 04:13   #118
BlisteringSheep

Oct 2006
On a Suzuki Boulevard C90

111101102 Posts

Quote:
 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.

2007-03-24, 01:51   #119
geoff

Mar 2003
New Zealand

13·89 Posts

Quote:
 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.

2007-05-28, 02:04   #120
geoff

Mar 2003
New Zealand

22058 Posts

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.
Attached Files
 vec-ppc64.txt (2.1 KB, 129 views)

 2007-06-15, 05:21 #121 BlisteringSheep     Oct 2006 On a Suzuki Boulevard C90 2×3×41 Posts 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). Last fiddled with by BlisteringSheep on 2007-06-15 at 05:21

 Similar Threads Thread Thread Starter Forum Replies Last Post rogue Software 304 2021-11-06 13:51 pepi37 Software 5 2013-08-09 22:31 SaneMur Information & Answers 2 2011-08-21 22:04 mgpower0 Prime Sierpinski Project 54 2008-07-15 16:50 nuggetprime Riesel Prime Search 40 2007-12-03 06:01

All times are UTC. The time now is 01:10.

Fri May 20 01:10:45 UTC 2022 up 35 days, 23:12, 2 users, load averages: 1.78, 1.61, 1.47