Documentation de Kronos 1.7a	Belfort le 5 Fvrier 2004

Avant toute chose:

Kronos utilise certaines librairies dynamiques pour fonctionner!

Ces librairies sont toutes bases sur le systme LDG de Dominique
Brziat, Arnaud Bercegeay et Olivier Landemarre

   - SCREEN.LDG pour tout le management d'image TC et les 
   transformations (Guillaume Tello - Olivier Landemarre)
   - IGIF.LDI Librairie dynamique LDG de chargement d'images GIF
   (Pierre Gougelet - Olivier Landemarre)
   - TINY_GL.LDG : Pseudo OpenGL lger de Fabrice Bellard (port 
   Atari : Olivier Landemarre)

Kronos a t compil  l'aide de GCC 2.8.1 compil par Christian Felsh
Mintlib 48, Mgemlib 40 (http://gemtos.free.fr) et libm (http://gemtos.free.fr)

Motif OpenGL de la pomme tir de Eureka de Francois Le Coat

Les images de raytracing ont t ralise par Frdric Boudet avec Inshape 3
sous MagicMac (partie modelage) et calcules sous MacOS en PPC avec le modeleur
natif PPC d'Inshape 3.

La version 0.80 alpha tait base sur le ressource de zbench de Zorro
certaines ressemblance continuent   transparaitre malgr un profond
remanaiement, les icones proviennent de ce ressource, la comparaison 
s'arrete l.

Ce logiciel est ralis en grande partie par un gnrateur de code
pour grer l'interface GEM.

Merci a Francois Le Coat et Eric Reboux pour leurs tests


Minimum requis  l'utilisation de Kronos:

Ecran: 640*400 Noir et blanc (en fait 640*480 pour voir
correctement toutes les boites, mais cela fonctionne
quand meme en 640*400)
Mmoire: autour de 4Mo de Ram
Systme : Tous (TOS, Magic, Mint, mulateurs)

Configuration conseille: Ecran true color!!!!!


Qu'est ce que Kronos?

Kronos tente de mesurer certaines performances
de votre ordinateur ou de votre systme.

A aucun moment les interruptions ne sont dsactives

Version 1.70a
Correction affichage des cartes acclratrices CT30 CT60 qui ne s'affichaients
pas et pour cause je me trompais de boite de dialogues -> peut etre risque de plantages
Ajout dans le fichier du rsultat mothercard perf

Version 1.04  1.70
Correction de 2 bugs dans tests CPU pouvant entrainer des rsultats errons
Detection des cartes acclratrices CT30 et CT60
Ajout de la valeur motehrcard perf -> donne une ide de la capacit de la carte mre 
(pas de vido pris en compte, utilisation mmoire, CPU et FPU)
Autres corrections ?? ne me rappel plus.


Version 1.03

Elimination d'un bug de reproductibilit, lors d'un 2eme
appel successif au test CPU, entrainant une erreur jusqu' 3%
lors du 2eme test.
Rcriture du test muldiv, utilise maintenant mulu et divu comme
calcul, les rsulats sont sensiblement plus rapides.


Version 1.02

Possibilit de plantage alatoire  cause de IGIF.LDI (pb
incompatibilit fonction standard C de la Mintlib avec les LDG)
Possibilit de plantage (non vrifi) pour cause de scratch registers
Plantage des fenetres des rsultats dtaills en TC 16 et 32 bits
lors de l'excitation en mouvement de la fenetre (si redessin  la
vole), problme de rentrance, rien  voir avec NVDI 5, merci
Zorro, maintenant en plus ca va un peu plus vite.

Correction du plantage au dmarage du test OpenGL (Hades 40 seulement!)

Amlioration de la prcision des mesures d'environ 0,2% (c'est pas 
grand chose mais bon pourquoi s'en priver!)

Correction de la formule du calcul de la frquence pour le
68020 et 68030, les autres procsseurs ne sont pas concerns.

