D'ailleurs, SmartEiffel dépend toujours d'un compilateur C pour produire un exécutable, je vois difficilement comment on peut faire plus rapide que du C en produisant du C...
Euhh.... Alors là, c'est une affirmation gratuite (ou un sophisme, comme tu veux).
Il ne faut pas oublier qu'un humain qui programme en C organise, structure son code et son algorithme en fonction d'une représentation, d'une typologie et pour être plus exacte, dans une ontologie qui reste humaine, et n'est donc pas forcément adapté à la machine.
Les langages objet, surtout quand ils sont objets jusqu'au bout (quand la conditionnelle est défini dans la librairie et non dans le compilateur par exemple), permettent au compilateur, grâce à la sémantique du langage, d'otpimiser au mieux le code, en inlinant d'une part et d'autres part en spécialisant celui-ci au contexte.
Par exemple, en C, tu as un gros tableau de char (pour de la vidéo par exemple) et tu copie celui-ci, ou encore tu effectue un calcul simple sur celui-ci. Lorsque tu copie ton tableau, tu vas copier des chars, alors que copier des long reviendrai au même et serait plus rapide. Tu peux aussi porter ton calcul effectué char par char sur un long en refaisant la formule (c'est plus dur à implémenter ça déjà, mais avec les outils théorique que l'on possède c'est possible pour des cas simples).
Tu peux alors concevoir ton compilo, de sorte qu'il analyse le code et - pour la copie par exemple - t'optimise tout en 32 bits ou 64...
Il y a aussi énormément de jeu de réécriture d'algo qui te permettent d'améliorer ses performances mais qui restent très chiant à écrire et qui t'oblige à gérer un codce imbitable. Par exemple dans certains cas, utiliser un goto label en C est plus rapide car c'est plus proche d'un code ASM.
Pour un humain, au bout de 5,6 imbications ça devient prise de tête.
Pas pour un compilo...
Ne laissez jamais un humain faire le travail d'un programme...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est encore programmé en C ?!
Posté par Ontologia (site web personnel) . En réponse à la dépêche Le moteur du jeu Quake 3 en GPL. Évalué à 5.
Euhh.... Alors là, c'est une affirmation gratuite (ou un sophisme, comme tu veux).
Il ne faut pas oublier qu'un humain qui programme en C organise, structure son code et son algorithme en fonction d'une représentation, d'une typologie et pour être plus exacte, dans une ontologie qui reste humaine, et n'est donc pas forcément adapté à la machine.
Les langages objet, surtout quand ils sont objets jusqu'au bout (quand la conditionnelle est défini dans la librairie et non dans le compilateur par exemple), permettent au compilateur, grâce à la sémantique du langage, d'otpimiser au mieux le code, en inlinant d'une part et d'autres part en spécialisant celui-ci au contexte.
Par exemple, en C, tu as un gros tableau de char (pour de la vidéo par exemple) et tu copie celui-ci, ou encore tu effectue un calcul simple sur celui-ci. Lorsque tu copie ton tableau, tu vas copier des chars, alors que copier des long reviendrai au même et serait plus rapide. Tu peux aussi porter ton calcul effectué char par char sur un long en refaisant la formule (c'est plus dur à implémenter ça déjà, mais avec les outils théorique que l'on possède c'est possible pour des cas simples).
Tu peux alors concevoir ton compilo, de sorte qu'il analyse le code et - pour la copie par exemple - t'optimise tout en 32 bits ou 64...
Il y a aussi énormément de jeu de réécriture d'algo qui te permettent d'améliorer ses performances mais qui restent très chiant à écrire et qui t'oblige à gérer un codce imbitable. Par exemple dans certains cas, utiliser un goto label en C est plus rapide car c'est plus proche d'un code ASM.
Pour un humain, au bout de 5,6 imbications ça devient prise de tête.
Pas pour un compilo...
Ne laissez jamais un humain faire le travail d'un programme...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker