Reprise du message précédent :

Je pense pas qu'on aie besoin de s'y connaitre en dev pour comprendre que des taches dans ce monde (y compris en dehors d'un ordi) ne sont pas parallelisables. C'est de la logique pure. Dans certains cas il n'est juste pas possible de commencer une tache sans avoir le resultat de l'autre (certains ont propose l'exemple des suites mathematiques).

je ne suis pas dev, je m'arrête à quelques scripts, mais j'ai suivi  y'a 6 mois des cours de MT ou prog concurrente, et je peux dire ceci, here tu te gourre.
 
Here, au delà  des tes grandes envolées sur le dev MT, je remarque que tes arguments sont bancals et que tu prends bien de haut moumoule et Samourai80, dont leurs explications sont bien plus éclairantes que les tiennes.
 
et un smiley n'y changera rien.

Exactement, c'est ce qu'on apprend en étude d'informatique/électronique embarquée en cours d'architecture Processeur  
Et après on t'apprend à paralléliser des tâches (autant que possible) pour avoir le même résultat en un minimum de temps. Le tout en.... assembleur x)

 
Dan l'utilsation kon a (Workeur ki trvaill sur des données/tretement diférent, donk qch de relativement sinple), jamai eu de pbs kelkonke parraport à ce ke tu mens tionne.
 
Désolé, j'ai quelques lacunes en français, j'y travaille doucement mais sûrement ...    

Merci   Bon je vais quand meme attendre le test de HFR. La publication est autorisee a partir de 15h UTC (16h heure fr) si j'ai bien compris ?

 
Certainement que théoriquement tout n'est pas parallèlisable. Mais dans la la pratique un programme ne va pas faire une seule tache N qui sera nécessaire pour la tache N+1.
 
C'est le cas pour l'encodage vidéo. Il faut en gros que la frame N ait été encodé pour pouvoir passer à la frame N+1 (dans le cas des Pframes par exemple). Mais il n'empêche qu'un codec vidéo est hautement parallèlisable tout simplement parce que l'encodage de la Frame N est parallèlisable.
 
C'est aussi le cas avec l'exemple théorique du calcul d'une suite. Il faut bien sûr attendre d'avoir le résultat pour le terme N pour calculer le terme N+1. Mais le calcul du terme N est peut-être une tâche qui est parallèlisable.  Et d'ailleurs c'est un bien mauvais exemple car pour beaucoup de suite on pourra calculer directement le terme N. Mais bref, passons.
 
 
Mais bon les débats théoriques c'est bien. la pratique c'est mieux. Et en en pratique, tu constates qu'il n'existe que très peu d'application qui ne bénéficie pas du MT, jeux y compris.

Perso j'ai donne l'exemple de Modelsim dont la tache principale (vsim) n'est pas parallelisable car tout est interdependant. Ou alors il faudrait revoir le concept du logiciel.
 
Mais bref, perso ce que je disais c'etait pas que le MT ne servait pas, mais qu'on ne pouvait pas paralleliser a l'infini et que plus on avance dans la parallelisation et plus il est difficile de trouver de nvlles choses a paralleliser. En gros le nombre de threads des softs augmente mais cette augmentation a pris qques annees et je ne la vois pas accelerer, bien au contraire.
 
Des traitements comme le traitement d'image sont eux tres parallelisables et continueront de beneficier de l'augmentation des cores pendant encore un moment. Je suis pas trop mal place pour en parler, mon boulot consiste a concevoir des FPGAs de traitement du signal en imagerie medicale. Dans ce cas precis la parallelisation est limitee par le nombre de matrices de pixels a traiter par frame, et encore il y a moyen de paralleliser entre les frames aussi. Mais bon mon cas c'est du traitement 100% hardware, sans utiliser d'instruction.

Fichtre, on en lit de la branlette
Bon ils viennent ces fichus tests ou bien?  
 
Bisous

ON EST LE 2 MARS

Le NDA est valide jusqu'à 16h.

Peut être 15h à vérifier

Je crois que c'est 16h.

Va-t-on pouvoir lire des choses cools et se toucher sur la vitesse de dézippage du Ryzen?

16h , heure d'hiver tout ça .

 
Tu donnes des exemples ou effectivement y a moyen de paralléliser en masse et tu penses pouvoir l'appliquer à tous les domaines. C'est ça le problème: l'encodage c'est une tâche bidon niveau complexité (ça reste cependant très lourd)
 
L'encodage vidéo est parallélisable au niveau de la frame elle-même (cf slice based threading) et au niveau des frames (cf frame based threading). Y a des dépendances entre les frames certes mais tu peux paralléliser le traitement des frames majeures (key frames). Combiné au fait que dans le cas d'un encodage dit prévisible (donc pas du réel time genre pour un stream, même si cette notion n'existe pas vraiment, autre discussion), tu peux paralléliser MASSIVEMENT et tu es juste limité par ton matériel et par l'application que tu utilises pour encoder.
 
Maintenant, les jeux vidéos c'est un domaine clairement non prévisible car dépendant d'interactions de l'utilisateurs. Et vu que tu peux pas prédire, tu es limité à ce niveau là. Sans parler du fait qu'un jeu vidéo c'est pas juste un bête traitement mais composé d'inputs utilisateurs, mise-à-jour d'informations (local/en ligne), gestion de la physique, etc, etc ...

 
Bon faut arrêter avec la non-parallèlisation des jeux avec des raisonnement fumeux. Un i7 7700K c'est huit thread, et cela correspond déjà à une parallèlisation CPU assez massive. Et les jeux ne vont pas s'arrèter là. Beaucoup de jeux sont capables de tirer partie de 20 Threads. Voilà la réalité des faits.

Sources et exemples ?

 
Ca je préfère même pas commenter ...    
 
Un codec c'est tout sauf simple. Je pense que c'est tout simplement une des tâche les plus lourde, les plus complexe et avec la plus grande variété possible de calcul que tu puisses rencontrer.
(tu as du DCT, iDCT, SAD, SADT, SSE, PSNR, SSIM, RD, recherche vectorielle, compression entropique ... etc etc etc).
 
Le x265 est actuellement une des seule appli à vraiment tirer partie des instructions AVX/AVX2, avec des optimisations personnalisées pour chaque architecture.
 
D'ailleurs le x265 est le bench que j'attends le plus, car c'est lui qui indiquera la véritable puissance brute de Rysen, plus à mon avis que n'importe quelle autre bench.
 

Bouh article dispo sur anandtech. Ils trichent

 
Rien de plus facile ... ;-)
 
Sources et jeux déjà données plus haut à de multiples reprises:
https://www.computerbase.de/2017-02 [...] ored-2-fps
 
Les i7 6900K et  i7-6950 sont les meilleurs CPU avec une Titan pascal en 1080p sur:
- Anno 2205
- Ashes of the Singularity
- BF1
- Deus Ex: Mankind Divided
- Dishonored 2
- Doom (Vulkan)  
- Gears of War 4
- Rise of the Tomb Raider (DX11)
- Shadow Warrior 2
- Total War: Warhammer  
- Watch Dogs 2
 
... et c'est une liste non-exhaustive
 

grosse déception en single-thread quand même

 
Les raisonnement fumeux que tu ne comprends pas ? Tu peux balancer l'article de computerbase sur tous les posts parlant de CPUs du hfr, la plupart vont suivre ton raisonnement sur base de:
 
- i7-7700k (4/8 threads, grosse fréquence)
- Intel Core i7-6950X (10/20 threads, basse fréquence)
 
Omg le Core i7-6950X est devant de 7 % sur 14 jeux en 1080p => le monde est multi-threadé. Voilà, la vérité vraie est absolue, le i7-7700k est has-been, le hype Amd Ryzen prends le dessus et chaque joueur devra installer un serveur chez soi pour jouer correctement.  
 
Omg le Core i7-6950X est devant de 19 % sur 14 jeux en 720p => le monde est hyper multi-threadé, on a réussi à éliminer l'influence du GPU et on a constaté une meilleure perf sur le  i7-6950X !! C'est un cas réel et représentatif, ben oui, tout le monde joue en 720p de nos jours    
 
Sans prendre en considération que la fréquence à partir d'un seuil moment à moins d'intérêt, que le i7-6950X a plus de cache, le système mémoire est plus performant, blablabla. Mais osef, regarde la fréquence, elle est plus basse ! Et il est devant l'enfoiré !!!! This is madness.
 
(Attention pour être clair: y a des jeux qui affichent des performances meilleurs avec plus de coeurs, j'en suis persuadé. Mais c'est pas que ca, n'est-ce pas)
 
 

 
L'encodage, c'est l'application d'une série d’algorithme/de méthodes défini et appliqué dans un ordre plus ou moins précis. C'est très lourd niveau traitement, c'est très juste. Complexe ? Les algorithme/méthodes le sont, mais pour ça, tu as quelque choses qui s'appelle, attends voir ... API ! Donc c'est quelque chose de défini, tu réinventes pas la roue, n'est-ce pas.
 
Va développer un jeu ou en fonction des besoins/choix/envies tu dois définir tes propres algorithme parce que, ben, y a pas d'API qui magiquement fait ce que tu toi tu veux faire ! Va développer une AI très poussée qui réagit en fonction de l'input de l'utilisateur. Va essayer de faire communiquer toutes les entités ensemble et tout ça de manière synchro. Non, à mon avis, tu ne pourras jamais comprendre. J'ai déjà à me casser la tête au niveau applicatif, j'imagine même pas un  jeu de la trempe de WD 2 ...

Bon encore une fois ça suffit avec tes explications fumeuses.

Je vais donc te rappeler la base: le MT ça commence à 2 thread. A un moment, il faut être cohérent. Si tu prétend que le i7 7700K est la meilleure solution pour les jeux, tu parles ici d'un CPU 4C/8T, qui peut déjà être considérée comme une solution CPU massivement MT (en tout cas en terme de CPU grand publique).

Et peu importe l'éfficacité du MT, les faits c'est qu'un i7-6900K ou un 17-6950K seront meilleurs dans certains jeux qu'un i7-7700K, et que l'explication est uniquement dû au fait d'un meilleur support du MT par le jeux lui-même (ou les pilotes d'ailleurs). Et c'est d'ailleurs extrêmement facile à vérifier pour un même CPU puisqu'il suffit de désactiver un nombre croissant de core pour le vérifier. Point final.

 
Non, non et non. Le sous-système mémoire et le cache joue aussi rôle, que tu le veuilles ou non.  
 
Ta méthodologie pour vérifier tout cela par contre est très juste.  
 
Sinon, vu que tu vénères tellement le test de computerbase, je vais te mettre le lien vers le récap de hfr (on est en 1080p pour infos) et te laisser méditer tout ça: http://www.hardware.fr/articles/95 [...] mance.html  
 
Attention, je ne dis pas qu'un test est meilleur que l'autre.

Ben en fait c'est surtout que le test que tu linkes est en parfaite contradiction avec la plupart des tests que j'avais pu voir comparant les Broadwell-E aux Skylake / Kaby-Lake. Personnellement je considere les tests de HFR nettement plus credibles, notamment celui des Broadwell-E il y a qques mois, et celui du Ryzen aujourd'hui. Concernant le nombre de threads adequats, beaucoup de tests montrent que le sweet spot est autour de 4 threads, etant donne que dans les jeux l'HyperThreading mutliplie en gros le nombre de cores par 1.5, ca signifie qu'un core i3 (2c+HT=3 threads) sera un cran en deca a cause du manque de thread par rapport a un core i5 (4c). Pour des jeux tres optimises et ceux qui sortent dans un futur proche, on peut considerer que 6 threads (4 core + HT) permette d'avoir un peu de marge de ce cote la. Pour le reste c'est la bande passante memoire et la frequence qui joue beaucoup dans les jeux.

Bref va jeter un coup d'oeil au sympatique article de HFR paru aujourd'hui meme.

Computerbase est un site sérieux, notre ancien protocole pour les jeux commençait à dater et ne doit pas être pris en référence en 2017
 
D'ailleurs chez eux Ryzen semble en moyenne plus véloce dans les jeux et certains jeux ont des comportement différents vs le nombre de coeurs (F1 2016 par exemple), je ne me l'explique pas encore.

Concernant le Core Parking il existe un logiciel qui s'appelle ParkControl
https://bitsum.com/parkcontrol/
 
A voir ce que cela donne.A tester

En effet les tests en jeu semblent assez variables de nos jours. Quoiqu'il en soit depuis on a eu votre test Ryzen avec le nouveau protocole donc on sait mieux a quoi s'en tenir.

Bon de ttes facons pour le gaming le tests des R3 et R5 face aux core i3 i5 aura plus d'interet.