Added results from a Phenon x4 9550 i rescued from the trash

Added P3 1200 and Celeron 1400, both Tualatins.

Added a Celeron 575 laptop. Interesting that it outperforms the Celeron 900 (3 yrs newer and 200Mhz higher frequency). Maybe because I just put a fresh OS install on the 575. BTW, it's Vista Basic 32-bit, so 7-zip is 32-bit.

If you want to test a system without Windows on it, get yourself a linux live CD that comes with 7zip. I use MX-15. Here's a screenshot that shows the Windows version of 7-zip, with important numbers enclosed in colored boxes. To the right is the linux equivalent. Just match the colored boxes to compare results.

Dictionary size in linux is "25", that is 2^25=32MB.

I'll edit the OP with this info as well.

Wait, I thought we were supposed to run the old 9.2 32-bit version.
I'll have to re-test my 4930K @ 4.5 with the latest x64 build.

My suggestion is to run 32-bit version on 32-bit cpus and 64-bit version on 64-bit cpus.

clueless1 wrote:

My suggestion is to run 32-bit version on 32-bit cpus and 64-bit version on 64-bit cpus.

It should be:
32 bit for 32 bit CPUs and 64 bit CPUs running 32 bit OSes
64 bit for 64 bit CPUs running 64 bit OSes

You can get 9.20 x64 here if you want to still use 9.20: http://prntscr.com/cyipyv
http://www.7-zip.org/download.html

I have a question. Would results from non x86 CPUs be allowed here?

I plan to get a Raspberry Pi 2/3 someday and bench it with 7z since there are an 7-zip build for ARM on Ubuntu Mate and Raspbian repos, i'm kinda tempted to try on it. There are a IA-64 (Intel Itanium) build of 7-zip 9.20 as well

Also still plan to bench more CPUs as well, i got more computer and CPUs to mess with, including a 233 mhz Pentium MMX

Carlos S. M. wrote:

It should be: 32 bit for 32 bit CPUs and 64 bit CPUs running 32 bit OSes 64 bit for 64 bit CPUs running 64 bit OSes […]
Show full quote

clueless1 wrote:

My suggestion is to run 32-bit version on 32-bit cpus and 64-bit version on 64-bit cpus.

It should be:
32 bit for 32 bit CPUs and 64 bit CPUs running 32 bit OSes
64 bit for 64 bit CPUs running 64 bit OSes

You can get 9.20 x64 here if you want to still use 9.20: http://prntscr.com/cyipyv
http://www.7-zip.org/download.html

I have a question. Would results from non x86 CPUs be allowed here?

I plan to get a Raspberry Pi 2/3 someday and bench it with 7z since there are an 7-zip build for ARM on Ubuntu Mate and Raspbian repos, i'm kinda tempted to try on it. There are a IA-64 (Intel Itanium) build of 7-zip 9.20 as well

Also still plan to bench more CPUs as well, i got more computer and CPUs to mess with, including a 233 mhz Pentium MMX

Good point. Thanks for the clarification. 😀

I think ARM results would be awesome 😀 (Just put ARM in the 'Type' column)

I've been meaning to look into this, but haven't had time yet. I could swear there were command line options for 7-zip, I wonder if you could run from MS-DOS boot disk? That would open the door to a whole bunch of slower cpus!

clueless1 wrote:

I've been meaning to look into this, but haven't had time yet. I could swear there were command line options for 7-zip, I wonder if you could run from MS-DOS boot disk? That would open the door to a whole bunch of slower cpus!

I don't know if it can run in DOS, but the command "7z b" in Windows gives the same console output as in the linux screenshot you showed above, so if there's a version that runs in DOS then I'd expect it would still be the same output. The Windows GUI benchmark is invoked with "7zg b".

