non paulop, mon calcul est correct, c'est juste que les processeurs d'entree de gamme sont a 2.66 Ghz donc tu as 4x4x2.66Ghz = 42.56GFlops

D'ailleurs plus bas dans la page tu as un i7-920XM a 2Ghz qui tire bien 32GFlops.

En gros un ARM900, c'est en performance quelquepart entre un P2 et un P3. Ca depend de quel sont des accelerateurs dans le ARM aussi. (c'est super merdique ARM comme norme)

"(c'est super merdique ARM comme norme)"

comme norme? comme architecture? j'avais entendu dire que x86 tenait un peu du bricolage, mais que ca s'est tellement répandu qu'intel est resté dessus, mais que ça restait une architecture lourde et pleine d'instructions complexes et qu'ARM corrigeait justement ce genre de défauts...

Qu'est ce qui fait qu'une P4 à 2ghz est moins puissant qu'un i7 au final ?

1. Paulop Voir le profil de Paulop
2. Posté le 20 septembre 2011 à 20:38:02 Avertir un administrateur
3. Qu'est ce qui fait qu'une P4 à 2ghz est moins puissant qu'un i7 au final ?

le cache est plus réduit, il y aurait de la latence dans le pipeline d'instruction de ces processeurs-là, moins de coeurs, probablement le nombre d'instructions traitées en même temps qui est plus réduit... on peut difficilement résumer un processeurs à sa fréquence d'horloge.

En GFlops, un p4 et un i7 sont pareil Mais les GFlops, c'est une metrique merdique.
meilleur cache, meilleur prediction de branchement, plus d'instructions atomique, plus d'instruction vectorielle, plus de registre...

caelacanthe, ARM c'est plus une norme qu'autre chose, tout le monde peut produire des ARMs, et ARM c'est une norme frankeinstein avec des plugins dans tous les sens. En fonction des extension ARM que tu as, tu as un jeu d'instruction different. Linus torvalds a gueuler sur les fondeurs de ARM a ce sujet il y a pas longtemps [1].

Par exemple, dans mon n810, c'est un arm11 (de memoire), mais avec un coproc graphique integre (OMAP). Mais pendant longtemps, on avait pas assez d'information dessus pour avec des compilateurs et des drivers raisonnable. Donc les kernels produits par la communaute pouvait utiliser le coeur de l'arm mais pas le coproc graphique.

[1] http://linux.slashdot.org/story/11/08/18/1728227/ARM-Is-a-Promising-Platform-But-Needs-To-Learn-From-the-PC

J'avais déjà admis que la fréquence ne faisait pas tout, que le cache et les registres étaient importants, mais ça reste quand même flou pour pas mal de choses.

"caelacanthe, ARM c'est plus une norme qu'autre chose, tout le monde peut produire des ARMs, et ARM c'est une norme frankeinstein avec des plugins dans tous les sens. En fonction des extension ARM que tu as, tu as un jeu d'instruction different. Linus torvalds a gueuler sur les fondeurs de ARM a ce sujet il y a pas longtemps [1]."

merci du renseignement... je pensais qu'ARM était voué à remplacer x86 dans les années à venir, mais si c'est un désordre comme ça...

sinon, quelqu'un connaitrait un algorithme de tri efficace et simple à coder, pour trier un tableau d'environ 50000 nombres?

j'en ai besoin pour un jeu, le temps de chargement d'un des niveaux dépend directement de ce tri. avec bubble sort, j'ai 30 secondes de temps de chargement. 30 secondes, presque une boucle infinie.

Et il a toujours besoin d'un six-coeurs et d'un SLI de 580 GTX pour tourner ton jeu?

1. Pocolo Voir le profil de Pocolo
2. Posté le 20 septembre 2011 à 23:31:14 Avertir un administrateur
3. Et il a toujours besoin d'un six-coeurs et d'un SLI de 580 GTX pour tourner ton jeu?

justement, j'essaye de tirer la config recommandée vers le bas, là...

le framerate est déja acceptable (une vingtaine de FPS ) sur le niveau qui sert de banc d'essai, là, j'améliore juste le confort visuel.