Modification de la routine de calcul de frquence elle dpassait un peu les
256 octets de cache disponible du 68030 produisant un rsultat en deca de
celui prvu. L'opration se fait sur 120 instructions au lieu de 128.

Modification de la routine memowrite() destine  calculer la le taux de 
transfert de CPU vers mmoire, la valeur impose 0, provoquait pour le GCC
l'utilisation de l'instruction clr.l au lieu de move.l, plus lent sur les
processeurs 68000 au 68030

Modification de la routine Bitshift afin qu'elle puisse tenir dans le cache
68030 le 68030 est donc moins pnalise pour cette opration l'valuation
du shift est aussi plus correcte on n'a plus l'influence de l'accs mmoire.
La fonction s'value sur 120 oprations au lieu de 256

Modification de la fonction overlap() afin qu'elle puisse tourner dans le cache
du 68030 le  68030 est donc moins pnalis pour cette opration d'valuation
cette opration est plus correcte car on limine l'influence de l'accs mmoire.
La fonction s'value sur 120 oprations au lieu de 128




Version 1.0

La version alpha 0.80 prsentaient certains gros bugs
comme plantage en 256 couleurs entrelacs, TOS<4.0 etc...
Ces bugs sont normalement rsolus
Il reste MagicPC qui ne supporte pas le test disque et le test
de vitesse de transfert vido (cf Faq), les rsultats sous
mulateurs sont  prendre avec prcaution surtout si des parties
du systme sont directement implmentes sous la machines
hote (lecteurs locaux, VDI optimise principalement). Si 
l'mulateur est suffisament bon les tests CPU, FPU et opengl ne 
devraient pas poser de problmes car bas sur de l'mulation pure.

Sous Hades 60 TOS 3 + cache = copyback + AES 3, bus error pouvant
etre ratrap pour faire test, avec remplacement de l'AES par AES 4
le logiciel dans les memes circonstances fonctionne. Pour pouvoir
faire fonctionner les caches sont momentanment dsactivs lors du 
chargement des modules dynamiques, cela est fait uniquement dans cette
configuration.


Parties values par Kronos

Elles sont pricipalement de 5 sortes

Le CPU pour la partie entire du processeur, comprenant
l'acces  la mmoire principale, et des opration se faisant
entirement dans le cache.

Le FPU caractrisation du coprocesseur arithmtique, ces oprations
se faisant dans le cache du processeur si possible, pour les
machines sans ce coprocesseur, ce sont des routines d'mulation
qui sont utilises.

Divers tests de performance de transfert (STRam, vido)

Le VDI, pour caractriser la vitesse d'affichage de diverses 
fonctions du VDI

Acces disque, via les fonctions Fopen() Fread() Fwrite() du systeme

OpenGL, qui est un bon example de puissance de calcul en cas rel
du FPU et de la rapidit mmoire, car exigeant, c'est une utilisation
plus proche de la ralit d'utilisation conventionnelle d'un ordinateur

En plus de cela et  part en application TOS est fourni le portage
de "BYTEBench" le Bench de BYTE Magazine qui permet de comparer
les performances relatives  un PC. Ce  Bench a t compil  l'aide
de GCC 2.8.1 et peut comme toute compilation de source C, avoir
des rsultats divers selon le compilateur utilis pour le compiler.
Il a nanmoins de trs grandes qualits de prcision, meme si le test
peut sur une machine Atari s'avrer parfois trs long (dvelopp
pour un Pentium 90 en base). Les diverses versions de BYTEBench
ne font pas parti de Kronos par lui meme, je le livre l comme
complment intressant  Kronos. L'option de lancement de ce logiciel
 partir de Kronos a t dsactiv, il est prfrable de le lancer
 partir du bureau.


Fichiers rfrences pour les comparaisons

