> >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.
>
> This feature would have meant that V17 shift count bug would have cost
> the project more cpu years than it did. In my case, its impact is a
> little under 1 cpu year (one exponent in the 10.5M area) because most
> processors I'm running were at older versions.
Well, that is unfortunately true in this case, but that also means there
will be CPU years being wasted by folks still running v17 who haven't heard
the news yet. Either way, when a version is buggy, you lose. As long as it
was optional.
Further thinking points me in the direction that you could point each
primenet client to a local server somewhere to retrieve updates. I do that
for McAfee Antivirus on my network of about 2 dozen servers. Put the latest
DAT files on a shared directory and schedule the servers to check for
updates every day. When a new DAT comes out, I test it on my machine and if
it's good, I put it in that directory and the servers will update themselves
in no more than 24 hours automatically.
For Norton programs, there's the Live Update Admin Utility where you can put
Live Updates on a local server and point all the Norton programs there
instead of the Symantec site.
Things like that are really wonderful, and if you're the type who'd rather
stick with an older version unless you *need* to upgrade, you do have that
option as well.
> There is a publicly available service which checks for changes in
> web pages,
> and sends email when a checked page changes. I think Internet Explorer
> V5 supports some sort of favorite-page-change detection too.
IE4 and IE5 have that (probably Netscape too?), and I think the web site
that checks and sends emails is www.mindit.com.
> This combined with being able to remotely stop an NT service and deposit
> updated files from a batch procedure on one workstation makes managing
> large numbers of workstations practical and quick.
Remember, you're talking to a guy who installed thousands of instances of
NTPrime remotely, across 3 different states, in a matter of days (using
nothing more than 4NT batch files and RCMD/NETSVC programs from the resource
kit). But we won't go there. :-) I'm not saying it can't be done, but it'd
be so much easier with some sort of built-in method for self-updates.
> I would find a popup box a terrible nuisance, so I'd like an option
> to turn it off or on, with default off.
If it were an option, there should be a way for REALLY important alerts to
get through, so that anyone running v17 would have been alerted about the
bug even if normal alerting were turned off. Wouldn't you rather have some
exceptions get through, with the decision about what qualifies as
"exceptional" being made by George and/or Scott?
> The feature I'd like to see at some point is the LLtest code made dual-cpu
> aware, splitting the load so one cpu does one half of the run-length and
> the other cpu does the other half, so that the onboard and on-chip caches
> would be more efficiently used, and total working set smaller,
> and exponents completed more quickly. I have a dual-pentium 200 MMX that
isn't terribly
> fast when running two prime95 instances on exponents above 10^7. The
> performance on the dual-pentium or dual-ppro systems I have access to is,
> when running two instances, about 1.6 times that of running 1 instance.
> So there is some room for improvement. On this setup, there are
> 2 L1 caches,
> but one L2 cache being shared by two prime95 instances.
Amen. In fact, if it were possible to code it to split the work among
multiple CPU's in any way, then it *is* technically possible to have even
seperate machines work on the same number, though you'd be limited by the
network link speed.
Consider. If you had a chip with multiple FPU engines, couldn't you code
the program to take advantage of that? From there, it's only a small step
to using the FPU processors on *seperate* CPU's, and from there, given a
fast enough link, seperate CPU's on entirely different machines.
SMP in NT does provide for some nice code-sharing parts that could make it
easier, but I'll leave it to the programmers to decide if the idea has any
merit.
In your case, sharing a single L2 cache is probably why you're seeing a
performance hit. On the quad PPro's I have, I run 4 instances of NTPrime,
each with the affinity set to a particular CPU, and I get just about 4X the
performance of a single CPU. They're Compaq servers and the architecture of
them is lovely though...buffered memory, of course each PPro has it's own L2
cache and I think they're the 1MB L2 cache chips, but I'm not sure.
Speaking of cache sizes, how much faster would you expect Prime95 to run on
a Pentium III Xeon with 2MB L2 cache, as opposed to one with only 512K L2
cache?
Aaron
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
