Optimisation sous Linux

Le 02-08-2012, P4nd1-P4nd4 <P4nd1-P4nd4@> a écrit :

leeed avait énoncé :

Le 02-08-2012, P4nd1-P4nd4 <P4nd1-P4nd4@> a écrit :

leeed avait énoncé :

Parceque tu sais compter, toi? Allez, on va la faire simple:

303/315*100= 3 % de différence

LOL

303/315*100 = 96.190476 - tu repasseras, hein ;) Et 100-96 = 4, pas 3.
Ça concerne la version OpenGL de Source, sous windows et sous linux.

Et puisque tu continues à jouer à "je coupe les citations là où ça
m'arrange":

Windows 7/Direct3D: 270 FPS
Windows 7/OpenGL: 303 FPS
Linux/OpenGL: 315FPS.

Alors, au cas où tu n'aurais pas été *FOUTU* de lire ce que je t'ai
écrit tout à l'heure:

Windows7/Direct3D Vs Windows7/OpenGL: 270/303*100 ~= 89%. Direct3D sous
Windows est donc 11% plus lent qu'OpenGL sous Windows. Même machine,
même driver. Déjà, ça la fout mal pour Direct3D.

Windows7/Direct3D Vs Linux/OpenGL: 270/315*100 ~= 85%. Direct3D sous
Windows est donc 15% plus lent qu'OpenGL sous gnu/Linux. Même machine,
drivers équivalents. Ça la fout mal pour le couple Windows/Direct3D.

Windows7/OpenGL Vs Linux/OpenGL: 303/315*100 ~= 96%. Donc, *après* les
optimisations de Valve en ce qui concerne la version openGL de leur
moteur, GNU/Linux est *ENCORE* 4% plus rapide que Windows. Ça la fout
*TOUJOURS* mal pour Windows.

Ça n'a rien à voir. Ici on parle juste de performances comparées des
deux systèmes, et des deux APIs utilisées. Et dans tous les cas de
figure, ton Windows 7 et son Direct3D se l'est pris dans le baba.

Ah, ils ont tsté DIrect3D ?

Ah, tu n'as pas lu l'article dont nous parlons! Ceci explique celà. Pour
l'ouvrir à tort et à travers, t'es un vrai champion! Dis donc, si à
chaque fois que tu l'ouvres tu ne prends même pas la peine de lire, de
te renseigner un minimum, je comprends que tu sortes des âneries plus
grosses que toi à chacun de tes posts.

Maintenant, un autre petit calcul (histoire que tu fasses tes devoirs de
vacances):

1 seconde = 1000 millisecondes.

1000/270 = 3.7037037 millisecondes pour rendre une frame sous
Windows/Direct3D.
1000/303 = 3.30033 millisecondes pour rendre une frame sous
Windows/OpenGL.
1000/315 = 3.1746032 millisecondes pour rendre une frame sous
Linux/OpenGL.

Ton Windows + Direct3D perd donc 3.7037037 - 3.1746032 = 0,5291005
millisecondes par rapport à Linux+OpenGL pour rendre *UNE* frame
(image). Je me demande vraiment ce qu'il branle pendant une demi
milliseconde. Et une demi-milliseconde, à la vitesse des machines
actuelles, c'est *beaucoup*. Et la différence sera encore plus énorme
sur du matériel moins performant (ce n'est pas linéaire).

Ah, et ce coup-ci, aies au moins la politesse de ne pas me couper quand
tu me cites, merci!

Mouai, certes, mais bon, les différences sont si ridicules que je ne
vois aucune suppériorité de Linux !

De plus, eux-mêmes ne savent pas comment optimiser Direct3D alors bon,
si c'était des vrais dév Direct3D, Windows serait bien plus rapide

Enfin, quand on parle de demi-milliseconds, je m'attendrai que l'on
parle de supériorité de Linux en dizaine de secondes ;>9

Tout d'abord, merci de ne pas m'avoir cutté comme une brute. Ce que tu
oublies, ici, c'est qu'on parle d'une demi-milliseconde *PAR IMAGE
CALCULÉE ET RENDUE* et ça fait une *ÉNORME* différence, sachant qu'il y
a plusieurs centaines d'images rendues par seconde (entre 270 et 315
d'après leur tests). De plus, si tu lis bien leur article, tu verras que
leurs performances en ce qui concerne le couple Windows/OpenGL (les 303
FPS), c'est *après* qu'ils aient optimisé leur moteur *et* travaillé
avec les fabriquants de cartes graphiques pour le rendu openGL. Que ce
soit sous Windows ou sous gnu/Linux.

On peut très bien imaginer que cette demi milliseconde de gain soit
utilisée pour, par exemple, rajouter de nouveaux effets ou améliorer le
rendu graphique général.

D'où l'intérêt souligné par Carmack himself dans un de ses récents
articles de parler en termes de millisecondes de rendu par image plutôt
qu'en terme d'images par seconde. Article que je t'invite chaudement à
lire, mis à part un peu de maths, ce n'est pas imbuvable et à la portée
de tout le monde ayant un minimum de connaissances.

Pour finir, tu te rends quand même compte que tu parles des devs de
Valve, et que leur gagne pain des dix dernières années, ils le doivent
aussi à Direct3D, donc, ouais, ils connaissent cette API certainement
bien mieux que toi ou moi. Ils sont d'ailleurs (il suffit de lire leur
article) étonnés des résultats obtenus avec OpenGL, que ce soit sous
Windows ou sous GNU/Linux. Et une différence de 4% sur un core i7 blindé
avec une GTX680 (le top du moment pour les "gamers"), ça peut aussi
signifier une différence de 20% sur un core i3 avec une GT530. Comme je
te le disais dans mon précédent post, ce n'est pas une loi forcément
linéaire (pas au sens mathématique du terme "linéaire"): ça dépend du
matériel, des entrées sorties, de la RAM, et de beaucoup d'autres
paramètres.

