Raster graphics

The curve on the first diagram is not as optimistic as in case of rendering -- but at least it goes up. You'll see why it's not as pronounced, when you take a look at the second diagram and the table.

Here is the picture:

• ACDSee somehow manages to use several cores, but no more than two. +4% for the fourth core holds out some hope, but as the third core is totally useless, this hope is very vague.
• PaintShop Pro and PhotoImpact use two cores even worse than ACDSee, if they use them at all: +12% is a good value, of course, but don't forget that the second core takes up all system services (Windows Vista runs lots of them). PaintShop and PhotoImpact definitely cannot use three or four cores.
• Adobe Photoshop is halfway to the ideal point (+49%, where the perfect scenario is 100, +21% out of 50, and +9% out of 33). However, it's still a very good result. The more cores, the less efficiently Photoshop can use them: real efficiency in the dual-core system is about half of the maximum theoretical value, while in case of three cores, it drops to less than a third. We can assume that efficiency will continue to drop, as the number of cores is increased.
• Excellent scalability and top efficiency in this group is demonstrated by Paint.NET. It's the only graphics editor in this group of tests, based completely on the Microsoft.NET platform. Our sincere admiration of this brilliantly-parallelized program is dimmed by one thing only: it's a primitive graphics editor. Probably the simplest of all programs in this group.

Lossless data compression

Both the first and the second diagrams indicate the same thing. And frankly speaking, we've known this long ago. As another author put it in his article on processors, "It's no secret that multithreading means double-threading for archivers." He is right, both 7-Zip and WinRAR demonstrate good efficiency with two cores, and... that's it. The third core yields +2% and +5% correspondingly. And what the fourth core contributes falls within the measurement error. If we analyze results themselves, we can say that 7-Zip uses two cores a tad more efficiently. To all appearances, WinRAR at least tries to use the third core. Besides, it's significantly faster in absolute values.

Compiling

There is no need in detailed diagrams, because there is only one test in this group. The difference of 322% between the extreme values (for one and four cores) out of maximum possible 400% testifies that we have finally managed to develop a well-parallelized benchmark to evaluate compile speed with Microsoft Visual C++*. In their modern reincarnation our tests successfully confirm the old theoretical postulate: indeed, compiling a big project can be accelerated significantly, if multiple cores are used wisely.

* In fact, in this very case a well-parallelized benchmark was indeed a serious problem, because the head-on approach used in the previous test procedure resulted in inadequate reflection of reality: MS VC++ supported parallel compiling, but we failed to use this feature. Unlike the previous version, the new benchmark does not suffer from this problem: now we use the parallel feature of MS VC++ to the full.

By the way, speaking of funny details about this benchmark: when you compile a project with vcbuild, you can use the option /M<...> (the number of compile threads). The most obvious solution that comes to mind is to set it to the number of processor cores. That's when we faced a totally unexpected problem: when the /M3 option is used (for the system with three cores) -- VC++ compiler acted as if it used /M2. That is the third core wasn't used at all. We have to use the /M4 option for three cores -- then the third core provides some performance gain, you can see it in the diagram.

Audio encoding

In this case detailed diagrams are not necessary, but for a different reason: in the new version of the test procedure we use dBpoweramp to benchmark audio encoding. This shell can parallelize the encoding process almost perfectly by launching several single-threaded codecs simultaneously (as many as the number of processor cores). Thus, we had the right to expect almost perfect efficiency: several parallel processes, which are not quite critical to memory and cache size (this feature of audio codecs is well known), usually don't interfere with each other. That's exactly what happens in reality, just look at test results: +392%, if we compare the single-core and the quad-core systems.

Even the rude graph clearly shows a small dip in the area of three cores. If you download this xls spreadsheet with detailed results, you may calculate on your own that it really exists. That is efficiency of using three cores is a tad lower than that of two and four cores.

Video encoding

The first diagram clearly demonstrates performance gains from increasing the number of cores in this group. However, this effect is significantly lower than the ideal (approximately twice as small), so the additional diagram and the table are certainly necessary. Well, let's sort everything out in the video encoding group.

Unfortunately, Canopus (GrassValley) ProCoder is an apparent outsider. This relatively old program (it hasn't been updated for several years) is still one of the top-quality software encoders into MPEG2. However, it uses modern hardware only perfunctorily: even the second core yields only 19% performance gain, and efficiency drops even further with more cores...

DivX codec tries to be efficient to the end, but it fares worse with each new core. However, the open source XviD demonstrates similar behavior. There are still some minor differences between them: DivX uses the second core more efficiently, but XviD manages to benefit more from the fourth core. However, these differences are not critical.

Monsters of parallel optimizations are the commercial Mainconcept and, strange as it may seem, the open source x264. The latter manages to get close to maximum possible results, and even cross the line with four cores! But we already know what actually happens here: "pseudo-exceeding" of the theoretical limit probably has to do with x264 "not getting enough" from three cores. We already came across this phenomenon of the three-core system, didn't we?

On the whole, we can say that the first diagram would have looked better without the old Canopus. On the other hand, lots of people still use MPEG2 for home video DVDs. And as long as this format lives, so will be the best codec for this format, even if it does not use modern computers very efficiently.

Write a comment below. No registration needed!