Guide pour effectuer un test de performance informatique significatif pour la productivité

Les programmes de benchmarking tentent d’analyser la « performance » d’un ordinateur sur la base d’un banc d’essai bien défini (qui ne ressemble normalement pas à la configuration finale de l’ordinateur). L’évaluateur peut profiter des limites à confronter, telles que les ressources système, l’environnement logiciel virtuel, les applications, la simulation de charge de traitement, la simulation de charge utilisateur et la simulation d’utilisation du système, entre autres ; et faire tout ce qui est nécessaire pour dépasser ces limites et donner un résultat discutable. Or, « avoir une référence industrielle est toujours une bonne chose, si les benchmarks ne sont pas truqués. Malheureusement, de nombreux benchmarks industriels sont truqués. […] Pourtant, de nombreuses organisations semblent acheter du matériel sur la base de benchmarks plutôt que de comprendre leurs charges de travail et d’acheter du matériel en fonction de leurs besoins et, bien sûr, de leur budget. » (Newman, 2015) Cela explique pourquoi le client doit savoir exactement ce qui est censé être mesuré. Un programme de benchmark ne pourra jamais refléter ce qu’on appelle l’expérience du monde réel ; il reflétera simplement la façon dont ce programme fonctionne sur l’ordinateur visé. Il incombe donc au client de déterminer comment le résultat sera appliqué dans son environnement productif.

Étonnamment, effectuer correctement des benchmarks est quelque chose de très difficile, car il existe de nombreuses possibilités d’obtenir des résultats erronés ou trompeurs et d’omettre des éléments. Le livre blanc « A Nine Year Study of File System and Storage Benchmarking » résume ceci :

Dans cet article, nous passons en revue 415 benchmarks de systèmes de fichiers et de stockage provenant de 106 articles récents. Nous avons constaté que la plupart des benchmarks populaires sont défectueux et que de nombreux articles de recherche ne fournissent pas une indication claire de la performance réelle. (Traeger, Zadok, Joukov, & Wright, 2008)

Dans ce livre blanc, on peut voir des déclarations selon lesquelles les benchmarks devraient expliquer ce qui est sur le point d’être testé et pourquoi, et qu’ils devraient également effectuer (ou faciliter) une sorte d’analyse de la performance système attendue.

Dans l’article « Performance Anti-Patterns », certains points sont mis en évidence pour déterminer, dans ce cas, pourquoi et comment les benchmarks doivent être exécutés. Par conséquent, un bon benchmark devrait être :

• Reproductible, afin que des expériences de comparaison puissent être menées relativement facilement et avec un degré de précision raisonnable.
• Observable, de sorte que si une faible performance est constatée, le développeur a un point de départ pour ses recherches. Rien n’est plus frustrant qu’un benchmark complexe qui fournit un chiffre unique, laissant le développeur sans information supplémentaire sur l’endroit où le problème pourrait se situer.
• Portable, afin que des comparaisons soient possibles avec vos principaux concurrents (même s’il s’agit de vos propres versions précédentes). Maintenir un historique de la performance des versions précédentes est une aide précieuse pour comprendre votre propre processus de développement.
• Facilement présentable, afin que tout le monde puisse comprendre les comparaisons dans une brève présentation.
• Réaliste, afin que les mesures reflètent les réalités vécues par le client.
• Exécutable, afin que tous les développeurs puissent rapidement constater les effets de leurs changements. S’il faut des jours pour obtenir des résultats de performance, cela n’arrivera pas très souvent.

Tous les benchmarks sélectionnés ne répondront pas à tous ces critères, mais il est important que certains d’entre eux le fassent. Smaalders invite à choisir des benchmarks qui représentent vraiment les besoins du client, sinon tous les efforts finiront par optimiser pour le mauvais comportement. Il encourage également à résister à la tentation d’optimiser pour le benchmark dans le but de gagner le concours à tout prix. Un tel comportement offrira de faux résultats qui pourraient entraîner un manque de confiance envers la marque ou le fournisseur. Généralement, un benchmark mettra en évidence l’aspect optimisé, au détriment d’autres aspects qui ne sont pas mesurés (et qui pourraient être importants pour le client). (Smaalders, 2006)

