Concurrency :: parallel_sort Overhead und Performance-Hit (Faustregel)?

Question

Kürzlich bin ich auf eine sehr große Leistungsverbesserung gestoßen - ich spreche von einer 4x-Verbesserung - mit einer Codeänderung von nur einer Zeile. Ich habe gerade einen std :: sort Aufruf concurrency_parallel Art

// Get a contiguous vector copy of the pixels from the image. 

std::vector<float> vals = image.copyPixels(); 

// New, fast way. Takes 7 seconds on a test image. 

concurrency::parallel_buffered_sort(vals.begin(), vals.end()); 

// Old, slow way -- takes 30 seconds on a test image 
// std::sort(vals.begin(), vals.end()); 

Diese für ein großes Bild war und ließ meine Verarbeitungszeit 30 Sekunden bis 7 Sekunden. In einigen Fällen sind jedoch kleine Bilder erforderlich. Ich weiß nicht, ob ich das blind tun kann oder sollte.

Ich möchte paralell_sort, parallel_for und ähnliches vernünftigerweise verwenden, aber ich frage mich, welcher Schwellenwert überschritten werden muss (in Bezug auf die Anzahl der zu sortierenden Elemente), bevor es zu einer Hilfe wird und kein Hindernis.

Ich werde irgendwann einige langwierige Leistungstests durchlaufen, aber im Moment habe ich nicht viel Zeit dafür. Ich würde mir wünschen, dass dies "die meiste Zeit" besser funktioniert und die Performance nicht immer (oder zumindest nur selten) beeinträchtigt.

Kann jemand mit etwas Erfahrung in diesem Bereich mir eine vernünftige Faustregel geben, die mir in "den meisten Fällen" hilft? Gibt es einen?

Answer 1

Hier ist, wie ich darüber denke, Windows-Thread-Zeitplan Zeitquanta ist ~ 20-60 ms auf der Workstation und 120ms auf dem Server, so dass alles, was in dieser Zeit getan werden kann, keine Nebenläufigkeit benötigt.

Also rate ich bis 1k-10k Sie sind gut mit Std :: sortieren die Latenz beim Starten mehrerer Threads wäre ein Overkill, aber 10k weiter gibt es einen deutlichen Vorteil bei der Verwendung von parallelen Sortierung oder p-gepufferte Sortierung (wenn Sie es sich leisten können) und parallele Radix-Sortierung wäre wahrscheinlich sehr gut für sehr sehr große Werte.

Vorbehalte gelten. : o)

Answer 2

Die Anforderung von RandomIterator und das Vorhandensein von Überladungen mit einem const size_t _Chunk_size = 2048 Parameter, die die Schwelle der Serialisierung steuern, implizieren, dass die Bibliotheksautoren dieses Anliegen kennen. Also wahrscheinlich nur concurrency::parallel_ * als Drop-in Ersatz für std:: * wird gut tun.

Answer 3

Ich weiß nicht über concurrency Namespace, aber jede sinnvolle Implementierung eines parallelen Algorithmus passt sich der Größe der Eingabe entsprechend an. Sie sollten sich keine Gedanken über die Details der zugrunde liegenden Thread-Implementierung machen müssen. Mach es einfach.