Re: Why "upx --brute" might be a bad idea...

On Oct 31, 8:32 pm, RayeR <gl...@xxxxxxxxxx> wrote:
Yes as we discused it there it have quite important effect on compiler
speed.

Here's my benchmark. I used latest libjpeg 0.6 sources for testing.
And I'm very surprised how does it so different even on such fast CPU
as C2D is! Numbers says it clear (make all):
LZMA: 41s
NRV (--best): 21s
uncompressed: 19s

I'm the one who started all this discussion on another forum. :-)

Anyways, UPXing DJGPP compiler .EXEs is good for lowering bandwidth
(e.g. DJ's slow P2 server). Of course, nobody ever did listen to me
about using AdvanceComp (advzip) for the .ZIPs. :-P

http://advancemame.sourceforge.net/comp-readme.html

Anyways, in pure DOS, UPXing speeds everything up x 2 (at least on my
old P166 w/ FAT16), but on XP or Vista the result seems to be worse
(NTVDM's fault?). Honestly, we need more people to test this and
report back. So far, all I can say for sure is that your mileage may
vary: LZMA is slower than NRV at unpacking but much better
compression. 32-bit COFF .EXEs from DJGPP are usually compressed with
LZMA even without --lzma (e.g. --brute or --ultra-brute but not --
best). Andris says he's been using --brute on his compiles.

If anyone wants to test the compilation time, they can use REDIR or
FreeDOS' Runtime. Actually, I tested with Jack Ellis' UIDE cache and
his CC (clear cache) util. And if you want to test real DOS, try my
FreeDOS image(s). But I don't expect most here worry about this kinda
stuff too much. :-/

http://www.coli.uni-saarland.de/~eric/stuff/soft/specials/runtime.zip
http://johnson.tmfc.net/dos/drivers.html
http://rugxulo.googlepages.com

.

Relevant Pages

  • Re: Release Dll Problem - Optimization Issue
    ... If optimising for speed on smaller size processors, ... This limits the compiler in using fast registers for the ... and speeds up access to the variable. ...
    (microsoft.public.pocketpc.developer)
  • Re: non load/store architecture?
    ... On the history front, I recall one company, decades ago now, ... Microcontroller speeds have advanced much less than tool speeds. ... correspondingly faster memory and disk. ... The compiler is an old DOS compiler that could use expanded/extended ...
    (comp.arch.embedded)
  • Re: Why We Use C Than C++...
    ... once for each type that must be dealt with. ... Whether you do this manually in C or have the compiler do it for you automatically in C++, it still results in two chunks of object code that are very similar. ... a C and a C++ compiler will result in similar speeds in the output. ... C++ features leads to bad performance, ...
    (comp.lang.c)
  • Re: Is export "useless and broken"?
    ... basic speeds of the compilers. ... Comeau, OTOH, compiles from C++ to ... and then invokes another compiler to translate that to object code. ... inclusion with Digital Mars, and use the results from the first test ...
    (comp.lang.cpp)
  • Re: Native code is slower than bytecodes?!
    ... The "printf" is a fundamental function in any C ... results _may_ have noting to do with the compiler itself. ... "interpret" way for executing codes, until recently the release of JDK ... - it speeds up than its previous versions. ...
    (comp.compilers.lcc)