7-zip claims DOS compatibility through the HX DOS Extender. However, the link on 7-zip's site is dead:
http://www.7-zip.org/links.html
I found and downloaded HX DOS Extender from Sourceforge:
https://sourceforge.net/projects/hx-dos/
and followed the directions in the text file. Basically, I copied the files from my Windows 7zip directory to DOS, copied the HX folder structure, added /HX/BIN to my environment variables, then tried the 3 methods outlined in the HX readme. None worked. 🙁
Next, I found this page:
http://www.fracassi.net/iw2evk/7zipdos.htm
and followed their directions, only to get the same errors as before.
Finally, I found this page:
http://www.ausreg.com/dos_ports/index.htm
That has an older version of 7-zip (4.58) linux version converted to DOS. Filename is p7z458c.zip
This works! Just run '7za b' after copying the file to your DOS machine. The problem is RAM 😀 on my 8MB 486/66, even a dictionary size of 2MB errors the benchmark out with a "can't allocate required memory!" message. I think if I had 64MB of RAM on my 486, I could run the benchmark to completion. Of course, the other issue is the version difference (4.58 vs 9.20). But someone with a high memory 486 could run this and get some interesting results to share here....<hint>

edit: FWIW, my 486/66 with dictionary size 18 (256KB) gets 18 MIPS, Compress Speed of 17KB/s, and Decompress Speed of 254KB/s. My POD200MMX with 32MB can only run up to Diction size of 20, and gets 100 MIPS, with 99KB/s Compress and 1298KB/s decompress. These results are very close to the Pentium 200MMX results in the charts (116 MIPS; 98/1347).

Full results for my 486DX2-66 with 8MB RAM:
7za b -md18 (forces dictionary size 18 which is highest that will complete on 8MB)

17-Zip (A)  4.58 beta  Copyright (c) 1999-2008 Igor Pavlov  2008-05-05
2p7zip Version 4.58 (locale=C,Utf16=off,HugeFiles=off,1 CPU)
3
4RAM size:     128 MB,  # CPU hardware threads:   1
5RAM usage:      6 MB,  # Benchmark threads:      1
6
7Dict        Compressing          |        Decompressing
8      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
9       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS
10
1118:      17   100     15     15  |      254   100     21     21
12----------------------------------------------------------------
13Avr:          100     15     15               100     21     21
14Tot:          100     18     18

and my POD200MMX with 32MB RAM:
7za b -md20 (dictionary size 20 max that will complete on 32MB)

17-Zip (A)  4.58 beta  Copyright (c) 1999-2008 Igor Pavlov  2008-05-05
2p7zip Version 4.58 (locale=C,Utf16=off,HugeFiles=off,1 CPU)
3
4RAM size:     128 MB,  # CPU hardware threads:   1
5RAM usage:     16 MB,  # Benchmark threads:      1
6
7Dict        Compressing          |        Decompressing
8      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
9       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS
10
1118:      98   100     87     87  |     1307   100    111    111
1219:      99   100     89     89  |     1303   100    112    112
1320:      99   100     90     90  |     1296   100    113    113
14----------------------------------------------------------------
15Avr:          100     89     89               100    112    112
16Tot:          100    100    100

I know it might be a bit of work for you but if you could create a bootable dos 6.22 floppy with the required parmaters and make it run the test in autoexec.bat .. maybe ask it how much ram your system has via batch files with a asking the user type thing and then let us pick and then run it based on what we have.. then image it with WinImage and post the resulting floppy image so we can download, write it out and run it... I'd be willing to test a bunch of machines. I have a lot of no-windows-capable machines I'd run it on.

kithylin-
that thought crossed my mind. 😉 But first I need to run some comparison tests between 4.58 and 9.20 to see if it would be safe to compare results. Otherwise, might need to make a separate tab on the spreadsheet.

I did some tests with 4.58 and 9.20 on a Socket 478 Celeron D (1GB RAM; single core, 1 thread) in XP (9.20) and DOS 6.22 (4.58). With a 32MB dictionary, their results were very similar, comparable, I'd say. But as the dictionary size was reduced, the differences in results between the two versions grew pretty significantly. And the whole idea of comparing results of different dictionary sizes doesn't feel right. Larger dictionaries will improve compression efficiency, so being "forced" to use a smaller dictionary because of a RAM limitation will punish the results. In short, we should stick with the current method (9.20 run either on Windows or Linux) with a 32MB dictionary size (which requires 512MB RAM).