Il y a une autre chose à prendre en compte lors de la comparaison de divers systèmes dans l’intention de les acheter : le rapport prix/performance. Ce taux peut être quantifié en incluant le coût en capital de l’équipement sur 5 ans. (Anon & Gray, 1985)

Des tests simples avec un logiciel de benchmark ne constituent pas une analyse complète de la performance. Les programmes de benchmark fonctionnent normalement dans un environnement contrôlé, ils peuvent donc être manipulés pour obtenir un taux souhaité — le plus élevé possible. Néanmoins, un tel taux ne nous donnera JAMAIS une corrélation appropriée avec l’expérience réelle du client. Au contraire, les mesures fournies vous donnent seulement un score représentatif de la façon dont le programme fonctionne sur un benchmark particulier. Un gros problème est que l’utilisateur ne sait jamais vraiment ce qui est testé, comment les aspects d’un score de benchmark sont mesurés, quels indicateurs ont été définis dans le compilateur, quel code ou quelles bibliothèques sous-tendent le programme, et, plus important encore, si ce que le programme teste reflétera l’utilisation réelle prévue pour l’ordinateur. Il y a donc quelques points à souligner :

• Un benchmark ne reflétera jamais l’utilisation dans le monde réel. Étant un programme entièrement automatisé, il ouvrira, écrira, définira, lira, enregistrera, affichera, regardera, naviguera, déplacera, calculera, assignera et effectuera de nombreuses autres tâches de manière entièrement automatisée. Une telle manière ne reflétera jamais le rythme auquel un humain effectuera son travail. Par conséquent, tout programme de benchmark qui promet des résultats basés sur une utilisation dans le monde réel ment.
• Tous les benchmarks n’évaluent pas la performance multitâche. La grande majorité des benchmarks évaluent uniquement des tâches exécutées en série. Ils testent une chose, puis la suivante. Ils ne demanderont jamais à une application de faire quelque chose pendant qu’une autre application fait autre chose (et, si c’est le cas, ils essaient normalement deux ou, tout au plus, trois instances). Dans la vie réelle, les utilisateurs exécutent plusieurs applications simultanément. La plupart des utilisateurs ouvrent de nombreuses applications à la fois (le système d’exploitation exécute également de nombreuses tâches pendant que nous effectuons nos tâches quotidiennes). Il est important de mentionner qu’un benchmark qui ne reflète qu’un seul processus/application ne s’adapte pas linéairement avec le deuxième, le troisième, et le reste des processus/applications. Par conséquent, dans la technologie multicœur moderne, il est important de prendre les résultats d’un programme de benchmark avec des pincettes.
• « Taux » n’est pas synonyme de « performance ». Le taux est juste un chiffre donné par le programme. La performance est quelque chose de plus compliqué. Le chiffre du taux dépend du programme de benchmark et de l’échelle définie par ses développeurs. La performance est l’accomplissement d’une tâche donnée mesurée par rapport à des normes prédéfinies de précision, d’exhaustivité, de coût et de vitesse (The Business Dictionary, 2017). Par conséquent, aucun taux de programme de benchmark ne reflète un indice de performance.
• Les benchmarks sont imprécis. La variation du taux d’un programme de benchmark peut atteindre 10 % (parfois plus). Ces taux de benchmark sont toujours subjectifs, ce qui est contraire aux principes objectifs de la science et de la technologie. C’est pourquoi un programme de benchmark doit être exécuté au moins 3 fois pour calculer une moyenne du taux donné. Après avoir déterminé la moyenne, une variation d’au moins +/- 3 % du résultat est attendue (une telle variation peut être calculée en fonction des résultats recueillis).
• Les résultats de benchmark peuvent être manipulés. Il existe des moyens de manipuler les résultats d’un programme de benchmark et d’offrir des taux artificiellement élevés juste pour impressionner l’utilisateur. Cela peut être fait par de nombreuses techniques, comme des réglages excessifs, des paramètres dans le BIOS, l’altération du matériel, l’utilisation de pilotes spéciaux, la manipulation du code, et d’autres. Les taux de benchmark peuvent être obtenus avec des paramètres irréalistes par rapport à la façon dont l’ordinateur sera utilisé en pratique : le système doit être exempt de programmes et de processus et avoir des valeurs spécifiques qui dépendent du benchmark particulier, et cela ne reflète pas la façon dont l’ordinateur sera utilisé en productivité. Comme l’a déclaré Henry Newman : « Ce qu’un benchmark nous dit, c’est : 1) Combien de matériel un vendeur peut entasser dans une boîte, 2) À quel point l’équipe du vendeur peut optimiser le logiciel [pour le benchmark], et 3) À quel point le vendeur veut conclure l’affaire. » (Olds & OrionX, 2011) S’il n’y a pas de protocole de benchmark clairement énoncé par le client, la porte sera ouverte à toutes les astuces que l’évaluateur peut utiliser pour atteindre (ou dépasser) les résultats souhaités et impressionner le client.

