On 19 Oct 99, at 20:17, [EMAIL PROTECTED] wrote:
> [... snip ...]
> Since the all-integer algorithms tend to run 5-10X
> slower on similar hardware as the floating-FFT-based ones, the only way
> to effect an all-integer verification was to parallelize it: a floating-
> point run serves as a "wavefront" and deposits residues periodically, and a
> number of "drone" machines running integer-based convolutions, with each
> grabbing a pair of residue files, say drone Y gets files for squarings x1
> and x2, with x1 < x2. Drone Y then starts with the x1 residue, does (x2-x1)
> modular all-integer squarings, then compares that result with the contents
> of the floating-point generated x2 residue file. In this way, one can use
> multiple slow machines to check the results of one fast machine in about
> the same time the fast machine needs for the calculation.
This is an excellent justification for the idea of keeping savefiles.
Perhaps there's still useful work for slow machines to do?
> Having a standard,
> platform-independent savefile format means that one can write a high-level
> (e.g. C) code for the verification, compile it on any needed platform, and
> not have to worry about converting savefile formats.
The burden of converting from least-significant-byte-first to most-
significant-byte-first format is hardly significant, given that it
needs to be done rarely. Only when a savefile written by a system
with one convention is picked up by a system using a different
convention.
> Crandall's Fermat-number
> format does a bytewise write of the residue, i.e. one doesn't need to worry
> about whether a given machine uses a big or little-endian scheme for storing
> individual bytes of integer data.
Having made an idiot of myself on the subject of integer divide
instructions (thanks to Peter Montgomery for correcting me!) I hate
to sound dogmatic about this. But I can write an entire array of any
size with one call from a high-level language, whereas writing it
byte by byte takes as many calls as there are bytes in the array.
Given that the system call is likely to involve a processor context
save & restore and a switch from user to kernel privelege & back
again, I rather suspect that the single call method may be more
efficient. The problem with the single call is that the data will be
written in the processor's native format.
It's true that the physical I/O performance will probably regulate
the time interval needed to read or write a savefile, irrespective of
any extra processing. Savefile write (for security) is probably going
to be the commonest operation. We don't neccessarily need to wait for
the savefile write to complete; we could make a copy of the memory
buffer & carry on crunching numbers using the spare CPU cycles
available whilst the I/O subsystem is busy writing.
Unless I'm completely up the garden path (again) I think it's going
to be worthwhile putting up with the "complication" of having a byte
order flag.
>
> Not true - all of the fastest codes (Prime95, Mlucas and MacLucasUNIX) write
> residue digits in 4-byte integer form to one or more savefiles. Only MLU
> writes a floating-point version of the residue, in addition to the integer.
I think MacLucas just writes the residue as it stores it in memory
i.e. an array of 2^n double-precision floating-point values. This is
wasteful, since there's a whole bundle of trailing zeroes in the
mantissae, once rounding to the nearest integer has been carried out.
>
> I discussed the idea of a platform-independent savefile format with George
> and Scott several times during the past year, in conjunction with the idea
> of central (e.g. PrimeNet) storage of user residues at periodic intervals;
> Scott's major objection was that he didn't think the amount of work lost
> due to hard disk problems, accidental savefile deletion or user dropout
> justifies such an effort. On the other hand, he admitted he didn't really
> have a good estimate of the incidence of the above events (except possibly
> the latter item). My main point was that as exponents get larger, the
> likelihood of the above occurrences is likely to increase, but one still
> needs a reasonable estimate of how frequently it occurs now. The best
> prospect for doing this would seem to be some kind of e-mail poll of the
> current users, and that needs a decent response rate to be significant.
> (And human memories are notoriously unreliable.)
The responses would be biased by the fact that those replying would
tend to be the more concientious users.
>
> A less intrusive, logistically simpler method might be to simply look at
> the percentage of exponents that are reassigned by PrimeNet after their
> time limit expires. One might assume that that these were on average
> 20% completed, so if 5% of exponents get reassigned, one estimates that
> 1% of work could be saved if the savefiles for said exponents could be
> reassigned, as well.
>
> Interestingly, Scott seemed to think the bandwidth needed for storing
> and managing user savefiles was less of a problem than justifying the
> need for such a strategy in the first place. (Scott, correct me if I'm wrong
> in my recollection about this.) Obviously not all users
> will have sufficiently fast Internet connections to allow them to
> participate in such a scheme, but it's not something that should be
> mandatory in any event.
If we could get double-checks done by banks of slower machines
(perhaps 486's or low-end Pentia, like those often still found in
secondary school laboratories) we might be able to encourage more
people to take an interest. This would, in itself, be a
justification.
I certainly agree that we shouldn't try to make the scheme mandatory!
But, if only 5% of the systems participated, that would still
generate plenty of work for a large number of slower systems - which
might well have reasonable network connectivity.
Regards
Brian Beesley
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