We *could* make a separate tab for DOS results with a 256KB dictionary size, which would allow all systems with at least 8MB to participate. Any opinions on that?

clueless1 wrote:

I did some tests with 4.58 and 9.20 on a Socket 478 Celeron D (1GB RAM; single core, 1 thread) in XP (9.20) and DOS 6.22 (4.58). With a 32MB dictionary, their results were very similar, comparable, I'd say. But as the dictionary size was reduced, the differences in results between the two versions grew pretty significantly. And the whole idea of comparing results of different dictionary sizes doesn't feel right. Larger dictionaries will improve compression efficiency, so being "forced" to use a smaller dictionary because of a RAM limitation will punish the results. In short, we should stick with the current method (9.20 run either on Windows or Linux) with a 32MB dictionary size (which requires 512MB RAM).

We *could* make a separate tab for DOS results with a 256KB dictionary size, which would allow all systems with at least 8MB to participate. Any opinions on that?

Whole new thread? whole new table? start over from scratch for small-mem, old dos computers? It might be interesting.. I don't know if it would be useful, I doubt we'll be using 7zip..

One thing I would be interested in, basic compatibility.. if I could compress something with modern 7zip and then de-compress it in ms-dos systems I'd like to know that.. then maybe see how different systems do with faster/slower decompression.... would be fun to know.... so yeah I'd participate.. if I didn't end up filling most / all of the fields myself with my systems.

Simply from a benchmarking standpoint it might be interesting/useful. I never expected the current 7-zip database to grow as much as it has. Also, it's entirely possible to run the old benchmark on newer systems, so there still can be a way to compare the very old with the new. It will be up to the benchmarker what system they want to test.

Interesting you mention new thread/chart, vs continuing here and adding a tab to the existing chart. I'm not sure I have a strong opinion either way, are there any strong opinions on this that anyone wants to share?

clueless1 wrote:

Simply from a benchmarking standpoint it might be interesting/useful. I never expected the current 7-zip database to grow as much as it has. Also, it's entirely possible to run the old benchmark on newer systems, so there still can be a way to compare the very old with the new. It will be up to the benchmarker what system they want to test.

Interesting you mention new thread/chart, vs continuing here and adding a tab to the existing chart. I'm not sure I have a strong opinion either way, are there any strong opinions on this that anyone wants to share?

i think we should keep this thread for 7-Zip Windows/Linux benchmarks and maybe start another sheet/thread for DOS results due to the RAM/Dictionary limitations

Carlos S. M. wrote:

clueless1 wrote:

Simply from a benchmarking standpoint it might be interesting/useful. I never expected the current 7-zip database to grow as much as it has. Also, it's entirely possible to run the old benchmark on newer systems, so there still can be a way to compare the very old with the new. It will be up to the benchmarker what system they want to test.

Interesting you mention new thread/chart, vs continuing here and adding a tab to the existing chart. I'm not sure I have a strong opinion either way, are there any strong opinions on this that anyone wants to share?

i think we should keep this thread for 7-Zip Windows/Linux benchmarks and maybe start another sheet/thread for DOS results due to the RAM/Dictionary limitations

That was my thoughts exactly.. if it's going to be a different revision of the software and different dictionary size (and thus not even comparable to what we have so far at all) then I don't really see why it should be included with, or near the existing results. That's just my thoughts though.

Before I post a new thread for the DOS version of 7-Zip Benchmark, could I get some folks to look at the chart and critique it?
https://docs.google.com/spreadsheets/d/1GaRF9 … t#gid=815709577
Any changes that anyone would recommend?
Note the Read Me tab with directions. If you'd like to test, I've attached the file. Just extract it and copy it to a DOS machine. You can run it from a bootable floppy, so a hdd is not required. What it does require is 8MB of RAM. The command to run it is '7za b -md18'

I know it runs on a 486. If anyone with a 386 or slower could test, I'm curious if it will run on those platforms.

Thanks!

EDIT: I added a Core 2 Duo T7250 to the Windows list and started the new thread for the DOS Edition:
7-Zip Benchmark, DOS Edition

Here's an old IBM Aptiva I just rescued.

Pentium 100, 64MB EDO, Windows ME