En fin de compte, un programme de benchmark n’est pas un outil précis et doit être utilisé avec précaution. Comme Henry Newman l’a cité dans une communication personnelle : « Comparer des outils de performance système […] avec […] des benchmarks, c’est comme comparer des pommes avec des cochons volants. » (Carrier, 2012)

Les scores fournis par un benchmark doivent être utilisés conjointement avec d’autres benchmarks et des détails supplémentaires pour obtenir une compréhension complète de la performance globale du système. Le benchmark, dans le meilleur des cas, ne fait que « mesurer la vitesse » d’un ordinateur, mais il y a beaucoup d’autres aspects à prendre en compte : normes commerciales, normes militaires, fonctionnalité, caractéristiques, certifications, prix, entre autres.

Si l’ordinateur en cours d’évaluation pour l’achat doit répondre à une variété d’exigences d’utilisateurs différentes, il est préférable de prédéterminer les cas d’utilisation prévus afin qu’un ensemble détaillé de critères de qualification appropriés soit établi. Dans la plupart des cas, l’ordinateur sera probablement utilisé dans un ou plusieurs des contextes suivants :

• Sera utilisé avec des environnements d’exploitation graphiques actuels (Windows 10, ou distributions GNU/Linux au minimum)
  • Ou s’il sera utilisé avec des versions précédentes de systèmes d’exploitation, comme Windows 7 ou Windows 8.1, ou une distribution GNU/Linux précédente.
• Productivité de base (Pas plus de 5 applications en cours d’exécution, incluant) :
  • Antivirus
  • Traitement de texte
  • E-mail
  • Utilisation légère de tableurs
  • Applications basées sur le Web
  • Navigation Web avec pas plus de 6 onglets ouverts.
• Productivité standard (5 à 10 applications en cours d’exécution, incluant) :
  • Identique à la productivité de base, et aussi…
  • Applications bureautiques (Traitement de texte avec manipulation d’images, tableurs avec formules et quelques scripts, Présentations, gestion de base de données de base)
  • Navigation Web avec jusqu’à 15 onglets
  • Web conférence
  • Visionnage et édition simple d’images et de vidéos
  • Éducation
  • On peut supposer une utilisation abondante de vidéos, images, animations, accès Web et applications qui utilisent actuellement l’informatique accélérée.
• Utilisateur avancé (Plus de 10 applications en cours d’exécution, incluant) :
  • Identique à la productivité standard, et aussi…
  • Développement d’applications
    • Utilisation de langages et d’environnements de programmation
    • Création, gestion et test de bases de données
    • Banc d’essai avec virtualisation
    • Environnements de test contrôlés
  • Programmes pour la recherche scientifique
    • Applications spécialisées
    • Applications d’ingénierie et scientifiques
    • Réalité virtuelle
