Intéressant. On dirait que Swift semble beaucoup plus sensible au niveaux d'optimisation sélectionné. Il faut que je prenne le temps d'investiguer côté NSBitmapImageRep pour me mettre dans un vrai cas concret.
ça devient difficile de comparer, parce qu'on pourrait se passer des objets coté Objective-C aussi pour améliorer les résultats mais en terme de facilité d'écriture du code et de souplesse des éléments à manipuler, les structures en Swift semblent vraiment meilleures. Elles sont d'ailleurs bien plus sollicitées qu'en Objective-C... ils en parlent beaucoup dans les démos et la doc.
C'est pour ça que je demandais à voir le code d'Apple car effectivement si on compare pure Obj-C vs Swift il est assez logique que Swift prenne l'avantage sur du tout objet. Hors en Obj-C, il faut être bien benêt pour passer sont temps à manipuler des chiffres avec des NSNumber par exemple. Ou alors on est pas surpris d'obtenir des perfs lamentables comme Numbers... ;D
J'avoue être assez séduit par la syntaxe de Swift (même si je peste encore à trouver mes marques tellement je suis habitué à l'Obj-C/C). Par contre, je rejoins l'avis de certains sur le fait qu'il est loin d'être "plus facile".
Au passage, je viens de voir qu'il n'est pas possible de mixer du C++ sans passer par un wrapper C ou Obj-C. Ca c'est un peu dommage.
On a dérivé mais ce n'était pas ma question de départ. Je voulais pouvoir taper sur des typages de base pour justement jouer avec des pixels d'une NSBitmapImageRep. Donc pour me faire les dents en attendant sur la syntaxe, je me suis amusé avec une boucle à 2 balles. Mais force est de constater qu'il y a bien un loup jusqu'à preuve du contraire.
En fait, le test de la boucle compare swift à du C, pas à de l'objective-C. Pour du code qui bouge des buffers de droite à gauche et fait du calcul matricielle, il faudra sans doute continuer à faire du C.
Sur 10 mètres un homme cours plus vite qu'un cheval, mais sur 100m ou 1000m, le cheval gagne largement. Pour Swift c'est pareil, il faut le laisser déployer sa force.
Pour du code objet avec des méthodes virtuels, des collections d'objet, des getters et des setters dans tous les sens, il est possible que Swift soit plus rapide. Le fait que l'utilisation des pointeurs soit restreinte, fait que le compilateur peut faire des optimisations supplementaires. En objective-C, il y a toujours la possibilité de faire de l'arithmetique sur les pointeurs et donc tous les objets sont modifiables à tout instant sans que le compilateur puisse le prevoir. C'est un peu comme faire des contrôles migratoires dans un monde où la teleportation existe.
On est bien d'accord. Moi juste ce qui me gène dans ce que tu dis c'est "il faudra sans doute continuer à faire du C". On est en droit d'attendre mieux d'un nouveau langage qu'une énième couche d'abstraction.
Pour moi le "mieux", c'est un langage pragmatique qui tient compte de l'existant.
Le 'C' existe et cela n'a pas d'interet de depenser des ressources à tenter de creer un langage idéal qui ferait le grand ecart entre un langage moderne et les performances du 'C'.
Pour d'autres, le 'mieux' c'est de faire table rase et de viser l'idéal. Je pense que ce mieux est l'ennemi du bien et conduit à des compromis qui sont cachés.
Le compromis choisi par Apple me convient bien, d'ailleurs je n'ai jamais compris l'intérêt des langages basés sur des IL type java ou C#.
Je suis plus inquiet sur la gestion des retain cycle en Swift qu'il faudra continuer a surveiller alors que tous les autres aspects de la gestion des allocations mémoires ont ete supprimés.
Réponses
Intéressant. On dirait que Swift semble beaucoup plus sensible au niveaux d'optimisation sélectionné. Il faut que je prenne le temps d'investiguer côté NSBitmapImageRep pour me mettre dans un vrai cas concret.
C'est pour ça que je demandais à voir le code d'Apple car effectivement si on compare pure Obj-C vs Swift il est assez logique que Swift prenne l'avantage sur du tout objet. Hors en Obj-C, il faut être bien benêt pour passer sont temps à manipuler des chiffres avec des NSNumber par exemple. Ou alors on est pas surpris d'obtenir des perfs lamentables comme Numbers... ;D
J'avoue être assez séduit par la syntaxe de Swift (même si je peste encore à trouver mes marques tellement je suis habitué à l'Obj-C/C). Par contre, je rejoins l'avis de certains sur le fait qu'il est loin d'être "plus facile".
Au passage, je viens de voir qu'il n'est pas possible de mixer du C++ sans passer par un wrapper C ou Obj-C. Ca c'est un peu dommage.
En fait, le test de la boucle compare swift à du C, pas à de l'objective-C. Pour du code qui bouge des buffers de droite à gauche et fait du calcul matricielle, il faudra sans doute continuer à faire du C.
Sur 10 mètres un homme cours plus vite qu'un cheval, mais sur 100m ou 1000m, le cheval gagne largement. Pour Swift c'est pareil, il faut le laisser déployer sa force.
Pour du code objet avec des méthodes virtuels, des collections d'objet, des getters et des setters dans tous les sens, il est possible que Swift soit plus rapide. Le fait que l'utilisation des pointeurs soit restreinte, fait que le compilateur peut faire des optimisations supplementaires. En objective-C, il y a toujours la possibilité de faire de l'arithmetique sur les pointeurs et donc tous les objets sont modifiables à tout instant sans que le compilateur puisse le prevoir. C'est un peu comme faire des contrôles migratoires dans un monde où la teleportation existe.
On est bien d'accord. Moi juste ce qui me gène dans ce que tu dis c'est "il faudra sans doute continuer à faire du C". On est en droit d'attendre mieux d'un nouveau langage qu'une énième couche d'abstraction.
Pour moi le "mieux", c'est un langage pragmatique qui tient compte de l'existant.
Le 'C' existe et cela n'a pas d'interet de depenser des ressources à tenter de creer un langage idéal qui ferait le grand ecart entre un langage moderne et les performances du 'C'.
Pour d'autres, le 'mieux' c'est de faire table rase et de viser l'idéal. Je pense que ce mieux est l'ennemi du bien et conduit à des compromis qui sont cachés.
Le compromis choisi par Apple me convient bien, d'ailleurs je n'ai jamais compris l'intérêt des langages basés sur des IL type java ou C#.
Je suis plus inquiet sur la gestion des retain cycle en Swift qu'il faudra continuer a surveiller alors que tous les autres aspects de la gestion des allocations mémoires ont ete supprimés.