Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

p7zip 9.20.1b "testing" (Users)

posted by Rugxulo Homepage, Usono, 25.08.2012, 01:58

> If you've got the time, it would be interesting to test how the size and
> speed with -Os compares.
http://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/9.20.1/p7z9201b-misc.zip (2.1 MB)


Archive:  p7z9201b-misc.zip
Zip file size: 2206984 bytes, number of entries: 5
-rwxa--     6.3 fat   195244 b- defN 12-Aug-24 18:26 7zcon.exe
-rwxa--     6.3 fat   553556 b- defN 12-Aug-24 18:24 o3-i686.exe
-rwxa--     6.3 fat   600620 b- defN 12-Aug-24 18:24 o3i486fp.exe
-rwxa--     6.3 fat   414704 b- defN 12-Aug-24 18:24 os-i386.exe
-rwxa--     6.3 fat   451168 b- defN 12-Aug-24 18:24 osi486fp.exe
5 files, 2215292 bytes uncompressed, 2206472 bytes compressed:  0.4%


N.B. Since I was recompiling anyways, I figured I'd also do the "obvious" and make a "small as possible" sfx module. (Why didn't I think of that before?) Still too big, honestly, but whatever, I guess it supports lots of things that 7zdecode doesn't.

> I'm testing it on 2 systems, one is an old Intel Atom netbook, the other an
> i7 2600k, so it appears that -machinetype=i686 would yield best results on
> both systems. Also, you could try -O3 and I can compare if there are any
> speed differences.
I only tested "p7zip b" (totally silly benchmark, aren't they all?) on this Core i5, but of these four builds above, there isn't much difference. This is probably the compiler's fault, though. The os-i386.exe was a bit slower than others at compressing while o3-i686.exe (686+ only, -march=i686) was a bit faster than others at decompressing. Otherwise, basically the same.

EDIT: I have no idea if native build via DOSEMU works anymore. Probably not, at least not without some tweaks. At least that would let me use newer G++, e.g. 4.5.0 first introduced explicit support for Atom. I never had any Atoms, only heard first ones were "in order" (like 486, see above) and later were "out-of-order". So I have no idea what would help here.

> > > which I still use,
> > > and which was also compiled with [FSU] pthreads. There seems no speed
> > advantage
> > > at all to 9.13 vs 9.20, are there any hidden advantages?
You'll have to ask Khusraw. Maybe I could email him. Anyways, it depends on what compiler version and options he used.

> > Honestly, I don't know, perhaps bugfixes. I didn't check the changelog,
> > just assumed it was better! :-)
> >
> > http://www.7-zip.org/history.txt
>
> Lots of "bug fixes" listed since 9.13, but it is not specified what these
> fixes are or do!
Dunno. If it doesn't bite you, then it doesn't matter, I suppose.

I vaguely remember DOS386 mentioning this one (esp. since he had written his own 3rd-party fix for previous versions), but I don't use passwords, so I never tested it.

"- The console version now doesn't show entered password."

> > > EDITED to ask if it's possible to get a compile of 7zip .ZIP deflate
> > modes
> > > ONLY, without any other compression modules?
> >
> > No, not really, not that I know of. You can try AdvanceComp's ADVZIP.EXE
> > ("-z4") to repack .ZIPs in place. It may? also allow creating archives
> from
> > scratch, but I don't know if that's .7z only or what (can't remember).
> >
> > http://advancemame.sourceforge.net/comp-readme.html
> >
> > N.B. Those binaries of his are several years old
>
> Yes, I've used ADVZIP for years, however even its "insane" setting isn't as
> good as 7zip's -mx9 deflate settings for creating optimized .ZIPS. This may
> be due to the old age of the code (2005) I'm using, but see below!
>
> I found AdvanceComp 1.16 beta here:
> http://advancemame.sourceforge.net/beta/
> which is the latest version for DOS I can find.
I wasn't aware of this, but it's probably? minor.

> It doesn't improve on speed
> or compression. If you've got newer code that you can compile (with
> machinetype=i686 and -O2 or -O3 GCC compiler options, I'd love to try them
> out! Thanks for offering.
I don't have any newer code, but I can cross-compile with (newer) G++ 3.4.6. (Didn't he use older 3.2.3 ??) Actually, I've successfully rebuilt it with DJGPP natively before (though needs GNU Configure + assorted tools, somewhat annoying but not really hard, comparatively!!). So I could try that, but for the moment, I haven't (yet). TODO!

EDIT: In my limited experience, G++ 3.x seems to improve on -O3 for common code, but 4.x doesn't. So I don't think -O3 would help there, but who knows, without testing I can't say for sure.

> > I assume this means you used the second one ('\' fixes, aka
> > "9.20.1b-testing")?
>
> Yes, that second one works perfectly for me with -mx8 and -mx9 and .EXE
> filters, your first compile did not work with -mx9 and .EXE filters. Good
> sleuthing on figuring out that compiler error!
FYI, these "misc" binaries mentioned in this post did not workaround such a thing, so they probably still have that bug. Sorry, but I didn't want to complicate (or confuse) any benchmarking. If you really want, I can recompile again with same switches and have them all "fixed" (just use "-Os" for the BCJ*.cpp files). But honestly, I think random benchmarking non-.EXE files should be sufficient for now.

It's an interesting idea to compile for various machines, but if it doesn't show much benefit, there isn't much point. So I'd rather target only one or two common ones, if possible (so as not to be too confusing). BUT ... we shall see. ;-)

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum