Les nouveautés de l'iPhone OS 3

17 03 2009 In: Conférences, iPhone / iPod Touch

Apple vient de présenter les nouveautés de la version 3.0 de l'iPhone OS et on peut dire qu'il y a des points vraiment sympatique pour les développeurs et les utilisateurs :

  • Attendu depuis longtemps, le copier / coller arrive sur iPhone et fonctionne de la manière suivante :
    • On tape deux fois sur un mot pour le sélectionner. Une fois un mot surligné, on peut modifier les bords de la sélection pour séléctionner un bloc.
    • On secoue l'iPhone pour annuler une sélection ou rétablir une sélection annulé.
    • Il est possible d'effectuer copier / coller d'une application à une autre.
  • 1000 nouvelles API pour les développeurs.
  • Possibilité de proposer à la vente du contenu dans la application. Par exemple de vendre des niveaux dans un jeu, des ebooks pour une application du genre Kindle.
  • Gestion des jeux multi-joueurs ou de l'échange de données entre iPhone avec une auto-détection des iPhone proches (en utilisant le protocole Bonjour sur une connexion Bluetooth).
  • Possibilité de communiquer avec les accessoires externes Made for iPod par le connecteur 30 broches présent sous l'iPhone.
  • En pour finir, l'arrivé du support des applications Push (qui nécessiterait beaucoup moi de batterie que les taches de fond). Cela fonctionnera de la manière suivante :
    • quand l'application est en ligne elle reçoit les données directement depuis le serveur.
    • quant elle ne tourne pas, les serveurs d'Apple font office de mandataire.

Vous trouverez tous les informations utile, et la possibilité pour les développeurs de télécharger la version beta sur l'iPhone Dev Center :

iPhone 3.0 : Apple lance les invitations

12 03 2009 In: iPhone / iPod Touch

Apple vient de lancer des invitations pour le 17 mars concernant la sortie d'une future version 3.0 du système d'exploitation de l'iPhone. Il sera intéressant de voir les nouveautés de cette version, tout particulièrement en ce qui concerne les programmes en taches de fond. J'essayerais bien sur de suivre les retranscriptions de cette conférence de presse et de faire un résumé des informations intéressantes pour les développeurs.

Get an advance preview of what we're building

Générateur d'images fractales (8)

11 03 2009 In: Pas à pas

À force de jouer avec le générateur, quelque chose me chagrine: un nouvel utilisateur ne saurait même pas qu'il peut agir sur la vue à la souris. Nous allons donc modifier son pointeur pour apporter cette information.

Comportement voulu

Voici le fonctionnement que j'attends:

  • Fèches haut/basQuand on appuie sur la touche Contrôle, le curseur de la souris doit se transformer en flèches. Ceci, dès que le pointeur se trouve dans la vue.
  • Main ouverte Sinon, si le bouton n'est pas appuyé, le curseur est une main ouverte.
  • Main ferméeS'il est appuyé, une main fermé.

Changer le pointeur

Je vais déjà vous expliquer comment fonctionne ce système de curseurs sous Cocoa, la doc d'Apple me semblant assez indigeste pour quelque chose d'aussi simple.

La classe NSCursor dispose d'un ensemble de méthodes de classes qui renvoient un nouvel NSCursor, ayant des apparences diverses (croix, main, flèches, etc.). Fixer le pointeur est aussi simple que ceci:

[[crosshairCursor] set];

Qui donnera une apparence de croix au pointeur.

Cependant, NSCursor possède un mécanisme plus élaboré, basé sur une pile:

  • Quand une instance de NSCursor reçoit un appel à -[NSCursor push], cette instance devient le curseur courant, et l'ancien curseur est empilé.
  • Quand la classe NSCursor reçoit un appel à +[NSCursor pop], le curseur sur le haut de la pile est retiré et devient le nouveau curseur.

C'est ce mécanisme que nous allons utiliser, puisqu'il nous simplifie la vie, en mémorisant dans quel état il faut remettre le curseur.

Événements clavier

Il nous faut surveiller l'appui sur la touche Contrôle:

- (void)flagsChanged:(NSEvent *)theEvent
{
    if(pointeurDansLaVue)
    {

-[NSResponder flagsChanged:] est appelée dès qu'une touche spéciale est appuyée, que le pointeur soit dans la vue ou non.
J'ai donc créé une variable d'instance pointeurDansLaVue. Nous fixerons sa valeur dans les méthodes indiquant l'entrée ou la sortie du pointeur de la vue.

        if([theEvent modifierFlags] & NSControlKeyMask)

On regarde si la touche Contrôle est appuyée.

            [[NSCursor resizeUpDownCursor] push];

On change le curseur (en mémorisant l'ancien).

        else
            [NSCursor pop];

Sinon, Contrôle n'est plus appuyée: il faut rétablir le curseur précédent.

    }
}

Il faut également rajouter ce code:

- (BOOL) acceptsFirstResponder
{
    return YES;
}

Autrement, nous ne recevrions pas les événements clavier.

Entrée et sortie de la vue

Tracking Area

Cocoa propose de surveiller la position du pointeur par le biais de la classe NSTrackingArea, qui représente un rectangle de la vue. Ajoutons les variables d'instance:

@interface CFRFractalView : NSView {
    IBOutlet CFRMandelbrotRender* render;

    NSTrackingArea* trackingArea;   
    BOOL pointeurDansLaVue; 
}

Et initialisons-les:

- (id)initWithFrame:(NSRect)frame {
    self = [super initWithFrame:frame];
    if (self)
    {
        trackingArea = nil;
        pointeurDansLaVue = NO;
    }
    return self;
}

Apple conseille de créer les tracking areas lorsque la vue est insérée dans la fenêtre:

- (void)viewDidMoveToWindow
{
    trackingArea = [[NSTrackingArea alloc] initWithRect:[self bounds] 
        options:(NSTrackingMouseEnteredAndExited 
        | NSTrackingInVisibleRect | NSTrackingActiveInKeyWindow) 
        owner:self 
        userInfo:nil];

Nous fournissons à la méthode d'initialisation:

  • le rectangle définissant la tracking area
    Nous lui passons le rectangle définissant la vue. Il s'agit du rectangle de départ, la tracking area changeant de dimensions lors des redimensionnements de la vue.
  • Des options, combinées par l'opérateur OU:
    • NSTrackingMouseEnteredAndExited indique que nous voulons que les méthodes -mouseEntered: et -mouseExited: soient appelées lors de l'entrée, respectivement de la sortie du pointeur.
    • NSTrackingInVisibleRect nous permet de ne pas nous préoccuper de redimensionner la tracking area.
    • NSTrackingActiveInKeyWindow dit de ne surveiller le pointeur que quand la fenêtre est active.
  • owner est le propriétaire de la tracking area. Il est possible de déléguer cette gestion, mais ici c'est notre vue qui s'en occupe.
  • userInfo permet de passer des informations à l'intérieur du NSEvent reçues par les méthodes d'événement. Inutile pour nous.
    [self addTrackingArea:trackingArea];
    

    }

Nous associons ensuite la tracking area à la vue.

Événements mouseEntered et mouseExited

- (void)mouseEntered:(NSEvent *)theEvent
{
    [[NSCursor openHandCursor] push];
    pointeurDansLaVue = YES;
}

Quand le pointeur entre dans la vue, nous changeons le curseur en une main ouverte, et mettons à jour pointeurDansLaVue, nécessaire à la méthode -flagsChanged: décrite plus haut.

- (void)mouseExited:(NSEvent *)theEvent
{
    pointeurDansLaVue = NO;
    [NSCursor pop];
}

Quand le pointeur sort de la vue, nous rétablissons le curseur précédent, a priori la flèche normale.

Événements mouseDown et mouseUp

- (void)mouseUp:(NSEvent *)theEvent
{
    [NSCursor pop]; 
}

Lorsque le bouton de la souris est relâché, nous rétablissons le curseur précédent.

Pour les clics:

- (void)mouseDown:(NSEvent *)theEvent
{

Lors d'un clic…

    if([theEvent modifierFlags] & NSControlKeyMask)
    {

… si la touche Contrôle est appuyée…

        [[NSCursor resizeUpDownCursor] push];

Utiliser un curseur en formes de doubles-flèches. À vrai dire, ce curseur est déjà le curseur actuel (puisque la touche Contrôle a été enfoncée avant le clic), mais cet appel permet de contrebalancer le [NSCursor pop] de la méthode -mouseDown:…

    }
    else
    {
        [[NSCursor closedHandCursor] push];

… appel lui même nécessaire pour contrebalancer cet appel à adopter un curseur en main fermée.

    }
}

Nous en avons fini avec ces histoires de curseurs. Je vous accorde que ça semble un peu bricolé, mais on ne peut guère faire autrement.

Résultat

Il n'y a plus qu'à essayer: ça fait tout de suite beaucoup plus pro !

Version de Mac OS X

La classe NSTrackingArea fut introduite avec Mac OS 10.5. Autrefois, on utilisait le mécanisme des tracking rectangles, qui est similaire mais plus compliqué à mettre en œuvre. Toujours est-il que nous perdons la compatibilité avec les anciens systèmes, alors prévenons leurs utilisateurs avec un joli message d'erreur. Pour cela:

  • Clic droit sur Info.plist > Open As > Plain Text File
  • avant la balise </dict> finale, insérez:
    <key>LSMinimumSystemVersion</key>
    <string>10.5.0</string>

À bientôt pour la suite.

Le projet XCode complet à télécharger.

Renaud Pradenc
Céroce.com

Générateur d'images fractales (7)

05 03 2009 In: Pas à pas

Aujourd'hui nous allons permettre — enfin ! — de se déplacer dans l'ensemble de Mandelbrot.

Retirer la mesure de performance

Commencez par ouvrir MyDocument.xib et retirez l'instance de CFRMesurePerf qui ne nous est plus nécessaire.

Navigation

L'utilisateur naviguera de la façon suivante:

  • se déplacer sur le repère se fait en glissant la souris avec le bouton principal (gauche) appuyé.
  • le zoom se fait grâce à la molette de la souris, ou pour les souris qui n'en seraient pas pourvues, en maintenant la touche Contrôle appuyée, et en glissant la souris avec le bouton appuyé.

Le déplacement

Rappelez-vous que la classe CFRMandelbrotRender contient une variable d'instance centre:

Complexe_t centre;  // Centre du repère

De fait, se déplacer dans l'ensemble consiste à déplacer le centre du repère, à recalculer la bitmap et à l'afficher.

Glissé de la souris

Je vous rappelle que NSView hérite de NSResponder. Or, la méthode -[NSReponder mouseDragged:] est appelée lorsque la souris est glissée sur la vue, avec le bouton principal appuyé :

- (void)mouseDragged:(NSEvent *)theEvent
{

    // Déplacer le centre de la vue
    [render decalerCentreX:-[theEvent deltaX] 
                        y:[theEvent deltaY]];

Je vais revenir tout de suite sur la méthode decalerCentreX:y:. Les méthodes -[NSEvent deltaX] et -[NSEvent deltaY] permettent d'obtenir le nombre de points dont s'est déplacé le pointeur de la souris pendant le glissé.

    [self setNeedsDisplay:YES];
}

Cette méthode demande à la vue se réafficher dans la prochaine boucle d'affichage : la méthode -drawRect: sera appelée à nouveau.

Décaler le centre

Venons-en à la méthode -[CRFMandelbrotRender decalerCentreX:y:]. Nous avons ici une conversion d'échelle à faire. En effet, les décalages lui sont exprimés en pixels, et il nous faut les exprimer en coordonnées "repère":

- (void) decalerCentreX:(NSInteger)pixelsHoriz
                    y:(NSInteger)pixelsVerti
{
    double facteurReperePixel = largeur / largeurBitmap;

D'abord, nous calculons le rapport d'échelle entre la largeur du repère, et celle de la bitmap (en pixels, comme la vue).

    double deltaX = pixelsHoriz * facteurReperePixel;
    double deltaY = pixelsVerti * facteurReperePixel;

Nous appliquons alors ce facteur aux décalages en pixels pour obtenir les décalages en coordonnées "repère".

    centre.reel += deltaX;
    centre.imag += deltaY;
}

Enfin, nous translatons le centre du repère.

Et voilà, lancez le programme, ça fonctionne.

Le zoom à la molette

Zoomer

Zoomer consiste à modifier la variable largeur de CFRMandelbrotRender, qui représente la largeur de l'intervalle de calcul:

double largeur;

Ainsi, si vous divisez la largeur par 2, vous zoomez de 200%; si vous multipliez la largeur par 2, vous dézoomez de 50%:

- (void) zoomerDuFacteur:(double)facteur
{
    largeur = largeur * facteur;

    // Corriger les valeurs extrêmes
    if(largeur < 0.0001)
        largeur = 0.0001;
    else if(largeur > 8.0)
        largeur = 8.0;
}

J'ai ajouté la correction des valeurs extrêmes après quelques essais . Les limites sont empiriques; d'ailleurs, nous changerons sans doute la limite basse un jour.

Gestion de la molette

Quand la molette est actionnée, la méthode -[NSResponder scrollWheel:] est appelée:

- (void)scrollWheel:(NSEvent *)theEvent
{
    // deltaY est > 0 quand la molette est tournée en avant.
    //  Il vaut +/- 0.1 pour un petit mouvement et +/- 10 pour un grand.
    double deltaY = [theEvent deltaY];

Il m'a fallu faire quelques essais pour régler l'amplitude du zoom. J'ai mesuré que tourner lentement la molette vers l'avant donnait un deltaY aux alentours de 0,1, et la tourner vite, autour de 10.
deltaY est négatif quand on la molette est tournée vers l'arrière.

    [render zoomerDuFacteur: 1.0 + deltaY/20.0];

La division par 20 de deltaY est là encore empirique. Par exemple, en tournant rapidement la molette vers l'arrière, vous obtenez un facteur de zoom de l'ordre de 1+ (-10)/20) = 0.5, soit un zoom x2.

    [self setNeedsDisplay:YES];
}