"sinon, quelqu'un connaitrait un algorithme de tri efficace et simple à coder, pour trier un tableau d'environ 50000 nombres?"

qsort ?
std::sort?

1. godrik Voir le profil de godrik
2. Posté le 21 septembre 2011 à 00:01:25 Avertir un administrateur
3. "sinon, quelqu'un connaitrait un algorithme de tri efficace et simple à coder, pour trier un tableau d'environ 50000 nombres?"

qsort ?
std::sort?

c'est bien du c++... mais je n'ai pas vraiment droit aux librairies externes, coder soi-même ce genre de choses fait partie du cahier des charges qui vient avec ce projet, il a un but didactique qui ne se cache pas.

Pourquoi pas le tri rapide, tout simplement, il porte tellement bien son nom ^^

http://fr.wikipedia.org/wiki/Tri_rapide

oui, celui-ci a l'air bien! j'étais en train de regarder un peu sur wikipédia, et j'hésitais entre celui-ci et le merge sort...

je vais essayer le tri rapide, il parait qu'il consomme un peu de mémoire, mais ça ne fait pas partie de mes contraintes. merci de ton avis !

Globalmenet, n'importe quel trie en O(n log n) ira tres bien

Ca depend de ton probleme et des tes donnees en entree. Si tes donnes arrivent deja trie ou presque trie dans la plupart des cas, merge sort est tres bien. Si tes donnes sont deja quasiment trie et que tu applique qsort, tu aura besoin de faire une passe de shuffle auprealable, sinon tu vas tirer des perfs pourries

Personnelment, j'aime beaucoup heap sort. Parceque j'aime les heap

le quicksort irait plus vite sur un tableau qu'on aurait mélangé avant? c'est plutôt étrange comme comportement.

caelacanthe, oui, quicksort est rapide en moyenne mais pas au pire cas. Au pire cas, il est en O(n^2). Et le pire cas est quand il est trier (ou ordre inverse, je sais plus). Donc pour avoir le plus de perf dans quicksort, il faut commencer par melanger le tableau.

j'ai regardé un peu quicksort, mais finalement, j'ai eu du mal à cerner l'algorithme donc je me suis rabattu sur heapsort (en recopiant bêtement l'algorithme proposé sur cette page: http://en.wikipedia.org/wiki/Heapsort )

j'ai envie de dire... "OMG"? le temps de tri de ce tableau est passé de 30 secondes à moins d'une fraction de seconde.

Ce que je vais dire peut être sujet à discussion.

Je ne pense pas que le critère essentiel pour le quicksort soit demélanger le tableau au début ou non, bien que ca complexité moyenne soit en O(n.log n) et sa pire complexité en O(n^2).
Si mes souvenirs sont bons, ce qui va différencier un bon tri rapide d'un mauvais, c'est essentiellement le choix du pivot, qui peut être une affaire pas évidente.
On peut évidemment chercher la médiane, mais cela induit un coût supplémentaire.

Après, suivant la méthode de choix du pivot, et dans le cas où celle ci est assez bête (ce qui est souvent le cas), un tableau déjà mélangé dans le désordre sera effectivement plus avantageux, car il y a plus de chance que le pivot soit "un bon pivot", i.e. pas loin de la valeur médiane.

En fait ce que je voulais dire par là c'est que l'influence d'un pré-mélange était indirecte.

Je pense que c'est parce qu'un pré-mélange a plus de chance de transformer un mauvais pivot en un piveau potable.
Et pas que l'algorithme n'aime pas particulièrement les tableaux triés en sens contraire (pas comme un tri à bulles qui n'aime par exemple vraiment pas que le plus petit élément soit à la fin, ce manière intrinsèque).

"On peut évidemment chercher la médiane, mais cela induit un coût supplémentaire. " mais la complexité dans le pire cas devient O(n.log(n)). De mémoire, se contenter de réutiliser l'astuce pour le calcul de la mediane en temps linéaire lors du choix du pivot suffit, et donne lieu à un bon compromis.

Sinon, je signalais par IRC qu'il peut être important de compter le nombre d'éléments égaux au pivot. Dans une grande liste avec beaucoup d'éléments redondants, ça donne des quicksort extrêment efficaces.