Then it tests CPU Frequency again (in multithreading mode, if multithreading mode was specified)
CPU 199 2868 5696 101 200
2868 is not correct CPU frequency here, since Hyper-Threading doesn't give full resources to each thread from two threads.
Then it tests Compression, Decompression and HASH calculation code.
MIPS - are results normalized for AMD K8 cpu.
Effec - are results normalized to CPU frequency.
For example, Effec = 130 means that CPU is 30% faster per MHz than AMD cpu.
The test AES256CBC:2 - is AES hardware test (that test is supported only if CPU supports AES instructions).
You can post results here at forum for your CPU.
Please write full name of your CPU and real CPU frequency, if you know it.
The results for two tests are interesting:
7z b -mm=* -mmt1
7z b -mm=*
Please use "Code Highlighting" for results in messages.
You can designate a code block by surrounding it with lines of tildes:
However my CPU has an IDA p-state (Intel Dynamic Acceleration) which should clock one (and only one) core at 2400 MHz (multiplier 9 instead of 8.5) if the other core is idle. I don't know if it was active during tests though, since I don't know of a reliable way to detect IDA p-states.
I'll try the above commands later (I'm on another computer right now).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CPU was configured for maximum performance (so by default multiplier 8.5 is used).
However I don't know if this disables IDA, too (and I don't know software that is designed to disable IDA). Also I was never really able to test if IDA is used since
a) I don't know of a tool that is designed for this (only general tools, that show the current CPU clock).
b) IDA is never active all the time. It's only active for fractions of a second, since the limitation applies that other core has to be idle (which is very unlikely on modern systems)
If you know of better ways to test this, please tell me (I assume you have run into similar issues when benchmarking).
Last edit: Ede_123 2015-01-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to CPU-Z the CPU was running mostly with multiplier 34 (3.4 GHz) during tests.
For the test with one thread sometimes Multiplier 35 (3.5 GHz) or (seldom) 36 (3.6 GHz) was set.
(If you know how of an easy way to fix i5 CPUs with Intel Turbo Boost to a specific multiplier and need those tests, too, tell me. I could retest then.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now for me it's not so important to get exact results without Turbo-Boost.
I just wanted to check that CPU frequency detection works OK. In your case it showed:
3543 (-mmt1)
3380 (-mmt4)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cpu usage is higher than 100% for single thread.
Probably GetProcessTimes() function returns incorrect results for such overclocked cpu.
What exact settings do you change to overclock cpu: BIOS or some program?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kernel Time = 0.312 = 0%
User Time = 174.908 = 102%
Process Time = 175.220 = 103% Virtual Memory = 225 MB
Global Time = 169.953 = 100% Physical Memory = 208 MB
7-Zip [64] 9.38 beta Copyright (c) 1999-2014 Igor Pavlov 2015-01-03
Kernel Time = 1.778 = 0%
User Time = 727.791 = 379%
Process Time = 729.569 = 380% Virtual Memory = 897 MB
Global Time = 191.766 = 100% Physical Memory = 798 MB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Intel Core i5-3570 (Ivy Bridge) at 3600 MHz (original 3400, overclocked by 2 multiplier steps), Turbo Boost active (up to 3800 MHz); 2x8GB DDR3-1600, 9-11-11-29 (CL-RCD-RP-RAS); Windows 7 x64 SP1. I have tested both 32-bit and 64-bit versions, the latter is generally faster.
Update.Delta:4 suffers greatly from 64-bit implementation. My tests show a 18% speed drop. Why? (By the way, does it subtract 8-bit or 32-bit quantities?) On the contrary, Deflate and BZip2 decompression and SHA filters gain from 9% to 33% upon transition to 64-bit code. AES256CBC:1 shows up to 20% gain, but AES256CBC:2 has a 3% drop.
Delta code is not fully optimized still. It works with bytes (8-bit).
x64 provides some advantages over 32-bit x86 for 7-Zip code:
1) more registers: 16 vs 8. But modern CPUs are fast for stack variables, so gain in x64 is not so big.
2) There is some code that uses 64-bit integers, but it's small part of code in benchmark.
3) 32-bit code doesn't use CMOV instruction that is not implemented in old 32-bit CPUs.
Some code strongly depends on memory latency (LZMA compression). So 32-bit and 64-bit code wait data from RAM or cache for same time.
Some code is writtten in ASM: CRC and AESCBC:2. And it's optimized for both 32-bit and 64-bit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you think of implementing a Delta filter for 16-bit or bigger numbers? I suggest naming them like Delta:4:1: period 4, subtract 1-byte quantities. This could give some gain for data arrays. Such a technique is already implemented in TIFF differencing. I have once implemented a Delta:8:8 filter for my scientific computations; it was better than Delta:8 even despite type difference (the original data were 8-byte reals, but I casted them as 8-byte integers for lossless filtering).
Please consider this post as a low-priority feature request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We were thinking about it when we selected Delta filter for xz format. Wider versions do not provide big gain, and such filter will be used not too often. So we have selected only simplest 8-bit variant.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for tests.
Some additional notes about p7zip benchmark.
1) According to your OS, copy makefile.linux,
makefile.freebsd, makefile.cygwin, ...
over makefile.machine
you can use:
makefile.linux_amd64
makefile.linux_amd64_asm
makefile.linux_any_cpu
_asm version must provide fastest CRC code for x86.
2)
Change
OPTFLAGS=-O
to
OPTFLAGS=-O2
in makefile.machine
3) SHA256 source code is not optimized for speed. So it's slow.
AES-NI is not supported in p7zip still.
Last edit: Igor Pavlov 2015-02-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, definitely better speeds. I missed the part about moving the makefiles in the readme, gah! Thank you!
Reran the benchmarks and edited my post above with the new results.
Used 'makefile.linux_amd64_asm' for x86-64 and 'makefile.linux_any_cpu_gcc_4.X' for ARM.
Used OPTFLAGS=-O2 -march=native (except on the Nano, as gcc doesn't seem to know the native CPU)
AES-NI now does seem to work! I also ran a quick test using the Windows 64-bit via wine64, and got roughly the same ballpark figures, so hopefully this is more representative.
As a reference for OpenSSL speeds, scroll down to the CPU Benchmarks section here for what I get on the above CPUs using 1 thread (ignore the Nano CPU as it's using h/w accel there). I suspect OpenSSL devs have put a lot more effort into the hashing/encryption performance, since it's basically what it does. Not expecting anyone to replicate it, but I just thought it may be of interest. Ever considered linking to it maybe?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip 9.38 beta supports new benchmark that tests the speed of some code from 7-Zip (not only LZMA).
You can call it so:
At first it tries to detect CPU frequency to select the complexity of test.
Last value: 3282 is estimated CPU frequency.
Then it tests CPU Frequency again (in multithreading mode, if multithreading mode was specified)
2868 is not correct CPU frequency here, since Hyper-Threading doesn't give full resources to each thread from two threads.
Then it tests Compression, Decompression and HASH calculation code.
MIPS - are results normalized for AMD K8 cpu.
Effec - are results normalized to CPU frequency.
For example, Effec = 130 means that CPU is 30% faster per MHz than AMD cpu.
The test AES256CBC:2 - is AES hardware test (that test is supported only if CPU supports AES instructions).
You can post results here at forum for your CPU.
Please write full name of your CPU and real CPU frequency, if you know it.
The results for two tests are interesting:
Please use "Code Highlighting" for results in messages.
You can designate a code block by surrounding it with lines of tildes:
Last edit: Igor Pavlov 2015-01-12
Thanks for results.
I don't like that it shows 2337 MHz instead of 2266 MHz.
Do you know real frequency of your CPU (measured with CPU-Z or some other program)?
Try:
And stop program (Ctrl-C) after "CPU" lines:
Last edit: Igor Pavlov 2015-01-13
2.26 GHz should be the real CPU frequency.
However my CPU has an IDA p-state (Intel Dynamic Acceleration) which should clock one (and only one) core at 2400 MHz (multiplier 9 instead of 8.5) if the other core is idle. I don't know if it was active during tests though, since I don't know of a reliable way to detect IDA p-states.
I'll try the above commands later (I'm on another computer right now).
It's not good for benchmarking when CPU can change the frequency.
CPU was configured for maximum performance (so by default multiplier 8.5 is used).
However I don't know if this disables IDA, too (and I don't know software that is designed to disable IDA). Also I was never really able to test if IDA is used since
a) I don't know of a tool that is designed for this (only general tools, that show the current CPU clock).
b) IDA is never active all the time. It's only active for fractions of a second, since the limitation applies that other core has to be idle (which is very unlikely on modern systems)
If you know of better ways to test this, please tell me (I assume you have run into similar issues when benchmarking).
Last edit: Ede_123 2015-01-13
If you run single thread code, then other core will be idle at 99% of time.
If you want to see exact CPU frequency, any test from 7benchmark probably can show it (it uses precision timer from CPU):
http://sourceforge.net/projects/sevenmax/files/7-Benchmark/7bench1400.7z/download
Last edit: Igor Pavlov 2015-01-13
According to CPU-Z the CPU was running mostly with multiplier 34 (3.4 GHz) during tests.
For the test with one thread sometimes Multiplier 35 (3.5 GHz) or (seldom) 36 (3.6 GHz) was set.
(If you know how of an easy way to fix i5 CPUs with Intel Turbo Boost to a specific multiplier and need those tests, too, tell me. I could retest then.)
Now for me it's not so important to get exact results without Turbo-Boost.
I just wanted to check that CPU frequency detection works OK. In your case it showed:
3543 (-mmt1)
3380 (-mmt4)
Intel(R) Core(TM)2 Duo CPU T7700 @2.40GHz 3.31GHz windows XP SP3 3.5GB RAM
Cpu usage is higher than 100% for single thread.
Probably GetProcessTimes() function returns incorrect results for such overclocked cpu.
What exact settings do you change to overclock cpu: BIOS or some program?
Probably BIOS, this system runs in a VM on top of some Linux.
CPU: QuadCore Intel Core 2 Quad Q9400, 2666 MHz (8 x 333)
OS: Windows 8.1 Professional x64
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel Core 2 Quad Q9300, 2500 MHz (7.5 x 333)
7-Zip [64] 9.38 beta Copyright (c) 1999-2014 Igor Pavlov 2015-01-03
CPU Freq: 4266 2064 2000 4266 2031 2348 2737 2432 2525
RAM size: 4095 MB, # CPU hardware threads: 4
RAM usage: 419 MB, # Benchmark threads: 1
Method Speed Usage R/U Rating E/U Effec
KB/s % MIPS MIPS % %
CPU 100 2491 2491
CPU 100 2501 2501
CPU 100 2491 2492 100 100
LZMA:x1 10195 100 3728 3727 150 150
30632 100 2467 2467 99 99
LZMA:x5:mt1 2488 100 3109 3109 125 125
29642 100 2493 2493 100 100
LZMA:x5:mt2 4412 161 3417 5513 137 221
29642 100 2493 2493 100 100
Deflate:x1 25771 100 3273 3272 131 131
84568 100 2616 2616 105 105
Deflate:x5 7835 100 3018 3017 121 121
84914 100 2616 2616 105 105
Deflate:x7 2706 99 3022 2999 121 120
84914 100 2626 2615 105 105
Deflate64:x5 7501 100 3242 3242 130 130
84179 100 2614 2614 105 105
BZip2:x1 4566 100 2759 2759 111 111
23974 100 2567 2566 103 103
BZip2:x5 3861 100 3222 3223 129 129
18977 100 3688 3688 148 148
BZip2:x5:mt2 7192 194 3097 6002 124 241
30303 161 3666 5888 147 236
BZip2:x7 1169 100 3030 3030 122 122
18984 100 3686 3687 148 148
PPMD:x1 3420 100 3538 3538 142 142
3053 100 3595 3596 144 144
PPMD:x5 2273 100 3861 3852 155 155
2031 100 3814 3807 153 153
Delta:4 536074 100 3293 3294 132 132
474732 100 2917 2917 117 117
BCJ 825394 100 3380 3381 136 136
816531 100 3345 3345 134 134
AES256CBC:1 110161 100 2707 2707 109 109
107389 100 2640 2639 106 106
AES256CBC:2
CRC32:4 1018772 100 2274 2274 91 91
CRC32:8 1840264 100 2496 2495 100 100
CRC64 939647 100 1924 1924 77 77
SHA256 58836 100 2801 2801 112 112
SHA1 165998 100 3472 3473 139 139
CPU 100 2507 2506
Tot: 106 3041 3235 123 130
Kernel Time = 0.312 = 0%
User Time = 174.908 = 102%
Process Time = 175.220 = 103% Virtual Memory = 225 MB
Global Time = 169.953 = 100% Physical Memory = 208 MB
7-Zip [64] 9.38 beta Copyright (c) 1999-2014 Igor Pavlov 2015-01-03
CPU Freq: 2000 2064 4266 2000 2782 2327 2534 2522 2476
RAM size: 4095 MB, # CPU hardware threads: 4
RAM usage: 850 MB, # Benchmark threads: 4
Method Speed Usage R/U Rating E/U Effec
KB/s % MIPS MIPS % %
CPU 393 2456 9663
CPU 397 2475 9815
CPU 396 2468 9773 101 400
LZMA:x1 39266 386 3719 14355 152 587
121010 395 2469 9745 101 399
LZMA:x5:mt1 8269 391 2643 10331 108 423
112660 388 2443 9471 100 388
LZMA:x5:mt2 8862 389 2843 11071 116 453
115322 396 2445 9694 100 397
Deflate:x1 101843 396 3268 12932 134 529
331165 395 2590 10239 106 419
Deflate:x5 30439 394 2973 11720 122 480
329850 393 2582 10157 106 416
Deflate:x7 10607 393 2991 11753 122 481
336809 397 2614 10367 107 424
Deflate64:x5 29178 396 3185 12609 130 516
328457 395 2584 10199 106 417
BZip2:x1 17876 395 2732 10800 112 442
94187 394 2557 10080 105 413
BZip2:x5 12730 395 2687 10624 110 435
57538 389 2874 11179 118 458
BZip2:x5:mt2 12654 395 2676 10561 110 432
62375 396 3057 12119 125 496
BZip2:x7 4371 393 2882 11326 118 464
56013 398 2735 10878 112 445
PPMD:x1 14003 394 3679 14483 151 593
12002 395 3577 14135 146 578
PPMD:x5 8157 395 3499 13824 143 566
7280 393 3468 13644 142 558
Delta:4 2102041 396 3263 12915 134 529
1879728 393 2938 11549 120 473
BCJ 3186751 390 3346 13053 137 534
3236459 399 3324 13257 136 543
AES256CBC:1 433911 394 2706 10664 111 436
406314 387 2583 9986 106 409
AES256CBC:2
CRC32:4 4009846 396 2260 8950 92 366
CRC32:8 7247412 397 2476 9827 101 402
CRC64 3674376 395 1903 7525 78 308
SHA256 211443 377 2671 10065 109 412
SHA1 541846 368 3078 11335 126 464
CPU 396 2473 9793
Tot: 393 2873 11282 118 462
Kernel Time = 1.778 = 0%
User Time = 727.791 = 379%
Process Time = 729.569 = 380% Virtual Memory = 897 MB
Global Time = 191.766 = 100% Physical Memory = 798 MB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel Core i5-3570 (Ivy Bridge) at 3600 MHz (original 3400, overclocked by 2 multiplier steps), Turbo Boost active (up to 3800 MHz); 2x8GB DDR3-1600, 9-11-11-29 (CL-RCD-RP-RAS); Windows 7 x64 SP1. I have tested both 32-bit and 64-bit versions, the latter is generally faster.
Update.
Delta:4
suffers greatly from 64-bit implementation. My tests show a 18% speed drop. Why? (By the way, does it subtract 8-bit or 32-bit quantities?) On the contrary,Deflate
andBZip2
decompression andSHA
filters gain from 9% to 33% upon transition to 64-bit code.AES256CBC:1
shows up to 20% gain, butAES256CBC:2
has a 3% drop.32-bit single-threaded:
32-bit 4-threaded:
64-bit single-threaded:
64-bit 4-threaded:
Last edit: Shell 2015-01-16
CPU Freq line (preload) uses single thread:
CPU lines in test are multi-threaded for-mmt4:
So results are correct.
Yes, I have figured that out already and edited my post. Yet thank you for the comment.
Delta code is not fully optimized still. It works with bytes (8-bit).
x64 provides some advantages over 32-bit x86 for 7-Zip code:
1) more registers: 16 vs 8. But modern CPUs are fast for stack variables, so gain in x64 is not so big.
2) There is some code that uses 64-bit integers, but it's small part of code in benchmark.
3) 32-bit code doesn't use CMOV instruction that is not implemented in old 32-bit CPUs.
Some code strongly depends on memory latency (LZMA compression). So 32-bit and 64-bit code wait data from RAM or cache for same time.
Some code is writtten in ASM: CRC and AESCBC:2. And it's optimized for both 32-bit and 64-bit.
Did you think of implementing a Delta filter for 16-bit or bigger numbers? I suggest naming them like
Delta:4:1
: period 4, subtract 1-byte quantities. This could give some gain for data arrays. Such a technique is already implemented in TIFF differencing. I have once implemented aDelta:8:8
filter for my scientific computations; it was better thanDelta:8
even despite type difference (the original data were 8-byte reals, but I casted them as 8-byte integers for lossless filtering).Please consider this post as a low-priority feature request.
We were thinking about it when we selected Delta filter for xz format. Wider versions do not provide big gain, and such filter will be used not too often. So we have selected only simplest 8-bit variant.
Intel Xeon E3 1230v2
- Turbo 3700/3700/3600/3500 MHz
- Hyperthreading
- 2x8GB DDR3-1600 CL11-11-11-28
7z b -mm=* -mmt1
7z b -mm=*
This may be less relevant, but interesting nonetheless.
Tests conducted using p7zip 9.38 on Debian 7, compiled using 'make all3'.
Tested on Debian 7 x86-64, compiled with gcc 4.7.2:
VIA Nano U2250, 1.6GHz (single core CPU):
AMD Athlon II X2 240, 2.8GHz (1 thread):
AMD Athlon II X2 240, 2.8GHz (multi-thread):
Intel Xeon E3 1246v3, 3.9GHz (1 thread):
Intel Xeon E3 1246v3, 3.5GHz (multi-thread):
Compiled on Debian 7 armhf, with gcc 4.9.1:
Marvel Armada 370/XP, ? GHz (1 thread):
Marvel Armada 370/XP, ? GHz (multi-thread):
I've also noticed that the hash calculation speed seems to be a fair bit behind that from OpenSSL.
Last edit: ZiNgA BuRgA 2015-02-25
Thanks for tests.
Some additional notes about p7zip benchmark.
1) According to your OS, copy makefile.linux,
makefile.freebsd, makefile.cygwin, ...
over makefile.machine
you can use:
makefile.linux_amd64
makefile.linux_amd64_asm
makefile.linux_any_cpu
_asm version must provide fastest CRC code for x86.
2)
Change
OPTFLAGS=-O
to
OPTFLAGS=-O2
in makefile.machine
3) SHA256 source code is not optimized for speed. So it's slow.
AES-NI is not supported in p7zip still.
Last edit: Igor Pavlov 2015-02-25
Ah, definitely better speeds. I missed the part about moving the makefiles in the readme, gah! Thank you!
Reran the benchmarks and edited my post above with the new results.
OPTFLAGS=-O2 -march=native
(except on the Nano, as gcc doesn't seem to know the native CPU)AES-NI now does seem to work! I also ran a quick test using the Windows 64-bit via wine64, and got roughly the same ballpark figures, so hopefully this is more representative.
As a reference for OpenSSL speeds, scroll down to the CPU Benchmarks section here for what I get on the above CPUs using 1 thread (ignore the Nano CPU as it's using h/w accel there). I suspect OpenSSL devs have put a lot more effort into the hashing/encryption performance, since it's basically what it does. Not expecting anyone to replicate it, but I just thought it may be of interest. Ever considered linking to it maybe?