> From: George Woltman
> Now for some good news-------->
>
> Prime95 v19 is under way. It involves rewriting ALL the FFT code!
> So this QA project is quite timely.
>
> What's new in v19? It should support FFT lengths from 32 up to 4M
> with PFA lengths (3*power-of-two and 5*power-of-two) supported.
> It has a slightly modified memory model that should be more efficient in
> using the Pentium's TLB (translation look-aside buffers) cache for
> larger FFT sizes. A little less memory traffic for some FFT lengths.
> P-1 factoring support.
>
> What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n)
> GCD to make P-1 and ECM factoring on larger exponents feasible. A more
> memory efficient but slower stage 2 for large exponents. Several
> FFT sizes
> are not coded yet. Obviously, don't expect v19 anytime soon!
>
> Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster.
>
> Oh, and by the way, the re-engineered assembly code will be easily usable
> in other large integer programs.
George...is it too late to request features for the new version?
I had done some thinking on it, and wouldn't it be great if there were some
sort of "live update" feature, where it could upgrade itself when new
versions come out. That's pie in the sky and I remember discussing
previously how that wouldn't work for everyone - security issues, bandwidth
issues, etc. but perhaps if it were an option.
At the very least, I think that there should be an "alert" or other
notification of some sort when a new version comes out, rather than relying
on emails being sent. The problems with version 17 should give a good
example of how that would help. A problem is found with a version, or
simply a new faster version is out, so the next time Prime contacts
Primenet, it sees some flag set and pops up a box on the screen telling the
user about the new version. And a seperate option for how often to check
for "messages" besides the number of days between checking in at primenet to
update expected completion dates.
Also, do you plan to optimize the assembly code in any way for the new types
of CPU's out? AMD's K6-3, Pentium III, etc. It would certainly "seem" that
some slight tweaking could be done to squeeze out a few extra percent of
improvement, but I could only guess at that. Maybe just recompiling the
assembly in a compiler that is PIII/K63 aware would take advantage of the
processor type, and then just include each compilation in the program with
the appropriate branches into the code depending on the CPU type actually
being used, just as you have now for PPro/PII, Pentium, etc.
One other thing that is, perhaps more pie in the sky, but central
configuration for a team. What I mean is, for all my computers, I generally
have them set the same in terms of days between check ins, minutes between
retries, etc. If I ever need to change some setting, I have to go to each
machine (over the network at least) and change each instance. I thought
it'd be nice if there were a feature where you could set some configuration
to point to a local network share that contains the latest "master" copy of
the prime.ini file. Each time the program starts, it would check the master
for any changes, or continue with the existing INI file if the master isn't
reachable or if no changes were found. Or maybe have it check it on a
regular, adjustable schedule.
Oh yes, I thought of one more thing. Currently, things like affinity and
the service names for NTPrime are located in the PRIME.INI file. Since
those are more peculiar to the instance running, I thought that perhaps
those options would be better suited in the local.ini file. Reason being, I
have several quad processor machines and I have to modify not only local.ini
to set the "computerid" but also prime.ini for each instance to set a unique
service name and affinity. Wouldn't it be better to have just a single,
unchanged prime.ini for each one and only have a unique local.ini that has
all the changeable info in it? That makes the idea of a centralized
prime.ini that much better/easier.
Thats all. For now. :-)
Aaron
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
