If you think that one or two changes might get the system slighlt slimmer and give you that extra 1 per cent speedup in Einstein then...
Remember to emerge gentoolkit - can be a lifesaver - might allow you to crunch for Einstein instead of re-installing...
That package gives you the "emerge -pv depclean" (**** PLEASE **** note the -pv bit, which you remove once you have checked the results) this allows you to remove what depclean thinks is not required for the system - works well especially after an "emerge -e world" (grin) - it removes unneeded dependencies.
You MUST run "revdep-rebuild" after a depclean to check stuff hasn't got broken someplace. The 2 together allow for lots of happy tweaking sessions, while still being able to BOINC afterwards, rather than yet another re-install.
Cheers - Gray
PS: check depclean reults carefully - sometimes safer to just use it to give a list and then remove what you think appropriate...
Not really my free choice. But my harddisk failed terribly. It started squeezing. Very scary. So I ripped it out, and now I'm running diskless. Fortunately I had my home directory still on an external hd, so nothing important lost (well, ok some WUs..)
If everything remains running well, I'll be runnning diskless for a while. This laptop is too old to replace its parts. So when the money is there, it will be completely replaced (and this one will remain crunching). And with Gentoo on it!
Anyway, a good opportunity to check DSL for it's performance. 34 processes, running 1000 % cpu, with 99.9% for BOINC. And using just 19% of RAM (of 234MB). It's very light weight and fast.
Yeah I tried DSL for a while - not a bad system at all ! I also ran BOINC therein for a couple days as well, way back when a linux box did around a third less Einstein than an XP box - the bad ol' days (grin), but back then my cpu and graphics fan were not Zalmans and hence amazingly noisy, so I had to close down every night and just got irritated by the startup routine - just was not what I wanted. But for speed... it is not bad - was my first intro to Fluxbox in fact.
Hope to see you back with Gentoo in the not too distant future.
Re that script - that would come in vert useful - I'd like to see it when you finish :)
If you're still interested in that script, please contact me on (I'll remove my mail adress in a while...)
DSL is running fine, although not as fine as Gentoo. It takes about 30 mins more to crunch a WU. But not as bad as bloated Knoppix (although I haven't tried it with fluxbox)... That script came in quite handy, as I'm running DSL without X (it just hung after a while).
Certainly, I'll be back with Gentoo!
Happy crunching! I see your RAC is already increasing again.
The 2.6.20 kernel has this new feature for 32 bit x86 processors which should speed up FPU-intensive programs a little.
Sleazy FPU optimization
This is a x86-32 port of the x86-64 feature implemented in 2.6.19. It doesn't gives huge performance except a small improvement in FPU-intensive programs, but it's also a interesting optimization. Right now the kernel has a 100% lazy fpu behavior: after *every* context switch a trap is taken for the first FPU use to restore the FPU context lazily. This is of course great for applications that have very sporadic or no FPU use (since then you avoid doing the expensive save/restore all the time).
However for very frequent FPU users you take an extra trap every context switch. This feature adds a simple heuristic to this code: After 5 consecutive context switches of FPU use, the lazy behavior is disabled and the context gets restored every context switch. If the app indeed uses the FPU, the trap is avoided (the chance of the 6th time slice using FPU after the previous 5 having done so are quite high obviously). After 256 switches, this is reset and lazy behavior is returned (until there are 5 consecutive ones again). The reason for this is to give apps that do longer bursts of FPU use still the lazy behavior back after some time.
Hello Bert If you think
)
Hello Bert
If you think that one or two changes might get the system slighlt slimmer and give you that extra 1 per cent speedup in Einstein then...
Remember to emerge gentoolkit - can be a lifesaver - might allow you to crunch for Einstein instead of re-installing...
That package gives you the "emerge -pv depclean" (**** PLEASE **** note the -pv bit, which you remove once you have checked the results) this allows you to remove what depclean thinks is not required for the system - works well especially after an "emerge -e world" (grin) - it removes unneeded dependencies.
You MUST run "revdep-rebuild" after a depclean to check stuff hasn't got broken someplace. The 2 together allow for lots of happy tweaking sessions, while still being able to BOINC afterwards, rather than yet another re-install.
Cheers - Gray
PS: check depclean reults carefully - sometimes safer to just use it to give a list and then remove what you think appropriate...
Well, I'm running DSL
)
Well, I'm running DSL now...
Not really my free choice. But my harddisk failed terribly. It started squeezing. Very scary. So I ripped it out, and now I'm running diskless. Fortunately I had my home directory still on an external hd, so nothing important lost (well, ok some WUs..)
If everything remains running well, I'll be runnning diskless for a while. This laptop is too old to replace its parts. So when the money is there, it will be completely replaced (and this one will remain crunching). And with Gentoo on it!
Anyway, a good opportunity to check DSL for it's performance. 34 processes, running 1000 % cpu, with 99.9% for BOINC. And using just 19% of RAM (of 234MB). It's very light weight and fast.
Somnio ergo sum
Hello Bert Yeah I tried
)
Hello Bert
Yeah I tried DSL for a while - not a bad system at all ! I also ran BOINC therein for a couple days as well, way back when a linux box did around a third less Einstein than an XP box - the bad ol' days (grin), but back then my cpu and graphics fan were not Zalmans and hence amazingly noisy, so I had to close down every night and just got irritated by the startup routine - just was not what I wanted. But for speed... it is not bad - was my first intro to Fluxbox in fact.
Hope to see you back with Gentoo in the not too distant future.
Gray
Hi Gray! RE: Re that
)
Hi Gray!
If you're still interested in that script, please contact me on (I'll remove my mail adress in a while...)
DSL is running fine, although not as fine as Gentoo. It takes about 30 mins more to crunch a WU. But not as bad as bloated Knoppix (although I haven't tried it with fluxbox)... That script came in quite handy, as I'm running DSL without X (it just hung after a while).
Certainly, I'll be back with Gentoo!
Happy crunching! I see your RAC is already increasing again.
Regards,
Bert
Somnio ergo sum
The 2.6.20 kernel has this
)
The 2.6.20 kernel has this new feature for 32 bit x86 processors which should speed up FPU-intensive programs a little.
Sleazy FPU optimization
This is a x86-32 port of the x86-64 feature implemented in 2.6.19. It doesn't gives huge performance except a small improvement in FPU-intensive programs, but it's also a interesting optimization. Right now the kernel has a 100% lazy fpu behavior: after *every* context switch a trap is taken for the first FPU use to restore the FPU context lazily. This is of course great for applications that have very sporadic or no FPU use (since then you avoid doing the expensive save/restore all the time).
However for very frequent FPU users you take an extra trap every context switch. This feature adds a simple heuristic to this code: After 5 consecutive context switches of FPU use, the lazy behavior is disabled and the context gets restored every context switch. If the app indeed uses the FPU, the trap is avoided (the chance of the 6th time slice using FPU after the previous 5 having done so are quite high obviously). After 256 switches, this is reset and lazy behavior is returned (until there are 5 consecutive ones again). The reason for this is to give apps that do longer bursts of FPU use still the lazy behavior back after some time.
http://kernelnewbies.org/LinuxChanges