La rfrence pour la comparaison des rsultats est donn par DEFAULT.ABH
ce fichier peut etre remplac  votre convenance par un fichier .ABH 
de Kronos complet (tous tests effectus sans problme (donc pas test 
MagicPC)). Les " Result1 " et " Result2 " peuvent etre directement chargs
en fournissant DEFAULT1.ABH et DEFAULT2.ABH dans le rpertoire de Kronos.


Principe de fonctionnement de Kronos

Kronos est bas sur le principe, qu'il est ncessaire que le test
prenne suffisament de temps pour qu'il soit suffisament prcis.
La base de temps pour la plupart des tests est de 1 seconde sauf
pour les test OpenGL (20secondes) et disque (5 secondes). Tous
ces tests font un  nombre de cycle croissant jusqu'a obtenir le
temps voulu minimal sauf le test VDI pour des raisons
esthtiques! ou c'est le temps qui est vrifi  chaque itration.
Pour cette raison le test VDI est ralis en mode superviseur.
Le test OpenGL, pour des questions de temps de calcul ne fait intervenir
le recalcul du nombre de cycle que pour le 1er test en mode plein avec 
affichage sur une base de 20 secondes. Les autres tests OpenGL se feront sur
ce nombre d'itrations.

L'ensemble des tests sont regroups sur divers librairies dynamiques
ce qui permet le cas chant d'utiliser une version optimise pour
le processeur hote (principalement utile pour le FPU et OpenGL). Les
sources des divers tests sont fournis, ce qui pourra vous permettre
de les recompiler  votre guise (sauf OpenGL et vitesse transfert video).

La plupart des tests sont raliss en C sauf cas particulier
ou le C n'est pas a meme de faire le code dsir.

Aucune intrruption n'est invalide, ce qui donne une utilisation
raliste du bench. Malgr tout les rsultats sont non significativement
different des rsultats sans les intrruptions, il est recommand tout 
de meme de ne pas bouger la souris pendant les tests, car cette intrruption 
est trs lourde en temps .

De la meme manire sur systme multitache il est recommand de
ne pas faire les tests si un logiciel en mmoire est succeptible
d'absorber de faon non ngligeable du temps CPU.

La machine est cense etre utilise dans les conditions optimales
de vitesses (comme caches activs etc...)


Les tests sont corrig pour ne tenir compte que de la partie
efficace du test (on ne mesure pas les boucles!), grace  un code
suffisament long entre chaque saut rendant le saut peu important
au regard du test, mais aussi en estimant le temps utilis par
le test dans les oprations de boucle (cela permet de relever
lgrement les rsultats, mais a pour inconvnient de doubler
l'erreur de mesure du temps, donc l'erreur de mesure du test, cela
reste malgr tout assez faible). Les tests VDI drogent lgrement
 la rgle pour agrmenter le test les couleurs peuvent changer
en cours du test, ce changement de paramtre est ngligeable
par rapport aux temps des tests, car ces changement interviennent
trs peu souvent en regard du nombre d'appel  la fonction, de plus
ces changements sont trs rapide par rapport aux fonctions testes.


Principe technique des tests

L'ensemble des tests  l'exception des tests VDI (voir plus bas)
est bas sur une boucle finie de nombre de test (gnralement faible)
le temps coul est mesur, le nombre de tests est corrig puis le test
refait et cela jusqu'a ce que le temps utilis soit suffisament grand
pour obtenir une prcision suffisante. Chaque boucle est prcde
d'une attente de synchronisation, par attente du timer 200Hz, cela
afin d'assurer une meilleure reproductivit des rsultats.


TESTS CPU

Le source du test CPU est donn dans le fichier CPU.C
Ces tests permettent d'valuer principalement les vitesses de transfert
en memoire (TTRam prfrentiellement), ainsi que la ralisation
de certaines oprations succeptibles de s'ffectuer principalement dans le 
cache si il y en a un.

