Ik ben op mijn werk al enige tijd bezig met het maken van een camera. Hiervoor is een aantal nogal rekenintensieve algoritmen nodig om het rauwe beeld van de sensor een beetje toonbaar te krijgen. Omdat dit ook een beetje snel moet, heb ik bepaalde zaken dmv. OpenMP multi-threaded gemaakt.

Zo heb ik voor een bepaald de-Bayer algoritme het werk opgesplitst in 8 threads in de hoop dat het ook 8x minder tijd kost per frame en ik dus meer frames per seconde kan verwerken. In de praktijk blijkt de tijdswinst ongeveer een kleine factor 4 te zijn.

Op een computer met een Intel Core i7 870 (4 cores, 4 hyperthreading-cores) en Windows 7 (32bit) krijg je dan ook de volgende grafiek te zien:

Echter wanneer ik dezelfde applicatie, met dezelfde instellingen, op mijn eigen PC uitvoer (Intel Core i7-2600 @3.40GHz met Windows 7, 64bit), dan krijg ik het volgende:

De enige verschillen zijn:

• 32bit om 64bit Windows
• Core i7 van de eerste generatie en een van de 2e generatie (vergelijking op site van Intel)

In beide gevallen heeft de applicatie 8 threads actief (plus nog een paar, maar die gebruiken op dat moment weinig CPU-cycles), maar op de 2e configuratie (Sandy Bridge processor en 64-bit Windows) is de verdeling duidelijk anders. N.B. het is dezelfde executable (dus 32-bit)

Het is in elk geval uitgesloten dat dit een geheugen I/O probleem is, aangezien ik in een andere (vergelijkbare) test-applicatie ruim 40x zoveel data kan verwerken per seconde.

Ik vermoed dat ik in mijn algoritme bepaalde instructies/operaties gebruik die elkaar in de weg zitten op een enkele core en de bijbehorende hyperthreading core, waardoor beide threads op elkaar staan te wachten. Dat zou verklaren waarom de verbetering (in rekentijd per frame) hooguit een factor 4 is en niet de factor 8 die ik hoopte te bereiken met 8 threads. Tevens verklaart dat ook waarom de CPU-load nagenoeg halveert wanneer de 8 threads over 4 ‘echte’ cores verdeeld zijn.

De vraag is echter wat het veroorzaakt dat op het 2e systeem de elkaar blokkerende threads bij elkaar gezet worden door de scheduler.

Is dat iets wat het verschil is tussen de 64-bit en 32-bit versies van Windows? Ik kan mij voorstellen dat daar best wel wat verschil in zit, mede omdat er totaal geen rekening meer gehouden hoeft te worden met 16-bit applicaties in 64-bit Windows. Maar dan zou Windows ook moeten kunnen merken dat 2 threads op elkaar staan te wachten. In de grafiek van het 2e systeem is goed te zien dat in het begin de ‘5e core’ er eerst wel bijgehaald wordt, maar dat die op een gegeven moment toch minder belast wordt. De test-applicatie is het enige wat actief bezig is.

Een andere mogelijke oorzaak zou het verschil kunnen zijn tussen werking van de Turbo Boost van de 1e generatie Core i7 en de 2e generatie. Dat zou dus een verbetering kunnen zijn in de totale performance van het systeem, aangezien de niet gebruikte delen van de CPU beschikbaar zijn voor andere taken.

Dit vraagt om verder onderzoek, dus ik zal hier later nog wel een keer op terug komen.