Les deux sont clairement intéressants.
Un code fiable, c'est utile (parce que faire un truc inexploitable rapidement, c'est inutile), un code rapide aussi (parce que réaliser des calculs tellement lentement que le résultat est obsolète quand on l'a, c'est tout aussi inutile).
Et il y a d'autres avantages aussi, comme la compacité du blob, la possibilité de vérifier que les dépendances sont installées (à plusieurs reprises j'ai eu ce genre de problèmes avec des paquets debian qui contenaient des applications pythons: libfoobar.so non trouvée. Amuses-toi à retrouver le paquet qui aurait dû être installé automatiquement...) via des outils comme ldd, la possibilité même de lier en statique pour avoir un truc vraiment petit et qui démarre à la vitesse de l'éclair...
Je disais juste que, personnellement, en tant que développeur, ce que j'apprécie le plus chez les compilateurs, c'est bien le fait qu'ils peuvent me signaler quand je fais de la merde (et ça arrive assez souvent pour que je n'aie aucune envie d'utiliser sérieusement des langages interprétés).
Si la vitesse est vraiment critique, je pense qu'il faut déjà réfléchir l'application autrement, et pas juste la passer à un compilo.
Déjà, ça va dépendre du CPU cible: s'il a, ou non, des caches, combien de coeurs logiques sont présents, est-ce que l'application à vraiment besoin de pointeurs de 64 bits (parce que 8 octets, sur une ligne de cache, ça fait beaucoup, alors que pour pas mal d'applications 4 suffiraient probablement).
Ensuite il y a l'architecture du soft.
Bref, c'est toujours sympa de récupérer de la vitesse, mais si c'est critique, je doute que juste passer dans une moulinette soit la façon la plus efficace de travailler.
[^] # Re: la vitesse d'exécution n'est pas le principal intérêt d'un compilateur à mes yeux.
Posté par freem . En réponse au journal Pythran 0.8.5 - de l'intérêt des compilateurs. Évalué à 5.
Les deux sont clairement intéressants.
Un code fiable, c'est utile (parce que faire un truc inexploitable rapidement, c'est inutile), un code rapide aussi (parce que réaliser des calculs tellement lentement que le résultat est obsolète quand on l'a, c'est tout aussi inutile).
Et il y a d'autres avantages aussi, comme la compacité du blob, la possibilité de vérifier que les dépendances sont installées (à plusieurs reprises j'ai eu ce genre de problèmes avec des paquets debian qui contenaient des applications pythons: libfoobar.so non trouvée. Amuses-toi à retrouver le paquet qui aurait dû être installé automatiquement...) via des outils comme ldd, la possibilité même de lier en statique pour avoir un truc vraiment petit et qui démarre à la vitesse de l'éclair...
Je disais juste que, personnellement, en tant que développeur, ce que j'apprécie le plus chez les compilateurs, c'est bien le fait qu'ils peuvent me signaler quand je fais de la merde (et ça arrive assez souvent pour que je n'aie aucune envie d'utiliser sérieusement des langages interprétés).
Si la vitesse est vraiment critique, je pense qu'il faut déjà réfléchir l'application autrement, et pas juste la passer à un compilo.
Déjà, ça va dépendre du CPU cible: s'il a, ou non, des caches, combien de coeurs logiques sont présents, est-ce que l'application à vraiment besoin de pointeurs de 64 bits (parce que 8 octets, sur une ligne de cache, ça fait beaucoup, alors que pour pas mal d'applications 4 suffiraient probablement).
Ensuite il y a l'architecture du soft.
Bref, c'est toujours sympa de récupérer de la vitesse, mais si c'est critique, je doute que juste passer dans une moulinette soit la façon la plus efficace de travailler.