Review and comparative testing of PC "Elbrus 401 ‑ PC". Part Four - benchmarks
The final part of the article is devoted to comparing the performance of a new Russian computer with foreign competitors and its own predecessors.
Caution: a lot of letters and pictures!
')
We remind the content of the previous parts:
Enjoy reading!
For a long time, the author was deeply mistaken, believing that this computer was acquired by the company for its own needs - in addition to the older generation equipment that was being used. And only at the time of receipt it turned out that the novelty is intended for further delivery as part of the complex. Therefore, instead of the initially planned thoughtful reading of documentation, practical acquaintance with all the subtleties, careful selection of testing tools and other meditative activities, we had to act quickly, if not to say chaotically. The degree of inadequacy has further increased due to the pre- and post-new year all-year-round job, in the feasible elimination of which the author participated in parallel.
We did not set ourselves a goal of achieving a “truly correct” result that accurately reveals the unique advantages or disadvantages of a particular platform. I just wanted to get an everyday view of the computing power of the new “Elbrus” against the background of previously known samples of domestic and western electronics - from the perspective of an ordinary user using ready-made programs in assembled form or compiling them from source codes without using esoteric knowledge on optimization and porting. Therefore, there will be no sensations in the article like “Elbrus broke Xeon when encrypting according to the GOST algorithm” or “Elbrus in x86 emulation mode works even faster than executing native code” (which can be read here and there on the Internet, and always for some reason without disclosing details). However, the truth and intrigue for the sake of, it is worth noting that in one series of tests the main character of this review really showed several times better results than a similar computer based on Core i7.
Since the absolute values of the results obtained in the benchmarks usually represent very abstract values, even when the testing algorithms are based on the software code of real applications, it was decided to conduct a series of identical measurements on a number of computer platforms that are as different as possible and at the same time range of relevant equipment of similar purpose.
X86‑64 computer architecture based on intel atom
Perhaps the ideal rival for Elbrus would be some modern Intel Celeron or Atom with four cores and a low frequency, or an analogue under the AMD brand; but from the fact that there was in the bins, there was only a dual-core Atom D2500, soldered on an Intel D2500CC mini ‑ ITX motherboard. The configuration of this compact and obviously not too fast computer, probably, does not need additional explanations; it had only one atypical component — a 3.5-inch hard disk (albeit an initial series), but since the I / O performance was not the focus of the study, this fact can be neglected. For maximum software similarity, the Debian 7.9.0 distribution for the x86‑64 architecture with the Linux 3.2.0 kernel was chosen as the operating system (especially since installing and updating older versions of Debian is not a quest for the faint of heart).
Computer x86‑64 architecture based on Intel Core i7
The second natural participant was a computer from the opposite pole of functions and speed - a desktop mini-tower Dell OptiPlex 990 with a Core i7-2600 processor and an original motherboard based on the Q67 chipset. The system worked in its daily mode - with the overclocking feature disabled (Turbo Boost), but with the enabled multithreading technology (Hyper-Threading), running openSUSE 13.2 for the x86‑64 architecture with the Linux kernel 3.16.7.
Computer "Elbrus ‑ 90micro" based on the MCST R500
However, it would be incorrect to compare only with the mainstream, as the new Elbrus-4C is primarily a replacement for the old Elbrus product line, which includes not only E2K computers, but also SPARC. Unfortunately, our company does not have the technology of the modern SPARC V9 architecture, such as the MCST R1000, but “we are lucky” to mess with the whole brood of the R500 - from the generation of the SPARC V8, which is still 32-bit. The first representative of the old guard was the Elbrus-90micro computer in the format of a conventional mini-tower with two unsoldered R500 processors, a discrete video card of its own design, a regular hard disk and an optical drive. The operating system of this computer is MSVS 3.0 for the SPARC architecture with the Linux 2.4.25 kernel, the GCC 3.3.6 compiler and the GNU LibC 2.2.5 library.
Another computer architecture SPARC V8 based on the R500 (approximate view, photo from the MCST site)
The other computer is also equipped with a pair of R500 processors, but is made in the Euromechanics 6U modular design, has only 512 MB of RAM and an industrial-grade flash card as the main drive (the Meltron P7 model is proudly referred to as “SSD”, but the actual performance is part of computer rather closer to the old, slow flash). The principal difference from the previous participant is that the Elbrus operating system (OS 311-03), dated at the beginning of 2011, is installed with the Linux 2.6.16 kernel, the LCC 1.16.12 compiler (GCC 3.4.6 is declared) and the GNU LibC 2.16.0 library. As will be seen later, these software differences from the MSWS sometimes lead to a significant difference in speed, with the scales tilting one way or the other. Therefore, below are both series of results, labeled respectively “R500 / E” for a computer with the Elbrus system and R500 / M for a computer with an MAWS system.
As already briefly mentioned, the software includes a rather extensive collection of test utilities for checking the correct functioning of hardware and system libraries, as well as for measuring performance. Some of these utilities are in-house developed by MCST, and some are well-known third-party programs. Among the latter, there are also versions adapted specifically for Elbrus: for example, CoreMark requires for each platform to implement its own interface that takes into account the features of the compiler and libraries, system calls and data structures, multithreading, time measurement tools. This porting does not provide any hidden benefits, however, especially since the results of the main run are then rechecked using the profiler.
The CoreMark test was created by the Embedded Microprocessor Performance Measurement Consortium (EEMBC) and consists of several synthetic tasks, including processing matrices and linked lists, switching states of a finite state machine, calculating a checksum. Apparently, for the reason that downloading the source codes and publishing the results obtained requires registration, this test has not gained much popularity: there are currently 406 records in the database.
The result achieved by the Elbrus-4C processor in single-threaded mode is slightly higher than the old AMD Athlon XP ‑ M with the same clock frequency, and when all four cores are activated, it is close to the dual-core Athlon 64 X2 QL ‑ 65, Intel Atom 330, D525 , D2500, Core 2 Duo E4300, in which the frequency is at least twice as high.
R500 demonstrated a strange behavior with the Elbrus operating system: when using two threads or two processes, both of them divided one core equally, and only the third and subsequent threads or processes were distributed to the second core too, and saturation occurred only with a degree of parallelism equal to 8. Therefore, the dotted line on the diagram also shows additional results when the number of threads exceeds the number of cores of a computer: as you can see, all of the other participants in the test have these dotted lines vayutsya in a horizontal line - the way it should be, when each thread consumes all available resources. The causes of the anomaly could not be clarified: perhaps these are the features of the task scheduler settings in the Elbrus system on that computer.
The idea of including the built-in test of the archiver into the test program matured after reading the review on CNews 2014, where the performance of the Core i7-2600 was also compared (without Hyper-Threading, but with Turbo Boost, apparently) and Elbrus-4C, albeit at a frequency 700 MHz, as well as “Elbrus-2C +”, which has only two cores and a frequency of 500 MHz, but there are four more ElCore9 DSP signal processing cores from Elvis (however, they were not involved in this testing). Judging by the values given there, the author ran “ 7z b ” and divided the result by the number of cores. We publish the results in their original form, with an estimated number of integer operations on all cores per unit time (MIPS) selected as a measure of speed, and the table shows the absolute data processing speed and the relative rating of one core, taking into account the actual processor load in either different mode of operation.
Here we can observe how the new “Elbrus” almost does not lag behind Atom even in single-threaded mode, and the total performance of all the cores exceeds the indicators of it already significantly - one and a half times.
The reluctance to scale with two threads this time showed both computers based on the R500. Moreover, for some reason, the 7 ‑ Zip in the MSWS system could not determine the degree of congestion of the cores during unpacking - I had to accept it equal to 99% by analogy with compression and calculate the rating manually.
Similar to the previous test, the decision to drive OpenSSL naturally came after repeated collisions with theses like “Domestic processors are very effective in cryptography, especially on GOST algorithms” (which implementations of algorithms are used, alas, not specified). Searches for files containing the word “ gost ” in their name resulted in a rather modest result:
Supplied with the system, the most common OpenSSL 0.9.8zc also could not boast of anything. Therefore, for tests, more popular hashing algorithms, symmetric encryption, and digital signature calculation were chosen.
Here and below are the maximum figures, expressed in “decimal” megabytes per second. The fraction shows the results when using one core and all cores. A dash means that this algorithm is not supported in the standard version of OpenSSL: the old Elbrus system is 0.9.8b, the MSWS is 0.9.7b (yes, we are not vulnerable to Heartbleed!).
While symmetric cryptography usually takes the same time when encrypting and decrypting messages of equal volume (except, perhaps, the cost of generating the initial state), asymmetric algorithms deal with data of a fixed size, but require a different set or number of actions to form and verify digital signature. Therefore, the following results are presented separately and are expressed in the number of operations per second.
The total performance of the Elbrus-4C in these tests is also at the level of the Atom D2500, demonstrating the advantage, the lag from the algorithm to the algorithm. The results of the R500 with the Elbrus operating system are given for 4 streams, - it was in this mode that it reached the maximum, while still losing much to its fellow member running the MSWS on hashing and encryption, but slightly rehabilitating itself on asymmetric cryptography tasks.
This set of synthetic tests affecting various aspects of computer operation, from elementary arithmetic operations to system calls and disk operations, was first developed in the early 1980s and, gradually evolving, lived to this day without losing popularity as a cross-platform tool. integral assessment of system performance in general and individual components in particular.
It should be noted that the Elbrus 401 ‑ PC software bundle included the UnixBench version 5.1.2, but for consistency, the current version 5.1.3 was used everywhere, especially as the standard version showed the same performance (within the measurement error).
It was difficult to ignore an article about speeding up Postgresql on IBM Power8 , which described the process of optimizing software for this architecture in particular, and gave a positive assessment of the development of the project as a whole, without being infected with the desire to test how far more modest equipment is from the fantastic high performance shown there . Another thing is that personal computers chosen for testing do not claim to be a serious database server, not only because they have much fewer processor cores and execution threads, but less cache, RAM, “no” disk system. However, the volume of the test database (less than 0.5 GB) fits perfectly within the personal data storage appropriate for a personal computer and, moreover, it fits completely in the RAM of most of the selected machines. Therefore, this test can be considered a comprehensive measure of the speed of the entire computer as a whole, which, unlike UnixBench, has a realistic, albeit one-sided, nature of the load.
The computer's operating system, Elbrus 401 ‑ PC, incorporates Postgresql 9.2.3, and it was decided to make this version a reference point for all other participants, while not forgetting about more current versions. Having copied the developer repository as of December 3, 2015 , we tried to build the current version, hereafter referred to as “9.6devel”, but at the configuration stage it turned out that each architecture requires a platform-specific implementation of spinlocks (what it is, and the difference between other types of locks used by Postgresql is described in the article mentioned above), and for E2K in the mainline it is not there, of course. As a fallback , you can use the “ ‑ -disable-spinlocks ” mode , however, as the documentation warns, at the price of a noticeable — though not catastrophic — drop in performance. Moreover, if the self-assembled version of 9.6devel was slower than the regular 9.2.3, then the 9.2.3 version collected from public sources was even slower than 9.6devel. And restarting the standard version 9.2.3 after all the other tests ended confirmed that the drop in performance cannot be explained solely by the features of the SSD-drive (although it wasn’t enough without them in the combined test for reading and writing). Hence the conclusion that the programmers of the MCST made the necessary amendments to the regular version, that is, they performed the full porting, and therefore we will designate this version with the “ e2k ” suffix, and the self-assembled version without spinlocks - with the “ ds ” suffix.
On the contrary, there were no problems when building version 9.2.3 from public sources on the SPARC platform, as it is officially supported. However, an attempt to consolidate success with version 9.6devel failed at the compilation stage, as memory barriers (a mechanism for ensuring a strict order of memory operations on processors with extraordinary execution of instructions) are now supported only on SPARC V9. The same error occurred when building version 9.4.5 (the main stable branch at that time), although the documentation still states support for the old architecture.
The testing methodology was as straightforward as possible: the DBMS was launched with the default settings immediately after the initialization of the storage, a test database was created there, which was filled with the Pgbench utility for 32 parallel threads, and then a series of Pgbench launches were performed for 60 seconds each with a changing number of simulated clients, each of which worked in its own stream (as the results were higher than when several clients shared one stream). The number of requests sent within each session remained by default (10 requests per connection), and since the clients were running on the same machine as the server, the time spent on establishing connections was not taken into account.
The Pgbench main load script mimics the TPC ‑ B test suite developed by the Data Processing Performance Board as early as the 1990s, and consists of various requests for selecting and modifying data. Obviously, in this case the disk subsystem becomes a bottleneck, which is not significant for us. Therefore, we also carried out read-only tests (SELECT-only), - as already mentioned, the entire database fits entirely in RAM; In addition, it was this scenario that was used by the authors of Power8 patches and their predecessors from the x86‑64 mill to demonstrate their improvements.
, : , 9.2.3 . , , ; , , , ( , ).
— : « 401‑PC» SSD, , . , , «‑4» Atom D2500 , — ; , - (8 1 ). « » !
R500 «». , , Pgbench 2- 3- . ( scaling factor; ) , , . , , «» :
!
, - .
, , Postgresql, , : E2K, , — , .
, , « » ( «»), 707.3.4 Postgresql 8.4.3 . Pgbench , .
Postgresql : , , , ‑ . , Postgresql — C++.
9.2.3 : , , ( , , -, ). : , , . , , , Pgbench, — .
, — . x86‑64 GCC 4.8.3 4.7.2 , GCC 3.3.6 SPARC, «» LCC 1.16.12 1.19.18 , LCC SPARC E2K — , . , . , , , — , .
Java, , , . , «Desktop» «Server»: , .
, , — 10:1 Core i7 «‑4», ( ), , «Server» . , — , « 401‑PC» SSD, , — . , «Disk», , Seagate Barracuda 7200.9 325 / Atom D2500, WD Caviar Blue — , , — 1650 / Core i7. SATA‑2, , , — .
, Java Micro Benchmark, , . , ‑ , , , .
(SPEC), — SPEC CPU , — , , , . , SPECjvm98 SPECjvm2008 , — .
Core i7 «‑4» — 100:1, , . , 4‑ «» 2‑ Atom! Java-, : , .
, Core i7 Java — 1.7.0, «» 1.6.0, — 1.6.0 Atom; , JVM 23.25 20.0 ( , ). , Java — , : , 512 , , , .
, : , , «Java , », — 2 , Java-. , , , .
, , , , Java, 1.8.0, JPEG. , Java, , , .
05.02.2016. «», Core i7, «-Djava.compiler=NONE». , SPECjvm, «compiler» . () : , 12 , 2 .
SPECjvm2008, . SciMark 2.0 , , . , , Firefox «» , .
, . , , — SPECjvm. , , JVM: client server, , — .
05.02.2016. Core i7 , . , 4:1 – 6:1. , Java «» , - , .
‑ , — «Linpack» . 1997 , , «» , . . . ‑ , 100 ( , Core i7 — , , ).
, Java , «», , : , SPECjvm .
05.02.2016. Core i7 , . (30:1), , - .
Java, JavaScript, , - . . «», SunSpider , , . — JetStream — . Peacekeeper, Futuremark, ‑ , . JetStream, ‑ .
, , , Firefox — , . , «» Firefox 3.6.28, (38.5.0 42.0.0) JavaScript. , , «» , — , , .
«» — , , . mplayer 1.1 , , Full HD, MPEG‑4.10 (AVC). , -lavdopts threads=4, . : «». , — mplayer , . (SD), : 10 %.
mplayer -benchmark, , , . , «‑4» Full HD 98 % ; . 2 , mplayer 85 %, 4 , — 15 %. , ‑ . : HD- — «». R500, 352×288 MJPEG 8–9 .
, FFmpeg 1.0, : , . .
-, , . ‑, Kingston SSDNow mS200 . ‑, — ‑ , . , «» ‑ , . , fio 2.3 (16 ) 185 /.
63 /. () 34 /. , , , , , . — , SATA‑2 , 10–15 %.
, — iPerf 3.1.1. « 401‑PC» Core i7 Intel 82579LM, openSUSE 13.2; . iPerf TCP , UDP 60 .
UDP , openSUSE, , UDP 10 / ; , «» .
«-2000» (E2K) , . , , , «». , .
E2K , . , ‑ , , — , , .
, x86/x86‑64, « » — , (Windows, *nix) . , ; , , x86, , .
«‑4», 800 , Intel Atom D2500 (1866 ), — , . , . , Doom 3 . Full HD , . , , ; , , . ‑ , .
« 401‑PC» , . , , . , .
, «» , , . , Core i7 ( Xeon E7, ), Intel AMD . , «», , — . , «‑8», , , , . , , — , . , .
, 09.02.2016 « » — , x86-, Java-, «», . , , , , , — . , , — .
03.03.2016. — « : ».
Caution: a lot of letters and pictures!
')
We remind the content of the previous parts:
- hardware overview :
- the acquisition process;
- Hardware;
- Software review :
- launch of the operating system;
- staff software;
- development tools overview :
- architecture features;
- machine language;
- development tools;
- performance benchmarking:
- description of competing computers ;
- benchmark results:
- CoreMark ;
- 7-zip ;
- OpenSSL ;
- UnixBench ;
- Pgbench (Postgresql);
- LCC, GCC ;
- Java Micro Benchmark ;
- SPECjvm ;
- SciMark ;
- JavaLinpack ;
- SunSpider, JetStream, Peacekeeper ;
- Mplayer ;
- FIO, DD ;
- iPerf ;
- summing up .
Enjoy reading!
Disclaimer
For a long time, the author was deeply mistaken, believing that this computer was acquired by the company for its own needs - in addition to the older generation equipment that was being used. And only at the time of receipt it turned out that the novelty is intended for further delivery as part of the complex. Therefore, instead of the initially planned thoughtful reading of documentation, practical acquaintance with all the subtleties, careful selection of testing tools and other meditative activities, we had to act quickly, if not to say chaotically. The degree of inadequacy has further increased due to the pre- and post-new year all-year-round job, in the feasible elimination of which the author participated in parallel.
“Making the right testing is possible only in one way. Do the wrong testing can be an infinite number of different ways. And guess what happens most often. ” ( nutanix )
We did not set ourselves a goal of achieving a “truly correct” result that accurately reveals the unique advantages or disadvantages of a particular platform. I just wanted to get an everyday view of the computing power of the new “Elbrus” against the background of previously known samples of domestic and western electronics - from the perspective of an ordinary user using ready-made programs in assembled form or compiling them from source codes without using esoteric knowledge on optimization and porting. Therefore, there will be no sensations in the article like “Elbrus broke Xeon when encrypting according to the GOST algorithm” or “Elbrus in x86 emulation mode works even faster than executing native code” (which can be read here and there on the Internet, and always for some reason without disclosing details). However, the truth and intrigue for the sake of, it is worth noting that in one series of tests the main character of this review really showed several times better results than a similar computer based on Core i7.
Test participants
Since the absolute values of the results obtained in the benchmarks usually represent very abstract values, even when the testing algorithms are based on the software code of real applications, it was decided to conduct a series of identical measurements on a number of computer platforms that are as different as possible and at the same time range of relevant equipment of similar purpose.
X86‑64 computer architecture based on intel atom
Perhaps the ideal rival for Elbrus would be some modern Intel Celeron or Atom with four cores and a low frequency, or an analogue under the AMD brand; but from the fact that there was in the bins, there was only a dual-core Atom D2500, soldered on an Intel D2500CC mini ‑ ITX motherboard. The configuration of this compact and obviously not too fast computer, probably, does not need additional explanations; it had only one atypical component — a 3.5-inch hard disk (albeit an initial series), but since the I / O performance was not the focus of the study, this fact can be neglected. For maximum software similarity, the Debian 7.9.0 distribution for the x86‑64 architecture with the Linux 3.2.0 kernel was chosen as the operating system (especially since installing and updating older versions of Debian is not a quest for the faint of heart).
Computer x86‑64 architecture based on Intel Core i7
The second natural participant was a computer from the opposite pole of functions and speed - a desktop mini-tower Dell OptiPlex 990 with a Core i7-2600 processor and an original motherboard based on the Q67 chipset. The system worked in its daily mode - with the overclocking feature disabled (Turbo Boost), but with the enabled multithreading technology (Hyper-Threading), running openSUSE 13.2 for the x86‑64 architecture with the Linux kernel 3.16.7.
Computer "Elbrus ‑ 90micro" based on the MCST R500
However, it would be incorrect to compare only with the mainstream, as the new Elbrus-4C is primarily a replacement for the old Elbrus product line, which includes not only E2K computers, but also SPARC. Unfortunately, our company does not have the technology of the modern SPARC V9 architecture, such as the MCST R1000, but “we are lucky” to mess with the whole brood of the R500 - from the generation of the SPARC V8, which is still 32-bit. The first representative of the old guard was the Elbrus-90micro computer in the format of a conventional mini-tower with two unsoldered R500 processors, a discrete video card of its own design, a regular hard disk and an optical drive. The operating system of this computer is MSVS 3.0 for the SPARC architecture with the Linux 2.4.25 kernel, the GCC 3.3.6 compiler and the GNU LibC 2.2.5 library.
Another computer architecture SPARC V8 based on the R500 (approximate view, photo from the MCST site)
The other computer is also equipped with a pair of R500 processors, but is made in the Euromechanics 6U modular design, has only 512 MB of RAM and an industrial-grade flash card as the main drive (the Meltron P7 model is proudly referred to as “SSD”, but the actual performance is part of computer rather closer to the old, slow flash). The principal difference from the previous participant is that the Elbrus operating system (OS 311-03), dated at the beginning of 2011, is installed with the Linux 2.6.16 kernel, the LCC 1.16.12 compiler (GCC 3.4.6 is declared) and the GNU LibC 2.16.0 library. As will be seen later, these software differences from the MSWS sometimes lead to a significant difference in speed, with the scales tilting one way or the other. Therefore, below are both series of results, labeled respectively “R500 / E” for a computer with the Elbrus system and R500 / M for a computer with an MAWS system.
Coremark
As already briefly mentioned, the software includes a rather extensive collection of test utilities for checking the correct functioning of hardware and system libraries, as well as for measuring performance. Some of these utilities are in-house developed by MCST, and some are well-known third-party programs. Among the latter, there are also versions adapted specifically for Elbrus: for example, CoreMark requires for each platform to implement its own interface that takes into account the features of the compiler and libraries, system calls and data structures, multithreading, time measurement tools. This porting does not provide any hidden benefits, however, especially since the results of the main run are then rechecked using the profiler.
The CoreMark test was created by the Embedded Microprocessor Performance Measurement Consortium (EEMBC) and consists of several synthetic tasks, including processing matrices and linked lists, switching states of a finite state machine, calculating a checksum. Apparently, for the reason that downloading the source codes and publishing the results obtained requires registration, this test has not gained much popularity: there are currently 406 records in the database.
| Mode | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| single core | 15'218 | 3'595 | 2'260 | 602 | 434 |
| all cores | 88'570 | 7'108 | 8'850 | 1'214 | 850 |
The result achieved by the Elbrus-4C processor in single-threaded mode is slightly higher than the old AMD Athlon XP ‑ M with the same clock frequency, and when all four cores are activated, it is close to the dual-core Athlon 64 X2 QL ‑ 65, Intel Atom 330, D525 , D2500, Core 2 Duo E4300, in which the frequency is at least twice as high.
R500 demonstrated a strange behavior with the Elbrus operating system: when using two threads or two processes, both of them divided one core equally, and only the third and subsequent threads or processes were distributed to the second core too, and saturation occurred only with a degree of parallelism equal to 8. Therefore, the dotted line on the diagram also shows additional results when the number of threads exceeds the number of cores of a computer: as you can see, all of the other participants in the test have these dotted lines vayutsya in a horizontal line - the way it should be, when each thread consumes all available resources. The causes of the anomaly could not be clarified: perhaps these are the features of the task scheduler settings in the Elbrus system on that computer.
7 ‑ zip
The idea of including the built-in test of the archiver into the test program matured after reading the review on CNews 2014, where the performance of the Core i7-2600 was also compared (without Hyper-Threading, but with Turbo Boost, apparently) and Elbrus-4C, albeit at a frequency 700 MHz, as well as “Elbrus-2C +”, which has only two cores and a frequency of 500 MHz, but there are four more ElCore9 DSP signal processing cores from Elvis (however, they were not involved in this testing). Judging by the values given there, the author ran “ 7z b ” and divided the result by the number of cores. We publish the results in their original form, with an estimated number of integer operations on all cores per unit time (MIPS) selected as a measure of speed, and the table shows the absolute data processing speed and the relative rating of one core, taking into account the actual processor load in either different mode of operation.
| Indicator | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| compression, MB / s | 17'200 | 1'300 | 2'144 | 228 | 247 |
| unpacking, MB / s | 211'282 | 24'738 | 38'894 | 3'227 | 2'430 |
| rating mips | 18'781 | 1'823 | 2'920 | 269 | 241 |
| core rating | 2'662 | 1'000 | 843 | 263 | 243 |
Here we can observe how the new “Elbrus” almost does not lag behind Atom even in single-threaded mode, and the total performance of all the cores exceeds the indicators of it already significantly - one and a half times.
The reluctance to scale with two threads this time showed both computers based on the R500. Moreover, for some reason, the 7 ‑ Zip in the MSWS system could not determine the degree of congestion of the cores during unpacking - I had to accept it equal to 99% by analogy with compression and calculate the rating manually.
Openssl
Similar to the previous test, the decision to drive OpenSSL naturally came after repeated collisions with theses like “Domestic processors are very effective in cryptography, especially on GOST algorithms” (which implementations of algorithms are used, alas, not specified). Searches for files containing the word “ gost ” in their name resulted in a rather modest result:
/usr/include/nettle/gosthash94.h /usr/include/php/ext/hash/php_hash_gost.h
Supplied with the system, the most common OpenSSL 0.9.8zc also could not boast of anything. Therefore, for tests, more popular hashing algorithms, symmetric encryption, and digital signature calculation were chosen.
| Algorithm | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| MD5 | 615/3546 | 320/635 | 125/500 | 10/19 | 30/59 |
| SHA-1 | 534/2181 | 192/381 | 165/658 | 6.3 / 13 | 17/34 |
| SHA-512 | 301/1227 | 119/237 | 89/355 | 0.7 / 1.4 | - |
Here and below are the maximum figures, expressed in “decimal” megabytes per second. The fraction shows the results when using one core and all cores. A dash means that this algorithm is not supported in the standard version of OpenSSL: the old Elbrus system is 0.9.8b, the MSWS is 0.9.7b (yes, we are not vulnerable to Heartbleed!).
| Algorithm | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| RC4 | 797/4060 | 202/401 | 61/246 | 5.8 / 12 | 12/24 |
| AES-CBC | 81/351 | 43/79 | 32/128 | 2.1 / 4.1 | 5.1 / 10 |
| AES-IGE | 78/341 | 20/40 | 43/170 | - | - |
While symmetric cryptography usually takes the same time when encrypting and decrypting messages of equal volume (except, perhaps, the cost of generating the initial state), asymmetric algorithms deal with data of a fixed size, but require a different set or number of actions to form and verify digital signature. Therefore, the following results are presented separately and are expressed in the number of operations per second.
| Algorithm | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| RSA-4096, signature | 105/477 | 11/22 | 6.6 / 27 | 0.8 / 1.7 | 0.8 / 1.5 |
| RSA-4096, verification | 6496 / 30'176 | 700/1400 | 453/1790 | 56/126 | 49/98 |
| DSA-2048 signature | 2396 / 11'200 | 267/534 | 157/634 | 20/40 | 18/37 |
| DSA-2048, verification | 2052/9531 | 220/440 | 136/534 | 17/34 | 15/29 |
| ECDSA-p384 signature | 4896 / 22'480 | 782/1560 | 273/1085 | 55/108 | - |
| ECDSA-p384 check | 1135/4994 | 157/312 | 49/198 | 10/21 | - |
| ECDH-p384, exchange | 1367/ 6014 | 187/374 | 58/233 | 12/25 | - |
The total performance of the Elbrus-4C in these tests is also at the level of the Atom D2500, demonstrating the advantage, the lag from the algorithm to the algorithm. The results of the R500 with the Elbrus operating system are given for 4 streams, - it was in this mode that it reached the maximum, while still losing much to its fellow member running the MSWS on hashing and encryption, but slightly rehabilitating itself on asymmetric cryptography tasks.
Unixbench
This set of synthetic tests affecting various aspects of computer operation, from elementary arithmetic operations to system calls and disk operations, was first developed in the early 1980s and, gradually evolving, lived to this day without losing popularity as a cross-platform tool. integral assessment of system performance in general and individual components in particular.
| Test | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| Dhrystone 2 | 3240 / 13'735 | 595/1190 | 185/738 | 67/132 | 59/118 |
| Whetstone | 820/5344 | 171/382 | 126/505 | 27/52 | 23/46 |
| Excl | 886/5630 | 257/524 | 82/314 | 47/85 | 88/136 |
| File 1024/2000 | 3040/2994 | 451/683 | 287/373 | 44/47 | 37/32 |
| File 256/500 | 1983/1890 | 307/479 | 185/232 | 34/34 | 30/23 |
| File, 4096/8000 | 4273/5664 | 807/1112 | 618/904 | 55/57 | 38/42 |
| Pipe | 1747/8922 | 419/851 | 209/824 | 59/115 | 107/181 |
| Context | 585/4865 | 214/428 | 175/688 | 51/99 | 62/116 |
| Fork | 1260/4537 | 264/570 | 63/222 | 78/85 | 83/120 |
| Shell, 1 | 1968/6990 | 458/703 | 210/551 | 45/65 | 123/183 |
| Shell, 8 | 5465/7113 | 670/684 | 490/562 | 68/68 | 166/166 |
| Syscall | 2978/6584 | 781/1183 | 333/1082 | 79/152 | 133/223 |
| total | 1920/5550 | 403/682 | 203/519 | 52/76 | 66/92 |
It should be noted that the Elbrus 401 ‑ PC software bundle included the UnixBench version 5.1.2, but for consistency, the current version 5.1.3 was used everywhere, especially as the standard version showed the same performance (within the measurement error).
Pgbench (Postgresql)
It was difficult to ignore an article about speeding up Postgresql on IBM Power8 , which described the process of optimizing software for this architecture in particular, and gave a positive assessment of the development of the project as a whole, without being infected with the desire to test how far more modest equipment is from the fantastic high performance shown there . Another thing is that personal computers chosen for testing do not claim to be a serious database server, not only because they have much fewer processor cores and execution threads, but less cache, RAM, “no” disk system. However, the volume of the test database (less than 0.5 GB) fits perfectly within the personal data storage appropriate for a personal computer and, moreover, it fits completely in the RAM of most of the selected machines. Therefore, this test can be considered a comprehensive measure of the speed of the entire computer as a whole, which, unlike UnixBench, has a realistic, albeit one-sided, nature of the load.
The computer's operating system, Elbrus 401 ‑ PC, incorporates Postgresql 9.2.3, and it was decided to make this version a reference point for all other participants, while not forgetting about more current versions. Having copied the developer repository as of December 3, 2015 , we tried to build the current version, hereafter referred to as “9.6devel”, but at the configuration stage it turned out that each architecture requires a platform-specific implementation of spinlocks (what it is, and the difference between other types of locks used by Postgresql is described in the article mentioned above), and for E2K in the mainline it is not there, of course. As a fallback , you can use the “ ‑ -disable-spinlocks ” mode , however, as the documentation warns, at the price of a noticeable — though not catastrophic — drop in performance. Moreover, if the self-assembled version of 9.6devel was slower than the regular 9.2.3, then the 9.2.3 version collected from public sources was even slower than 9.6devel. And restarting the standard version 9.2.3 after all the other tests ended confirmed that the drop in performance cannot be explained solely by the features of the SSD-drive (although it wasn’t enough without them in the combined test for reading and writing). Hence the conclusion that the programmers of the MCST made the necessary amendments to the regular version, that is, they performed the full porting, and therefore we will designate this version with the “ e2k ” suffix, and the self-assembled version without spinlocks - with the “ ds ” suffix.
On the contrary, there were no problems when building version 9.2.3 from public sources on the SPARC platform, as it is officially supported. However, an attempt to consolidate success with version 9.6devel failed at the compilation stage, as memory barriers (a mechanism for ensuring a strict order of memory operations on processors with extraordinary execution of instructions) are now supported only on SPARC V9. The same error occurred when building version 9.4.5 (the main stable branch at that time), although the documentation still states support for the old architecture.
The testing methodology was as straightforward as possible: the DBMS was launched with the default settings immediately after the initialization of the storage, a test database was created there, which was filled with the Pgbench utility for 32 parallel threads, and then a series of Pgbench launches were performed for 60 seconds each with a changing number of simulated clients, each of which worked in its own stream (as the results were higher than when several clients shared one stream). The number of requests sent within each session remained by default (10 requests per connection), and since the clients were running on the same machine as the server, the time spent on establishing connections was not taken into account.
The Pgbench main load script mimics the TPC ‑ B test suite developed by the Data Processing Performance Board as early as the 1990s, and consists of various requests for selecting and modifying data. Obviously, in this case the disk subsystem becomes a bottleneck, which is not significant for us. Therefore, we also carried out read-only tests (SELECT-only), - as already mentioned, the entire database fits entirely in RAM; In addition, it was this scenario that was used by the authors of Power8 patches and their predecessors from the x86‑64 mill to demonstrate their improvements.
| Scenario | i7-2600 | D2500 | E2S-800 | R500 / E | R500 / M |
|---|---|---|---|---|---|
| TPC-B | 307/542 | 248/285 | 991/991 | 16/16 | 87/87 |
| SELECT | 82'304 / 83'280 | 4076/4076 | 8732/8732 | 650/650 | 766 / 766 |
, : , 9.2.3 . , , ; , , , ( , ).
— : « 401‑PC» SSD, , . , , «‑4» Atom D2500 , — ; , - (8 1 ). « » !
R500 «». , , Pgbench 2- 3- . ( scaling factor; ) , , . , , «» :
#0 0x00.... in __lll_lock_wait_private () from /lib/libc.so.6
#1 0x00.... in __lll_lock () from /lib/libc.so.6
#2 0x00.... in free () from /lib/libc.so.6
#3 0x00.... in doCustom ()
#4 0x00.... in main ()
!
, - .
, , Postgresql, , : E2K, , — , .
, , « » ( «»), 707.3.4 Postgresql 8.4.3 . Pgbench , .
LCC, GCC
Postgresql : , , , ‑ . , Postgresql — C++.
9.2.3 : , , ( , , -, ). : , , . , , , Pgbench, — .
| i7‑2600 | D2500 | E2S-800 | R500/E | R500/M | |
|---|---|---|---|---|---|
| -O0 | 0:00:17 (0:01:15) | 0:03:00 (0:05:08) | 0:02:00 (0:06:17) | 0:25:51 (0:42:09) | 0:14:18 (0:23:53) |
| -O1 | 0:00:24 (0:02:12) | 0:04:31 (0:07:56) | 0:05:25 (0:15:18) | 1:33:35 (2:02:02) | 0:19:14 (0:33:10) |
| -O2 | 0:00:32 (0:03:01) | 0:06:02 (0:10:47) | 0:13:12 (0:34:50) | 1:38:30 (2:46:51) | 0:27:31 (0:46:57) |
| -O3 | 0:00:38 (0:03:37) | 0:07:02 (0:12:41) | 0:33:04 (1:22:04) | 2:17:38 (4:05:42) | 0:30:20 (0:51:40) |
, — . x86‑64 GCC 4.8.3 4.7.2 , GCC 3.3.6 SPARC, «» LCC 1.16.12 1.19.18 , LCC SPARC E2K — , . , . , , , — , .
Java Micro Benchmark
Java, , , . , «Desktop» «Server»: , .
| i7‑2600 | D2500 | E2S-800 | |
|---|---|---|---|
| CPU, . | 3927 | 196 | 356 |
| Disk | 2546 | 164 | 126 |
| Desktop | 3238 | 181 | 241 |
| Server | 7568 | 378 | 405 |
, , — 10:1 Core i7 «‑4», ( ), , «Server» . , — , « 401‑PC» SSD, , — . , «Disk», , Seagate Barracuda 7200.9 325 / Atom D2500, WD Caviar Blue — , , — 1650 / Core i7. SATA‑2, , , — .
, Java Micro Benchmark, , . , ‑ , , , .
SPECjvm
(SPEC), — SPEC CPU , — , , , . , SPECjvm98 SPECjvm2008 , — .
| i7‑2600 | D2500 | E2S-800 | |
|---|---|---|---|
| compiler | 533,11 | 34,24 | 4,54 |
| compress | 292,94 | 21,48 | 2,74 |
| crypto | 269,87 | 19,14 | 3,10 |
| derby | 427,77 | 24,85 | 5,00 |
| mpegaudio | 184,79 | 12,48 | 2,29 |
| scimark.large | 45,88 | 5,46 | 1,13 |
| scimark.small | 414,42 | 20,43 | 4,02 |
| serial | 207,05 | 13,86 | 1,45 |
| startup | 32,31 | 5,19 | 0,69 |
| sunflow | 110,51 | 6,85 | 0,89 |
| xml | 621,66 | 36,76 | 5,25 |
| 206,50 | 15,03 | 2,30 |
Core i7 «‑4» — 100:1, , . , 4‑ «» 2‑ Atom! Java-, : , .
, Core i7 Java — 1.7.0, «» 1.6.0, — 1.6.0 Atom; , JVM 23.25 20.0 ( , ). , Java — , : , 512 , , , .
, : , , «Java , », — 2 , Java-. , , , .
, , , , Java, 1.8.0, JPEG. , Java, , , .
05.02.2016. «», Core i7, «-Djava.compiler=NONE». , SPECjvm, «compiler» . () : , 12 , 2 .
SciMark
SPECjvm2008, . SciMark 2.0 , , . , , Firefox «» , .
| i7‑2600 | D2500 | E2S-800 | |
|---|---|---|---|
| default, | 1715,45 / 76,60 | 206,06 | 17,92 |
| FFT (1K) | 996,14 / 23,80 | 123,85 | 16,89 |
| SOR (100) | 1435,35 / 153,27 | 375,48 | 32,87 |
| Monte Carlo | 745,65 / 15.92 | 97,12 | 4,24 |
| Sparse matmult (1000, 5000) | 1579,66 / 85,78 | 206,61 | 15,15 |
| LU (100) | 3820,45 / 104,22 | 227,25 | 20,44 |
| large, | 1562,90 / 78,49 | 176,90 | 14,65 |
| FFT (1M) | 171,20 / 21,69 | 26,68 | 9,11 |
| SOR (1000) | 1314,13 / 151,12 | 365,33 | 28,46 |
| Monte Carlo | 745,40 / 16,03 | 95,94 | 4,25 |
| Sparse matmult (100k, 1M) | 1329,01 / 90,91 | 180,85 | 13,26 |
| LU (1000) | 4254,75 / 112,73 | 215,68 | 18,20 |
, . , , — SPECjvm. , , JVM: client server, , — .
05.02.2016. Core i7 , . , 4:1 – 6:1. , Java «» , - , .
JavaLinpack
‑ , — «Linpack» . 1997 , , «» , . . . ‑ , 100 ( , Core i7 — , , ).
| i7‑2600 | D2500 | E2S-800 | |
|---|---|---|---|
| MFLOPS | 236,33 / 70,44 | 14,69 | 2,25 |
, Java , «», , : , SPECjvm .
05.02.2016. Core i7 , . (30:1), , - .
SunSpider, JetStream, Peacekeeper
Java, JavaScript, , - . . «», SunSpider , , . — JetStream — . Peacekeeper, Futuremark, ‑ , . JetStream, ‑ .
| i7‑2600 | D2500 | E2S-800 | |
|---|---|---|---|
| Latency | 80,45 | 12,80 | – |
| 3d-cube | 45,73 | 7,08 | 0,74 |
| 3d-raytrace | 64,40 | 7,11 | 1,17 |
| base64 | 50,22 | 12,11 | 0,83 |
| cdjs | 60,29 | 12,70 | / |
| code-first-load | 78,59 | 13,87 | 5,55 |
| code-multi-load | 77,03 | 12,96 | 4,73 |
| crypto-aes | 66,67 | 11,97 | 1,20 |
| crypto-md5 | 72,29 | 11,58 | 0,71 |
| crypto-sha1 | 63,78 | 10,04 | 0,50 |
| date-format-tofte | 100,60 | 15,61 | 1,84 |
| date-format-xparb | 70,15 | 9,90 | 1,79 |
| mandreel-latency | 145,80 | 10,16 | ∞ |
| n-body | 107,80 | 14,77 | 0,33 |
| regex-dna | 108,30 | 27,95 | 0,50 |
| splay-latency | 294,30 | 54,03 | 3,57 |
| tagcloud | 77,28 | 11,09 | 1,63 |
| typescript | 59,16 | 9,25 | 1,86 |
| Throughput | 244,16 | 36,68 | – |
| bigfib.cpp | 246,60 | 48,82 | |
| … | … | … | … |
| mandreel | 219,40 | 23,81 | NaN |
| … | … | … | … |
| splay | 195,20 | 31,15 | 0,70 |
| … | … | … | … |
| Geometric Mean | 150,47 | 23,18 | – |
, , , Firefox — , . , «» Firefox 3.6.28, (38.5.0 42.0.0) JavaScript. , , «» , — , , .
Mplayer
«» — , , . mplayer 1.1 , , Full HD, MPEG‑4.10 (AVC). , -lavdopts threads=4, . : «». , — mplayer , . (SD), : 10 %.
mplayer -benchmark, , , . , «‑4» Full HD 98 % ; . 2 , mplayer 85 %, 4 , — 15 %. , ‑ . : HD- — «». R500, 352×288 MJPEG 8–9 .
, FFmpeg 1.0, : , . .
FIO, DD
-, , . ‑, Kingston SSDNow mS200 . ‑, — ‑ , . , «» ‑ , . , fio 2.3 (16 ) 185 /.
dd if=/dev/zero of=myfile oflag=direct bs=16M count=64
63 /. () 34 /. , , , , , . — , SATA‑2 , 10–15 %.
iPerf
, — iPerf 3.1.1. « 401‑PC» Core i7 Intel 82579LM, openSUSE 13.2; . iPerf TCP , UDP 60 .
| TCP | UDP | |
|---|---|---|
| , / | 725 | 820 |
| , / | 665 | / |
UDP , openSUSE, , UDP 10 / ; , «» .
«-2000» (E2K) , . , , , «». , .
E2K , . , ‑ , , — , , .
, x86/x86‑64, « » — , (Windows, *nix) . , ; , , x86, , .
«‑4», 800 , Intel Atom D2500 (1866 ), — , . , . , Doom 3 . Full HD , . , , ; , , . ‑ , .
« 401‑PC» , . , , . , .
, «» , , . , Core i7 ( Xeon E7, ), Intel AMD . , «», , — . , «‑8», , , , . , , — , . , .
Post scriptum
, 09.02.2016 « » — , x86-, Java-, «», . , , , , , — . , , — .
03.03.2016. — « : ».
Source: https://habr.com/ru/post/390099/
All Articles