Aller au contenu


jp

Inscrit(e) : 26 janv. 2006
Hors-ligne Dernière activité : nov. 16 2017 18:07
*****

#214962 Le retour (ou pas) d'AliGator

Posted by jp on 19 avril 2013 - 22:20

Bien sûr, Realstudio n'a jamais admis qu'il utilisait un RunTime. Ils m'ont toujours dit que les programmes était compilés et non semi-interprétés. Ca se voit pourtant par le fait que c'est moins rapide que du C :)

Ca n’empêche que j'aime beaucoup ce qu'il ont fait du vieux basic.



J'ai bien peur qu'Aligator se trompe à ce sujet :s

REALbasic génère bien du code i386 / x86_64 qui peut être désassemblé sans aucun problème par tout logiciel capable de désassembler du code Intel (otool, gdb, IDA, Hopper Disassembler, etc.).
Pas de byte code ni de machine virtuelle à la java, justement. Le "RunTime" est une espèce de grosse bibliothèque ("rbframework.dylib" de mon temps) qui est linkée au binaire générée, et qui est chargée de gérer tout l'API "REALbasic". Ça va de ce qui est propre au langage RB, jusqu'à la surcouche d'abstraction avec les API système (affichage des fenêtres, gestion du clavier, souris, etc.).
D'ailleurs, les applications sont dans un format Mach-O tout à fait standard (vérifiable via otool ou MachOView), qui possède même une table de symbole très complète avec entre autre toute vos fonctions dedans.

Si les applications sont si lourdes, c'est parce que cette bibliothèque contient énormément de choses, et qu'elle n'est pas linkée statiquement (donc pas de possibilité d'inclure au link uniquement les éléments du RunTime effectivement utilisés).
Si les applications sont si lentes, c'est parce que le code processeur généré n’est vraiment pas optimal - assez basique, brute, sans intelligence, et que le code RB lui-même n'est pas optimisé non plus. Et puis finalement, toute la surcouche d'abstraction, ainsi que la gestion des éléments propres au langage, n'améliore rien.

Quand on voit les optimisations que peut faire LLVM sur du C (qui est un langage bas niveau qui force plus que RB à écrire un code qui est proche de ce que va effectivement faire le processeur)... Par exemple, sur les optimisations qu'il peut faire sur les comportements non définis par le langage ! Mais il y a des tonne d'autres : dérécursification, optimisation de boucles, etc.

Quand on vois également des fonctions dans le Runtime Objective-C (/usr/lib/libobjc.A.dylib) comme objc_msgSend, qui est chargé de dispatcher les envois de message et d'appeler les codes des méthodes : système de cache, optimisation de malade. Très critique, très souvent appelé, très optimisé. Pas simple dans un environnement objet.

RB est très loin de tout ça.