Lancez le programme: ça zoome !

Le zoom par Contrôle + glissé

Modifions la méthode -mouseDragged:

- (void)mouseDragged:(NSEvent *)theEvent
{
    // La touche Contrôle est-elle appuyée ?
    if([theEvent modifierFlags] & NSControlKeyMask)
    {

Il nous faut d'abord savoir si la touche Contrôle est appuyée pour distinguer les deux type de glissés.

        // Zoomer/dézoomer
        double deltaRelatif = 2.0 * ([theEvent deltaY] / [self bounds].size.height);

Par soucis d'ergonomie, ce qui nous intéresse, n'est pas le déplacement absolu de la souris, mais son déplacement relatif. D'où le calcul de deltaY/(hauteur de la vue). J'ai ensuite ajouté un facteur 2, déterminé — vous l'aurez deviné — de façon empirique.

        [render zoomerDuFacteur: 1.0 + deltaRelatif];
    }
    else
    {
        // Déplacer le centre de la vue
        [render decalerCentreX:-[theEvent deltaX] y:[theEvent deltaY]];     
    }
    [self setNeedsDisplay:YES];
}

Le reste a déjà été expliqué.

Le résultat

Lancez le programme, et admirez le résultat. Personnellement, je trouve l'affichage encore un peu lent.

En zoomant loin en avant, on reconnaît enfin la structure "fractale" de l'ensemble (le même motif se répétant à des échelles différentes).

Répétitions de la structure fractale

Zoom sur un détail Cependant, les détails ne sont alors plus très présents. C'est parce que nous avons fixé le nombre d'itérations maximales trop bas. Heureusement, nous permettrons prochainement de modifier ce seuil.

À bientôt.

Le projet XCode complet à télécharger.

Renaud Pradenc
Céroce.com

Générateur d'images fractales (6)

03 03 2009 In: Pas à pas

Nous continuons aujourd'hui l'optimisation de la génération de l'image.

Les bitmaps

J'ai vaguement expliqué ce qu'était une bitmap, me contentant de dire qu'il s'agissait d'une grille de pixels. Intéressons-nous à leur organisation en mémoire.

32 bits par pixel

Utiliser 32 bits pour stocker les composantes d'un pixel est des plus classiques:

Mode 32 bits/pixel

Chaque composante utilise un octet, et peut donc contenir une valeur de 0 à 255. Doser les quantités de rouge, de vert et de bleu permet de choisir la teinte du pixel; la composante alpha correspond à l'opacité du pixel.

256 niveaux de gris

Notre générateur utilise une bitmap en 256 niveaux de gris:

Mode 8 bits/pixel

C'est le même principe: la valeur de l'octet fournit la nuance; 0 correspond au noir et 255 au blanc, voilà pourquoi nous utilisons la ligne:

NSUInteger nuance = n * 255 / MAX_ITERATIONS;

pour déterminer la nuance du pixel calculé.

Organisation en mémoire

Voyons maintenant la relation entre les pixels et les coordonnées:

Bitmap en 256 niveaux de gris

Dans cet exemple, la bitmap mesure 400 pixels de large et 300 de haut. Ce qui est intéressant, c'est que les pixels se suivent en mémoire. Ainsi, si nous disposons de l'adresse à laquelle est stockée la bitmap, adresseBitmap:

  • Le pixel de coordonnées (0,0) se trouve à l'adresse adresseBitmap.
  • Le dernier pixel de la première ligne (399, 0) se trouve à l'adresse adresseBitmap + 399 (puisqu'un pixel prend exactement un octet).
  • Le premier pixel de la deuxième ligne (0, 1), se trouve à l'adresse adresseBitmap + 400.
  • etc.

En généralisant nous obtenons:

adressePixel = adresseBitmap + (400 * y) + x

ou en généralisant d'avantage:

adressePixel = adresseBitmap + (largeurBitmap * y) + x

Il nous suffit d'écrire la nuance à cette adresse pour modifier le point. Vous devez maintenant avoir une bonne idée du fonctionnement de la méthode -[NSBitmapImageRep setPixel:atX:y];

Row Bytes

À vrai dire, j'ai simplifié la figure précédente, en omettant un détail. Voici une figure plus juste:

Bitmap en 256 niveaux de gris + rowBytes

En effet, pour des raisons de performances, des octets inutilisés (row bytes) sont ajoutés à la fin de chaque ligne. Ils servent à aligner la bitmap en mémoire. On ne connaît pas leur nombre a priori: cela dépend de plusieurs paramètres.

Toujours est-il qu'il faut en tenir compte.

L'optimisation

Dans notre boucle de rendu, il ne nous reste plus grand chose que nous puissions améliorer si ce n'est cette ligne:

[bitmapRep setPixel:&nuance atX:x y:y];

Cette méthode est tout de même appelée un million de fois (pour notre rendu en 1000 x 1000 pixels). Les bénéfices attendus en écrivant directement dans la bitmap sont les suivants:

  • Ne plus appeler la méthode [setPixel:atX:y:]. Les appels de méthodes sont encore plus lents que les appels de fonctions. Nous ferons entre-autres l'économie de l'exécution de la fonction objc_msgSend_rtp().
  • La méthode [setPixel:atX:y:] est forcément plus compliquée qu'un écriture directe dans la bitmap, ne serait-ce que par son côté généraliste. De plus, si vous vous rappelez l'article précédent, Shark listait des appels aux méthodes
    -[NSBitmapImageRep _setCGImageRef:]
    -[NSBitmapImageRep getBitmapDataPlanes:]
    -[NSBitmapImageRep _acquireRetainesCGImageRef]
    Je pense que ceci va nous permettre de nous en passer.

Le code

Inverser les énumérations des x et y

À cause de la manière dont est stockée la bitmap, il est nécessaire les énumérations de x et y :

for(y = 0; y < hauteurBitmap; y++)
{       
    for(x = 0; x < largeurBitmap; x++)
    {

                …

        c.reel += incX;
    }

    c.reel = premierPoint.reel;
    c.imag += incY;
}

Adresser la bitmap

Avant le calcul:

// Obtenir la bitmap
unsigned char* bitmapPtr = [bitmapRep bitmapData];

On demande l'adresse de la bitmap.

unsigned int rowBytes = [bitmapRep bytesPerRow] - largeurBitmap;

La méthode [bitmapRep bytesPerRow] renvoie le nombre d'octets utilisés pour stocker une ligne. Comme nous savons que largeurBitmap octets sont utiles, nous en déduisons le nombre d'octets d'alignement (rowBytes).

for(y = 0; y < hauteurBitmap; y++)
{       
    for(x = 0; x < largeurBitmap; x++)
    {

                    …

        // Donner le niveau de gris au pixel
        *bitmapPtr = n * 255 / MAX_ITERATIONS;

Nous conservons la formule du calcul de la nuance, que nous écrivons dans la bitmap à l'adresse du pixel courant.

        bitmapPtr++;

Puis nous passons au pixel suivant.

        c.reel += incX;
    }

    c.reel = premierPoint.reel;
    c.imag += incY;
    bitmapPtr += rowBytes;  // Sauter les octets inutilisés en fin de ligne

À la fin de chaque ligne, nous sautons les octets inutilisés.

}

Résultat

50 images rendues en 12.864695 secondes.
Moyenne = 3.886606 images/s

Nous tournons aux alentours de 4 images/s. Je vous rappelle que la première mesure donnait 0,79 images/s… la vitesse a été multipliée par 5 !

Nous arrivons aux limites de ce que nous pouvons ainsi optimiser. Nous allons nous arrêter là.

Et si ce n'était que le début ?

Améliorer la vitesse demanderait maintenant de recourir à des astuces.

Voici une idée: vous pouvez remarquer que deux pixels qui se suivent sont très souvent de la même nuance. On pourrait ne calculer qu'un pixel sur deux:

  • Si le pixel n°3 n'est pas de la même nuance que le pixel n°1, alors on calcule le pixel 2
  • Sinon, on lui donne la nuance du pixel 3.

On ne manquerait que des variations brusques (<1 pixel), peu perceptibles.

Cependant, tout cela est sans intérêt, parce que la vraie façon d'améliorer la vitesse est de déléguer le calcul… à la carte graphique! Je crois que n'importe quelle carte est aujourd'hui capable de faire ce calcul en temps réel. Ce sera peut-être pour une prochaine fois (quand j'aurais appris à me servir d'OpenGL Shading Language). En attendant, l'application est utilisable. Nous allons pouvoir nous balader dans l'ensemble de Mandelbrot.

À bientôt pour la suite.

Le projet XCode complet à télécharger.

Renaud Pradenc
Céroce.com

En vrac

02 03 2009 In: Cocoa, Interview, Livres

Aujourd'hui ça va du développement de jeu, aux livres en passant par des interviews de développeurs :

L'actualité du développement web

26 02 2009 In: Liens, Logiciel

Si vous suivez l'actualité Mac, vous avez certainement vu que Apple vient de rendre disponible une version bêta de Safari 4. Parmi les nouveautés, quelques une nous intéresse tout particulièrement :

Pour finir, je voudrais aussi signaler les actualités concernant Cappuccino, qui proposera d'ici peu un nouveau thème et une application web de type XCode pour développer des applications Objective-J / Cappuccino :

Vous trouverez ci-dessous la vidéo de Atlas, qui mérite d'être vue tellement on a l'impression d'avoir à faire à un XCode en ligne :

Gérer une base de données MySQL

25 02 2009 In: Logiciel

Lorsque l'on développe une application, et plus particulièrement dans le cadre d'une application web, on utilise souvent une base de données pour stockés les données de l'application. Une des solutions est d'utiliser phpMyAdmin qui est souvent installé par défaut sur les hébergements ou les packages permettant de faire du développement web, mais il faut avouer que son interface n'est pas toujours des plus facile à utiliser. L'alternative est de passer par un client MySQL installé sur votre ordinateur, c'est pour ça que je vais aujourd'hui vous en présenter quelques-uns :

  • Sequel Pro qui est utilisable à partir de Mac OS X 10.5 et qui est gratuit et sous licence GNU GPL.
  • Querious, un logiciel qui coûte 25$ et qui me semble plus facile à utiliser et avec une interface plus dans la philosophie Mac.
  • Navicat MySQL, qui coûte entre 79$ et 149$ et qui propose une version lite gratuite. Elle n'est pas la plus orienté Mac, mais elle propose la gestion des tunnels SSH ce qui est très pratique pour gérer les serveurs MySQL distants. C'est en ce qui me concerne le logiciel que j'ai choisi (la version lite). Il existe en plus une version pour PostgreSQL et une version pour Oracle si vous n'utilisez pas MySQL.

Edit : Un test de Querious et Sequel Pro est disponible sur MySQL Showdown: Querious vs. Sequel Pro

Création d'un groupe Cocoaheads Paris

23 02 2009 In: Conférences

Guillaume Cerquant lance un groupe Cocoaheads sur Paris qui aura lieu le 12 mars 2009 de 19h à 21h et il est à la recherche de personnes pouvant intervenir lors de la soirée. Pour plus d'informations et pour contacter l'organisateur, je vous invite à lire Cocoaheads Paris et à découvrir le site CocoaHeads.

Générateur d'images fractales (5)

23 02 2009 In: Pas à pas

Nous étions restés la fois précédente sur une version un peu lente de notre générateur. Nous allons tenter d'améliorer cela.

Une mise au point s'impose

Je lis fréquemment des gens qui tiennent à peu près ce discours: "Les programmeurs ne tirent pas partie de la puissance des machines, s'ils programmaient en assembleur, les programmes iraient super vite. Ils programment comme des porcs, uniquement pour des raisons financières".

Premièrement, les raisons financières restent de bonnes raisons. Deuxièmement, il faut toujours faire des compromis: programmer efficacement en assembleur est très long, exige des connaissances pointues et le code n'est absolument pas portable, ce qui pose problème quand un logiciel doit être maintenu pendant des années.

Mais surtout, troisièmement, le postulat que les programmes tout-assembleur seraient bien plus rapides est faux ! Dans une application habituelle, 90% du temps est passé dans 10% du code. Cela signifie qu'améliorer ces 10% du code va suffire à accélérer grandement le programme. La bonne stratégie est d'écrire de la façon la plus lisible possible et de n'optimiser que les parties les plus critiques.

L'optimisation… dans l'ordre

  • Choisissez les bons algorithmes
    C'est le moyen le plus sûr d'accélérer un programme. À quoi bon programmer au plus près de la machine s'il existe un algorithme plus efficace par son principe ?
  • Exploitez au mieux le matériel
    Utilisez tous les cœurs de votre micro-processeurs, déléguez les traitements à la carte graphique, profitez des instructions vectorielles
  • Sachez comment fonctionne votre Unix
    C'est le système d'exploitation qui gère les ressources de votre applications, en particulier la mémoire et les fichiers. Ses contraintes peuvent avoir un impact important sur les performances.
  • En dernier recours seulement, travaillez sur le bas niveau
    Dans certaines applications (jeux, calculs 3D), tailler le code au plus près du microprocesseur reste nécessaire.

