Ce que les bench­marks nous disent… ou pas

Si puis­sance ne rime pas tou­jours avec ef­fi­ca­ci­té, à quoi servent les tests que nous pu­blions ré­gu­liè­re­ment. Sommes-nous des pousse-au-crime encourageant l’achat de ma­té­riel oné­reux sans fon­de­ment ? C’est tout le pro­blème des lo­gi­ciels de test, et de la m

Micro Pratique - - DOSSIER -

Tors qu’ un ex te cou­rant construc­teur sort une nou­velle puce, il nous ap­par­tient d’en éva­luer les ap­ports en termes de gains de per­for­mance. Pour le faire, des ou­tils spé­ci­fiques sont uti­li­sés. Sou­vent les mêmes d’une gé­né­ra­tion à l’autre afin de conser­ver une base de com­pa­rai­son aus­si per­ti­nente que pos­sible. Mais ces ou­tils ont un dé­faut : ils sont bien faits. En ef­fet, ils per­mettent d’éva­luer dif­fé­rents scé­na­rios d’uti­li­sa­tion, uti­li­sant par exemple un coeur ou plu­sieurs, en li­mi­tant les fré­quences ou en les pous­sant à fond, en uti­li­sant ou non tel ou tel jeu d’ins­truc­tions, etc. Pour les CPU, l’un des ou­tils pré­fé­rés des tes­teurs est Ce der­nier si­mule un ren­du 3D, et est par­fai­te­ment « mul­ti-threa­dé », c’est-à-dire qu’il sait par­fai­te­ment utiliser tous les coeurs CPU dis­po­nibles. D’où un avan­tage très net aux ar­chi­tec­tures bour­rées de coeurs, comme les der­niers Th­rea­drip­pers d’AMD par exemple.

Ne pas sau­ter à la conclu­sion

Le piège se­rait de sau­ter di­rec­te­ment à la conclu­sion et d’en dé­duire que le pro­ces­seur X ayant ob­te­nu un score 30% su­pé­rieur à ce­lui du pro­ces­seur Y au même test se­ra plus performant ( pri­mo) et dans les mêmes pro­por tions (deu­zio). En ef­fet, les bench­marks ne livrent que des ré­sul­tats théo­riques. Une théo­rie qui, pour de­ve­nir réa­li­té, vou­drait que les lo­gi­ciels que vous uti­li­sez au quo­ti­dien soient pro­gram­més de la même ma­nière. Si vous faites de la vi­déo par exemple, tous les édi­teurs n’uti­li­se­ront pas votre ma­té­riel de la même fa­çon. Et au sein de chaque pro­gramme, dif­fé­rentes ac­tions ou mo­di­fi­ca­tions pour­ront faire ou non ap­pel au plein po­ten­tiel de votre ma­chine. Un exemple concret : dis­po­sant des der­nières ver­sions de Ligh­troom CC (via abon­ne­ment au Crea­tive Cloud), nous avons ré­cem­ment vou­lu conver­tir des an­nées de fi­chiers RAW de chez Ni­kon et Fu­ji­film en DNG Adobe, puisque le for­mat prend moins de place et conserve les mêmes in­for­ma­tions. Sélection des mil­liers de pho­tos, lancement du mo­dule de conver­sion et… sur­prise de­vant les temps de trai­te­ment an­non­cés, in­croya­ble­ment longs. En ana­ly­sant les sol­li­ci­ta­tions hard­ware du pro­ces­sus, on se rend compte qu’en 2018, cer tains mo­dules de pro­grammes au de­meu­rant bien mul­ti-threa­dés n’uti­lisent en­core qu’un seul coeur CPU et au­cun GPU. Et pour cou­ron­ner le tout, en pas­sant sur Mac, on se rend compte que le même mo­dule de conver­sion du même pro­gramme est là ca­pable d’utiliser tous les coeurs CPU et de sol­li­ci­ter le GPU. L’exemple est in­té­res­sant car il per­met de me­su­rer la dif­fi­cul­té à la­quelle on fait face lors­qu’on veut op­ti­mi­ser son tra­vail : chaque pro­gramme est co­dé dif­fé­rem­ment, et à l’in­té­rieur de ces pro­grammes dif­fé­rents mo­dules et dif­fé­rentes ac­tions sont aus­si co­dées de dif­fé­rentes ma­nières. Rap­pe­lons­nous des dé­buts du sup­port du GP-GPU dans l’édi­tion vi­déo : chez la plu­part des édi­teurs, le GPU ne ser­vait à l’ori­gine qu’à flui­di­fier la pré­vi­sua­li­sa­tion des ef­fets ap­pli­qués dans la ti­me­line… mais ne ser­vait pas à ac­cé­lé­rer les ren­dus d’ex­por­ta­tion. De ces exemples, on ti­re­ra plu­sieurs conclu­sions, la pre­mière étant que le ma­té­riel n’est ja­mais en cause. Ce n’est pas de la faute d’In­tel, AMD ou nVi­dia si les édi­teurs ne mo­di­fient pas ou pas as­sez bien le code de leurs ou­tils pour qu’ils puisent dans le po­ten­tiel of­fer t par le ma­té­riel. La se­conde le­çon est que l’op­ti­mi­sa­tion est une tâche ex­tra­or­di­nai­re­ment ar­due né­ces­si­tant une connais­sance très ap­pro­fon­die des ou­tils lo­gi­ciels que vous uti­li­sez. Connais­sance sou­vent ren­due opaque par la com­plexi­té de ces mêmes ou­tils. Ce sont de vrais cou­teaux suisses dis­po­sant de divers mo­dules per­met­tant d’ef­fec­tuer au­tant d’opé­ra­tions (par exemple pour la vi­déo : mon­ter, pla­cer des tran­si­tions, des ef­fets, ajus­ter la co­lo­ri­mé­trie, etc.). Troi­siè­me­ment en­fin, les bench­marks ne mentent pas et per­mettent d’af­fir­mer qu’une puce est plus puis­sante qu’une autre et dans quelles pro­por­tions. Ce que le bench­mark ne sait pas faire, c’est sor­tir du cadre pu­re­ment théo­rique et plon­ger dans le dé­tail de votre flux de tra­vail.

Les lo­gi­ciels de test per­mettent d’éta­blir une hié­rar­chie se­lon divers scé­na­rios pré­dé­fi­nis. Ils sont fiables et im­par­tiaux, mais ils ne per­mettent pas d’en ti­rer des conclu­sions plus dé­taillées.

Ob­te­nir un meilleur score sur un test avec un ma­té­riel X ne si­gni­fie pas qu’il se­ra plus ra­pide que le ma­té­riel Y moins bien no­té ; tout dé­pend des lo­gi­ciels que vous uti­li­sez au quo­ti­dien, et de la ma­nière dont ils sont op­ti­mi­sés ou non pour votre hard­ware.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.