¶New CPU's a bit faster than I expected

Midway through the development of the VirtualDub 1.5.x series, one of the decisions that I made was to deprecate the old VBitmap-based blit library and write a new library based on what I call pixmap objects. These were new descriptor structures that solved a number of annoyances in the old VBitmap structure, such as:

• not being able to distinguish between 555 and 565 16-bit RGB
• not supporting YCbCr or multi-plane formats
• *#($&# upside down encoding

In addition, I started writing a unified blit interface (VDPixmapBlt) that would support orthogonal blitting between any two formats, with the only exception being paletted formats, which were source-only. This turned out to be a great decision, because now I don't have to worry about whether a conversion exists for a particular path and can just do blits as I need them. This isn't always advisable for performance or quality reasons -- Y8 is not a good intermediate format for conversion from 24-bit RGB to 32-bit RGB -- but it's wonderful for less critical paths such as UI and just migrating old code in general. It's the main reason that the number of RGB-only paths in VirtualDub has been shrinking over time and will continue to dwindle.

I've now begun to run up against the limits of this current scheme, and a while ago I started toying with a new scheme I call uberblit, which is a scanline-based scheme consisting of a tree of generators. The main motivations behind uberblit are to increase flexibility (dithering, chroma resampling options, more formats) and to eliminate the current table-based scheme where I have to initialize an O(N^2) table of blitters. It's turned out to be more complex than I like and hasn't yet become a good general purpose replacement for the existing blitter, but it has some advantages in terms of flexibility and data cache strategy, and it was useful enough that I pulled it into 1.8.0 for YCbCr resampling.

As part of some work to see if I could make it usable for general blitting, I wrote a benchmark to compare its performance against the existing blitters, and the result wasn't pretty. For conversions the uberblitter is almost always slower than the primary blitter, usually because either there are extra conversions, optimized span routines aren't hooked up, or simply just overhead in the row fetch paths (a few layers of virtual calls can be slower than the turbo SSE2 routine it controls). After a little bit of tweaking I got depressed, since it was pretty obvious that it would take more than hooking up a couple of routines to get uberblit up to snuff. Still, being able to more easily handle a wider variety of formats like YCbCr with PAL DV style chroma and float3/4 is a compelling reason to keep trying.

Anyway, back to the subject... after getting my new laptop, I decided to compare the two quickly just to see what the performance of the new CPU was like. The old laptop is a 1.8GHz Pentium M, while the new laptop is a current generation Core 2 Duo with SSE4.1 support ("Penryn" core). The dual core part is irrelevant here as the blitters are single threaded, as is SSE3/SSSE3/SSE4.1 as I don't use them yet, but the Core 2 Duo part is important as the extra execution unit and the single clock SSE throughput are very applicable.

Results are after the jump (all results in megapixels/second), but the gist is that the Penryn-based system is a lot faster at running the existing blitters than I had expected given the GHz ratings. The most likely reason is memory and the front side bus being faster, because the direct blit (no conversion) cases are ridiculously faster and those definitely are not execute bound as they're memcpy() based. It's also possible that the Core 2 Duo is cheating due to larger caches, but it wins handily even in the cases where heavy computation is involved (RGB<->YCbCr conversion with chroma subsampling). The blitters are also designed to reduce this effect by interleaving calculations via scanline stripes whenever multipassing is required, so that data flows in and out of the caches smoothly instead of having performance drop off a cliff after a certain bitmap size.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.