I do not have a problem with prime95 / mprime taking any amount of memory, as
long as thrashing is adequately dealt with. I am currently trying to get
assignments as small as possible for memory reasons, with (from prime95 point
of view) enough memory present 95% of the day, the other 5% being
Hello all, here are my 2 euros ...
Why don't you act with the memory as you act with the CPU ?
I mean : If the machine needs it, swap the info to disk, give the memory
back, and go survey the machine's need until you can grab the memory again.
It's not as real time as if can be done to steal the
A question for readers. Prime95 currently uses about 8MB (exponent
around 11 million). How would you feel if the P4 optimized version
used 13MB? 23MB? 33MB?
I hate to code up 3 versions of the P4 code (small, medium, large),
but it might be necessary.
Whether 33MB is important depends
On 28 Nov 00, at 0:15, Jeramy Ross wrote:
33MB shouldn't be too unreasonable. I, like Nathan, have 128MB and 70MB
of that is set to be available in Prime95 and have not seen any loss of
performance.
Well, you won't be _using_ 70 MBytes, except whilst running P-1 stage
2 on a large
On 28 Nov 00, at 10:26, Martijn wrote:
I do not have a problem with prime95 / mprime taking any amount of memory,
as long as thrashing is adequately dealt with. I am currently trying to
get assignments as small as possible for memory reasons, with (from
prime95 point of view) enough memory
One of the nicer things about the windoze implementation of mprime is
the facility to manually stop restart the program from the main
menu. It gives up its main workspace whilst suspended in this way,
though obviously retaining the relatively small resources belonging
to its process
John R Pierce wrote:
One of the nicer things about the windoze implementation of mprime is
the facility to manually stop restart the program from the main
menu. It gives up its main workspace whilst suspended in this way,
though obviously retaining the relatively small resources
George wrote:
One correction to my previous post. I said that the latency to
access the L1 data cache was 2 clocks. This is correct for integer
instructions only. For floating point and SSE2 instructions the latency
is 6 clocks! Interestingly, the L2 cache latency is 7 clocks for
Mersenne Digest Tuesday, November 28 2000 Volume 01 : Number 795
--
Date: Sun, 26 Nov 2000 22:45:41 +0100
From: "Hoogendoorn, Sander" [EMAIL PROTECTED]
Subject: Mersenne: OT: Home Primes
A bit Off Topic, but i
Hi,
At 07:45 AM 11/28/00 +, Brian J. Beesley wrote:
Surely the latency is much less relevant than the throughput,
provided that there are sufficient registers and pipeline entries.
True. The manuals are unclear as to how many XMM registers are
available. There are 8 user visible ones and
This 'Wonderful' compression technology maybe "Awesome"; however, MY main
objection or perhaps philosophy towards all of this is that Prime95 is
not a large
piece of code. It takes a relatively small amount of time to download
over
a modem
compared to other software items that we modem
- Original Message -
From: Stephan T. Lavavej [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 28, 2000 2:06 PM
Subject: Mersenne: More on Compression
The P4 at 1.5 GHz is just the beginning of a sequence of ever faster
processors which I think will dominate the
*SNIP*
The question is, if compression involves a one-time, five-minute
cost on the part of the developer and saves everyone a few seconds of
download time and a few K of HD space, then why not? Why have bloated
code?
I sure like looking at 200K executables instead of megabyte and larger
On Tue, Nov 28, 2000 at 02:06:41PM -0800, Stephan T. Lavavej wrote:
The question is, if compression involves a one-time, five-minute
cost on the part of the developer and saves everyone a few seconds of
download time and a few K of HD space, then why not?
Perhaps since UPX requires a writable
I can see something like this being worth it for a very large executable
- this summer, I was forced to download the Sun JDK over a 56k modem.
It wasn't fun.
However, the question we must consider is whether saving space in a
1-meg executable is worth the extra trouble for all concerned, as
However, the question we must consider is whether saving space in a
1-meg executable is worth the extra trouble for all concerned, as well
as using a non-standard compression format.
No, no, no!
Okay, UPX packing is not an archival format like .ZIP is. It is applied to
a .EXE file and
On Tue, 28 Nov 2000, Nathan Russell wrote:
However, the question we must consider is whether saving space in a
1-meg executable is worth the extra trouble for all concerned, as well
as using a non-standard compression format.
If you want to keep stuff compressed on your disk, use the e2compr
I vote no, if anyone's counting.
Stephan, if compressing the executable is that important to you, why not just compress your own copy? It really sounds as though many of the resident list experts feel this is a bad idea.
I vote no, if anyone's counting.
(A), It's not a vote,
Stephan, if compressing it is that important to you, why not just compress
your own copy?
(B), I have, but everyone should enjoy the benefits of having a smaller
Prime95 executable, as minor as they may be.
It really sounds as though
On Tue, Nov 28, 2000 at 09:21:03PM -0800, Stephan T. Lavavej wrote:
Packed executables also have an advantage on networked systems: they can be
transmitted to other computers faster, thereby creating the illusion of
increased startup speed.
Be careful; this idea may end up backfiring on you.
20 matches
Mail list logo