• Juste pour information générale, les jeux sont actuellement considérés comme du calcul haute performance (Stevenson, Le Du, & El Afrit, 2011)
• Autres critères
  • Une faible consommation d’énergie est-elle requise ?
  • L’espace occupé par l’ordinateur est-il important ou limité ?
  • La mobilité est-elle requise ?
  • L’autonomie de la batterie est-elle importante ?
  • Le poids est-il important ?
  • Certains autres usages qui impliquent une utilisation portable dans des environnements difficiles, poussiéreux ou bruyants

Le terme dans le titre de cette section peut sembler étrange, mais il s’agit en fait d’une question généralement ignorée ou négligée. Elle fait référence à la question suivante : quel temps de réponse compte vraiment pour l’utilisateur ? La vitesse et la performance sont en réalité des termes relatifs. Ilya Grigorik propose un concept intéressant de ce que signifie le mot « performance ».

« La performance ne se résume pas à des millisecondes, des images et des mégaoctets. C’est aussi la façon dont ces millisecondes, images et mégaoctets se traduisent dans la façon dont l’utilisateur perçoit l’application. » (Grigorik, 2014)

Chaque application prescrit son propre ensemble d’exigences en fonction de critères commerciaux, du contexte, des attentes des utilisateurs et des constantes de temps de traitement perceptuel entièrement orientées vers l’utilisateur. Encore une fois, les attentes des utilisateurs ont une relation avec la première loi de Maister : « La satisfaction est égale à la perception moins l’attente. » (Maister, 1985) Peu importe à quelle vitesse la vie s’accélère, ou du moins est perçue comme s’accélérant (1 image toutes les 66 ms), nos temps de réaction restent constants. Si nous considérons qu’un utilisateur peut voir environ 15 images par seconde selon les études traditionnelles (Thorpe, Fize, & Marlot, 1996), le tableau suivant (basé sur la norme militaire 1472G) donne une idée claire du temps de réponse qu’un utilisateur attend normalement. Cela, quel que soit le type d’application (installée sur l’ordinateur ou en ligne) ou de support (ordinateur portable, de bureau ou appareil mobile).

Temps réel et perception de l’utilisateur (Seow, 2008)

• 0 – 100 ms : Instantané
• 100 – 500 ms : Immédiat
• 500 – 1000 ms : Rapide
• 1 – 10 s : Un retard est perçu, mais l’utilisateur ne perd pas sa concentration.
• +10 s : L’ordinateur est trop lent pour maintenir l’attention de l’utilisateur.

Pour que la réponse à une demande de l’utilisateur soit perçue comme rapide, elle doit arriver en moins d’une seconde. Si cela prend une seconde ou plus, l’utilisateur peut percevoir un certain retard, mais son attention ne sera pas détournée de la tâche. Après 10 secondes — à moins que le programme ne fournisse un type d’information à l’utilisateur — la tâche sera normalement abandonnée et l’utilisateur ressentira de l’agacement. Si l’ordinateur en cours d’évaluation peut fournir des réponses en un temps comparable ou en moins de 10 secondes, l’utilisateur tirera davantage profit de l’ordinateur. Ces seuils sont beaucoup plus utiles dans le monde réel que les résultats des programmes de benchmark, qui n’offrent pas d’orientation claire quant à leur signification.

Cela dit, dans un benchmark efficace, le client devrait savoir : comment il sera appliqué, l’analyse et les conclusions qui en seront tirées. Pour l’analyse, il est important de comprendre ou d’apporter :

• Un seuil ou une référence du résultat minimum attendu
• Ce qui est sur le point d’être testé
• Quels sont les facteurs limitants
• Toute perturbation pouvant affecter les résultats
• Les détails du système testé
• Le prix (au moins la moyenne) du système testé
• Quelles conclusions on cherche à atteindre avec les résultats

Le seuil peut être obtenu à partir de sites publics (comme Futuremark) ou créé localement à partir d’un ordinateur actuellement utilisé et avec une bonne configuration afin d’établir la référence pour chaque benchmark à partir des ordinateurs sur le point d’être proposés. Notez les détails de la configuration de cet ordinateur utilisé comme référence (processeur, mémoire [quantité, vitesse, configuration, timings], stockage, graphiques et écran) pour en avoir une idée claire.