Franchement, au lieu de dénigrer, tu devrais te réjouir: un peu de
concurrence ne peut que nous amener de belles innovations, des deux
côtés de la barrière, et peut être nous sortir un peu de la
"consolisation" du domaine des jeux vidéos actuellement.

Et ça, c'est tout bénef, pour toi comme pour moi.

leeed a couché sur son écran :


bla-bla ... plein de mauvaise foi, etc ...



Puis-je juste me permetre de te faire remarquer que tu as délicatement
fais l'impasse sur une petite info dans l'article ....


"adapter les pilotes graphiques" ...

Donc, il faut à Linux des pilotes sur-mesure pour un jeu/test et avec
ça, il n'arrive à prendre à Windows (lui avec des pilote grand public
de série, pas de prototype de rally) que juste 12 petis fps sur 315 ...
aie, et t'appelle ça de la performance ?


Généralement, quand on oppose un nouveau prototype à un appareil de
série, on parle d'écarts significatifs, là un superbe 3.8 % d'écart, on
se demande quelle est la part de +performance et la part d'imprécision
de la mesure.

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Le Fri, 03 Aug 2012 17:49:09 +0200,
Ascadix <ascadix.ng@free.fr> écrivait :

leeed a couché sur son écran :


bla-bla ... plein de mauvaise foi, etc ...

C'est tout de même l'hôpital qui se fout de la charité.

Puis-je juste me permetre de te faire remarquer que tu as délicatement
fais l'impasse sur une petite info dans l'article ....


"adapter les pilotes graphiques" ...

Donc, il faut à Linux des pilotes sur-mesure pour un jeu/test et avec
ça, il n'arrive à prendre à Windows (lui avec des pilote grand public
de série, pas de prototype de rally) que juste 12 petis fps sur 315 ...
aie, et t'appelle ça de la performance ?

Parce que sous Windows, les pilotes ne seraient pa optimisés ? Je
t'aide, on compare une distribution 32 bits à un Windows 64. Pour
mémoire parce que tu as la comprenette bouchée à l'émeri,
l'architecture x86 est la _seule_ dont le passage de 32 bits vers 64
bits s'est accompagné d'un accroissement des performances (parce
qu'au passage l'ABI a changé et qu'il y a deux fois plus de
registres). Tes 3,8 % (en fait, 15, parce qu'il faudrait tout de
même voir à comparer les bibliothèques natives des OS, donc d'un
côté DX, de l'autre OpenGL parce qu'au passage, comparer OpenGL sur
un Unix de base avec OpenGLM sous Windows revient à dire que DX est
une bouse infecte) sont _significatifs_ et loin d'être négligeables
parce que ton PC, il en fait des choses durant ce laps de temps.
C'est sans compter avec le protocole X qui est notoirement mauvais
(parce qu'il n'a pas été créé pour faire des affichages en 3D, mais
du déport d'écran).

La conclusion, c'est surtout de voir quelle énergie/temps est perdue en
utilisant Windows qui n'a aucune de ces contingences matérielles à
respecter. En d'autres termes, rien que pour toi, Windows n'a pas à
respecter le protocole X, peut fait ce que bon lui semble avec DX,
peut se permettre s'il veut d'allouer toutes les ressources de la
machine à ton affichage, peut même se permettre d'accéder
directement au matériel sans contraintes et est plus lent que la
même chose sous Linux qui pourtant est handicapé par un nombre de
registres utilisés moitié moindre et du calcul sur 32 bits. Pour qui
sait les lire, ces chiffres sont une déculotté pour Windows.

Généralement, quand on oppose un nouveau prototype à un appareil de
série, on parle d'écarts significatifs, là un superbe 3.8 % d'écart, on
se demande quelle est la part de +performance et la part d'imprécision
de la mesure.

Justement, c'est significatif. Quant à la part d'imprécision,
prétendre que 3,8% d'écart est dans le trait du crayon, c'est une
mauvaise foi caractérisée.

JKB (qui se contrefiche du nombre de FPS)

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr