Je suis impatient de voir le compilateur 64 bits final à l'œuvre.
Après l'avoir défendu ardemment pendant très longtemps (envers et contre tous), j'ai finalement dû abandonner Delphi en 2006 à cause de son non support de la compilation native 64 bits. FPC n'est pas une alternative sérieuse pour bien des raisons liées à sa conception. Il a donc fallu passer intégralement au C/C++ sous Visual Studio, qui permet de compiler en 32, AMD64 et IA64 depuis un sacré bout de temps. Dans l'imagerie numérique pro, la 3D et le montage vidéo, les OS 64 bits sont adoptés depuis longtemps (pour la quantité de RAM adressable). L'avantage d'un OS 64 bits est triple : c'est le "langage" natif des processeurs depuis quelques années (les pipelines sont optimisés pour le 64 bits), le plus grand nombre de registres permet enfin de coder efficacement en utilisant moins intensivement la pile et le stockage en mémoire, et bien sur le modèle mémoire permet d'utiliser des applications très gourmandes bien plus efficacement. De plus, sous Windows x64, le sous-système WOW64 pourtant très efficace qui gère les applications 32 bits introduit également des petites pénalités de performances : le basculement du processeur en mode 32 ou 64 bits, la traduction des chemins d'accès ainsi que les wrappers permettant la traduction des conventions d'appel et taille des paramètres a forcement un léger coût, que l'on ressent très nettement si beaucoup d'applications 32 bits tournent en même temps. Et sur plateforme IA64, c'est encore pire vu que le x86 est entièrement émulé...
Bien sur, recompiler un projet prévu pour du 32 bits (utilisant des int 32) en 64 bits n'apportera pas grand chose sinon rien en terme de performances, l'intérêt étant de prévoir son code pour tirer parti des spécificités de l'architecture 64 bits.
Le traitement d'images n'a aucun rapport avec la résolution du processeur ou de l'OS. Une image 8 bits reste 8 bits, une 32 bits reste 32 bits, indépendamment de l'OS ou du processeur. On traitait des images 32 bits sur des processeurs 8 bits (comme les premières palettes graphiques pro qui tournaient sous Z80), et on traite des images 8 bits sur des processeurs 64 bits, cela n'a strictement aucun rapport et ne change rien pour un programmeur en c ou pascal. Les espaces de couleur avec des composants de 16 bits (4x16 = 64) sont réservés à des traitements très spécifiques qui n'ont pas lieu d'être pour le commun des mortels. Par contre, cela fait plus de 10 ans que l'on traite les images grâce aux instructions et registres 64 bits introduits avec le mmx, puis 3D now, SSE, etc... Ainsi, en effet, on peut traiter 2 pixels 32 bits à la fois, 4 pixels 16 bits ou 8 pixels 8 bits (bien que cela ne présente que peu d'intérêt pour les formats palétisés). Cela est aussi très efficace pour le traitement audio. La librairie delphi Graphics32 utilise d'ailleurs abondamment cela pour gérer le blending et l'anti-aliasing de manière 100% software. Mais pour gérer efficacement du traitement d'images, rien n'égale DirectX sous Windows, qui est relativement simple à utiliser et permet de plus de bien comprendre comment les cartes vidéo gèrent les pixels et les espaces de couleur. Le type pf32bit sous delphi, si ma mémoire est bonne, est géré via une DibSection, qui reste le meilleur moyen software de gérer une image bitmap sous GDI, à la manière de DirectDraw. En 2005, j'ai créé une librairie de traitement graphique professionnelle multi-plateformes (d'abord écrite sous delphi puis portée très facilement sous C++), et l'utilisation des dibsection et de SetDIBitsToDevice() sous Windows permettait de limiter le code dépendant Win32 à quelques lignes seulement (tout le traitement possible sur les images en mode software ne nécessitant strictement aucune API ou fonction externe, uniquement des calculs et beaucoup de code machine optimisé pour chaque plateforme cible).
2 |
0 |
Envoyé par Caribensila