L’analyse des benchmarks nécessite du temps et de l’expérience pour être effectuée correctement. Comme dit précédemment, la partie la plus importante consiste à déterminer ce qui est sur le point d’être mesuré et si les résultats obtenus sont significatifs pour l’utilisation prévue des ordinateurs.

Ce qui suit est une proposition de protocole de benchmarking afin d’assurer — autant que possible — des résultats justes et réalistes des benchmarks sélectionnés ou appliqués.

Il est recommandé, pour les processus de configuration et de benchmarking, de ne pas laisser l’évaluateur seul, surtout s’il s’agit d’un tiers. Le client doit désigner un témoin pour noter tout ce que l’évaluateur fait avec la machine pour la configurer en vue du processus de benchmark. De plus, le témoin doit également noter tout changement ou modification effectué par l’évaluateur après chaque type de test de benchmark. Si vous, en tant que client, avez un protocole bien défini, l’évaluateur ne doit pas le violer juste pour gagner le processus de benchmarking. L’évaluateur et le témoin ne devraient pas être la même personne, encore une fois, surtout si l’évaluateur est un tiers.

Peu importe la marque ou le matériel proposé, tous les ordinateurs doivent répondre aux critères de configuration :

• Si vous avez demandé des processeurs quad-core physiques, tous doivent avoir quatre cœurs physiques.
• Si vous avez demandé une certaine quantité, vitesse et configuration de mémoire vive, vérifiez que tous les ordinateurs ont la même configuration. Notez toutes les différences :
  • Taille
  • Vitesse (MT/s)
  • Timings et latences (CAS, RAS, tRAS, tRC, Fréquence).
  • Canal simple vs Double canal
• Si vous avez demandé un certain type de stockage, vérifiez que tous les ordinateurs incluent ce type de stockage. Notez toutes les différences trouvées (débit, temps d’accès et temps d’écriture) :
  • Disque dur rotatif standard (5400 tr/min, 7200 tr/min, 10000 tr/min, SSHD)
  • SSD
• La carte graphique doit répondre au Shader Model 6.1 (DirectX 12.1) pour Windows 10 ou au Shader Model 5 (DirectX 11) pour les versions précédentes de Windows.
• L’écran doit présenter les mêmes caractéristiques sur chaque ordinateur
  • Temps de rafraîchissement
  • Temps de réponse (ms)
  • Résolution (des résolutions plus élevées pourraient donner des chiffres de benchmark plus bas)
  • Profondeur de couleur
• Le système d’exploitation doit être la même version et compilation.
  • Dans Windows, vous pouvez voir la version et la compilation en tapant winver et Entrée dans la zone Cortana ou après avoir appuyé sur Windows+R pour ouvrir la fenêtre Exécuter.
• Chaque ordinateur doit avoir installé uniquement les pilotes actuels approuvés par le fabricant de l’ordinateur. Note : Ne permettez pas l’utilisation de pilotes spéciaux ou de pilotes modifiés apportés par un fabricant de composants, car ils pourraient donner de faux résultats. Évitez l’utilisation de pilotes autres que ceux validés et publiquement disponibles sur le site Web ou l’outil de configuration du fabricant de l’ordinateur.
• Configurez l’ordinateur en mode Équilibré. C’est la façon dont les ordinateurs sont destinés à être utilisés par le client, et c’est le moyen le plus fidèle d’obtenir des résultats des benchmarks.
• Installez les applications couramment utilisées par le client. Peu importe qu’elles ne soient pas utilisées dans le test, c’est ainsi que les ordinateurs seront utilisés.
• Installez tout autre logiciel (comme les antivirus et outils) requis par le client. Cela configurera l’appareil aussi près que possible de l’utilisation par l’utilisateur final.
• Installez les programmes de benchmark.

