This file is indexed.

/usr/share/doc/HOWTO/fr-html/Benchmarking-HOWTO.html is in doc-linux-fr-html 2013.01-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.71">
<title>Benchmarking HOWTO Linux</title>
</head>
<body>
<h1>Benchmarking HOWTO Linux</h1>
<h2>par Andr&eacute; D. Balsa, <a href=
"mailto:andrewbalsa@usa.net">andrewbalsa@usa.net</a><br>
traduit par Fran&ccedil;ois Laagel, <a href=
"mailto:f.laagel@ieee.org">f.laagel@ieee.org</a></h2>
v0.12, 15 Ao&ucirc;t 1997 (v.f. : 2 du 28 Novembre 1997)
<hr>
<em>Le benchmarking HOWTO Linux traite de certains probl&egrave;mes
relatifs &agrave; l'&eacute;valuation de performances de
syst&egrave;mes Linux et pr&eacute;sente un ensemble d'outils ainsi
qu'un formulaire associ&eacute; qui permettent de produire des
mesures de performances significatives en quelques heures.
Peut-&ecirc;tre ce document contribuera-t-il &agrave; une
diminution du nombre d'articles inutiles dans
comp.os.linux.hardware...</em>
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<p><em>"Ce dont on ne peut parler doit &ecirc;tre pass&eacute; sous
silence."</em></p>
<blockquote><em>Ludwig Wittgenstein (1889-1951), philosophe
Autrichien</em></blockquote>
<p>L'&eacute;valuation de performances (benchmarking) consiste
&agrave; <b>mesurer</b> la vitesse &agrave; laquelle un ordinateur
ex&eacute;cute une t&acirc;che calculatoire, et ce de fa&ccedil;on
&agrave; pouvoir comparer diff&eacute;rentes configurations
logicielles/mat&eacute;rielles. Ceci n'a <b>aucun</b> rapport avec
la facilit&eacute; d'utilisation, l'esth&eacute;tique, les
consid&eacute;rations d'ergonomie ou toute autre
appr&eacute;ciation subjective.</p>
<p>L'&eacute;valuation de performances est une t&acirc;che
fastidieuse et r&eacute;p&eacute;titive. Elle
n&eacute;c&eacute;ssite que l'on pr&ecirc;te une grande attention
aux d&eacute;tails. Tr&egrave;s souvent les r&eacute;sultats
obtenus ne sont pas ceux auxquels on s'attendait et sont sujet
&agrave; interpr&eacute;tation (ce qui peut tr&egrave;s bien
&ecirc;tre le but d'une proc&eacute;dure d'&eacute;valuation de
performances).</p>
<p>Enfin, l'&eacute;valuation de performances tra&icirc;te de faits
et de chiffres et non pas d'opinion ou d'approximation.</p>
<h2><a name="ss1.1">1.1 Pourquoi l'&eacute;valuation de
performances est-elle si importante ?</a></h2>
<p>Hormis les raisons mentionn&eacute;es dans le BogoMips
Mini-HOWTO (section 7, paragraphe 2), il arrive, lorsque l'on se
constitue une machine Linux, que l'on soit confront&eacute;
&agrave; un budget limit&eacute; et/ou &agrave; des besoins en
performances minimales garanties.</p>
<p>En d'autres termes, lorsque l'on se pose les questions suivantes
:</p>
<ul>
<li>Comment maximiser la performance avec un budget donn&eacute;
?</li>
<li>Comment minimiser le co&ucirc;t n&eacute;c&eacute;ssaire pour
obtenir un niveau de performance donn&eacute; ?</li>
<li>Comment obtenir le meilleur rapport performance/co&ucirc;t
(&eacute;tant donn&eacute; un budget ou des besoins en performances
minimales garanties) ?</li>
</ul>
<p>il faudra examiner, comparer et/ou produire des benchmarks (ndt
: un benchmark est un programme ou un ensemble de programmes - on
parle alors de suite - servant &agrave; &eacute;valuer les
performances d'un syst&egrave;me informatique).</p>
<p>Minimiser les co&ucirc;ts sans contraintes de performance
implique d'ordinaire la constitution d'une machine &agrave; partir
de composants de r&eacute;cup&eacute;ration (ce vieux 386SX-16 qui
tra&icirc;ne dans le garage sera parfait), et ne
n&eacute;c&eacute;ssite pas de benchmarks. Maximiser la performance
sans co&ucirc;t plafond n'est pas une situation r&eacute;aliste
(&agrave; moins que l'on souhaite mettre un Cray dans son salon -
la banquette recouverte de cuir qui se trouve au dessus des
alimentations &eacute;lectriques est du meilleur go&ucirc;t,
n'est-t-il pas ?).</p>
<p>L'&eacute;valuation de performances sans contrainte de
co&ucirc;t ni de performance minimale garantie n'a pas de sens:
c'est une perte de temps et d'argent. L'&eacute;valuation de
performances n'a de sens que dans le cadre d'une prise de
d&eacute;cision, c'est &agrave; dire si l'on a le choix entre deux
alternatives ou plus.</p>
<p>D'ordinaire des crit&egrave;res autres que le <b>co&ucirc;t</b>
interviennent dans le processus d&eacute;cisionnel. Il peut s'agir
de la disponibilit&eacute;, du service, de la fiabilit&eacute;, de
consid&eacute;rations strat&eacute;giques ou de toute autre
caract&eacute;ristique rationnelle et mesurable d'un syst&egrave;me
informatique. Par exemple, lorsque l'on compare la performance de
diff&eacute;rentes versions du noyau Linux, la
<b>stabilit&eacute;</b> est toujours plus importante que la vitesse
d'ex&eacute;cution.</p>
<h2><a name="ss1.2">1.2 Non-crit&egrave;res en mati&egrave;re
d'&eacute;valuation de performances</a></h2>
<p>Malheureusement et tr&egrave;s souvent dans les newsgroups
(forums) et les mailing lists (listes de diffusion par courrier
&eacute;lectronique), sont cit&eacute;s :</p>
<ol>
<li>La r&eacute;putation du fabriquant (non-mesurable et sans
signification).</li>
<li>Les parts de march&eacute; du fabriquant (sans signification et
non-pertinent).</li>
<li>Des param&egrave;tres irrationnels (superstition ou a-priori
par exemple acheteriez-vous un processeur &eacute;tiquet&eacute;
131313ZAP et peint en rose ?).</li>
<li>La valeur per&ccedil;ue (non-significative, non-mesurable et
irrationnelle).</li>
<li>L'ampleur du tapage marketing (ndt : mercatique pour les
int&eacute;gristes :) est ce qu'il y a de pire, je crois.
Personnellement, j'en ai marre des logos "XXX inside" ou "kkkkkws
compatible" (maintenant "aaaaaPowered" est de la partie, et puis
quoi encore ?). AMHA, les milliards de dollards
d&eacute;pens&eacute;s durant de telles campagnes seraient bien
mieux utilis&eacute;s par de &eacute;quipes de recherche pour la
conception de nouveaux processeurs, plus rapides (moins chers :-)
et moins bugg&eacute;s. Aucune campagne publicitaire, si ambitieuse
soit-elle, n'est en mesure de supprimer une bug de la FPU en calcul
flottant sur le tout nouveau processeur que vous venez tout juste
d'enficher sur votre carte-m&egrave;re, alors qu'un &eacute;change
au profit d'un processeur re-con&ccedil;u le fera.</li>
<li>Les opinions du type "Vous avez ce pour quoi vous avez
pay&eacute;" ne sont pr&eacute;cis&eacute;ment que &ccedil;a : des
opinions. Donnez-moi des faits, s'il vous plait.</li>
</ol>
<h2><a name="s2">2. Proc&eacute;dures d'&eacute;valuation de
performances et interpr&eacute;tation des r&eacute;sultats</a></h2>
<p>Quelques recommendations semi-&eacute;videntes :</p>
<ol>
<li>Premi&egrave;rement et avant tout, <b>identifiez vos objectifs
d'&eacute;valuation de performances</b>. Qu'essayez vous exactement
d'&eacute;valuer ? En quoi un processus d'&eacute;valuation de
performances va-t-il vous aider &agrave; prendre une
d&eacute;cision ult&eacute;rieure ? Combien de temps et quelles
ressources voulez-vous consacrer &agrave; cet effort ?</li>
<li><b>Utilisez des outils standard</b>. Utilisez une version
&agrave; jour et stable du noyau, des versions standard et &agrave;
jour de gcc et de la libc, et un benchmark standard. En bref,
utilisez le LBT (voir plus loin).</li>
<li>Donnez une <b>description compl&egrave;te</b> de votre
configuration mat&eacute;rielle (voir le formulaire de compte-rendu
plus loin).</li>
<li>Essayez d'<b>isoler une variable unique</b>.
L'&eacute;valuation de performances comparative est plus
informative que l'&eacute;valuation de performances "absolue".
<b>Je n'insisterai jamais assez l&agrave;-dessus</b>.</li>
<li><b>V&eacute;rifiez vos r&eacute;sultats</b>. Faites tourner vos
benchmarks plusieurs fois et v&eacute;rifiez les variations des
r&eacute;sultats obtenus, si variation il y a. Des variations
inexpliqu&eacute;es invalideront vos r&eacute;sultats.</li>
<li>Si vous pensez que votre effort d'&eacute;valuation de
performances a produit de l'information significative,
<b>partagez-la</b> avec la communaut&eacute; Linux de fa&ccedil;on
<b>pr&eacute;cise</b> et <b>concise</b>.</li>
<li><b>Oubliez les BogoMips</b> s'il vous plait. Je me promets
d'impl&eacute;menter un jour un ASIC (ndt : un acronyme pour
Application Specific Integrated Circuit, c'est un circuit
int&eacute;gr&eacute; d&eacute;di&eacute; &agrave; une application
donn&eacute;e) dans lequel les BogoMips seront cabl&eacute;s. Et
alors on verra ce qu'on verra !</li>
</ol>
<h2><a name="ss2.1">2.1 Comprendre les choix en mati&egrave;re de
benchmarks</a></h2>
<h3>Benchmarks synth&eacute;tiques vs. benchmarks applicatifs</h3>
<p>Avant de consacrer le moindre temps aux travaux
d'&eacute;valuation de performances, il importe de faire un choix
de base entre benchmarks synth&eacute;tiques et benchmarks
applicatifs.</p>
<p>Les benchmarks synth&eacute;tiques sont sp&eacute;cifiquement
con&ccedil;us pour mesurer la performance des composants
individuels d'un ordinateur, d'habitude en poussant l'un desdits
composants jusqu'&agrave; sa limite. Un exemple de benchmark
synth&eacute;tique c&eacute;lebre est la suite <b>Whetstone</b>,
initialement programm&eacute;e en 1972 par Harold Curnow en FORTRAN
(ou &eacute;tait-ce en ALGOL ?), et dont l'usage est toujours
tr&egrave;s r&eacute;pandu de nos jours. La suite Whetstone
produira une mesure de la performance d'une CPU en mati&egrave;re
de calcul flottant.</p>
<p>La principale critique que l'on puisse faire aux benchmarks
synth&eacute;tiques est qu'ils ne repr&eacute;sentent pas la
performance d'un ordinateur, en tant que syst&egrave;me complexe,
dans des conditions d'utilisation r&eacute;elles. Prenons par
exemple la suite Whetstone, dont la boucle principale est
tr&egrave;s courte, et qui donc peut ais&eacute;ment tenir dans le
cache primaire d'une CPU, cette suite maintient le pipeline de la
FPU aliment&eacute; en permanence de fa&ccedil;on &agrave; pousser
celle-ci &agrave; sa vitesse maximale. On ne peut pas vraiment
critiquer la suite Whetstone si l'on se souvient qu'elle a
&eacute;t&eacute; programm&eacute;e il y a 25 ans (sa conception
est m&ecirc;me plus ancienne que &ccedil;a !), mais il nous faut
nous assurer que nous interpr&eacute;tons ses r&eacute;sultats avec
prudence quand nous nous pr&eacute;occupons d'&eacute;valuer les
performances de micro-processeurs modernes.</p>
<p>Un autre aspect tr&egrave;s important qu'il nous faut avoir en
t&ecirc;te &agrave; propos des benchmarks synth&eacute;tiques est
qu'id&eacute;alement, ils devraient pouvoir nous dire quelque chose
en ce qui concerne un aspect <b>sp&eacute;cifique</b> du
syst&egrave;me que l'on est en train de tester, et ce
ind&eacute;pendamment des autres aspects dudit sys&egrave;me : un
benchmark synth&eacute;tique d'une carte D'E/S Ethernet devrait
produire les m&ecirc;mes r&eacute;sultats (ou des r&eacute;sultats
comparables) que ce soit sur un 386SX-16 avec 4 MB de RAM ou sur un
Pentium 200 MMX avec 64 MB de RAM. Si tel n'&eacute;tait pas le
cas, le test mesurerait la performance globale de l'association
CPU/carte-m&egrave;re/bus/carte Ethernet/sous-syst&egrave;me
m&eacute;moire/DMA, ce qui n'est pas tr&egrave;s utile puisque la
diff&eacute;rence au niveau des CPUs aura un impact plus important
que la diff&eacute;rence au niveau des cartes Ethernet (ceci
suppose bien s&ucirc;r que nous utilisions la m&ecirc;me
combinaison noyau/driver (pilote de p&eacute;riph&eacute;rique)).
Dans le cas contraire la diff&eacute;rence de performances pourrait
&ecirc;tre encore plus grande) !</p>
<p>Enfin, une erreur fr&eacute;quemment commise est de calculer la
moyenne de divers benchmarks synth&eacute;tiques et de
pr&eacute;tendre qu'une telle moyenne est une bonne
repr&eacute;sentation de la performance globale d'un syst&egrave;me
donn&eacute; pour une utilisation dans la vie r&eacute;elle.</p>
<p>Voici un commentaire sur les benchmarks FPU (cit&eacute; avec la
permission du site Web de Cyrix Corp.) :</p>
<blockquote><em>"Une unit&eacute; de calcul flottant
acc&eacute;l&egrave;re le logiciel con&ccedil;u pour l'utilisation
de l'arithm&eacute;tique flottante : typiquement il s'agit de
programmes de CAO, de tableurs, de jeux en 3D et d'applications de
conception. Cependant, la plupart des applications PC populaires
d'aujourd'hui utilisent &agrave; la fois des instructions
flottantes et l'arithm&eacute;tique enti&egrave;re. C'est pourquoi
Cyrix a choisi de mettre l'accent sur le parall&eacute;lisme lors
de la conception du processeur 6x86 et ce dans le but
d'acc&eacute;l&eacute;rer les programmes qui entrem&ecirc;lent ces
2 types d'instructions.</em></blockquote>
<blockquote><em>Le mod&egrave;le de traitement des exceptions
flottantes de l'architecture x86 permet aux instructions
enti&egrave;res d'&ecirc;tre &eacute;mises et de se terminer
pendant qu'une instruction flottante est en cours
d'ex&eacute;cution. A l'oppos&eacute;, une seconde op&eacute;ration
flottante ne pourra pas &ecirc;tre ex&eacute;cut&eacute;e alors
qu'une pr&eacute;cedente instruction flottante est en cours
d'ex&eacute;cution. Pour supprimer cette limitation de performance
cr&eacute;ee par le mod&egrave;le de traitement des exceptions
flottantes, le 6x86, peut &eacute;mettre sp&eacute;culativement
jusqu'&agrave; 4 instructions flottantes vers la FPU
int&eacute;gr&eacute;e sur le circuit. Par exemple, dans une
s&eacute;quence de code constitu&eacute;e de 2 instructions
flottantes (FLTs) suivies de 6 instructions enti&egrave;res (INTs),
elles-m&ecirc;mes suivies de 2 FLTs, le 6x86 peut &eacute;mettre
toutes ces 10 instructions vers les unit&eacute;s
d'ex&eacute;cution appropri&eacute;es avant que l'ex&eacute;cution
de la premi&egrave;re FLT ne se soit termin&eacute;e. Si aucune de
ces instructions ne provoque d'exception (ce qui est typique),
l'ex&eacute;cution continue, les unit&eacute;s flottantes et
enti&egrave;res terminant l'ex&eacute;cution de ces instructions en
parall&egrave;le. Si l'une des FLTs g&eacute;n&egrave;re une
exception (le cas atypique), les possibilit&eacute;s
d'ex&eacute;cution sp&eacute;culatives du 6x86 permettent que
l'&eacute;tat du processeur soit restitu&eacute; de fa&ccedil;on
&agrave; ce que celui-ci soit compatible avec le mod&egrave;le de
traitement des exceptions flottantes.</em></blockquote>
<blockquote><em>L'examen de code de benchmarks synth&eacute;tiques
flottants r&eacute;v&egrave;le que ceux-ci utilisent des
s&eacute;quences d'instructions purement flottantes que l'on ne
trouve pas dans les applications du monde r&eacute;el. Ce type de
benchmarks ne tire pas profit des possibilit&eacute;s
d'ex&eacute;cution sp&eacute;culative du processeur 6x86. Cyrix
pense que les benchmarks non-synth&eacute;tiques bas&eacute;s sur
des applications du monde r&eacute;el refl&egrave;tent mieux la
performance que les utilisateurs vont effectivement obtenir. Les
applications du monde r&eacute;el contiennent des instructions
enti&egrave;res et flottantes entrem&ecirc;l&eacute;es et pour
cette raison tireront un meilleur parti des possibilit&eacute;s
d'ex&eacute;cution sp&eacute;culative du 6x86."</em></blockquote>
<p>La tendance r&eacute;cente en mati&egrave;re d'&eacute;valuation
de performances consiste donc &agrave; choisir des applications
usuelles et &agrave; les utiliser pour mesurer la performance
d'ordinateurs en tant que syst&egrave;mes complexes. Par exemple
<b>SPEC</b>, l'entreprise &agrave; but non-lucratif qui a
con&ccedil;u les c&eacute;l&egrave;bres suites de benchmarks
synth&eacute;tiques SPECINT et SPECFP, a lanc&eacute; un projet
pour d&eacute;velopper une nouvelle suite de benchmarks
applicatifs. Mais, l&agrave; encore, il est tr&egrave;s improbable
qu'une telle suite de benchmarks commerciale comporte du code Linux
un jour.</p>
<p>En r&eacute;sum&eacute;, les benchmarks synth&eacute;tiques sont
valables &agrave; condition d'avoir compris leurs objectifs et
leurs limites. Les benchmarks applicatifs refl&egrave;teront mieux
la performance d'un syst&egrave;me informatique, mais aucun d'entre
eux n'est disponible pour Linux.</p>
<h3>Benchmarks de haut-niveau vs. de bas-niveau</h3>
<p>Les benchmarks de bas-niveau ont pour ambition la mesure de la
performance du mat&eacute;riel : la fr&eacute;quence de l'horloge
du processeur, les temps de cycle de la DRAM (ndt : acronyme pour
Dynamic Random Access Memory) et de la SRAM (ndt : acronyme pour
Static Random Access Memory) cache, temps d'acc&egrave;s moyen d'un
disque dur, temps d'acc&egrave;s piste &agrave; piste, etc...</p>
<p>Cette approche peut &ecirc;tre utile si vous avez achet&eacute;
un syst&egrave;me et que vous vous demandez &agrave; partir de
quels composants il a &eacute;t&eacute; construit, bien qu'une
meilleure fa&ccedil;on de r&eacute;pondre &agrave; cette question
soit d'ouvrir le bo&icirc;tier, de dresser l'inventaire des
composants que vous trouverez &agrave; l'int&eacute;rieur, et
d'obtenir les sp&eacute;cifications techniques pour chacun d'entre
eux (elles sont la plupart du temps disponibles sur le Web).</p>
<p>Une autre utilisation possible des benchmarks de bas-niveau
consiste &agrave; s'en servir pour v&eacute;rifier qu'un driver du
noyau a &eacute;t&eacute; correctement configur&eacute; pour un
composant mat&eacute;riel donn&eacute; : si vous disposez des
sp&eacute;cifications techniques de ce composant vous pourrez
comparer les r&eacute;sultats d'un benchmark de bas-niveau aux
valeurs th&eacute;oriques figurant dans les specs.</p>
<p>Les benchmarks de haut-niveau ont plut&ocirc;t pour objectif la
mesure de la performance de l'association
mat&eacute;riel/driver/syst&egrave;me d'exploitation en ce qui
concerne un aspect sp&eacute;cifique d'un syst&egrave;me
informatique (par exemple la performance des
entr&eacute;es-sorties), ou m&ecirc;me une association
sp&eacute;cifique mat&eacute;riel/driver/syst&egrave;me
d'exploitation/application (par exemple un benchmark Apache sur
diff&eacute;rents ordinateurs).</p>
<p>Bien s&ucirc;r, tous les benchmarks de bas-niveau sont
synth&eacute;tiques. Les benchmarks de haut-niveau peuvent
&ecirc;tre synth&eacute;tiques ou applicatifs.</p>
<h2><a name="ss2.2">2.2 Benchmarks standard disponibles pour
Linux</a></h2>
<p>AMHA, un test simple que tout le monde peut effectuer &agrave;
l'occasion d'une mise &agrave; jour de la configuration de sa
machine Linux est de lancer une compilation du noyau avant et
apr&egrave;s cette mise &agrave; jour mat&eacute;rielle/logicielle,
et de comparer les dur&eacute;es de compilation. Si tous les autres
param&egrave;tres sont les m&ecirc;mes, alors ce test est valable
en tant que mesure de la performance en mati&egrave;re de
compilation, et l'on peut affirmer en toute confiance que :</p>
<blockquote>"Le remplacement de A par B a conduit &agrave; une
am&eacute;lioration de x % de la dur&eacute;e de compilation du
noyau Linux dans telles et telles conditions".</blockquote>
<p>Ni plus, ni moins !</p>
<p>Parce que la compilation du noyau est une t&acirc;che
tr&egrave;s courante sous Linux, et parce qu'elle met en oeuvre la
plupart des fonctionnalit&eacute;s impliqu&eacute;es dans les
benchmarks usuels (sauf le calcul flottant), elle constitue un test
<b>isol&eacute;</b> plut&ocirc;t bon. Cependant, dans la majeure
partie des cas, les r&eacute;sultats de ce test ne peuvent pas
&ecirc;tre reproduits par d'autres utilisateurs de Linux &agrave;
cause des diff&eacute;rences de configurations
mat&eacute;rielles/logicielles. Ce test ne constitue donc en aucun
cas une m&eacute;trique permettant de comparer des syst&egrave;mes
dissemblables (&agrave; moins que nous ne nous mettions tous
d'accord sur la compilation d'un noyau standard - voir plus
loin).</p>
<p>Malheureusement, il n'y a pas d'outils d'&eacute;valuation de
performances ciblant sp&eacute;cifiquement Linux, sauf
peut-&ecirc;tre les Byte Linux Benchmarks. Ceux-ci sont une version
l&eacute;gerement modifi&eacute;e des Byte Unix Benchmarks qui
datent de 1991 (modifications Linux par Jon Tombs, auteurs
originels : Ben Smith, Rick Grehan et Tom Yager).</p>
<p>Il existe un <a href=
"http://www.silkroad.com/bass/linux/bm.html">site Web</a> central
pour les Byte Linux Benchmarks.</p>
<p>Une version am&eacute;lior&eacute;e et mise &agrave; jour des
Byte Unix Benchmarks a &eacute;t&eacute; synth&eacute;tis&eacute;e
par David C. Niemi. Elle s'appelle UnixBench 4.01 pour
&eacute;viter une confusion possible avec des versions
ant&eacute;rieures. Voici ce que David a &eacute;crit au sujet de
ses modifications :</p>
<blockquote>"Les BYTE Unix benchmarks originels et
l&eacute;gerement modifi&eacute;s sont nases &agrave; bien des
&eacute;gards ce qui fait d'eux un indicateur inhabituellement
non-fiable de la performance d'un syst&egrave;me. J'ai
d&eacute;lib&eacute;r&eacute;ment fait en sorte que mes indices de
performance soient tr&egrave;s diff&eacute;rents pour &eacute;viter
la confusion avec les vieux benchmarks."</blockquote>
<p>David a mis en place une liste majordomo de diffusion par
courrier &eacute;lectronique pour les discussions relatives
&agrave; l'&eacute;valuation de performances sous Linux et sous les
syst&egrave;mes d'exploitation concurrents. Vous pouvez vous
joindre &agrave; ces discussions en envoyant un e-mail dont le
corps contiendra "subscribe bench" &agrave; l'adresse <a href=
"mailto:majordomo@wauug.erols.com">majordomo@wauug.erols.com</a>.
Les groupe des utilisateurs de la r&eacute;gion de Washington est
aussi en train de mettre en place un <a href=
"http://wauug.erols.com/bench">site Web</a> concernant les
benchmarks sous Linux.</p>
<p>R&eacute;cemment, Uwe F. Mayer, <a href=
"mailto:mayer@math.vanderbilt.edu">mayer@math.vanderbilt.edu</a> a
&eacute;galement port&eacute; la suite Bytemark de BYTE sous Linux.
Il s'agit d'une suite moderne et compil&eacute;e tr&egrave;s
habilement par Rick Grehan du magazine BYTE. Bytemark teste les
performances de la CPU, de la FPU et du sous-syst&egrave;me
m&eacute;moire des micro-ordinateurs modernes (ces benchmarks sont
strictement orient&eacute;s vers la performance du processeur, les
E/S ou la performance globale du syst&egrave;me ne sont pas pris en
compte).</p>
<p>Uwe a aussi mis en place un <a href=
"http://math.vanderbilt.edu:80/~mayer/linux/bmark.html">site
Web</a>, site o&ugrave; l'on peut acc&eacute;der &agrave; une base
de donn&eacute;es contenant les r&eacute;sultats de sa version des
benchmarks BYTEmark pour Linux.</p>
<p>Si vous &ecirc;tes &agrave; la recherche de benchmarks
synth&eacute;tiques pour Linux, vous remarquerez assez vite que
sunsite.unc.edu ne propose que peu d'outils d'&eacute;valuation de
performances. Pour mesurer les performances relatives de serveurs
X, la suite xbench-0.2 de Claus Gittinger est disponible sur
sunsite.unc.edu, ftp.x.org et d'autres sites (ndt : notamment
ftp.lip6.fr qui est l'un des mirroirs de sunsite). Dans son immense
sagesse, Xfree86.org refuse de promouvoir ou de recommender le
moindre benchmark.</p>
<p><a href="http://www.goof.com/xbench/">XFree86-benchmarks
Survey</a> est un site Web comprenant une base de donn&eacute;es de
r&eacute;sultats relatifs &agrave; x-bench.</p>
<p>En ce qui concerne les E/S purement disque, l'utilitaire hdparm
(qui fait partie de la plupart des distributions, mais est aussi
disponible sur sunsite.unc.edu) permet de mesurer les taux de
transfert gr&acirc;ce aux options -t et -T.</p>
<p>Il existe plein d'autres outils disponibles librement (sous
license GPL) sur Internet pour tester divers aspects de la
performance de votre machine Linux.</p>
<h2><a name="ss2.3">2.3 Liens et r&eacute;f&eacute;rences</a></h2>
<p>La FAQ du newsgroup comp.benchmarks par Dave Sill est la
r&eacute;f&eacute;rence standard en mati&egrave;re
d'&eacute;valuation de performances. Elle n'est pas
particuli&egrave;rement orient&eacute;e Linux, mais elle n'en reste
pas moins une lecture recommend&eacute;e pour tous ceux qui font
preuve d'un minimum de s&eacute;rieux envers le sujet. Elle est
disponible sur nombre de sites FTP et de sites Web et recense <b>56
benchmarks diff&eacute;rents</b> avec des liens vers des sites FTP
permettant de les t&eacute;l&eacute;charger. Cependant, certains
des benchmarks recens&eacute;s sont des produits commerciaux.</p>
<p>Je n'entrerai pas dans la description d&eacute;taill&eacute;e
des benchmarks mentionn&eacute;s dans la FAQ de comp.benchmarks,
mais il y a au moins une suite de bas-niveau au sujet de laquelle
j'aimerai faire quelques commentaires : la <a href=
"http://reality.sgi.com/lm/lmbench/lmbench.html">suite lmbench</a>
de Larry McVoy. Je cite David C. Niemi :</p>
<blockquote><em>"Linus et David Miller s'en servent beaucoup parce
qu'elle permet des mesures de bas-niveau utiles et peut aussi
quantifier la bande passante et la latence d'un r&eacute;seau si
vous avez deux machines &agrave; votre disposition pour le faire
tourner. Mais lmbench n'essaie pas de produire un indice de
performance global..."</em></blockquote>
<p>Un <a href="ftp://ftp.nosc.mil/pub/aburto">site FTP</a> assez
complet en mati&egrave;re de benchmarks disponibles
<b>librement</b> a &eacute;t&eacute; mis en place par Alfred
Aburto. La suite Whetstone utilis&eacute;e dans le LBT est
disponible sur ce site.</p>
<p>Une <b>FAQ multi-fichier par Eugene Miya</b> est
&eacute;galement post&eacute;e sur comp.benchmarks; c'est une
excellente r&eacute;f&eacute;rence.</p>
<h2><a name="s3">3. Le Linux Benchmarking Toolkit (LBT)</a></h2>
<p>Je propose ici un ensemble d'outils pour l'&eacute;valuation de
performances sous Linux. C'est la version pr&eacute;liminaire d'un
vaste environnement d'&eacute;valuation de performances pour Linux,
il est destin&eacute; &agrave; &ecirc;tre am&eacute;lior&eacute; et
&agrave; voir ses fonctionnalit&eacute;s &eacute;tendues. Prenez le
pour ce qu'il vaut, c'est-&agrave;-dire une proposition. Si vous
pensez que cette suite de test n'est pas valable, prenez la
libert&eacute; de m'envoyer (ndt : &agrave; l'auteur et non au
traducteur, merci :-) vos critiques par e-mail et soyez s&ucirc;rs
que je serai heureux d'int&eacute;grer les changements que vous
aurez sugg&eacute;r&eacute; dans la mesure du possible. Avant
d'entamer une pol&eacute;mique, lisez ce HOWTO et les documents
cit&eacute;s en r&eacute;f&eacute;rence : les critiques
inform&eacute;s sont les bienvenus, les critiques st&eacute;riles
ne le sont pas.</p>
<h2><a name="ss3.1">3.1 Motivations</a></h2>
<p>Elles sont dict&eacute;es par le bon sens, tout simplement :</p>
<ol>
<li>Cette suite ne doit pas n&eacute;cessiter plus d'une
journ&eacute;e de dur&eacute;e d'ex&eacute;cution. En
mati&egrave;re de benchmarks comparatifs (diverses
ex&eacute;cutions), personne ne veut passer des jours &agrave;
essayer de trouver la configuration mat&eacute;rielle le plus
rapide pour un syst&egrave;me donn&eacute;. Id&eacute;alement,
l'ensemble de la suite devrait pouvoir tourner en 15 minutes sur
une machine moyenne.</li>
<li>Tout le code source doit &ecirc;tre disponible librement sur le
Net, pour des raisons &eacute;videntes.</li>
<li>Les benchmarks devraient fournir des chiffres simples et
refl&eacute;tant la performance mesur&eacute;e.</li>
<li>Il devait y avoir un m&eacute;lange de benchmarks
synth&eacute;tiques et de benchmarks applicatifs.</li>
<li>Chacun des benchmarks <b>synth&eacute;tiques</b> devrait
pousser un sous-syst&egrave;me particulier &agrave; ses
limites.</li>
<li>Les r&eacute;sultats des benchmarks <b>synth&eacute;tiques</b>
ne devraient <b>pas</b> &ecirc;tre combin&eacute;s par le biais
d'une moyenne afin d'en extraire un facteur de m&eacute;rite global
(cela va &agrave; l'encontre du principe fondateur des benchmarks
synth&eacute;tiques et conduit &agrave; une perte d'information
consid&eacute;rable).</li>
<li>Les benchmarks applicatifs devraient &ecirc;tre
repr&eacute;sentatifs de t&acirc;ches couramment
ex&eacute;cut&eacute;es sur des syst&egrave;mes Linux.</li>
</ol>
<h2><a name="ss3.2">3.2 S&eacute;lection des benchmarks</a></h2>
<p>J'ai s&eacute;lectionn&eacute; 5 suites des benchmarks
diff&eacute;rentes en &eacute;vitant autant que possible les
recouvrements dans les tests :</p>
<ol>
<li>Compilation du noyau 2.0.0 (configuration par d&eacute;faut)
avec gcc.</li>
<li>Whetstone version 10/03/97 (la version la plus r&eacute;cente
de Roy Longbottom).</li>
<li>xbench-0.2 (avec les param&egrave;tres d'ex&eacute;cution
rapide).</li>
<li>Les benchmarks UnixBench version 4.01 (r&eacute;sultats
partiels).</li>
<li>Les benchmarks de la suite BYTEmark du magazine BYTE beta
release 2 (r&eacute;sultats partiels).</li>
</ol>
<p>Pour les tests 4 et 5, "(r&eacute;sultats partiels)" signifie
qu'une partie seulement des r&eacute;sultats produits est prise en
compte.</p>
<h2><a name="ss3.3">3.3 Dur&eacute;e des tests</a></h2>
<ol>
<li>Compilation du noyau 2.0.0 : 5 - 30 minutes, selon la
performance <b>r&eacute;elle</b> de votre machine.</li>
<li>Whetstone : 100 secondes.</li>
<li>Xbench-0.2 : &lt; 1 heure.</li>
<li>Les benchmarks d'UnixBench version 4.01 : environs 15
minutes.</li>
<li>Les benchmarks de la suite BYTEmark du magazine BYTE : environs
10 minutes.</li>
</ol>
<h2><a name="ss3.4">3.4 Commentaires</a></h2>
<h3>Compilation du noyau 2.0.0</h3>
<ul>
<li><b>Quoi :</b> c'est le seul benchmark applicatif de la
LBT.</li>
<li>Le code est largement disponible (c&agrave;d que j'ai
finalement trouv&eacute; une utilisation pour mes vieux CD-ROMs
Linux).</li>
<li>La plupart des linuxiens recompilent leur noyau assez souvent,
c'est donc une mesure significative de la performance globale.</li>
<li>Le noyau est gros et gcc utilise une bonne partie de la
m&eacute;moire (ndt : surtout &agrave; l'&eacute;dition de liens) :
ceci contribue &agrave; att&eacute;nuer le biais induit par le
cache L2 lorsque l'on se contente de passer de petits tests.</li>
<li>Les E/S vers le disque sont fr&eacute;quentes.</li>
<li>Proc&eacute;dure de test : trouvez une antique arborescence
source de 2.0.0, compilez la avec les options par d&eacute;faut
(make config, appuyez sur Enter autant de fois que
n&eacute;c&eacute;ssaire). Le temps affich&eacute; doit
correspondre &agrave; la dur&eacute;e pass&eacute;e sur la
compilation c&agrave;d apr&egrave;s que vous ayez tap&eacute; make
zImage (sans prendre en compte le make dep clean). Notez que
l'architecture cible par d&eacute;faut est i386, donc si vous
compilez sur une autre architecture, gcc devrait &ecirc;tre en
mesure de cross-compiler en utilisant i386 en tant qu'architecture
cible.</li>
<li><b>R&eacute;sultats :</b> la dur&eacute;e de compilation en
minutes et secondes (s'il vous plait, ne rapportez pas les
fractions de secondes).</li>
</ul>
<h3>La suite Whetstone</h3>
<ul>
<li><b>Quoi :</b> mesure la performance en calcul flottant pur
&agrave; l'int&eacute;rieur d'une courte (et dense) boucle. Le code
source (en C) est assez lisible et il est tr&egrave;s facile de
voir quelles sont les op&eacute;rations flottantes
impliqu&eacute;es.</li>
<li>C'est le plus court des tests de la LBT :-).</li>
<li>C'est un "Vieux Classique" : des chiffres sont disponibles pour
comparaison, ses d&eacute;fauts et ses faiblesses sont bien
connues.</li>
<li>Proc&eacute;dure de test : le code source le plus r&eacute;cent
devrait &ecirc;tre t&eacute;l&eacute;charg&eacute; depuis le site
d'Aburto. Compilez le et ex&eacute;cutez le en mode double
pr&eacute;cision. Sp&eacute;cifiez gcc et -O2 en tant que
pr&eacute;-processeur et option du compilateur respectivement.
D&eacute;finissez aussi la variable du pr&eacute;-processur POSIX
&agrave; 1 pour pr&eacute;ciser le type de machine.</li>
<li><b>R&eacute;sultats :</b> un indice de performance en calcul
flottant exprim&eacute; en MWIPS.</li>
</ul>
<h3>Xbench-0.2</h3>
<ul>
<li><b>Quoi :</b> mesure la performance de serveurs X.</li>
<li>La mesure en xStones fournie par xbench est une moyenne
pond&eacute;r&eacute;e de quelques tests rapport&eacute;s aux
performances obtenues sur une vieille station Sun ne disposant que
d'un display d'un seul bit de profondeur (ndt : en clair, c'est du
monochrome pur et dur). Mouais... on peut l&eacute;gitimement se
demander si xbench est v&eacute;ritablement ad&eacute;quat en tant
que test pour des serveurs X modernes. N&eacute;anmoins, c'est le
meilleur outil que j'ai trouv&eacute;.</li>
<li>Proc&eacute;dure de test : compilez avec -O2. On
sp&eacute;cifiera aussi quelques options pour une ex&eacute;cution
courte : <code>./xbench -timegoal 3 &gt;
results/name_of_your_linux_box.out</code>. Pour
g&eacute;n&eacute;rer l'indice xStones, il nous faudra encore
lancer un script awk; la fa&ccedil;on la plus simple de le faire
&eacute;tant de taper make summary.ms. Jetez un coup d'oeuil au
fichier summary.ms : l'indice xStone de votre syst&egrave;me est
dans la derni&egrave;re colonne de la ligne contenant le nom de
votre machine -- nom que vous aurez sp&eacute;cifi&eacute; pendant
le test.</li>
<li><b>R&eacute;sultats :</b> un indice de performances
exprim&eacute; en xStones.</li>
<li>Note : ce test, en l'&eacute;tat, est d&eacute;pass&eacute;. Il
devrait &ecirc;tre r&eacute;-&eacute;crit.</li>
</ul>
<h3>UnixBench version 4.01</h3>
<ul>
<li><b>Quoi</b> : mesure la performance globale d'un syst&egrave;me
UNIX. Ce test met en oeuvre &eacute;vidence la performance des E/S
fichier et de la gestion du multi-t&acirc;ches par le noyau.</li>
<li>J'ai supprim&eacute; tous les r&eacute;sultats de tests
arithm&eacute;tiques et je n'ai conserv&eacute; que les tests
orient&eacute;s syst&egrave;me.</li>
<li>Proc&eacute;dure de test : make avec -O2. Ex&eacute;cution avec
<code>./Run -1</code> (tournez chacun des tests une fois). Vous
trouverez les r&eacute;sultats dans le fichier ./results/report.
Calculez la moyenne g&eacute;om&eacute;trique des indices de EXECL
THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT
SWITCHING, PROCESS CREATION, SHELL SCRIPTS et SYSTEM CALL
OVERHEAD.</li>
<li><b>R&eacute;sultats :</b> un indice de performance du
syst&egrave;me.</li>
</ul>
<p>(ndt : la moyenne g&eacute;om&eacute;trique se d&eacute;finit
comme la racine n-i&egrave;me du produit des n termes
consid&eacute;r&eacute;s)</p>
<h3>Les benchmarks Bytemark du magazine BYTE</h3>
<ul>
<li>Quoi : fournit une bonne mesure de la performance CPU. Voici un
extrait de la documentation : <em>"Ces benchmarks ont
&eacute;t&eacute;s con&ccedil;u de fa&ccedil;on &agrave; mettre en
&eacute;vidence la limite sup&eacute;rieure de la CPU, de la FPU et
de l'architecture m&eacute;moire d'un syst&egrave;me. Ils ne
peuvent mesurer la performance du sous-syst&egrave;me graphique,
des acc&egrave;s disque ou du d&eacute;bit r&eacute;seau (ce sont
l&agrave; le domaine d'un ensemble diff&eacute;rent de benchmarks).
C'est pourquoi, il est souhaitable que vous n'utilisiez les
r&eacute;sultats de ces tests qu'en tant qu'&eacute;l&eacute;ment
d'appr&eacute;ciation partielle, et non pas totale, lors de
l'&eacute;valuation de la performance d'un
syst&egrave;me."</em></li>
<li>J'ai supprim&eacute; tous les r&eacute;sultats de test FPU
puisque la suite Whetstone est tout aussi repr&eacute;sentative des
performances &agrave; cet &eacute;gard.</li>
<li>J'ai d&eacute;compos&eacute; les tests entiers en deux groupes
: ceux qui sont plus repr&eacute;sentatifs de la performance cache
m&eacute;moire/CPU, et ceux qui utilisent l'arithm&eacute;tique
enti&egrave;re de la CPU.</li>
<li>Proc&eacute;dure de test : make avec -O2. Ex&eacute;cutez le
test avec ./nbench &gt;myresults.dat ou quelque chose d'approchant.
Puis, &agrave; partir de myresults.dat, calculez la moyenne
g&eacute;om&eacute;trique des indices des tests STRING SORT,
ASSIGNMENT et BITFIELD. Ceci vous donnera l'<b>indice
m&eacute;moire</b>. Calculez la moyenne g&eacute;om&eacute;trique
des indices des tests NUMERIC SORT, IDEA, HUFFMAN et FP EMULATION:
c'est l'<b>indice entier</b>.</li>
<li><b>R&eacute;sultats :</b> un indice m&eacute;moire et un indice
entier calcul&eacute;s comme expliqu&eacute; ci-dessus.</li>
</ul>
<h2><a name="ss3.5">3.5 Am&eacute;liorations possibles</a></h2>
<p>La suite de benchmarks id&eacute;ale tournerait en quelques
minutes, comprendrait des benchmarks synth&eacute;tiques testant
chaque sous-syst&egrave;me s&eacute;par&eacute;ment et des
benchmarks applicatifs fournissant des r&eacute;sultats pour
diff&eacute;rentes applications. Elle produirait aussi
automatiquement un rapport complet et &eacute;ventuellement
l'enverrait par e-mail &agrave; une base de donn&eacute;es centrale
sur le Web.</p>
<p>La portabilit&eacute; n'est pas vraiment notre souci premier
dans cette affaire. Pourtant, une telle suite devrait tourner au
moins sur toutes les versions (&gt; 2.0.0) du noyau Linux, et ce
dans toutes leurs d&eacute;clinaisons possibles (i386, Alpha,
Sparc...).</p>
<p>Si quelqu'un a la moindre id&eacute;e concernant
l'&eacute;valuation de performances r&eacute;seau au moyen d'un
test &agrave; la fois simple, facile d'emploi, fiable, et dont la
mise en oeuvre prendrait moins de 30 minutes (configuration et
ex&eacute;cution), s'il vous plait contactez-moi.</p>
<h2><a name="ss3.6">3.6 Formulaire de rapport LBT</a></h2>
<p>Au-del&agrave; des tests, la proc&eacute;dure
d'&eacute;valuation de performances n'aurait pas &eacute;t&eacute;
compl&egrave;te sans un formulaire d&eacute;crivant la
configuration mat&eacute;rielle utilis&eacute;e lors de leur
ex&eacute;cution. Le voici donc : (il se conforme aux directives
prescrites dans la FAQ de comp.benchmarks) :</p>
<p>(ndt : le formulaire en question n'a
d&eacute;lib&eacute;r&eacute;ment pas &eacute;t&eacute; traduit, de
fa&ccedil;on &agrave; ce que l'auteur de ce HOWTO puisse
automatiser leur traitement en vue de maintenir une base de
donn&eacute;es de r&eacute;sultats. Voir la section 4 pour un
exemple de formulaire correctement rempli).</p>
<blockquote>
<pre>
<code>______________________________________________________________________
LINUX BENCHMARKING TOOLKIT REPORT FORM
______________________________________________________________________

______________________________________________________________________
CPU
==
Vendor:
Model:
Core clock:
Motherboard vendor:
Mbd. model:
Mbd. chipset:
Bus type:
Bus clock:
Cache total:
Cache type/speed:
SMP (number of processors):
______________________________________________________________________

______________________________________________________________________
RAM
====
Total:
Type:
Speed:
______________________________________________________________________

______________________________________________________________________
Disk
====
Vendor:
Model:
Size:
Interface:
Driver/Settings:
______________________________________________________________________

______________________________________________________________________
Video board
===========
Vendor:
Model:
Bus:
Video RAM type:
Video RAM total:
X server vendor:
X server version:
X server chipset choice:
Resolution/vert. refresh rate:
Color depth:
______________________________________________________________________

______________________________________________________________________
Kernel
=====
Version:
Swap size:
______________________________________________________________________

______________________________________________________________________
gcc
===
Version:
Options:
libc version:
______________________________________________________________________

______________________________________________________________________
Test notes
==========
______________________________________________________________________

______________________________________________________________________
RESULTS
========
Linux kernel 2.0.0 Compilation Time: (minutes and seconds)
Whetstones: results are in MWIPS.
Xbench: results are in xstones.
Unixbench Benchmarks 4.01 system INDEX:
BYTEmark integer INDEX:
BYTEmark memory INDEX:
______________________________________________________________________

______________________________________________________________________
Comments*
=========
* Ce champ n'est pr&eacute;sent dans ce formulaire que pour de possibles
interpr&eacute;tations des r&eacute;sultats, et tant que tel, il est optionnel.
Il pourrait cependant constituer la partie la plus importante de votre
compte-rendu, tout particuli&egrave;rement si vous faites de l'&eacute;valuation
de performances comparative.
______________________________________________________________________
</code>
</pre></blockquote>
<h2><a name="ss3.7">3.7 Test de performances r&eacute;seau</a></h2>
<p>Le test des performances r&eacute;seau est un v&eacute;ritable
d&eacute;fi en soi puisqu'il implique au moins deux machines: un
serveur et une machine cliente. Pour cette raison ce genre de test
n&eacute;cessite deux fois plus de temps pour &ecirc;tre mis en
place, il y a plus de variables &agrave; contr&ocirc;ler, etc...
Sur un r&eacute;seau Ethernet, il me semble votre meilleure option
est le paquetage ttcp. (&agrave; developper)</p>
<h2><a name="ss3.8">3.8 Les tests SMP</a></h2>
<p>Les tests SMP sont un autre d&eacute;fi, et tout test
con&ccedil;u sp&eacute;cifiquement pour un environnement SMP aura
des difficult&eacute;s &agrave; s'av&eacute;rer valide dans des
conditions d'utilisation r&eacute;elles parce que les algorithmes
qui tirent parti du SMP sont difficiles &agrave; d&eacute;velopper.
Il semble que les versions du noyau Linux les plus r&eacute;centes
(&gt; 2.1.30 ou pas loin) feront du scheduling (ndt :
ordonnancement de thread ou de processus) &agrave; grain fin ; je
n'ai pas plus d'information que &ccedil;a pour le moment.</p>
<p>Selon David Niemi, <em>"... shell8</em> de la suite Unixbench
4.01 <em>fait du bon travail en mati&egrave;re de comparaison de
mat&eacute;riel/SE similaires en mode SMP et en mode UP."</em></p>
<p>(ndt : SMP = Symetric Multi-Processing, UP = Uni-Processor)</p>
<h2><a name="s4">4. Une ex&eacute;cution type et les
r&eacute;sultats</a></h2>
<p>Le LBT a &eacute;t&eacute; lanc&eacute; sur ma machine perso.,
une machine de classe Pentium tournant Linux que j'ai
assembl&eacute;e moi-m&ecirc;me et que j'utilise pour &eacute;crire
ce HOWTO. Voici le compte-rendu LBT pour ce syst&egrave;me :</p>
<blockquote>
<pre>
<code>LINUX BENCHMARKING TOOLKIT REPORT FORM

CPU
==

Vendor: Cyrix/IBM

Model: 6x86L P166+

Core clock: 133 MHz

Motherboard vendor: Elite Computer Systems (ECS)

Mbd. model: P5VX-Be

Mbd. chipset: Intel VX

Bus type: PCI

Bus clock: 33 MHz

Cache total: 256 KB

Cache type/speed: Pipeline burst 6 ns

SMP (number of processors): 1

RAM
====

Total: 32 MB

Type: EDO SIMMs

Speed: 60 ns

Disk
====

Vendor: IBM

Model: IBM-DAQA-33240

Size: 3.2 GB

Interface: EIDE

Driver/Settings: Bus Master DMA mode 2

Video board
===========

Vendor: Generic S3

Model: Trio64-V2

Bus: PCI

Video RAM type: EDO DRAM

Video RAM total: 2 MB

X server vendor: XFree86

X server version: 3.3

X server chipset choice: S3 accelerated

Resolution/vert. refresh rate: 1152x864 @ 70 Hz

Color depth: 16 bits

Kernel
=====

Version: 2.0.29

Swap size: 64 MB

gcc
===

Version: 2.7.2.1

Options: -O2

libc version: 5.4.23

Test notes
==========

Une charge tr&egrave;s faible. Les tests ci-dessus ont &eacute;t&eacute; ex&eacute;cut&eacute;s
avec quelques unes des options sp&eacute;cifiques du Cyrix/IBM 6x86 activ&eacute;es
gr&acirc;ce au programme setx86. Il s'agit de : fast ADS, fast IORT, Enable DTE,
fast LOOP, fast Lin. VidMem.

RESULTS
========

Linux kernel 2.0.0 Compilation Time: 7m12s

Whetstones: 38.169 MWIPS.

Xbench: 97243 xStones.

BYTE Unix Benchmarks 4.01 system INDEX: 58.43

BYTEmark integer INDEX: 1.50

BYTEmark memory INDEX: 2.50

Comments
=========

Il s'agit l&agrave; d'une configuration tr&egrave;s stable et dot&eacute;e de performances
homog&egrave;nes, id&eacute;ale pour une utilisation individuelle et/ou d&eacute;velopper
sous Linux. Je rendrai compte des r&eacute;sultats obtenus avec un 6x86MX d&egrave;s
que j'aurai r&eacute;ussi &agrave; mettre la main sur l'un d'entre eux !
</code>
</pre></blockquote>
<h2><a name="s5">5. Pi&egrave;ges et mises en garde en
mati&egrave;re d'&eacute;valuation de performances</a></h2>
<p>Apr&egrave;s avoir compil&eacute; ce HOWTO, j'ai commenc&eacute;
&agrave; comprendre pourquoi les mots de "pi&egrave;ge" et de "mise
en garde" sont si souvent associ&eacute;s &agrave;
l'&eacute;valuation de performances.</p>
<h2><a name="ss5.1">5.1 Comparer des pommes et des oranges</a></h2>
<p>Ou devrais-je dire des Apples et des PCs ? (ndt : pour
go&ucirc;ter pleinement toute la finesse de ce jeu de mots, il faut
quand m&ecirc;me savoir que pomme se dit apple en anglais :-) C'est
tellement &eacute;vident et c'est une controverse tellement
&eacute;cul&eacute;e que je ne rentrerai pas dans les
d&eacute;tails. Je doute que le temps n&eacute;cessaire pour booter
un Mac compar&eacute; &agrave; celui d'un Pentium moyen soit une
v&eacute;ritable mesure de quoi que ce soit. De fa&ccedil;on
similaire on pourrait parler du boot de Linux vs. Windows NT,
etc... Essayez autant que possible de comparer des machines
identiques &agrave; une seule diff&eacute;rence pr&egrave;s.</p>
<h2><a name="ss5.2">5.2 Information incompl&egrave;te</a></h2>
<p>Un seul exemple suffira &agrave; l'illustration de cette erreur
tr&egrave;s courante. On lit souvent dans comp.os.linux.hardware
l'affirmation suivante : "Je viens tout juste d'enficher le
processeur XYZ qui tourne &agrave; nnn MHz et la compilation du
noyau prend maintenant i minutes (ajustez XYZ, nnn et i selon vos
besoins). C'est &eacute;nervant parce qu'aucune autre information
n'est fournie: on ne connait m&ecirc;me pas la quantit&eacute; de
RAM, la taille du swap, les autres t&acirc;ches qui tournaient
&agrave; ce moment l&agrave;, la version du noyau, les modules
s&eacute;lectionn&eacute;s, le type de disque dur, la version de
gcc, etc...</p>
<p>Je vous recommende d'utiliser le formulaire de compte-rendu LBT,
lequel fournit au moins un cadre informationnel standard.</p>
<h2><a name="ss5.3">5.3 Mat&eacute;riel/logiciel
propri&eacute;taire</a></h2>
<p>Un fabriquant de micro-processeurs bien connu a publi&eacute;
nagu&egrave;re des r&eacute;sultats de benchmarks produits avec une
version sp&eacute;ciale et personnalis&eacute;e de gcc.
Consid&eacute;rations &eacute;thiques mises &agrave; part, ces
r&eacute;sultats sont d&eacute;nu&eacute;s de toute signification,
en effet, la totalit&eacute; de la communaut&eacute; Linux aurait
utilis&eacute; la version standard de gcc. Le m&ecirc;me genre de
consid&eacute;ration vaut aussi pour le mat&eacute;riel
propri&eacute;taire. L'&eacute;valuation de performances est
beaucoup plus utile quand elle va de pair avec du mat&eacute;riel
sur &eacute;tag&egrave;re et du logiciel gratuit (au sens
GNU/GPL).</p>
<h2><a name="ss5.4">5.4 Pertinence</a></h2>
<p>On parle de Linux, non ? On devrait donc faire abstraction des
benchmarks produits sous d'autres syst&egrave;mes d'exploitation
(ceci est une instance particuli&egrave;re de la comparaison des
pommes et des oranges mentionn&eacute;e plus haut). Si l'on se
propose d'&eacute;valuer la performance d'un serveur Web, on pourra
aussi se dispenser de citer la performance FPU et toute autre
information non-pertinente. Dans de tels cas, moins c'est plus.
Enfin, vous n'avez pas non plus besoin de parler de l'age de votre
chat, de votre humeur pendant que vous proc&eacute;dez &agrave; une
&eacute;valuation de performances, etc...</p>
<h2><a name="s6">6. FAQ</a></h2>
<dl>
<dt><b>Q1.</b></dt>
<dd>
<p>Existe-t-il un indice de performances sp&eacute;cifique aux
machines Linux ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>Non, Dieu merci personne n'a encore invent&eacute; de mesure du
type Lhinuxstone (tm). M&ecirc;me si c'&eacute;tait le cas,
&ccedil;a n'aurait pas beaucoup de sens : les machines Linux sont
utilis&eacute;es pour des t&acirc;ches tellement diff&eacute;rentes
allant des serveurs Web lourdement charg&eacute;s aux stations
graphiques pour utilisation individelle. Aucun facteur de
m&eacute;rite ne peut d&eacute;crire les performances d'une machine
Linux dans des situations si diff&eacute;rentes.</p>
</dd>
<dt><b>Q2.</b></dt>
<dd>
<p>Alors, pourquoi ne pas choisir une douzaine de m&eacute;triques
pour r&eacute;sumer la performance de diverses machines Linux ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>&Ccedil;a serait une situation id&eacute;ale. J'aimerai voir
&ccedil;a devenir une r&eacute;alit&eacute;. Y-a-t-il des
volontaires pour un <b>projet d'&eacute;valuation de performances
sous Linux</b> ? Avec un site Web et une base de donn&eacute;es de
rapports bien con&ccedil;us, compl&egrave;te et en ligne ?</p>
</dd>
<dt><b>Q3.</b></dt>
<dd>
<p>... BogoMips ...</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>Les BogoMips n'ont strictement rien &agrave; voir avec la
performance de votre machine. Voir le BogoMips Mini-HOWTO.</p>
</dd>
<dt><b>Q4.</b></dt>
<dd>
<p>Quel est le "meilleur" benchmark pour Linux ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>&Ccedil;a d&eacute;pend compl&egrave;tement de quel aspect des
performances d'une machine Linux on souhaite mesurer. Il y a des
benchmarks diff&eacute;rents pour faire des mesures r&eacute;seau
(taux de transfert soutenu sous Ethernet), des mesures de serveur
de fichiers (NFS), de bande passante, de performance CAO, de temps
de transaction, de performance SQL, de performances de serveur Web,
de performance temps-r&eacute;el, de performance CD-ROM, de
performance sous Quake (!), etc ... Pour autant que je sache,
aucune suite de benchmarks supportant tous ces tests n'existe pour
Linux.</p>
</dd>
<dt><b>Q5.</b></dt>
<dd>
<p>Quel est le processeur le plus rapide pour Linux ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>Le plus rapide pourquoi faire ? Si on est plut&ocirc;t
orient&eacute; calcul intensif, alors un Alpha &agrave;
fr&eacute;quence d'horloge &eacute;lev&eacute;e (600 MHz et
&ccedil;a continue &agrave; grimper) devrait &ecirc;tre plus rapide
que n'importe quoi d'autre, du fait que les Alphas ont
&eacute;t&eacute; con&ccedil;us dans cette optique. D'un autre
c&ocirc;t&eacute;, si vous voulez vous constituer un serveur de
news tr&egrave;s rapide, il est probable que le choix d'un
sous-syst&egrave;me disque rapide et de beaucoup de RAM vous menera
&agrave; de meilleures am&eacute;liorations de performances qu'un
changement de processeur (&agrave; prix constant).</p>
</dd>
<dt><b>Q6.</b></dt>
<dd>
<p>Laissez-moi reformuler la derni&egrave;re question, alors :
y-a-t-il un processeur qui soit le plus rapide dans les
applications d'usage g&eacute;n&eacute;ral ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>C'est une question d&eacute;licate mais la r&eacute;ponse est
simple : NON. On peut toujours concevoir un syst&egrave;me plus
rapide m&ecirc;me pour des applications d'usage
g&eacute;n&eacute;ral ind&eacute;pendamment du processeur.
D'ordinaire, en conservant tous les autres param&egrave;tres
&agrave; leur valeur nominale, des fr&eacute;quences d'horloge plus
&eacute;lev&eacute;es permettent d'obtenir de meilleures
performances (ndt : surtout si on parle de syst&egrave;mes
synchrones :-) et aussi plus de maux de t&ecirc;te. Si vous retirez
un vieux Pentium &agrave; 100 MHz d'une carte-m&egrave;re (laquelle
n'est pas souvent) upgradable, et que vous le remplaciez par un
Pentium 200 MHz MMX vous devriez sentir une diff&eacute;rence de
performances notable. Bien s&ucirc;r, pourquoi se contenter de 16
MB de RAM ? Le m&ecirc;me investissement aurait &eacute;t&eacute;
fait de fa&ccedil;on encore plus avis&eacute;e au profit de
quelques SIMMs suppl&eacute;mentaires...</p>
</dd>
<dt><b>Q7.</b></dt>
<dd>
<p>Donc la fr&eacute;quence d'horloge du processeur a une influence
sur la performance d'un syst&egrave;me ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>La plupart des t&acirc;ches sauf les boucles de NOP (qui sont
d'ailleurs supprim&eacute;es &agrave; la compilation par les
compilateurs modernes) une augmentation de la fr&eacute;quence
d'horloge permettra d'obtenir une augmentation lin&eacute;aire de
la performance. Des applications gourmandes en ressources CPU et
tr&egrave;s petites (pouvant donc tenir dans le cache L1 : 8 ou
16KB) verront leur performances augmenter dans la m&ecirc;me
proportion que l'augmentation de la fr&eacute;quence d'horloge.
Cependant les "vrais" programmes comportent des boucles qui ne
tiennent pas dans le cache primaire, doivent partager le cache
secondaire (externe) avec d'autres processus et d&eacute;pendent de
composants externes (ndt : pour les E/S)
b&eacute;n&eacute;ficieront d'un gain de performance beaucoup moins
important. Tout ceci parce que le cache L1 fonctionne &agrave; la
m&ecirc;me fr&eacute;quence d'horloge que le processeur, alors que
la plupart des caches L2 et des autres sous-syst&egrave;mes (DRAM
par exemple) tournent en asynchrone &agrave; des fr&eacute;quences
plus basses.</p>
</dd>
<dt><b>Q8.</b></dt>
<dd>
<p>D'accord, dans ce cas, une derni&egrave;re question sur le sujet
: quel est le processeur pr&eacute;sentant le meilleur rapport
prix/performance pour une utilisation d'usage g&eacute;n&eacute;ral
sous Linux ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>D&eacute;finir une "utilisation d'usage g&eacute;n&eacute;ral
sous Linux" n'est pas chose facile ! Etant donn&eacute;e une
application quelconque, il y a toujours moyen de d&eacute;terminer
quel processeur du moment d&eacute;tient le meilleur rapport
prix/performance pour ladite application. Mais les choses changent
si rapidement &agrave; mesure que les fabriquants diffusent de
nouveaux processeurs, que dire "le processeur XYZ &agrave; n MHz
est le choix du moment" serait forc&eacute;ment r&eacute;ducteur.
Cependant, le prix du processeur n'est pas significatif dans le
co&ucirc;t d'un syst&egrave;me complet que l'on assemble
soi-m&ecirc;me. Donc, la question devrait plut&ocirc;t &ecirc;tre
"comment maximize-t-on le rapport performance/co&ucirc;t d'une
machine donn&eacute;e ?" Et la r&eacute;ponse &agrave; cette
question d&eacute;pend en grande partie des besoins en performance
minimale garantie et/ou du co&ucirc;t maximal de la configuration
que l'on consid&egrave;re. Il arrive parfois que le mat&eacute;riel
sur &eacute;tag&egrave;re ne permette pas d'atteindre les besoins
en performance minimale garantie que l'on souhaite obtenir et que
des syst&egrave;mes RISC co&ucirc;teux soient la seule alternative
viable. Pour une utilisation personnelle, je recommende une
configuration &eacute;quilibr&eacute;e et homog&egrave;ne du point
de vue de la performance globale (et maintenant d&eacute;brouillez
vous pour deviner ce que j'entends par &eacute;quilibr&eacute; et
homog&egrave;ne :-); le choix d'un processeur est une
d&eacute;cision importante, mais pas plus que celle du disque dur
et de sa capacit&eacute;, celle de la quantit&eacute; de RAM, celle
de la carte graphique, etc...</p>
</dd>
<dt><b>Q9.</b></dt>
<dd>
<p>Qu'est-ce qu'une am&eacute;lioration significative des
performances ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>Je dirais que tout ce qui est sous 1% n'est pas significatif
(pourrait &ecirc;tre d&eacute;crit comme marginal). Nous autres,
simples mortels, avons du mal &agrave; percevoir la
diff&eacute;rence entre 2 syst&egrave;mes dont les temps de
r&eacute;ponses sont distants de moins de 5% . Bien s&ucirc;r,
certains &eacute;valuateurs de performances - plut&ocirc;t de la
tendance int&eacute;griste - ne sont aucunement humains et vous
raconteront, en comparant 2 syst&egrave;mes dont les indices de
performances sont de 65.9 et de 66.5, que ce dernier est
indubitablement plus rapide.</p>
</dd>
<dt><b>Q10.</b></dt>
<dd>
<p>Comment puis-je obtenir une am&eacute;lioration significative de
performance &agrave; moindre co&ucirc;t ?</p>
</dd>
<dt><b>A.</b></dt>
<dd>
<p>Puisque le code source complet de Linux est disponible, un
examen attentif et une re-conception algorithmique de
proc&eacute;dures cl&eacute;s peuvent, dans certains cas,
d&eacute;boucher sur des am&eacute;liorations jusqu'&agrave; un
facteur 10 en terme de performance. Si l'on est sur un projet
commercial et qu'on ne souhaite pas plonger dans les
tr&eacute;fonds du code source du syst&egrave;me, <b>l'implication
d'un consultant Linux est n&eacute;c&eacute;ssaire</b>. Cf. le
Consultants-HOWTO.</p>
</dd>
</dl>
<h2><a name="s7">7. Copyright, remerciements et divers</a></h2>
<h2><a name="ss7.1">7.1 Comment ce document a-t-il
&eacute;t&eacute; produit</a></h2>
<p>La premi&egrave;re &eacute;tape a consist&eacute; en la lecture
de la section 4 "Writing and submitting a HOWTO" de l'index des
HOWTOs &eacute;crit par Greg Hankins.</p>
<p>Je ne savais absolument rien au sujet de SGML ou de LaTeX mais,
apr&egrave;s avoir lu divers commentaires &agrave; propos de
SGML-Tools, j'&eacute;tais tent&eacute; d'utiliser un paquetage de
g&eacute;n&eacute;ration de documentation automatique. Cependant
l'insertion manuelle de directives de formattage me rappelait
l'&eacute;poque o&ugrave; j'assemblais &agrave; la main un moniteur
512 octets pour un processeur 8 bits aujourd'hui disparu. J'ai donc
fini par r&eacute;cup&eacute;rer les sources de LyX, les compiler
et je m'en suis servi dans son mode LinuxDoc. Une association
chaudement recommend&eacute;e : <b>LyX et SGML-Tools</b>.</p>
<h2><a name="ss7.2">7.2 Copyright</a></h2>
<p>Le Linux Benchmarking HOWTO est plac&eacute; sous le
r&eacute;gime du copyright (C) 1997 par Andr&eacute; D. Balsa. Les
HOWTO Linux peuvent &ecirc;tre reproduits en totalit&eacute; ou en
partie et distribu&eacute;s en totalit&eacute; ou partiellement sur
n'importe quel support physique ou &eacute;lectronique, &agrave;
condition que ce message de copyright soit conserv&eacute; dans
toutes les copies. La redistribution commerciale est permise et
encourag&eacute;e; cependant l'auteur aimerait &ecirc;tre
pr&eacute;venu de l'existence de telles distributions.</p>
<p>Toute traduction (ndt : dont acte :-), tout travail
d&eacute;riv&eacute; ou p&eacute;riph&eacute;rique incorporant un
HOWTO Linux doit &ecirc;tre couvert par ce message de
copyright.</p>
<p>C'est-&agrave;-dire qu'il ne vous est pas possible de produire
un travail d&eacute;riv&eacute; &agrave; partir d'un HOWTO et
d'imposer des restrictions suppl&eacute;mentaires sur sa
distribution. Des exceptions &agrave; cette r&egrave;gle pourront
&ecirc;tre accord&eacute;es sous certaines conditions; veuillez
contacter le coordinateur des HOWTO Linux &agrave; l'adresse
sp&eacute;cifi&eacute;e ci-apr&egrave;s.</p>
<p>Pour &ecirc;tre bref, nous souhaitons promouvoir la
diss&eacute;mination de cette information par autant de canaux que
possible. Cependant, nous souhaitons garder un droit de copyright
sur les HOWTOs et aimerions &ecirc;tre averti de tout projet de
redistribution les concernant.</p>
<p>Si vous avez des questions, veuillez contacter Greg Hankins, le
coordinateur des HOWTOs Linux, &agrave; gregh@sunsite.unc.edu par
e-mail ou au +1 404 853 9989 par t&eacute;l&eacute;phone.</p>
<p>(ndt : pour cette version fran&ccedil;aise du document original,
il semble plus appropri&eacute; de contacter Eric Dumas,
coordinateur des traductions de HOWTOs dans la langue de
Moli&egrave;re par e-mail &agrave; l'adresse
dumas@freenix.EU.org).</p>
<h2><a name="ss7.3">7.3 Nouvelles version de ce document</a></h2>
<p>De nouvelles version du Benchmarking-HOWTO Linux seront mises
&agrave; disposition sur sunsite.unc.edu et sur les sites mirroir
(ndt : citons ftp.lip6.fr pour nous autres francophones). Ce
document existe aussi sous d'autres formats tels que PostScript et
dvi, et sont disponibles dans le r&eacute;pertoire other-formats.
Le Benchmarking-HOWTO Linux est &eacute;galement disponible pour
des clients WWW comme Grail, un butineur Web &eacute;crit en
Python. Il sera aussi post&eacute; r&eacute;guli&egrave;rement sur
comp.os.linux.answers.</p>
<h2><a name="ss7.4">7.4 Retour</a></h2>
<p>Les suggestions, corrections, et ajouts sont
d&eacute;sir&eacute;s. Les contributeurs sont les bienvenus et en
seront remerci&eacute;s. Les incendies (ndt : est-ce une traduction
acceptable de flame ?) sont &agrave; rediriger sur /dev/null.</p>
<p>Je serai toujours joignable &agrave; andrewbalsa@usa.net.</p>
<h2><a name="ss7.5">7.5 Remerciements</a></h2>
<p>David Niemi, l'auteur de la suite Unixbench, s'est aver&eacute;
&ecirc;tre une source in&eacute;puisable d'informations et de
critiques (fond&eacute;es).</p>
<p>Je veux aussi remercier Greg Hankins, le coordinateur des HOWTO
Linux et l'un des principaux contributeurs au paquetage SGML-tools,
Linus Torvalds et toute la communaut&eacute; Linux. Ce HOWTO est ma
fa&ccedil;on de renvoyer l'ascenseur.</p>
<h2><a name="ss7.6">7.6 Paravent</a></h2>
<p>Votre kilom&egrave;trage peut varier et variera sans doutes.
Soyez conscients que l'&eacute;valuation de performances est un
sujet tr&egrave;s sensible et une activit&eacute; qui consomme
&eacute;norm&eacute;ment de temps et d'&eacute;nergie.</p>
<h2><a name="ss7.7">7.7 Marques d&eacute;pos&eacute;es</a></h2>
<p>Pentium et Windows NT sont des marques d&eacute;pos&eacute;es
d'Intel et de Microsoft Corporations respectivement.</p>
<p>BYTE et BYTEmark sont des marques d&eacute;pos&eacute;es de
McGraw-Hill, Inc.</p>
<p>Cyrix et 6x86 sont des marques d&eacute;pos&eacute;es de Cyrix
Corporation.</p>
<p>Linux n'est pas une marque d&eacute;pos&eacute;e, et
esp&eacute;rons qu'elle ne le sera jamais.</p>
</body>
</html>