Une page dédiée à la version 0.98 car j'estime que cette version est une mise à jours majeure sans apporter pour autant de grosses nouvelles fonctionnalités. Après les versions 0.96 et 0.97 qui avaient été des versions avec déjà de gros changements internes visant à faire mieux fonctionner MyAES, à réduire l'utilisation mémoire, fonctionner sur les résolutions inférieures à 256 couleurs, parfois à accélérer le noyau et parfois malheureusement l'inverse. Voici donc la version 0.98, une révision en profondeur du noyau de gestion des évènements qui vise essentiellement à sa performance. Pour y parvenir de très nombreux tests et benchs ont été réalisés, si les versions précédentes se situaient approximativement au niveau d'un TOS ou NAES, il était encore assez loin de XaAES et encore plus loin de Magic. Le but avoué est clairement de rivaliser avec ces 2 AES en terme de réactivité, c'est ce que nous allons voir. Bien sûr la version 0.98 apporte son lot de correction de bugs que je ne listerais pas, pour beaucoup pour l'affichage, mais aussi quelques nouveautés.

	Support de la création de thread par l'AES à la mode Magic via shel_write() c'est donc à ma connaissance le premier AES supportant les threads sous Mint, je rappelle que ce thread partage la zone mémoire du client, il possède sa propre pile gérée par l'application appelante, l'application appelante et le thread fonctionnent de manière concurrentes comme 2 programmes indépendants, il est donc très différent des fonctions gemdos Pfork() et Pvfork() fournies par Mint, il est donc impératif d'avoir un code "safethread" et d'utiliser des librairies capables de cela si le code utilisé éventuellement peut être utilisé de manière concurrentes comme les fonctions mt_aes pour appeler VDI et AES