Une fois les ordinateurs installés, il est recommandé d’effectuer un benchmarking à chaud. Un benchmarking à chaud nécessite un ingénieur (un ingénieur, pas un technicien) prenant note de tout ce qui se passe pendant le processus de benchmark (parties sautées du test, étapes manquantes, mauvais comportements de l’écran, figures ou images mal dessinées, et ainsi de suite). Ces anomalies doivent être notées et signalées. Il est conseillé d’éviter le benchmarking à froid (juste lancer le benchmark, s’éloigner de l’ordinateur et, ensuite, revenir juste pour noter le résultat) car aucune preuve de comportement étrange pendant le benchmark ne sera notée. Comme indiqué, il existe des moyens de manipuler les taux de benchmark et effectuer un benchmark à froid est le meilleur moyen de manquer ce genre de pratiques.

Comme les taux de benchmark pourraient donner lieu à des variations de 5 à 15 %, il est recommandé d’exécuter chaque test au moins 3 fois. Chaque fois nécessitera un redémarrage de l’ordinateur, d’attendre environ 5 minutes après l’apparition du bureau, puis d’exécuter à nouveau le benchmark. Après chaque exécution de benchmark, il est recommandé d’effectuer une capture d’écran du résultat pour conserver la preuve. Cela doit être fait pour chaque programme de benchmark sélectionné.

Il appartient au client de décider si les différents taux obtenus lors de chaque exécution de chaque benchmark seront moyennés, ou si l’on prendra la valeur la plus élevée ou la plus basse. Quelle que soit la décision du client, il est recommandé de l’appliquer à tous les différents benchmarks utilisés. En guise de suggestion, optez pour la moyenne.

Après avoir obtenu ces résultats, ceux-ci peuvent être normalisés (comme dans le corps de ce document) puis convertis linéairement en temps. Avec le prix des ordinateurs, le client peut également évaluer quel système offre le meilleur rapport prix/performance.

Un processus de benchmarking nécessite du temps, de l’expérience et de la patience. S’ils sont bien faits, les programmes de benchmark peuvent donner une bonne idée de la performance attendue de l’ordinateur. Tout ce qui est noté par le témoin sera utile pour déterminer ce que le candidat devra fournir en cas de sélection. La configuration (processeur, mémoire vive [quantité, vitesse, timings, mode canal], stockage [type, débit, capacité], écran, facteur de forme, etc.) notée pendant le processus de benchmarking sera utile pour s’assurer que l’ordinateur livré soit configuré exactement comme testé. C’est important car certains fournisseurs abusifs peuvent livrer un ordinateur spécialement configuré juste pour le processus de test, et un ordinateur très différent à la fin. Par conséquent, cela aidera le client à obtenir exactement ce qui a été testé.

De toute la discussion précédente, ce qui suit peut être conclu :

• Les achats que fait le client concernent des ordinateurs, pas juste un processeur ou un certain composant. Il est donc nécessaire de prendre en compte le système global (holistique) lors de la prise de décision d’achat.
• La performance d’un ordinateur découle de tous ses éléments. Cela inclut le matériel et le logiciel. La performance globale de l’ordinateur sera toujours égale à la performance de son élément le plus lent.
• Il est nécessaire de prendre en compte les mesures d’économie d’énergie, la génération de chaleur, la stabilité de l’ordinateur, ses certifications pour un usage professionnel et les services de sécurité qu’il offre. Plus que de la vitesse basée sur des benchmarks, la technologie actuelle exige une réduction de la consommation d’énergie et la fourniture de services de sécurité.
• Il est important d’être conscient que les nouvelles technologies intégrées aux applications et aux systèmes d’exploitation exploitent bien plus que le simple processeur. Elles se concentrent plutôt sur d’autres composants tels que le CPU, le GPGPU, les bus, la vitesse de la mémoire vive et le taux de transfert du disque.

Une mesure réelle de la puissance de calcul est obtenue lorsque l’ordinateur est mesuré de manière holistique, pas seulement dans le domaine du traitement en série ou du CPU. Le client qui utilise des outils bureautiques, des navigateurs Web, la compression de fichiers, des lecteurs vidéo, des outils de téléconférence, des applications basées sur le Web et des choses similaires tirera profit de toutes les fonctionnalités de ces nouvelles technologies avec une architecture hétérogène.

