2017-05-12 4 views
1

J'ai une application de streaming vidéo haute performance (614400) et de haute performance (100fps, 10ms pour 1 frame). Dans 1 frame je dois modifier mon cadre, et utilisé pour ce 8 threads. Ce qui est plus rapide: 1. accéder à tous les éléments du fil 1 par 1, e. g. Thread1 (1,2,3, ... n) Thread2 (n + 1, n + 2, ... n * 2) ... 2. éléments d'accès dans l'ordre suivant: Thread1 (1,9 , 17 ...) Thread2 (2, 10, 18) ... quelle voie peut être plus rapide? maintenant j'ai la deuxième méthode:Performances C++ dans un grand réseau

workers = new std::thread*[workersCount]; 
for (int j = 0; j < workersCount; j++){ 
    workers[j] = new std::thread(&parameterController::extractPart, this, j*2, workersCount*2); 
} 
for (int j = 0; j < workersCount; j++){ 
     workers[j]->join(); 
     delete workers[j]; 
    } 
delete workers; 
+0

Je soupçonne que * mesurer * répondra à votre question de quoi, si quelque chose, est plus rapide. – WhozCraig

+2

Créez-vous et détruisez-vous des threads pour chaque image? o.O – nakiya

+0

Je sais, c'est une mauvaise façon, mais maintenant aucune idée de la façon de mettre en œuvre cela. Maintenant, je cherche les threads infini init 8 dans le constructeur, qui attendent une nouvelle image. Une idée, comment attraper, que les threads attendent un nouveau cadre? parce qu'après cela, je dois faire plus avec ces données. – Nick

Répondre

1

Profil à la fois et voir la différence, c'est la seule façon d'être sûr. Je devrais deviner qu'ayant chaque thread produire un morceau contigu sera plus rapide en raison de préextraction et de convivialité de cache, mais seule la mesure peut vous rendre certain.

+0

Oui, chaque thread doit être créé une fois, d'accord. Pouvez-vous recommander le nombre de fils? Cette valeur relative avec les cœurs de CPU? – Nick

+0

@Nick Je dirais que vous devriez utiliser GPU pour cela, CPU avec autant de threads .. bien rien au-dessus du nombre de cœurs aurait un impact négatif sur les performances, CPU non-serveurs ont de 4 à 16 cœurs .. GPU démarrer avec des dizaines et se terminent avec des milliers. Mais dans votre cas, l'impact des performances principales est fait dans la création et la destruction du thread, pas dans l'accès au tableau de pointeurs. – Swift