Dans tous les cas: ME-SU-REZ !
Optimisez seulement après avoir localisé les sources de lenteurs: elles ne sont pas toujours évidentes. En outre, seules les mesures valident l'efficacité des optimisations.

Mesurons notre appli

Commençons donc par mesurer les temps d'exécution:

Mesure avec Shark

  • Sous Xcode, Choisissez l'article du menu Run > Start with Performance Tool > Shark.
  • Cliquez sur le bouton Start.
  • Une fenêtre apparaît (le chemin de notre exécutable est déjà réglé). Cliquez sur OK.
  • L'appli se lance. Redimensionnez la fenêtre continuellement pendant 30 secondes, jusqu'à ce que Shark prenne la main.

Shark avant optimisation

Le résultat n'est pas très surprenant, on trouve en tête nos fonctions qui génèrent l'image. Nous savons où attaquer: ces cinq premières méthodes totalisent plus de 80% du temps d'exécution.

Ensuite, on trouve objc_msgSend_rtp. Il s'agit de la fonction du runtime Objective-C qui permet d'envoyer des messages entre les objets. On peut éventuellement le réduire en envoyant moins de messages…
À vrai dire, ce qui m'étonne sont les 2,7% de setPixel:atX:y:, je pensais que ce serait plus. Il me paraît aussi assez surprenant que _setCGImageRef: apparaisse si haut dans le classement. Voilà pourquoi vous devez mesurer: où les optimisations doivent être faîtes n'est pas toujours évident.

Principe de mesure de Shark
Shark utilise une interruption. Chaque fois qu'elle est déclenchée (toutes les millisecondes, par défaut), Shark note quelle fonction ou méthode est en train d'être exécutée. À la fin, il n'a plus qu'à compter pour établir un classement. Notez qu'il s'agit d'une approche statistique: évaluer le même programme plusieurs fois ne donnera pas les mêmes résultats (les interruptions ne sont pas synchronisées avec le lancement du programme). Il faut admettre une marge d'environ 2%.

Une mesure absolue

L'inconvénient de la mesure avec Shark, c'est qu'elle nous fournit des proportions du temps passé. Ce qui serait intéressant serait d'avoir une mesure du temps de rendu pour mesurer l'amélioration. J'ai donc créé une nouvelle classe, CFMesurePerf pour cela:

#import "CFRMesurePerf.h"

#define IMAGES_A_RENDRE     50

Nous calculons la même image 50 fois de suite. Le temps d'exécution varie: notre programme ne tourne pas tout seul, il y a d'autres processus en parallèle, il faut du temps pour que le système décide de sortir du mode économie d'énergie, etc. . Calculer plusieurs fois permet de lisser les différences.

@implementation CFRMesurePerf

- (id) init
{
    if(self = [super init])
    {
        CFRMandelbrotRender* render = [[CFRMandelbrotRender alloc] init];
        [render setLargeurBitmap:1000];
        [render setHauteurBitmap:1000];

Nous créons un CFRMandelbrotRender. Il ne sera pas affiché à l'écran; ce qui nous intéresse est son temps de calcul. Nous demandons le calcul d'un million de points.

        NSDate* dateDepart = [NSDate date];

        // Rendre l'image IMAGES_A_RENDRE fois
        int image;
        for(image = 0; image < IMAGES_A_RENDRE; image++)
        {
            [render bitmapImageRep];
        }

        NSDate* dateFin = [NSDate date];

Nous notons la date de début, rendons les 50 images, puis notons la date de fin.

        float secondesEcoulees = [dateFin timeIntervalSinceDate:dateDepart];
        int imagesARendre = IMAGES_A_RENDRE;
        NSLog(@"%d images rendues en %f secondes.", imagesARendre, secondesEcoulees);
        NSLog(@"Moyenne = %f images/s", IMAGES_A_RENDRE/secondesEcoulees);

La différence entre les deux dates nous fournit la durée du calcul. Nous pouvons en déduire la moyenne.

    }

    return self;
}

@end

J'ai choisi d'instancier cette classe à partir de MyDocument.xib. Je vous laisse faire.

Dorénavant, lorsque le programme se lance, il va calculer 50 images. C'est assez long, soyez patients! Il faut plus d'une minute sur mon G5, avec une moyenne de 0,79 images/seconde.

Appels à complexeAvecCoordBitmapX:y:

