Mac OS X, Vitesse des primitives graphiques et optimisation.

[Didier Guillion]

Bonjour,

Je suis en train de faire des essais d'optimisation d'un programme.

Je compare des tracés de fontes vectorielle sur des fonds (GWorld) effacés par des patterns couleurs.

Les tests ont été conduit sur la même application carbonisé tournant successivement sur 8.6 et X.1.1.

D'après mes tests le X serait très exactement 50 % plus lent que le 8.

L'analyse par "sampler" du X montre que c'est CopyBits puis DrawChar qui occupent le plus de temps.

Quelqu'un a t'il conduit des tests similaires et si oui quels sont les résultats ?

Cordialement

 

[Didier Guillion]

Suite des tests,

Ce matin j'ai fait quelques comparaisons de vitesse entre le 8.6 et le X.1.1 afin de compléter mes tests précédents de vitesse graphique.

J'ai testé la vitesse de lecture/écriture de fichiers importants (32Mo).
Ceci me sert dans mon application à gérer des pistes audionumériques.
Agréable surprise le X est 20% plus rapide en lecture écriture.
Je n'ai pas encore testé le temps de création du fichier, mais c'est un bon point.

En allocation de mémoire temporaire, le X semblerait un tout petit peu plus lent mais de manière non significative.

Donc grosso modo, les problèmes de lenteur du X sont essentiellement du a des problemes d'accés graphique.
C'est plutot rassurant dans le sens ou cela est assez independant du systeme UNIX.
Les ingénieurs d'Apple avaient bien bossé sur les systèmes précédents pour optimiser cela,
il ne leur reste plus qu'a faire de même sur X.

Ce serait intéressant, amis développeurs, que d'autres conduisent des tests différents afin de valider ceci.
Cela couperait cours aux éternelles et stériles discussion entre ceux qui disent que le X est réactif et leur détracteurs.

Cordialement

 

[PowerMike]

A ce que je crois ... la prochaine étape pour eux est d'optimiser le serveur graphique d'OS X.

Les bases Unix apportent réellement un gain de performance pour tout ce qui est fichier ( création, copie etc.) et transfert sur le réseau.

Et puis à ce que j'ai vu dans le dernier Univers MacWorld les capacités audio sont par contre elles tout à fait intéressantes. OS X integre beaucoup de technologies qui était apportées séparemment par des logiciels tiers .. et avec beaucoup de fonctions quasi temps réel ...

Ça devrait donc être cool maintenant.

 

[Didier Guillion]

Suite de la suite des tests,

D'autres tests vont dans ton sens PowerMike.
Les copies d'offscreen a offscreen ou vers les offscreen automatiques gérés par X (sur X les fenetres sont gérées en mémoire sous forme d'offscreen) semblent rapides, meme parfois plus rapide que sous 8.

Apparamment l'affichage des caractères seraient 75 % plus lent que sous 8.6.

Je vais tester d'autre primitives graphiques, mais apparemment cela viendrait de la.

Sinon, pour les fichiers et l'audio, c'est vrai que c'est plus rapide.

Cordialement

 

[Didier Guillion]

Bonjour,

Aprés quelques tests plus poussés voici mes conclusions :

Les primitives graphiques du X sont de 1,5 à 6 (six!) fois plus lentes que sur Mac OS 8.6.

Seul le transfert des offscreen automatiques vers la carte video a été vraiment optimisé et est plus rapide que sur 8.

Le bonnet d'ane étant donné aux affichages de textes.

Sachant que l'interface Aqua est plus complexe : ombres portées (avec erreur de perspective d'ailleur), boutons pulsants, offscreen par défaut, transparences, on comprends la mauvaise réactivité du tout.

Y a du boulot !

Cordialement

 

[PowerMike]

Certes il y a du boulot !

Ce qui est bien c'est qu'Apple nous donne la possiblité de faire des choses jolies. Autrement dir, lorsque l'optimisation du système aura été poussé jusque dans cette partie ( un peu comme l application DVD qui est plus performante ) il sera très agréable de pourvoir utiliser ce qui aujourd'hui ralenti pas mal c'est vrai. Mais la puissance de nos processeurs et de nos cartes graphiques va augmenter.

Tout ce que permet aujourd'hui OS X au niveau affichage n'est pas tout le temps permi chez Windows.

C'est quand même un plus appréciable qui a un coût, mais aujourd'hui seulement je l'espère.

 

[Didier Guillion]

Bonsoir,

Je ne comprends pas trop comment la puissance de nos processeurs et des cartes graphiques pourraient augmenter sans que l'on change de matériel. A moins que l'on puisse de manière ou d'une autre reprogrammer le firmware, mais la on touche a des domaines ou je n'ai aucune connaissance.
Si par contre tu veut dire par la, cela ira plus vite quand on aura des machines plus rapide, je ne te suis pas non plus.
Je me vois mal dire a mes utilisateurs, oui c'est lent, mais achetez une machine deux fois plus rapide et cela ira deux fois plus vite. Il n'acepterons pas ce genre de Lapalissade.

Je ne vois pas non plus ce que le Mac propose de plus que le PC sur ce point précis. A mon avis l'avantage est même plutot du coté du PC au niveau de la rapidité des cartes graphiques. C'est vrai qu'en général les étalonnages des couleurs sont plus qu'approximatif sur Windows (d'ou l'interet des flasheurs pour le Mac) mais question rapidité c'est le jour et la nuit. Regarde un peu la rapidité des jeux sur PC et sur Mac.

La gestion des fontes, est, je le reconnait, un peu plus élaborée sur Mac OS mais aussi beaucoup plus limité. Et la rapidité de Windows en ce domaine surpasse encore le Mac.

J'ai conduit les memes tests de vitesse sur un PC sous Windows 2000, pentium 600,qui date de la meme année que mon G4 et le PC pulverise le Mac : il est environ deux fois plus rapide que sur Mac OS 8.6 et je ne te dit pas par rapport a mac OS X !

Je le maintient, il ya encore beaucoup de chemin a faire.

Cordialement

 

[Gwenhiver]

Didier, je viens de tomber sur ça. Ça devrait t'intéresser, même si c'est court.
(Pour info, Chris Jacobson est le développeur qui s'est occupé du portage de Baldur's Gate II sur le Mac.)

 

[P O L]

Salut Didier,

Il se trouve que j'ai discuté par e-mail hier avec des développeurs d'une compagnie fabriquante de cartes 3D très connue (j'ai promis de pas révéler l'identité). Voici un extrait de la conversation:

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>&gt; Unofficially speaking, what can you tell me about OpenGL
&gt; performances under OSX? Is it really better? Is it because of a better OS
&gt; architecture, or because some OpenGL features have not been (on purpose I
guess) hw
&gt; accelerated on OS 9?

roughly OpenGL performance on MacOS 9 and MacOS X are about the same, with
some exceptions:

- the Math library on MacOS X 10.1 sucks. People have measures 10x slower
perf on sqrt() than on MacOS 9
apparently Apple is shipping a new math library soon.

- unaligned data is up to 10x slower on MacOS X than on MacOS 9

- glTexSubImage() is slower on MacOS X than MacOS 9 because currently we
download the entire texture

- glDrawPixels() is slower on MacOS X than on MacOS 9, because the fast path
has not been fully enabled yet

- versions of MacOS X before 10.1 suffered from a texture download
bottleneck.<HR></BLOCKQUOTE>

Le point concernant la librairie de math est peut-être la cause de ton problème (je n'ai pas fait de tests de mon côté pour obtenir confirmation du phénomène).

 

[P O L]

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Didier Guillion:
Sachant que l'interface Aqua est plus complexe : ombres portées (avec erreur de perspective d'ailleur), boutons pulsants, offscreen par défaut, transparences, on comprends la mauvaise réactivité du tout.<HR></BLOCKQUOTE>

Autre extrait de ma conversation par e-mail:

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
&gt; And another question about OS X: are all the window transparency Aqua
&gt; effects hw accelerated by your drivers?

not yet. This is working in beta drivers, but won't ship until next Summer.

&gt; Now there's one stuff I don't get: I made some tests putting a
&gt; semi-transparent terminal partially on top of a 3D rendering
&gt; window, and it still looked hw accelerated (I thought the whole context
&gt; would switch to software rendering)!! Same for menus!

the 3D gets drawn to the back buffer via hardware (i.e. accelerated) and
then the Window Manager
handles reading from the 3D buffer and compositing with the transparent
windows that are overlapping
the 3D. So it's slower, but the 3D still uses the hardware.
<HR></BLOCKQUOTE>

 

[Didier Guillion]

Salut à tous,

Ces références sont très intéressante. Dans les tests de transfert graphique, je suis persuadé que la libraire Mathématique ne peut etre en cause car je n'ai pas utilisé l'OpenGl.

Par contre si l'affichage des fontes utilise cette librairie, il se peut bien qu'une optimisation de la librairie augmente drastiquement la vitesse. A étudier.

L'article de C. Kacobson propose comme solution de passer l'écran en millier plutot que de le laisser en millions. J'avais essayé, cela accelere en effet, mais de la meme proportion en 8 qu'en X.

Dans tout les cas, cela ne peut qu'améliorer le transfer des offscreen utilisateurs vers les offscreen systemes et pas des offscreen systeme vers l'écran car je suppose que les offscreen systemes ont la meme profondeur que l'écran.

Au passage, c'est d'ailleurs un excellent moyen pour accélerer d'une maniere generale le X sur une machine disposant de peu de mémoire : diminuer la profondeur de l'écran diminue également la taille des offscreens systeme et donc allége la consommation de mémoire.

Il ne faut pas oublier que pour chaque fenetre ouverte, le X en garde la copie en mémoire...

Je continue de mon coté à tester les primitives graphiques (n'utilisant pas l'OpenGL, je me limite au QuickDraw) et j'ai trouvé des bugs fameux...


Merci de vos informations,

Cordialement

 

[P O L]

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Didier Guillion:
Dans les tests de transfert graphique, je suis persuadé que la libraire Mathématique ne peut etre en cause car je n'ai pas utilisé l'OpenGl.<HR></BLOCKQUOTE>

Il s'agit de la librarie mathématique standard (celle qui fournit exp(), sqrt()... aux applis). C'est pas lié à OpenGL. Maintenant, pour faire du tracé de fonts vectorielles, t'as besoin de math, non? Donc si les calculs ne sont pas faits avec des approx mais en utilisant les fonctions "exactes" de la librarie mathématique, cela peut-être une raison.

 

[Didier Guillion]

Je suis tout a fait d'accord. Les tracés des glyphes doivent utiliser à fond les librairies mathématiques.

Je ne comprends pas trop pourquoi ils n'ont pas réutilisé celles des anciens systemes, que ce soit sur 8,9 ou X une racine carrée reste une racine carrée non ?

Cordialement