Discussion :

[arthurG]

Bonjour,

c'est une question de design que j'aimerais poser. En fait ce n'est pas vraiment une question mais j'aimerais avoir votre avis.

Le code ci-dessous présente deux méthodes basiques qui effectuent l'opération 255-valeur sur tous les éléments d'un tableau d'octets.
Comme en ce moment j'étudie à la fois la librairie TBB et certaines méthodes de design, j'ai voulu mêler les deux.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
#include "tbb/parallel_for.h"
#include "tbb/blocked_range.h"
 
typedef unsigned char byte;
 
struct InvertPolicy_Serial {
	static void apply (byte* ptr, const std::size_t sz) {
		byte* ptr_start = ptr;
		const byte* ptr_end = ptr_start+sz;
		for (; ptr_start!=ptr_end; ++ptr_start)
			*ptr_start = 255-*ptr_start;
	}
};
 
struct InvertPolicy_TBB {
 
	class FApply {
		byte* ptr_;
	public:
		FApply (byte* ptr) : ptr_(ptr) {}
		void operator () (const tbb::blocked_range<std::size_t>& r) const {
			InvertPolicy_Serial::apply (ptr_+r.begin(),r.size());
		}
	};
 
	static void apply (byte* ptr, const std::size_t sz, std::size_t grain_size=1e5) {
 
		tbb::parallel_for (tbb::blocked_range<std::size_t>(0,sz,grain_size),
						   FApply (ptr));
	}
};
 
 
template <typename FilterPolicy>
struct Invert {
 
	static void apply (byte* ptr, std::size_t sz) {
		FilterPolicy::apply (ptr,sz);
	}
 
	static void apply (byte* ptr, std::size_t sz, std::size_t grain_size) {
		FilterPolicy::apply (ptr,sz,grain_size);
	}
};

Donc on appelle les méthodes avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Invert<InvertPolicy_Serial>::apply (ptr,sz);
//ou
Invert<InvertPolicy_TBB>::apply (ptr,sz);

On pourrait imaginer un InvertPolicy_OpenMP, InvertPolicy_CUDA, InvertPolicy_ASM etc...

Alors la question quand-même, est-ce que cette méthode a un intérêt, à part faire des benchmark ?
Dans un programme plus important, est-ce que cela peut s'avérer utile si les différentes politiques ne peuvent communiquer entre-elles (pour choisir entre une implémentation TBB ou CUDA par exemple suivant les tâches en cours) ?

[SKone]

Bonjour,

A part les raisons que vous avez évoqué : les benchmark, qui ne sont à négliger il justifie le travail et l'investissement en heure (donc en argent) on montre en travaillant tant j'ai fait gagner tant au programme donc potentiellement tant au client ou à l'entreprise.

Les différentes implémentations en effet je vais faire une révélation : CUDA est plus performant sur nVidia, StreamAPI est plus performant sur AMD (ATI) OpenCL est "générique" modulo perte de perf sur tel ou tel hardware (et oui la généricité à un coût, on se limite à ce que tous le monde peut faire)... Cela permet aussi d'être portable tout les hardwares ne supporte par réellement le parallélisme...
On peut avoir des politiques SSE, MMX, Altivec, SPU, GPU, CPU parallèle...

[gbdivers]

CUDA est plus performant sur nVidia, StreamAPI est plus performant sur AMD (ATI) OpenCL est "générique" modulo perte de perf sur tel ou tel hardware (et oui la généricité à un coût, on se limite à ce que tous le monde peut faire)...

Ca va même plus loin qu'une perte de performances... CUDA ne fonctionne que sur NVIDIA et Stream que sur ATI.
Pour la différence de performance CUDA vs OpenCL, si tu as un benchmark, je suis preneur. Parce que dit comme ça, je suis pas vraiment convaincu...

[SKone]

Oui en effet ma phrase est ambigüe => en effet CUDA fontionne seulement sur les nVidia, comme StreamAPI sur AMD (ATI)
Pour les benchs c'est logique qu'une API sur un hardware spécifique soit plus performante qu'une autre générique. Lors de l'implémentation la solution générique ne peut par exemple pas appeler tel ou tel instruction spécifique à tel hardware qui est bien plus optimale dans tel ou tel cas.
C'est comme au dernier GDC où des conférencier d'AMD prouve que les ATI sont plus rapide que les nVidia et les speakers d'nVidia prouve l'inverse, c'est tout simplement qu'il ne font pas les benchs sur les mêmes fonctions
Et si vous voulez des liens (je ne les est pas lu, mais très vite survolé) :
http://www.cse.scitech.ac.uk/disco/m...MattHarvey.pdf
http://arxiv.org/pdf/1005.2581v3