Strider (./1) :
Je viens de tomber sur une série d'articles intéressants sur le GEM, depuis ses origines jusqu'à MultiTOS/MiNT.
Ils sont écrits par Mike Fulton qui a commencé comme développeur chez un éditeur avant d'être embauché par Atari.
Cela traite des débuts du GEM chez Digital Research, les défauts et avantages du GEM, la gestion des périphériques et des fontes avec GDOS et FSMGDOS, une comparaison Windows/GEM, etc.
On découvre l'envers du décor en quelque sorte. C'est assez intéressant à lire.
http://www.fultonsoft.com/category/atari-st/revisiting-gem-for-the-atari-st/(la 7ème partie a été écrite il y a quelques jours et la suite devrait arriver)
Je viens de lire l'article et j'ai plusieurs remarques.
L'auteur regrette dans GEM qu'il n'y ai pas de moyen de vérifier si des messages sont en attente sans avoir à passer par evnt_multi() ou event_mesag() si on a besoin de faire de long calculs. Si evnt_mesag() est bloquant si il n'y a pas de message en théorie evnt_multi() peut être couplé avec une demande timer courte et à priori 0 n'est pas interdit sauf que malheureusement que ce soit TOS, Magic, NaES, XaAES et il y a encore quelques versions MyAES tous au grand complet, switchent sur un autre process et reviennent après un cycle système (même avec un timer à 0) et cela même si tous les programmes sont en attente, du coup si on fait un appel à evnt_multi() en moins d'un cycle le programme n'a pour lui qu'au maximum 50% du temps, pire supposez que votre calcul prend 5ms avant d'appeler evnt_multi() vous récupérer la main 20ms plus tard (généralement c'est le timing d'un cycle des systèmes) soit 20% du temps et la rigolade de la chose vous aurez beau avoir une machine plus puissante l'application n'ira pas plus vite!
Bon voilà le tableau est bien noir, pour les jeux c'est la cata à vous dégouter de faire des jeux GEM!
Mais pas mal de jeux GEM (entre autre les ports SDL) sont rapides me direz vous!
Vous rappelez vous les premiers port de DOOM avec SDL de Patrice? Si on ne parle pas des soucis clavier, le nombre de FPS était assez bas rien à voir avec les versions actuelles et pourtant Patrice avait superbement travaillé il a du y passer du temps à porter SDL, mais sous GEM c'était d'une lenteur incroyable (comparé à faire tourner le même programme en 100% tos). Et bien tout cela à cause principalement d'un seul appel: evnt_multi()!
Alors j'ai essayé de remédier au problème dans MyAES et décidé de réécrire la boucle principal d'évènement (le cauchemar du programmeur d'AES!), pour ressortir avec un timer à 0 c'est l'enfer, tout se lie pour que cela bloque par moment (MadMax qui a été mon beta testeur ultra patient peut vous l'assurer), qu'il n'y ai plus qu'une appli qui monopolise le système, que le fonctionnement d'une machine à l'autre soit différent etc... j'ai du y passer près d'un an! Et j'avais un Doom qui fonctionnait pas mal! En fait les systèmes ne sont pas multitaches préemptifs lorsque le processeur est en superviseur, l'AES dit au système qu'il peut switcher la tache.
J'ai fait du lobbying auprès de Guillaume Tello pour qu'il arrête d'être toujours en superviseur avec Mplayer car le système ne répond plus!
Cela aurait été un bon coup de pub pour MyAES mais j'ai discuté avec Patrice pour lui faire part de mes observations et là il a trouvé un truc génial, incroyable, improbable!
Bon maintenant chargez un gros fichier avec Qed sur une machine rapide et comparez avec un autre AES
Le truc de Patrice qui marche sur tous les AES:
1 envoyer un message avec appl_write() à lui même parfaitement connu
Faire des event_multi() tant que le message n'est pas reçu
Et bien avec ce procédé, il n'y a plus d'attente et de switch l'AES retourne immédiatement, certe event_multi() est une fonction lourde et appl_write() rajoute une opération mais finalement le temps perdu est assez court
Je rajouterais un truc perso:
Pas la peine de faire des event_multi() à tout va pour vérifier si il y a message ou pas, tous les 80ms généralement c'est amplement suffisant, l'application restera très réactive.
Et on peut faire mieux?
Oui a mon avis, aujourd'hui quand même Mint et Magic sont des systèmes multitâche préemptifs, rien n'empèche de créer un thread pour faire les calculs et de l'autre de traiter tranquillement les évènements de manière un peu plus classique.
SDL necessite clavier, souris messages de l'AES, bien souvent, juste les messages sont nécessaires pendant qu'un gros calcul doit être fait, MyAES 0.96 rajoute une manière très simple d'être informé qu'il y a un message en attente via un signal système sans passer par event_multi() ou event_mesag() qui ne devront donc être appelé qu'en cas de besoin.
Olivier
