> 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 users may download in a
weeks
> period.
> Maybe if Prime95 was ..say .. a 20MB download. Then perhaps shaking
things
> up to save
> some download time would be a good idea, but as things stand now we are
only
> talking about saving 20 or so seconds. Perhaps that is the reason people
> may find it 'objectionable'..
> Maybe its just not worth the hassle at the moment for this particular
> application....
Actually, the download time wouldn't change all that much. (The package
would go from 400K to 300K.) But the executable itself, once unzipped,
would only be some 200K, as compared to over 1MB before. It's just more
efficient. 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
things. Makes me think of my old 486 where everything fit in 120MB.
> P.S. The website for the compression program never resolved for me; I'd
> like to take a look at it, if someone would send me the IP.
http://upx.tsx.org is a redirection URL for
http://wildsau.idv.uni-linz.ac.at/mfx/upx.html.
> The P4 at 1.5 GHz is just the beginning of a sequence of ever faster
> processors which I think will dominate the market for a long time
> to come, and, yes, with RDRAM giving much improved memory
> performance, which should give Prime95 a real kick.
RDRAM isn't good: http://www.tomshardware.com/.
> Sorry, I misunderstood your message. (Looks like I wasn't the only
> one...)
Indeed.
> Isn't the problem here that a page of code or data loaded from the
> executable has to be expanded each time it is loaded from the
> executable? This isn't a problem when there is loads of system memory
> available, but standard practise is to simply discard unmodified
> pages which are paged out, as they can be reloaded from the binary
> executable as easily as they can be reloaded after being written to
> the page/swap file. So running a compressed executable involves
> either more usage of memory or extra CPU cycles on each unmodified
> page fault.
No, the decompression cost is not paid again and again while the executable
runs: there is no (significant) memory cost or compute cost. I don't claim
to understand how UPX works, although I intend to learn some day, but the
UPX homepage notes "Your executables suffer no memory overhead or other
drawbacks". Also, "very fast decompression: more than 10 MB/sec even on my
old Pentium 133", "no memory overhead for your compressed executables",
"safe: you can list, test and unpack your executables. Also, a checksum of
both the compressed and uncompressed file is maintained internally." The
two things that don't work with UPX are executables that want to read data
from themselves and things with "overlays". (And, of course, executables
that want to _write_ to themselves), but for everything else it almost
always works and is transparent.
UPX works for Linux too - isn't there a Linux port of Prime95? The entry
for UPX's Linux capabilities in its readme does detail some of its inner
workings. It is lengthy.
Stephan
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