Une note finale à ce sujet est qu’un seuil ou une référence est toujours nécessaire afin d’avoir une meilleure idée des améliorations de performance sur le point d’être reçues. Si vous ne voulez pas utiliser la mesure de base offerte par FutureMark pour un « PC de bureau de référence » au jour d’aujourd’hui, vous pouvez mesurer votre ordinateur de base dans votre bureau selon vos propres critères (peut-être un ordinateur avec lequel vous êtes à l’aise avec sa performance standard). Une fois que vous exécutez le benchmark pour obtenir ses résultats, vous pouvez alors utiliser ces résultats comme seuil afin d’avoir un taux minimum attendu des solutions proposées. Juste une autre chose à noter est que les « taux » ne sont pas synonymes de « performance ». Un « taux » donne juste une qualification des processus exécutés par le programme de benchmark. La « performance » est le résultat réel que vous obtiendrez à mesure que vous utilisez cet ordinateur pour vos propres tâches.

Anon, E. A., & Gray, J. (février 1985). A Measure of Transaction Processing Power. Consulté le 22 mars 2015, depuis Internet Archive : https://archive.org/details/bitsavers_ta...

Carrier, J. (24 avril 2012). HPCS I/O Scenarios. Consulté depuis OpenSFS : http://cdn.opensfs.org/wp-content/upload...

Computerhope. (15 mars 2015). Thrashing. Consulté depuis Computer hope : http://www.computerhope.com/jargon/t/thr...

Gregg, B. (2014). Systems Performance Enterprise and the Cloud (1re éd.). USA : Pearson Education.

Grigorik, I. (12 mars 2014). Speed, Performance, and Human Perception. (Fluent, Éd.) San Francisco, CA, USA. Consulté le 22 mars 2015, depuis https://www.youtube.com/watch?v=7ubJzEi3...

Hoff. (30 décembre 2006). Multicore, SMP and SMT Processors. Consulté le 22 mars 2015, depuis HoffmanLabs : http://labs.hoffmanlabs.com/node/13

Maister, D. (1985). The Psychology of Waiting Lines. (T. S. Encounter, Éd.) Consulté le 22 mars 2015, depuis David Maister: Professional Business, Professional Life : http://davidmaister.com/wp-content/theme...

Mallik, A. (2007). Hollistic Computer Architectures based on Application, User, and Process Characteristics. Evanston, Illinois, USA : UMI.

Newman, H. (2015). Data Storage Issues: Big Data Benchmarking. Consulté depuis InfoStor : http://www.infostor.com/index/blogs_new/...

Olds, D., & OrionX. (19 décembre 2011). Benchmarks are $%#&@!! Consulté depuis The Register : http://www.theregister.co.uk/2011/12/19/...

Osterhage, W. (2013). Computer Performance Optimization (1re éd.). (Springer-Verlag, Trans.) Niederbachem, Allemagne : Springer-Verlag Berlin Heidelberg.

Seow, S. (2008). Designing and Engineering Time. Boston, USA : Prentice Hall.

Smaalders, B. (23 février 2006). Performance Anti-Patterns. doi:1542-7790/06/0200

Stevenson, A., Le Du, Y., & El Afrit, M. (mars 2011). High Performance Computing on Gamer PCs. Consulté depuis ArsTechnica : http://arstechnica.com/science/2011/03/h...

The Business Dictionary. (2017). Performance. Consulté depuis The Business Dictionary : http://www.businessdictionary.com/defini...

Thorpe, S., Fize, D., & Marlot, C. (6 juin 1996). Speed of processing in the human visual system. Nature, 381, 520-522. Consulté depuis Quora : http://cns.bu.edu/Profiles/Mingolla.html...

Traeger, A., Zadok, E., Joukov, N., & Wright, C. (mai 2008). A Nine Year Study of File System and Storage Benchmarking. Consulté le 22 mars 2015, depuis File systems and Storage Lab (FSL) : http://www.fsl.cs.sunysb.edu/docs/fsbenc...

Vieira, L. (3 octobre 2011). The Perception of Performance. Consulté le 22 mars 2015, depuis Sitepoint : http://www.sitepoint.com/the-perception-...