Doing TF and LL together on HT-System / Impact on TF-limit tradeoff calculation?

[cheesehead]

Originally posted by GP2
It's a pity that trial-factoring isn't much of a bottleneck for the project right now.

But that's only because of the current choice of TF limits.

Simply add 1 to each TF default power-of-two limit. All those Mnumbers that had been TFed up to their former default limits suddenly need extra TF work that equals the total of all previous TF work done on those numbers in the past! Instantly, we have a TF bottleneck -- doubled the TF workload!

[TauCeti]

Originally posted by cheesehead
But that's only because of the current choice of TF limits.

Simply add 1 to each TF default power-of-two limit. All those Mnumbers that had been TFed up to their former default limits suddenly need extra TF work that equals the total of all previous TF work done on those numbers in the past! Instantly, we have a TF bottleneck -- doubled the TF workload!

And we do not even have to "finish" the next power-two. Even Factoring up to xx% of a new limit makes sense. AFAIK the chance of finding a factor in the first 50% of a given limit should be (marginally) higher compared to the second half.

At least for me Hyperthreading is extremly usefull. I occasionally participate in Zetagrid and NFSNET and with HT i can Trial factor with 80-85% thoughput and run the other project with more then 70% peak. It is marvelous

Some more numbers the check, if raising TF-limit actually makes sense with HT-P4s:

Take exponent range 28000000 on a P4-3GHz for example. To LL those exponents, it takes (roughly) 21 days. With double check we have 42 days equal to 1008 hours. Right now, those numbers are only Trial factored up to 2^67. Because of the chance finding a factor between 2^67 to 2^68 is about 1/68, it makes sense to factor up to 2^68 if we are able to do so in less then 15 hours (1008/68). That is very close to the time the P4-3000 actually needs to TF from 2^67 to 2^68 (should be about 15 hours - not sure).

So - and i did not expect it - the TF cutoff points look like they are suited well even with the P4. The faster TF of a P4 is compensated by the faster LL. The 28000000 range is the upper limit of the 2^67 range. For lower numbers, the 2^67-factoring limit even looks to be set to high...

Taking HT into account, one can boost TF-performance about 60% (for our special case running 'compatible' projects on the box). But i don't think that 60% could justify raising 2^67 to 2^68.

I think the "step" between 2^67 and 2^68 is to big. Maybe the client can be modified to calculate the optimal value for Trial factoring in a way, that "fractional" results are allowed, that means e.g. "number XXXX factored up to 2^67 and 40% of 2^68". Of course that information had to be send back to the server after TF.

So, i am not that optimistic that raising the TF limits really helps a lot but i would like an option in the client to do so (just add "1" to the power-two). At least users who would not run prime95 as a primary DC-project but would like to use TF HT together with their project, may be interested to use that option and gain ranks in the Top-TF list.

[GP2]

Originally posted by PageFault
Crunching seti results in a huge gain - at 3 GHz, two clients produce about 20 WU per day. As a result, the AMD trollboyz are very disappointed. Those who have crunched seti know how impressive that is. f@h is reputed to have similar gains. It appears that anything with inefficient code gains from multiple deployment.

Ah, I forgot that nearly every other distributed-computing project out there does not have the finely-tuned assembly code of Prime95. So people on such projects will simply run a second copy of their own client to get greater throughput, and won't be interested in swapping crunching with GIMPS. The idea was probably logistically unwieldy anyway.

[QuintLeo]

In my experience, the Distributed.net project is the only other one that fine-tuned assembley coded their work - and I don't think they've done that *yet* on the current RC5-72 project clients.

I do miss the days that the K5 was *the* most efficient RC5 cruncher per Mhz - first along came the Athlon, which barely edged it out, then the P-III got fine-tuned and ran almost as well as the Athlon, then the G4 Altivec core showed up and that AltiVec client blew EVERYTHING else out of the water - though my K5 PR166s were STILL faster (at 117.5 actual Mhz) than MMX Pentiums up to 166, and very close to the 200Mhz MMX Pentiums even after the "MMX" core showed up....

I'd be curious to see how a ClearSpeed client would do - RC5 uses a lot of 32-bit integer operations, and CAN be easily paralellised (have each "core" work on a seperate key at the same time, similar to how the EFF dedicated DES cracker machine worked)....

[PageFault]

Its more likely the high fsb (assuming yours is at 250). I have HT off, w2k, and the box is hella responsive to any action not involving the file system. Frankly it shocks me and I have always had a bleeding edge machine - never have I felt anything like that before.

I wonder how that would feel in my main box with SCSI. Maybe a future project, 1000 MHz fsb cpu + 1 GB ddr500 + SCSI ... I'm waiting for Prescott or EE, the cache sounds real nice ...

Originally posted by nucleon

What I find with HT is that the PC feels more responsive. I think that I/O is handled better with a HT CPU. I noticed that with the LL and P-1 test at the same time, the PC "felt" slow. The PC didn't respond as quick to my keyboard/mouse clicks.

[nucleon]

If cache is your thing, then this story deserves a big Keanu 'Woah':

http://www.theinquirer.net/?article=12145

But what I'm looking forward to is the PCI Express. With proper RAID caching controller on PCI express and SATA drives, that should fly.

-- Craig

[PageFault]

Going back on topic, suddenly it seems sensible to follow this for 33M work. I'm building a second 2.4C / P4P800 for dedicated 33M crunching. If the orphanage can't accomodate me (its purpose it to save on factoring time, hence our collecting of expiring exponents from people who left the team) then it would be a simple matter of logging on, copying worktodo entries and firing up a second client to do the trial factoring and then stopping it once done.

For the multiple clients thing, HT could be very helpful. The ars UD team has pitched in to help defend against curtisc's borgs while we mass more troops and in return a UD client could be run at a priority below prime95 - the idea works because apparently UD awards points based on hardware even if little work is done. The typical TPR machine would score big on UD, highest speed P4 possible with large amounts of ram.

[PageFault]

This was done in the past with other ars teams. Particularly effective was the trades with the eccp109 team, swapping tbirds for P4's did help rack up my prime95 scores and helped put TVM in the win.

Originally posted by GP2
So people on such projects will simply run a second copy of their own client to get greater throughput, and won't be interested in swapping crunching with GIMPS. The idea was probably logistically unwieldy anyway.