Option "app_single" est une option qui peut être utile avec les applications assez anciennes qui aiment bien accaparer la souris et ont généralement été conçues sous TOS, cette option permet de n'avoir que cette application à l'écran comme sous TOS, cette option est à mettre typiquement dans le fichier app_conf.cnf suivi du nom de l'application à gérer ainsi exemple "app_single WORDPLUS" l'application wordplus sera lancée dans ce mode, des applications de ce genre on peut citer Pure Pascal, Degas Elite, Gembench (pour avoir une comparaison avec le TOS plus fidèle, gembench pouvant fonctionner sans problème majeur dans un environnement multi application)
	Option "focus_priority", permet de choisir entre 2 modes de fonctionnement de l'AES, si la valeur est fausse alors aucune préférence n'est faite entre les applications la réaction est équivalente, ce mode est similaire aux autres AES, si la valeur est vraie alors il y a priorité à l'application qui est en premier plan, les autres applications sont ralenties de manière volontaire dans l'AES (en dehors la priorité n'est pas modifiée), MyAES considère que l'application au premier plan doit avoir le maximum de ressource disponible et qu'une tâche de fond n'a pas à charger excessivement le système. Par défaut cette variable est vraie, celle ci peut être défine dans myaes.cnf : "focus_priority=true"

MyAES 0.98 corrige un certain nombre de bugs, mais améliore surtout la rapidité:

• Principalement rapidité du noyau qui gère les évènements, il a été profondément modifié, ce qui a entrainé une longue absence de mise à jours pour stabiliser ce nouveau noyau, sur certains cas extrêmes il peut être plus de 50 fois plus rapide que la version précédente et de manière plus courante environ 2 fois, l'idée des améliorations est principalement de ne pas avoir de ralentissement important par l'AES pour la gestion des évènements lors d'une utilisation intensive typiquement pour des jeux ou style lecteurs vidéo GEM, même si à mon avis le meilleur moyen est l'utilisation d'un thread dédié via shel_write(MT_THREAD....) jusque là uniquement supporté par Magic et présent dans cette version. J'ai créé quelques tests spécifiques pour pouvoir étudier ce noyau, ces résultats sont présentés un peu plus loin. MyAES est probablement l'AES le plus rapide dans ce domaine sur 68030 dès 32Mhz, 68060 et plus rapide en fait il se démarque d'autant plus que la machine est rapide, je n'ai pas pût faire de comparaison sur machine 68000 8Mhz faute de machine de configuration pour test, il sera de toute façon sensiblement plus rapide que TOS ou Emutos, à noter cependant que son utilisation n'est pas anodin, MyAES se comporte comme un serveur en grande partie ce qui veut dire qu'une petite partie des ressources sont pris même si l'AES n'est pas sollicité, si cela reste modeste sur un 68060 on note que plus la machine est modeste plus cette proportion est importante ainsi on peut estimer qu'en terme de perte de puissance lié à ce mode se situe aux alentours de 7% sur un 68030 at 32Mhz  et de l'ordre du pourcent sur un 68060.
  
• Légère accélération dans la routine d'affichage des objets GEM (objc_draw), selon mes tests il est équivalent aux meilleurs AES dans le domaine mais il est vrai qu'une grande partie du temps d'exécution est réalisé dans la VDI dans ce cas. 
  

    Afin de réaliser les tests, une nouvelle version de Kronos a été publiée, il intègre l'affichage d'une boite de dialogue GEM via objc_draw() et 3 tests event_multi() sensés retourner immédiatement, l'un des tests est d'ailleurs la méthode utilisée officiellement par SDL pour le driver GEM et utilise simultanément appl_write et evnt_multi.
    Si des valeurs manquent c'est que l'AES n'a pas été testé sur la machine, ne rien y voir d'autre, je tiens particulièrement à remercier 2 personnes pour ces tests : Mr Piotr Mietniowski qui possède un nombre considérable de configurations différentes (CT60, Hades 60, TT30) et Mr Guillaume Tello (TT30 et CT60), j'ai noté des différences considérables de vitesse entre le TT de Guillaume et Piotr, les configurations sont très différentes, sur chaque graphique j'essaye de ne présenter les résultats que d'une machine à la fois pour ne pas avancer des résultats qui pourraient amener des conclusions erronées, pour ce qui est des configurations de Mint, seul l'AES change, lorsqu'il s'agit de Magic je ne peux pas garantir que la configuration soit totalement équivalente, j'ai eu des résultats au fil du temps qui peuvent se révéler fluctuant, j'ai gardé par défaut dans le cas de Magic les résultats les meilleurs.
    J'ai compilé MyAES avec 3 compilateurs C différents (PureC, GCC 3 et GCC 4), suivant la machine, la configuration chacune de ces 3 configurations peut se révéler plus rapide que sur les autres, sur Aranym JIT typiquement la version GCC 3 sera la meilleure suivi de PureC et GCC 4, chez Piotr sur toutes ses machine GCC 4 se révèle le plus efficace, alors que sur le TT de Guillaume avec Mint 1.12 la version PureC est plus rapide et sur son autre machine avec Mint 1.19 GCC4 se comporte mieux, le mieux encore est de tester avec Kronos, mais dans tous les cas MyAES 0.98 donne d’excellents résultats.

‣ Test affichage objc_draw()

    Ce test comptabilise le nombre de boites de dialogue affichées par seconde, la boite de dialogue affichée est celle ci dessous.

‣ Comparaison objc_draw()

   
Test obj_draw, nombre de boites de dialogue affichées par seconde

    D'un AES à un autre les différences de vitesse d'affichage restent assez faibles sur les machines à l'affichage le plus lent et plus variables sur les machines à affichage plus rapide sans pouvoir tirer de conclusion définitives. La plus grande partie du temps passé lors de l'affichage se situe dans les routines VDI non modifiées par l'AES. MyAES se situe toujours proche du meilleur résultat, sur CT60 c'est le plus rapide (pas de référence avec NAES), sur TT il fait jeux égale avec NAES et Magic, sur Hades 60 le TOS est le plus rapide, XaAES est légèrement en retrait, le TOS selon la machine et la version a des résultats plus variables. Notez que MyAES 0.97 et 0.96 n'affichent pas correctement les couleurs des icônes monochrome si elles ne sont pas en noir et blanc.

‣ Comparaison temps de réponse evnt_multi avec le timer demandé à 0



    Ce test affiche le nombre d'appels réalisable par seconde en sollicitant la routine evnt_multi avec une limite timer de 0 ms + recherche message.

Test evnt_multi(MU_MESSAG+MU_TIMER(0)), nombre d'appels par seconde

    Magic était jusqu'à présent la référence sur la vitesse de traitement de vérification de la présence d'un message avec demande de retour immédiat si il n'y a pas de message grâce à l'imposition d'un évènement "timer" de 0ms. On observe sur TT que MyAES 0.98 est très légèrement plus rapide que Magic, sur 68060 l'écart se creuse beaucoup. On voit l’énorme différence entre la version 0.98 et les précédentes versions particulièrement peu efficaces aux performances de l'ordre du TOS voir moins bien. XaAES n'est pas particulièrement performant sur ce test même si il est tout de même sensiblement supérieur sur 68060. NAES (seulement testé sur TT) est particulièrement lent, bien plus lent que le TOS, c'est sans doute la raison que la version GEM de SDL a renoncé à cette méthode.

‣ Comparaison temps de réponse evnt_multi avec click souris relâché + timer 0 + recherche message

    Normalement si un click souris à l'état relâché est demandé alors la routine evnt_multi doit revenir si la souris est bien dans cet état, il y a un certain intérêt pour ajouter cette demande comme nous allons le voir ci-après sur les résultats. Ce test affiche le nombre d'appels réalisable par seconde.
    Ce mode de fonctionnement est utilisé par la librairie SDL que j'ai patché, les sources de cette version sont disponibles sur http://ol.lutece.net/ .

Test evnt_multi (Mu_MESSAG+MU_TIMER(0)+MU_BUTTON), nombre d'appels par seconde

    Aussi curieux que cela puisse sembler XaAES et surtout NAES voient leurs performances s'améliorer par rapport au test précédent tandis que MyAES 0.98 et Magic les voient légèrement se réduire mais ces deux AES restent sensiblement plus rapides surtout MyAES 0.98 sur 68060

‣ Comparaison temps de réponse de l'AES sollicité par appl_write + evnt_multi (MU_MESSAG + MU_BUTTON)

    Ce test affiche le nombre d'appels réalisable par seconde lorsque l'application s'envoie un message à lui même et demande à la suite de rechercher ce message par evnt_multi(). Ce mode de fonctionnement est réalisé par la libraire SDL en version officielle écrite par Patrice Mandin.

Test appl_write + evnt_multi(MU_MESSAG+MU_BUTTON), nombre d'appels par seconde

    Au regard des résultats je ne vois pas trop l'intérêt d'une telle méthode, MyAES 0.98 et Magic sont sensiblement plus performants mais voient tout de même leur performance divisé par 2 environ, comme on peut le voir sur l'image ci dessous:

Comparaison des 3 méthodes d'utilisation de evnt_multi, nombre d'appels par seconde

    MyAES propose des versions identiques compilées avec 3 compilateurs différents (PureC, GCC 4 (seul capable de produire un code natif pour processeur coldfire) et GCC 3), à la suite de ces tests et de certains autres, le choix n'a rien d'évident comme on peut le voir sur l'image suivante, il est possible que certaines partie de l'AES préfèrent un compilateur plutôt qu'un autre en terme de performance, ici nous nous concentrons sur la partie évènement au regard de la réactivité.
    Ici nous comparons le test evnt_multi avec un timer à 0 sur deux TT différents dans des configurations différentes, suivant le cas aucun compilateur ne domine, les différences si elles ne sont pas négligeables restent généralement d'un impacte relativement limité.

Test evnt_multi(MU_TIMER+MU_MESSAG), comparaison des compilateurs, nombre d'appels par seconde

 MyAES se présente comme un serveur on peut donc se poser la question de la charge de celui ci sur la réduction de capacité de calcul de la machine, tout comme l'utilisation d'un système multitâche comparé à un système non multitâche comme le TOS. Pour tenter de cerner ce problème nous allons utiliser un résultat de Kronos qui calcule une scène Opengl en offscreen 24 bits et purement 68000, pendant ce calcul, il n'y a aucun accès au système par Kronos, si  nous comparons les résultats nous devrions avoir une idée de cette charge.

Comparaison de la performance du calcul suivant la configuration utilisée

 Sous 68060 que ce soit sur CT60 ou Hades 60 les résultats sont très proches entre les configurations de l'ordre de +-1.5% d'écart entre les système multitâches, sur l'Hadès 60 les résultats du TOS sont supérieurs à MyAES 0.98 d'environ 6% (peut être dû aux services en route sur la configuration Mint).

 Sur TT 32Mhz avec Mint 1.19 ou Magic, MyAES 0.98 est sensiblement plus lent de 8 à 13% par rapport XaAES ou Magic alors que sous Mint 1.12 le TT semble largement plus rapide et MyAES est environ 4% plus rapide que le TOS. Enfin sous l'émulateur Hatari avec une Emulation STE à 8 Mhz MyAES 0.98 avec Mint "Helmut" perd 22% de puissance comparé au TOS par contre si on utilise un Mint 1.19 la chute est de 50%!.
 Une petite recherche nous a permis de déterminer un paramètre important pour revenir à une vitesse équivalente à la version Mint "Helmut", il suffit pour cela de définir dans mint.cnf : KERN_SLICES=12 (gère le temps entre les changements de tâche)  à ce moment là les résultats sont très proches de la version "Helmut", le temps réel reste tout à fait utilisable, cette même modification permet sur TT avec Mint 1.19 d'avoir une disponibilité équivalente à Magic, ce point reste à étudier lors d'une prochaine version pour les configurations modestes, en attendant vous pouvez utiliser ce paramètres si vous voulez utiliser MyAES 0.98 sans perdre en performance.

Impacte du paramètre KERN_SLICES sur la performance calcul de l'ordinateur

On peut noter aussi qu'un système multitâche ne provoque pas forcément un ralentissement par rapport au TOS et que parfois les performances sont améliorées!

 Je pense que sur le sujet de la rapidité du gestionnaire d'évènements le développement est clos sauf bug ou problème rencontré à ceci prêt qu'il serait intéressant de réduire un peu la charge CPU sur 68000.

Les axes d'amélioration encore envisagés sont :

- Réduire la charge processeur sur les plus petites configurations
- Réduction du besoin mémoire en version 68000
- Corrections de bugs entre autre certaines applications n'arrivent pas à faire fonctionner les champs éditables des objets (comme Devpac) si vous avez des bugs à reporter vous pouvez les signaler sur Github https://github.com/Landemarre/MyAES/issues
- Support nouveau format de fichier ressource
- .....