How CPU Features Affect CPU Performance
|
Scientific and engineering analysis
| |
DDR2-800
4-4-4-12
unganged |
DDR2-800
4-4-4-12
ganged |
DDR2-800
6-6-6-18
unganged |
DDR2-400
4-4-4-12
unganged |
| MAPLE ↑ |
0.1586 |
0.1539 |
-3% |
0.1522 |
-4% |
0.1398 |
-12% |
| Mathematica ↑ |
2.5968 |
2.6137 |
+1% |
2.5768 |
-1% |
2.399 |
-8% |
| MATLAB ↓ |
0.052493 |
0.052139 |
+1% |
0.052869 |
-1% |
0.060817 |
-14% |
| SolidWorks ↓ |
44.71 |
46.77 |
-4% |
45.94 |
-3% |
48.09 |
-7% |
| Pro/ENGINEER ↓ |
1934 |
1899 |
+2% |
1948 |
-1% |
2019 |
-4% |
| UGS NX ↑ |
4.33 |
4.46 |
+3% |
4.27 |
-1% |
3.89 |
-10% |
If we take a look at a similar diagram from the first part and try to bring into sync multiprocessing capability with the response to the ganged mode... it will not work out again. For example, SolidWorks cannot use multiple cores well (so it should theoretically prefer the ganged mode), but it slows down in the ganged mode. And MATLAB has the best support for multiprocessing in this group of tests, but it even accelerates in the ganged mode. However, we've already agreed that 1% "does not count." At least it did not slow down. All our applications responded unanimously negatively to "bad" timings, but their response was very weak.
The halved memory bandwidth most of all affected mathematical packages -- MATLAB, MAPLE, Mathematica. In fact, we've got an explanation to this: MATLAB should have responded as the most optimized program for multiprocessing in this group of tests, MAPLE and Mathematica work with symbolic computing, so they should be sensitive to processing speed of large data arrays.
Raster graphics
| |
DDR2-800
4-4-4-12
unganged |
DDR2-800
4-4-4-12
ganged |
DDR2-800
6-6-6-18
unganged |
DDR2-400
4-4-4-12
unganged |
| ACDSee ↓ |
00:06:44 |
00:06:45 |
0% |
00:06:45 |
0% |
00:07:24 |
-9% |
| Paint.NET ↓ |
00:00:26 |
00:00:26 |
0% |
00:00:26 |
0% |
00:00:26 |
0% |
| PaintShop Pro ↓ |
00:12:51 |
00:12:46 |
+1% |
00:12:51 |
0% |
00:13:04 |
-2% |
| PhotoImpact ↓ |
00:09:34 |
00:09:36 |
0% |
00:09:32 |
0% |
00:09:33 |
0% |
| Photoshop ↓ |
0:07:40 |
0:07:39 |
0% |
0:07:40 |
0% |
0:08:48 |
-13% |
These results are quite shocking: bitmap editors are absolutely indifferent to memory controller's modes and worse timings. Even the halved memory bandwidth slowed down only two applications, not much at that (compared to twofold!) We understand why Photoshop and ACDSee are the most sensitive applications -- they can both use multiprocessing. ACDSee is much worth at it than Photoshop -- so it loses less. Complete indifference of Paint.NET to anything is quite illustrative -- it's the only representative of software written on Microsoft.NET.
Lossless data compression
| |
DDR2-800
4-4-4-12
unganged |
DDR2-800
4-4-4-12
ganged |
DDR2-800
6-6-6-18
unganged |
DDR2-400
4-4-4-12
unganged |
| 7-Zip ↓ |
00:04:46 |
00:04:47 |
0% |
00:04:52 |
-2% |
00:05:37 |
-15% |
| WinRAR ↓ |
00:01:54 |
00:01:54 |
0% |
00:01:57 |
-3% |
00:02:17 |
-17% |
Another cold shower: we thought that archivers were the most sensitive programs to tiny changes in the memory system?! But we were wrong: they demonstrate zero reaction to the controller mode and reluctant response to worse timings. The halved memory bandwidth has a much more noticeable effect. But I repeat that minus 50% of memory bandwidth gives only minus 17% in performance. And that happens in applications that are traditionally considered the most memory-consuming ones.
Compiling
It's a smaller performance drop than in archivers with the cardinally cut memory bandwidth and a complete lack of any response to the ganged mode and worse timings. Note the absolute indifference of the multiprocessing test to the ganged mode again.
Audio encoding
Nothing affects the speed of encoding audio. It's even surprising. But on the other hand, it's quite natural: to all appearances, the size of cache in modern processors is large enough to fit all data and processing algorithms in this case.
Write a comment below. No registration needed!
|
|
 |
|
|
|