Du test "rawpower" est dduit la frquence suivant les informations du
cookie _CPU pour connaitre le processeur. A la base ce mode de calcul
est valide pour un processeur piplinis, avec cache interne  vitesse
du CPU mais sans mode superscalaire. C'est le cas typiquement du 68040
du rsultat "rawpower" se dduit directement la frquence puisque cela 
revient a calculer le nombre d'instrutions par unit de temps. Dans le cas
d'un 68060 le processeur peut etre mis en mode superscalaire, sur ce type
de test il est succeptible de faire passer 2 instructions par clock, la 
frquence est donc le nombre d'instructions ralis par unit de temps divis
par 2, si le mode superscalaire est valid, ce qui est test dans Kronos.
Pour un processeur non piplinis, le nombre de cycle pour raliser un 
move.l d0,d1 est de 4 cycles pour un 68000, il faudra donc multiplier le rsultat par 4
sur un 68020  ou 68030 il faut 2 cycle pour xcuter l'instruction donc
ce sera multipli par 2.
Cette frquence est donne  titre indicatif elle peut ne pas etre dans 
certains cas reprsentatif du processeur utilis (mulateurs par exemple
mais aussi vu le mode de fonctionnement des procsseurs, la frquence
n'est pas proportionnelle  la puissance du processeur!).

TESTS FPU

Le source du test FPU est donn dans le fichier FPU.C
Attention, les fonctions log, sqrt, sin et cos sont dpendantes de
la librairie mathmatique employe, celle utilise est celle employe
par netbsd et est le port de cette librairie disponible sur le site
http://gemtos.free.fr. Les double transmis aux diverses fonctions
doivent etre au format IEEE 64bit (donc incompilable par PureC de manire
correcte)

Cette librairie value, la multiplication, l'addition, le calcul d'un log,
d'un sinus et cosinus, de la racine care et enfin la transformation
d'un double vers un float et visversa.

On notera que sin, cos et sqrt, font partie des routines du 68881 mais qu'elles
ont disparues du 68040 et suivants.

sin, cos et log ne sont gnralement pas utilises de manire intensive par les
logiciels, car les transformations se font par calcul matriciel ou ces valeurs
trigonomtriques sont une fois pour toutes calcules pour etres mises dans
la matrice de transformation, il est par contre ncessaire que la multiplication
et l'addition soient trs rapides. sqrt peu aussi avoir une importance non 
ngligeable, car cela peut servir  normaliser les vecteurs (trs utilis en 
raytracing).

TESTS STRam - video

Le source de ce test est partiellement donn. En effet, les mesures
de transfert de STRam processeur sont les memes que pour le test CPU
et reprend la librairie dynamique associe. Le test avec la video
fait intervenir la fonction VDI vro_cpyfm() de memoire video  mmoire
vido, de la mmoire centrale (TTRam souhait) vers la video et inversement
cette partie n'a pas t intgr dans une librairie dynamique par flemme!
Il n'y a donc pas le source.


TESTS VDI

Le source du test VDI est donn dans le fichier VDI.C
Ce test est un peu particulier, car la boucle d'attente est donne
par rapport  une attente du timer 200 Hz cela afin de ne pas avoir
d'effets parasites visuel dsagrable pour l'utilisateur. Les tests
ont t concus de telle manire qu'ils soient  la fois dmonstratifs
mais aussi peu agrssifs que possible  observer, cela grace 
particulirement  un nombre de changement de couleurs peu lev par
rapport  certains logiciels, ce qui tombe bien puisque ce n'est pas
le changement de couleur qui nous intresse!

On peut aussi que le test vgtext() ne correspond pas  l'appel de
cette fonction mais celle de vgtext16()! Ce choix est motiv par
le fait que dans le VDI vgtext() n'existe pas, celle ci est un binding
spcifique  la fonction vgtext16(). En effet le VDI ne comprend
que les caractres sur 16bits (unicodes), par facilit nous utilisons
un codage sur 8 bit, la fameuse table des codes ASCII. vgtext() transforme
la chaine en caractres 8 bits en une chaine caractre 16 bits avant
d'appeler vgtext16(), les logiciels les plus rapides utilisent directement
vgtext16() pour ne pas avoir  passer par la conversion, l'ayant eux meme
prtabli.

TESTS OPENGL

Le source du test OpenGL est donn dans le source APPLE.C
Ce test n'est pas ralis sous la forme d'une librairie dynamique
comme les autres tests vous ne pouvez donc pas la remplacer! Cela
par simple faineantise de ma part!
Il fait strictement 2 fois le meme test, mais l'un avec l'affichage
(et donc les transformations de 24bits (image cr par le module
OpenGL) et le format physique de votre carte vido), l'autre sans
cela permet d'estimer par la meme ce que coute les transformations
vido.
Le test OpenGL est  mon sens le plus intressant de l'ensemble des
tests fait pour Kronos, en effet ce test est suffisament lourd et complexe
pour avoir une bonne ide de la puissance de la machine tester. Il
met  contribution fortement l'accs  la ram (TTRam prfrentiellement)
et le FPU.
Autant par demonstration que par plaisir, le mode plein avec transformation
vers cran a t prolong cela afin d'obtenir au minimum de 20 secondes sur
ce test, le nombre de cycle des autres tests sont ensuite identique
 ce premier test.

TESTS DISQUE

Le source du test Disk est donn dans le source DISK.C

Nous avons dans le cas des disques  mesurer un systme mcanique par dfinition
lent  ragir. Le temps ncessaire  la ralisation d'un test srieux est
plus long, un temps minimal de rfrence de 5 secondes  t choisi.
Ce test utilise pour une compatibilit maximale les fonctions classiques
GEMDOS utilises par les programmes, elles sont donc inaptes  donner la
vritable vitesse d'un disque! Par contre ce sont ces memes fonctions
utilises par les logiciels, elles sont donc pertinantes  tester pour
se faire une ide de la rapidit du couple systme - disque.
Vous pourrez observer une grande dispersion des rsultats entre diverses
machines qui ne rvlent en rien leur classement, cela est normal!
Ce test prsente 2 familles de tests, les tests orient transfert, ces test
prsentent gnralement une plus grande constance que la seconde catgorie
orient vitesse d'acces au systme de fichier, en effet dans ce cas dpend
largement de votre systme, certains ne prsentent aucun cache d'autre si
les rsultats sont donc impossible  comparer, mais par contre permet de ce
rendre compte de quel type de mthode est utilise. Ainsi ne vous alarmez pas
de voir que votre super Hades 60  des rsultats on ne peu plus mdiocre
par rapport  un MagicMac, l'un ne gre aucun accs cache l'autre si! Les
rsultats sont totalement incomparables.
Tests orient vitesse de transfert: Ces tests sont bas sur les fonctions
Fread() et Fwrite(), les blocs ecrits et lu sont de taille de 1Mo, dans un 
fichier si possible de 16Mo et au minimum de 4Mo. Un fichier plus petit que 
16Mo peut prsenter des rsultats de transfert plus faibles, cette taille
a t choisie comme un compromis entre taille et stabilit des rsultats.
Ces rsultats peuvent etre fortement altrs par le niveau de fractionnement
de votre disque dur. Ces rsultats peuvent aussi etre fausss si la taille
du fichier est trop petite par cache du fichier en mmoire (16Mo ne semble
pas suffisament important pour assurer la non tenue dans le cache sous les
gros PC avec Windows!)


Utilisation du logiciel

Kronos reste assez simple d'utilisation qui n'appelle pas de
commentaires particuliers, sauf a mon avis deux points....

L'affichage peut varier selon votre configuration mmoire et video ainsi
si vous avez suffisament de mmoire vive, vous verrez apparaitre un bureau
en fond d'cran, avec une jolie image raytrace. De meme le fond des zone
de rsulats dtaills sous une video 24 ou 32bits prsenteront le meme
motif que le bureau mais assombri.

La sauvegarde des rsultats est possible  tout moment et donc les rsultats
inscrits peuvent etre partiels, ces rsultats ne pourront pas etre utiliss
comme fiche de rfrence (fichier DEFAULT.ABH) sous peine d'une erreur processeur
par division par zro.

FAQ

Quelle est la diffrence entre Kronos et les autres logiciels
de ce type?

Certains logiciels de ce type sont ( ma connaissance) sur Atari bass sur
le schma, qui consiste  faire une boucle avec un nombre 
d'itrations connu et fixe avec ce que l'on veut tester au milieu.
Cela n'est pas idiot du tout mais cela suppose gnralement que l'on
va tester toujours des machines de puissance assez similaires. Bref
difficile de tester des gnrations diffrentes d'ordinateur, car
si la nouvelle gnration va trop vite alors le test sera trs court
en temps et la prcision de la mesure deviendra faible. Si on refait
un nouveau programme juste en augmentant le nombre d'itrations
pour le test alors sur un ancien modle le test deviendra trs long.
Bref difficile d'avoir par se principe un programme qui puisse comparer
plusieurs gnrations d'ordinateurs.
Kronos n'est pas bas sur ce principe, il est bas sur le principe
de l'attente d'un temps coul et dtermin, tant que ce temps n'est
pas coul le test est ritr, le compteur incrment (ce qui est la cause
de dysfonctionnement sous MagicPC par exemple).

L'autre problme provient gnralement de la prsentation des rsultats
ou les pourcentages affichs sont parfois calculs d'une manire
impropre au test de performances, c'est par exemple le cas de gembench
qui fait une moyenne arithmtique, sur les pourcentages des divers tests.
Cela n'est pas correcte, cette mthode amplifiera les performances
des tests les plus efficaces cela d'autant plus que les rsultats
sont dispercs par rapport  la rfrence (cas gnralement observ
entre un "vrai" Atari et un mulateur (dans certains cas trs rapide
dans d'autres nettement moins)). Le temps utilis pour faire l'ensemble
du test est nettement plus reprsentatif, le pourcentage par rapport
au temps de rfrence donne donc un rsultat plus correcte.

Note technique: Sur un point de vu pur de prise de mesure de temps le mieux
que l'on puisse esprer de faon fiable sur les diverses plateformes Atari
est le timer 200hz, la prcision de mesure sera donc de +-1/200 de seconde
pour 1 seconde de test nous avons donc une prcision de 1% ce qui est largement
suffisant pour les tests qui ne ncessitent pas de mise en route mcanique
(tout ce qui est soft donc tous les tests sauf les disques), nous avons  
corriger les boucles ralises pour faire le test, les erreurs s'accumulent,
au pire nous avons donc 2% d'erreur si notre test dure au moins 1 seconde.
Imaginons un test sous forme d'une boucle de taille fixe, qui serait de 1 seconde
sur un Milan 40 sur le FPU, dans le cas d'un nouvel ordinateur bien plus
puissant comme l'Atlantos (coldfire avec FPU 60), que va t'il se passer?
Probablement la machine ira 10 fois plus vite, donc la boucle s'xcutera en
0,1 seconde ce qui fera une erreur de 20%! Les tests de ce genre sont  terme
de toute facon non fiable.



Si je compare la reprsentation "time consuming" et "Arithmetic average"
les rsultats sont parfois opposs, est ce un bug?

Non ce n'est pas un bug c'est juste l'illustration de la question prcdente
le rsultat "Arithmetic average" n'a pas de ralit par rapport  la 
performance. Si tous les sous tests d'un meme test, ont exactement
le meme ratio par rapport  la rfrence alors, les deux modes de
calculs seront exactement en accords (%aa = 1 / %tc = %speed). Si par exemple
certains sous tests donnent quelques pourcents alors que d'autres donnent
quelques centaines de pourcents (cas raliste rencontrs en comparant
certains mulateurs avec de vraies machines (tests disque principalement))
alors les rsultats pourront etres en total dsaccords! Bien sur la
moyenne arithmtic ne doit pas etre prise en compte, cette reprsentation
n'est l que pour prsenter les dfauts de la mthode utilis par certains
logiciels.


Le test de performance du disque ne fonctionne pas sous MagicPC,que dois
je faire?

Rien, cela est malheureusement normal, vu les conditions du test. MagicPC
est en cause (ou peut etre plutot Windows!).
La cause de ce dfaut est connu, Kronos se base sur l'intruption timer
 200Hz, il est donc ncessaire que cette intrruption fonctionne  peu
prs correctement lors des tests. Lorsque Kronos fait appel au disque
(dans le cas du filesystem de Windows), Windows prend la main, les intruptions
sont perdues pour MagicPC (qui doit assurer ce service par un thread
qui n'est plus assum par Windows), Kronos boucle donc sans fin, un
vnement qui n'arrive pas. Ce meme problme  t constat sur les
toutes premires versions de Windows ARANYM et sur le filesystem de
Windows (cela fonctionnait bien sur le disque virtuel), alors que
la version Linux ne prsentait pas ce dfaut. Dans ce cas prcis c'est
le thread pour grer l'intruption timer qui n'tait plus appel par
Windows lors des appels disque (et dans une moindre mesure VDI). Cela
a t corrig en forcant l'appel au thread timer aprs les appels
systmes WIndows pour permettre la ralisation des intruptions du MFP
virtuel.
J'en suis dsol mais je ne modifierais pas ma facon de faire mon test
disque, pour rester dans la logique du logiciel. De plus si je venais
a mettre une boucle de taille prdfinie et  prendre le timer 200hz
comme mesure alors le rsultat serait de toute manire rron, l'autre
solution serait de prendre l'horloge systme, mais cette horloge est
trs imprcise, il faudrait alors faire un test excessivement long
pour obtenir un rsultat avec une erreur acceptable. Dans le cas prcis de
MagicPC meme cette solution ne fonctionne pas a priori, MagicPC ne semble
pas s'enquerir de l'heure du PC hote pour obtenir son horloge (ou alors
pas systmatiquement lorsque l'on appel l'heure systme).
Sur un mulateur avant de pouvoir dterminer si le test est correcte, vrifiez
au moins que l'horloge systme ne retarde pas! Cela peut apparaitre sur 
des machines peu puissantes.

Vous donnez un taux de transfert du disque en criture et lecture
est ce fiable?

Non pas vraiement! Kronos pour etre au maximum compatible
utilise bettement Fread() et Fwrite() du systme, de la manire
la plus correcte possible, mais le rsultat dpend largement du morcellement
de votre disque dur. Un test en lecture est envisag dans une version
ultrieure (pas l'criture  cause des risque encourus!), qui accederait
directement au hard. De meme actuellement sur filesystem Windows le
cache disque est d'une telle ampleur que le test ne mesure que les
performances de transfert vers le cache! donc extremement rapide!
Rassurez vous sur un vrai TOS il n'y a aucun cache gnralement,
les accs multiples s'en ressentent beaucoup! Avis aux programmeurs
dans certains cas cela peut ralentir ennormment vos softs!


Que pensez vous du test du BogoMips?

On m'a dit que ce n'est pas un test mais un moyen de calibrage, je ne
comprend pas bien. En tant que bench je trouve cela stupide, c'est
un boucle c'est tout, sans rien dedans, le rsultat dpend du compilateur
(sauf si on le fait en assembleur). Si Je me refre au code officiel
en C qui est un for(), alors je n'ai pas implment le Bogomips. Si c'est
implmenter une boucle sur elle meme de maniere la + efficace possible
alors j'ai implment le test, car j'ai intgr le code assembleur
du PureC pour un while() (sur GCC le for() et le while() donnent
le meme resultat, qui est moins bon que le code while() du PureC). Je
me suis rang de l'avis de plusieurs personnes et ai surtout t influenc
pour etre en correspondance avec le resultat du test de Mint. Z


Kronos marchera t'il sur la CT60

Pas test mais il n'y a pas de raison  priori.

Kronos marchera t'il sur la machine coldfire Atlantos?

J'espre!, mais attention il n'y a pas de version optimise
pour le coldfire, il faudra peut etre recompiler les LDG
de test pour optenir les meilleurs rsultats possible, mais
j'en doute vu les tests employs. La frquence  de bonne chance
d'etre errone


Zbench propose le coldfire mais pas Kronos, allez vous faire vous aussi
une version coldfire?

Non, pas tant que la machine ne sera pas sortie, je ne pense pas avoir
 changer en fait grand chose, beaucoup de test CPU, VDI, DISQUE et 
en partie FPU ne devraient pas avoir de problmes particulier le code
mul devrait etre null ou trs rduit (dans le FPU).
Le code OpenGL lui ne sera pas des plus efficace pour la partie
framebuffer qui est sur 24bits donc utilisant des acces par octets, la
ca ralentira la chose de beaucoup, je ne peux changer le format du frame
buffer sans avoir  recoder tout SCREEN.LDG. La partie calcul devrait
moins souffrir si le FPU est bien compatible avec un 68060.


La frquence dtecte est trs trange sur MagicMac et n'est pas raliste, 
pourquoi?

La frquence n'a pas pour but d'etre raliste en terme de performance, elle
doit donner des rsultats si possible en correspondance avec votre processeur
mais pas sur un mulateur, ca n'a pas vraiement de raison d'etre.
Sous PowerMac les rsultats sont hallucinants j'en convient, ainsi une machine
a 300Mhz donne un rsultat d'environ 1Ghz! Il y a 2 raisons a cela:
 - l'mulateur Apple est trs particulier et optimis avec une sorte de 
 cache
 - La comparaison se fait par rapport a un 68020, selon le type de processeur
 le rsultat est corrig suivant ses possibilit physique. Ainsi le test de frquence
 est bas sur des move.l entre deux registres. Sur un 68040 qui possde un pipline
 on peut considrer que les instructions comme si elles s'ffectuaient en 1 cycle.
 Sur un 68020 ce n'est pas le cas et les oprations se feront en 4. Du coup
 si la frquence est directement dduisible pour le 68040 il faudra multiplier
 par 4 pour un 68020, ce que Kronos fait donc sous MagicMac et PPC.
 
Sous Aranym si je suis en TOS ou sous Magic la frquence est 4 fois suprieure
 celle sous TOS, pourquoi?
 La rponse est donne  la question prcdente, sous TOS le cookie _CPU indique
un 68040, alors que sous Magic (qui se trompe) ce cookie indique un 68020. De la
meme manire sous MagicPC le cookie indique un 68000, la frquence sera donc
systmatiquement multiplie par 4, par rapport  Aranym sous TOS (en supposant
que Aranym soit de meme rapidit que MagicPC ce qui n'est pas le cas actuellement
pour le CPU)


Conclusion:

Un test de performance c'est bien et marrant, mais ca ne remplace pas
l'utilisation relle, qui a besoin d'un coprocesseur rapide pour
faire du traitement de texte ou  de l'internet? Alors que le raytracer
fou lui n'aura d'yeux que pour cela!

Je vous souhaite un bon moment d'amusement avec Kronos

Modifications 1.71 27 janvier 2005

gl_flush() en fin de dessin frame opengl (pas d'infleunce temps avec Tinygl)
Test de limite de temps des test CPU pour ne pas risquer de boucler  l'infini (cas possible
du test rawpower (frquence CPU) sous emulateur avec JIT (Aranym))
Utilisation de ldg_open() en place de ldg_load()
Affichage des barres retaill en fonction du max de chaque type de test et pas
en fonction du max de l'ensemble des tests


Olivier LANDEMARRE (olivier.landemarre@utbm.fr)