Passons maintenant à une optimisation de l'algorithme. La méthode -[complexeAvecCoordBitmapX:y] est actuellement appelée pour chaque point. Ce n'est absolument pas nécessaire. Il nous suffit de calculer de combien il faut incrémenter les coordonnées pour passer d'un point à un autre du plan.

Ainsi:
incrementX = (dernierPoint.reel - premierPoint.reel) / largeurBitmap;
incrementY = (dernierPoint.imag - premierPoint.imag) / hauteurBitmap;

Nous obtenons alors la méthode de rendu suivante:

// Créer la bitmap
NSBitmapImageRep* bitmapRep = [[NSBitmapImageRep alloc]
    initWithBitmapDataPlanes:NULL
    pixelsWide:largeurBitmap
    pixelsHigh:hauteurBitmap
    bitsPerSample:8
    samplesPerPixel:1
    hasAlpha:NO
    isPlanar:NO
    colorSpaceName:NSDeviceWhiteColorSpace
    bytesPerRow:0
    bitsPerPixel:8];

// Déterminer les incréments des coordonnées
Complexe_t premierPoint, dernierPoint;
premierPoint = [self complexeAvecCoordBitmapX:0 y:0];
dernierPoint = [self complexeAvecCoordBitmapX:largeurBitmap-1 y:hauteurBitmap-1];

Calculer les coordonnées des points extrêmes se fait encore avec notre bonne vieille méthode.

double incX = (dernierPoint.reel - premierPoint.reel) / largeurBitmap;
double incY = (dernierPoint.imag - premierPoint.imag) / hauteurBitmap;

Voir la formule plus haut.

// Calculer l'ensemble de Mandelbrot:
// Parcourir tous les points de la bitmap
double x, y;
Complexe_t c = premierPoint;

c est maintenant initialisé avec le premier point.

for(x = 0; x < largeurBitmap; x++)
{
    for(y = 0; y < hauteurBitmap; y++)
    {       
        // Initialiser z[0]
        Complexe_t z = {0.0, 0.0};

        NSUInteger n;
        for(n=0; n < MAX_ITERATIONS; n++)
        {
            // z[n+1] = z[n+1]^2 + c
            z = Additionner(Carre(z), c);

            // La suite diverge si |z| > 2
            if(ModuleAuCarre(z) > 4.0)
                break;
        }

        // Donner le niveau de gris au pixel
        NSUInteger nuance = n * 255 / MAX_ITERATIONS;
        [bitmapRep setPixel:&nuance atX:x y:y];

        c.imag += incY;

Nous incrémentons donc l'ordonnée ici.

    }

    c.imag = premierPoint.imag;
    c.reel += incX;

Il ne faut pas oublier de replacer l'ordonnée en haut du plan. Ensuite, nous incrémentons l'abscisse.

}

[bitmapRep autorelease];
return bitmapRep;

Au niveau des performances, j'atteins maintenant les 1,06 images/s, soit un gain de 34%. Pas mal !

Placer les fonctions mathématiques "en ligne"

En mettant un compteur dans la boucle for, vous sauriez qu'elle est exécutée 4 239 692 fois. Autant dire que tout ce qui s'y trouve est critique. Or, un appel de fonction réserve de la mémoire sur la pile et copie les paramètres. Il ne s'agit pas d'opérations particulièrement lourdes, mais quand on le fait 4 millions de fois, cela devient très significatif. Nous n'allons donc plus faire d'appels aux fonctions, mais les incorporer:

Complexe_t z = {0.0, 0.0};
Complexe_t zCarre;
NSUInteger n;
for(n=0; n < MAX_ITERATIONS; n++)
{
    // z[n+1] = z[n+1]^2 + c
        // Mettre z au carré
    zCarre.reel = z.reel*z.reel - z.imag*z.imag;
    zCarre.imag = 2.0 * z.reel * z.imag;  
        // Ajouter c
    z.reel = zCarre.reel + c.reel;
    z.imag = zCarre.imag + c.imag;

    // La suite diverge si |z| > 2
    if( (z.reel*z.reel + z.imag*z.imag) > 4.0)
        break;
}

Le résultat est sans appel: il ne faut plus que 24 s pour rendre les 50 images, soit une moyenne de 2,06 images/s — quasiment deux fois plus vite. La méthode est par contre moins lisible: c'est habituel dès que l'on optimise. Il s'agit toujours d'un compromis entre la vitesse et la maintenabilité du code.

La suite

Il nous reste une dernière optimisation à faire, mais comme elle nécessite des explications, je m'arrête là pour cette fois. À bientôt.

Le projet XCode complet à télécharger.

Renaud Pradenc
Céroce.com