Salut, à savoir, notamment, les options -march=pentium4 -sse2 -mfpmath=sse ?
Est-ce que l'utilisation de ces options produit vraiment un meilleur code sur une machine à P4 ?
Je n'ai pas de p4 sous la main (beurk, un proc intel ;) mais à priori c'est sensé avoir un effet sur certains codes (par exemple, je sais que l'an dernier les étudiants qui faisaient du calcul par chez nous ont vu la diff sur de la multiplication de matrices ... enfin, moi je multiplie des matrices tous les jours ... ;)
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon la différence de perf est TRÈS impressionnante ... à quand de vrai optim dans gcc ...)
On Mon, 5 Jan 2004 19:12:41 +0100
Vincent <0@free.fr> wrote:
Salut,
à savoir, notamment, les options -march=pentium4 -sse2 -mfpmath=sse ?
Est-ce que l'utilisation de ces options produit vraiment un meilleur
code sur une machine à P4 ?
Je n'ai pas de p4 sous la main (beurk, un proc intel ;) mais à priori
c'est sensé avoir un effet sur certains codes (par exemple, je sais que
l'an dernier les étudiants qui faisaient du calcul par chez nous ont vu
la diff sur de la multiplication de matrices ... enfin, moi je multiplie
des matrices tous les jours ... ;)
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc
intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon
la différence de perf est TRÈS impressionnante ... à quand de vrai optim
dans gcc ...)
Salut, à savoir, notamment, les options -march=pentium4 -sse2 -mfpmath=sse ?
Est-ce que l'utilisation de ces options produit vraiment un meilleur code sur une machine à P4 ?
Je n'ai pas de p4 sous la main (beurk, un proc intel ;) mais à priori c'est sensé avoir un effet sur certains codes (par exemple, je sais que l'an dernier les étudiants qui faisaient du calcul par chez nous ont vu la diff sur de la multiplication de matrices ... enfin, moi je multiplie des matrices tous les jours ... ;)
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon la différence de perf est TRÈS impressionnante ... à quand de vrai optim dans gcc ...)
Je n'ai pas de p4 sous la main (beurk, un proc intel ;) mais à priori c'est sensé avoir un effet sur certains codes (par exemple, je sais que l'an dernier les étudiants qui faisaient du calcul par chez nous ont vu la diff sur de la multiplication de matrices ... enfin, moi je multiplie des matrices tous les jours ... ;)
Et bien, quelle honte ! Multiplier des matrices, mon Dieu, ô tempora, ô mores ! :) Dans des boîtes de Pétri ? :)
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon la différence de perf est TRÈS impressionnante ... à quand de vrai optim dans gcc ...)
Ben je l'ai installé. J'ai fait un test avec un programme pourtant de calcul intensif, blandeenc, qui transforme du wav en mp3. Je n'ai trouvé que 5 à 10 % de gain, c'est plutôt décevant. Alors c'est peut-être dû au surcoût des couches d'adaptation Linux ?
Vincent
PS : icc pour Linux est gratos pour des applications non-commerciales.
Marwan Burelle <burelle@lri.fr> dixit :
Je n'ai pas de p4 sous la main (beurk, un proc intel ;) mais à priori
c'est sensé avoir un effet sur certains codes (par exemple, je sais
que l'an dernier les étudiants qui faisaient du calcul par chez nous
ont vu la diff sur de la multiplication de matrices ... enfin, moi je
multiplie des matrices tous les jours ... ;)
Et bien, quelle honte ! Multiplier des matrices, mon Dieu, ô tempora, ô
mores ! :) Dans des boîtes de Pétri ? :)
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc
intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais
bon la différence de perf est TRÈS impressionnante ... à quand de vrai
optim dans gcc ...)
Ben je l'ai installé. J'ai fait un test avec un programme pourtant de
calcul intensif, blandeenc, qui transforme du wav en mp3. Je n'ai trouvé
que 5 à 10 % de gain, c'est plutôt décevant. Alors c'est peut-être dû au
surcoût des couches d'adaptation Linux ?
Vincent
PS : icc pour Linux est gratos pour des applications non-commerciales.
Je n'ai pas de p4 sous la main (beurk, un proc intel ;) mais à priori c'est sensé avoir un effet sur certains codes (par exemple, je sais que l'an dernier les étudiants qui faisaient du calcul par chez nous ont vu la diff sur de la multiplication de matrices ... enfin, moi je multiplie des matrices tous les jours ... ;)
Et bien, quelle honte ! Multiplier des matrices, mon Dieu, ô tempora, ô mores ! :) Dans des boîtes de Pétri ? :)
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon la différence de perf est TRÈS impressionnante ... à quand de vrai optim dans gcc ...)
Ben je l'ai installé. J'ai fait un test avec un programme pourtant de calcul intensif, blandeenc, qui transforme du wav en mp3. Je n'ai trouvé que 5 à 10 % de gain, c'est plutôt décevant. Alors c'est peut-être dû au surcoût des couches d'adaptation Linux ?
Vincent
PS : icc pour Linux est gratos pour des applications non-commerciales.
Marwan Burelle
On Mon, 5 Jan 2004 19:32:39 +0100 Vincent wrote:
Ben je l'ai installé. J'ai fait un test avec un programme pourtant de calcul intensif, blandeenc, qui transforme du wav en mp3. Je n'ai trouvé que 5 à 10 % de gain, c'est plutôt décevant. Alors c'est peut-être dû au surcoût des couches d'adaptation Linux ?
Je ne connais pas exactement toutes les spécificités d'icc (l'archi je n'y touche plus, moi ce que je préfère dans les compilos c'est le typage ;), mais tu dois avoir des trucs qui vont prendre pas mal, surtout, si à l'origine le code C était peu optimiser, et d'autre pour lequel il n'y aura que peu de différence ...
La couche d'émul linux ne devrait pas ralentir outre mesure (voir dans la faq l'explication exact du support des binaires linux.)
On Mon, 5 Jan 2004 19:32:39 +0100
Vincent <0@free.fr> wrote:
Ben je l'ai installé. J'ai fait un test avec un programme pourtant de
calcul intensif, blandeenc, qui transforme du wav en mp3. Je n'ai
trouvé que 5 à 10 % de gain, c'est plutôt décevant. Alors c'est
peut-être dû au surcoût des couches d'adaptation Linux ?
Je ne connais pas exactement toutes les spécificités d'icc (l'archi je n'y
touche plus, moi ce que je préfère dans les compilos c'est le typage ;),
mais tu dois avoir des trucs qui vont prendre pas mal, surtout, si à
l'origine le code C était peu optimiser, et d'autre pour lequel il n'y
aura que peu de différence ...
La couche d'émul linux ne devrait pas ralentir outre mesure (voir dans la
faq l'explication exact du support des binaires linux.)
Ben je l'ai installé. J'ai fait un test avec un programme pourtant de calcul intensif, blandeenc, qui transforme du wav en mp3. Je n'ai trouvé que 5 à 10 % de gain, c'est plutôt décevant. Alors c'est peut-être dû au surcoût des couches d'adaptation Linux ?
Je ne connais pas exactement toutes les spécificités d'icc (l'archi je n'y touche plus, moi ce que je préfère dans les compilos c'est le typage ;), mais tu dois avoir des trucs qui vont prendre pas mal, surtout, si à l'origine le code C était peu optimiser, et d'autre pour lequel il n'y aura que peu de différence ...
La couche d'émul linux ne devrait pas ralentir outre mesure (voir dans la faq l'explication exact du support des binaires linux.)
Je ne connais pas exactement toutes les spécificités d'icc (l'archi je n'y touche plus, moi ce que je préfère dans les compilos c'est le typage ;), mais tu dois avoir des trucs qui vont prendre pas mal, surtout, si à l'origine le code C était peu optimiser, et d'autre pour lequel il n'y aura que peu de différence ...
Bof, le typage. Faut dire que moi, je viens du hardware ! Mon langage favori, c'est l'assembleur, 68000 de préférence :)
Je pense qu'il y a sans doute un problème de ce côté. En fait, le compilo ne peut pas optimiser les boucles mal écrite tout seul !
La couche d'émul linux ne devrait pas ralentir outre mesure (voir dans la faq l'explication exact du support des binaires linux.)
Oui, je sais, elle n'intervient grosso modo de toute façon que lors des appels systèmes.
Vincent
Marwan Burelle <burelle@lri.fr> dixit :
Je ne connais pas exactement toutes les spécificités d'icc (l'archi je
n'y touche plus, moi ce que je préfère dans les compilos c'est le
typage ;), mais tu dois avoir des trucs qui vont prendre pas mal,
surtout, si à l'origine le code C était peu optimiser, et d'autre pour
lequel il n'y aura que peu de différence ...
Bof, le typage. Faut dire que moi, je viens du hardware ! Mon langage
favori, c'est l'assembleur, 68000 de préférence :)
Je pense qu'il y a sans doute un problème de ce côté. En fait, le
compilo ne peut pas optimiser les boucles mal écrite tout seul !
La couche d'émul linux ne devrait pas ralentir outre mesure (voir dans
la faq l'explication exact du support des binaires linux.)
Oui, je sais, elle n'intervient grosso modo de toute façon que lors des
appels systèmes.
Je ne connais pas exactement toutes les spécificités d'icc (l'archi je n'y touche plus, moi ce que je préfère dans les compilos c'est le typage ;), mais tu dois avoir des trucs qui vont prendre pas mal, surtout, si à l'origine le code C était peu optimiser, et d'autre pour lequel il n'y aura que peu de différence ...
Bof, le typage. Faut dire que moi, je viens du hardware ! Mon langage favori, c'est l'assembleur, 68000 de préférence :)
Je pense qu'il y a sans doute un problème de ce côté. En fait, le compilo ne peut pas optimiser les boucles mal écrite tout seul !
La couche d'émul linux ne devrait pas ralentir outre mesure (voir dans la faq l'explication exact du support des binaires linux.)
Oui, je sais, elle n'intervient grosso modo de toute façon que lors des appels systèmes.
Vincent
talon
Marwan Burelle wrote:
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon la différence de perf est TRÈS impressionnante ... à quand de vrai optim dans gcc ...)
La différence est devenue trés peu impressionnante avec les derniers gcc et quelques options d'optimisation bien senties.
--
Michel TALON
Marwan Burelle <burelle@lri.fr> wrote:
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc
intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon
la différence de perf est TRÈS impressionnante ... à quand de vrai optim
dans gcc ...)
La différence est devenue trés peu impressionnante avec les derniers gcc
et quelques options d'optimisation bien senties.
Maintenant, si vraiment tu veux du code optimiser à mort pour un proc intel, regarde du côté d'icc (oui, je sais, c'est pas gratos ... mais bon la différence de perf est TRÈS impressionnante ... à quand de vrai optim dans gcc ...)
La différence est devenue trés peu impressionnante avec les derniers gcc et quelques options d'optimisation bien senties.
--
Michel TALON
pornin
According to Vincent :
Bof, le typage. Faut dire que moi, je viens du hardware ! Mon langage favori, c'est l'assembleur, 68000 de préférence :)
Je pense qu'il y a sans doute un problème de ce côté. En fait, le compilo ne peut pas optimiser les boucles mal écrite tout seul !
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes de base sont nazes, le programme généré sera naze, c'est tout.
Ce qui peut aider le compilateur, c'est quand on lui indique le plus de choses possible sur ce que fait le code, ce qu'il advient de chaque variable et de chaque valeur. Et ce qui permet ça, c'est justement... le typage !
--Thomas Pornin
According to Vincent <10.50@free.fr>:
Bof, le typage. Faut dire que moi, je viens du hardware ! Mon langage
favori, c'est l'assembleur, 68000 de préférence :)
Je pense qu'il y a sans doute un problème de ce côté. En fait, le
compilo ne peut pas optimiser les boucles mal écrite tout seul !
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes
de base sont nazes, le programme généré sera naze, c'est tout.
Ce qui peut aider le compilateur, c'est quand on lui indique le plus
de choses possible sur ce que fait le code, ce qu'il advient de chaque
variable et de chaque valeur. Et ce qui permet ça, c'est justement...
le typage !
Bof, le typage. Faut dire que moi, je viens du hardware ! Mon langage favori, c'est l'assembleur, 68000 de préférence :)
Je pense qu'il y a sans doute un problème de ce côté. En fait, le compilo ne peut pas optimiser les boucles mal écrite tout seul !
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes de base sont nazes, le programme généré sera naze, c'est tout.
Ce qui peut aider le compilateur, c'est quand on lui indique le plus de choses possible sur ce que fait le code, ce qu'il advient de chaque variable et de chaque valeur. Et ce qui permet ça, c'est justement... le typage !
--Thomas Pornin
Vincent
(Thomas Pornin) dixit :
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes de base sont nazes, le programme généré sera naze, c'est tout.
Ben oui, je suis bien d'accord.
Ce qui peut aider le compilateur, c'est quand on lui indique le plus de choses possible sur ce que fait le code, ce qu'il advient de chaque variable et de chaque valeur. Et ce qui permet ça, c'est justement... le typage !
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne réflexion en amont sur le code en lui-même plutôt qu'un recours à des règles strictes et inflexibles... qui me semblent plus réservées au contrôle - a priori - de la cohérence du code.
Enfin, ce que j'en dit. J'ai jamais aimé l'ADA ! :)
Vincent
pornin@nerim.net (Thomas Pornin) dixit :
Le compilateur ne peut pas faire de l'algorithmique. Si les
algorithmes de base sont nazes, le programme généré sera naze, c'est
tout.
Ben oui, je suis bien d'accord.
Ce qui peut aider le compilateur, c'est quand on lui indique le plus
de choses possible sur ce que fait le code, ce qu'il advient de chaque
variable et de chaque valeur. Et ce qui permet ça, c'est justement...
le typage !
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne
réflexion en amont sur le code en lui-même plutôt qu'un recours à
des règles strictes et inflexibles... qui me semblent plus réservées au
contrôle - a priori - de la cohérence du code.
Enfin, ce que j'en dit. J'ai jamais aimé l'ADA ! :)
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes de base sont nazes, le programme généré sera naze, c'est tout.
Ben oui, je suis bien d'accord.
Ce qui peut aider le compilateur, c'est quand on lui indique le plus de choses possible sur ce que fait le code, ce qu'il advient de chaque variable et de chaque valeur. Et ce qui permet ça, c'est justement... le typage !
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne réflexion en amont sur le code en lui-même plutôt qu'un recours à des règles strictes et inflexibles... qui me semblent plus réservées au contrôle - a priori - de la cohérence du code.
Enfin, ce que j'en dit. J'ai jamais aimé l'ADA ! :)
Vincent
pornin
According to Vincent :
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne réflexion en amont sur le code en lui-même plutôt qu'un recours à des règles strictes et inflexibles... qui me semblent plus réservées au contrôle - a priori - de la cohérence du code.
Le typage, c'est l'action consistant à analyser les expressions pour associer un type à toutes les valeurs intermédiaires et finales. Il y a du typage en C, puisque c'est notamment ça qui permet au compilateur de savoir où taper en mémoire quand il rencontre "x[5]" : si "x" est de type "tableau d'int", et que l'int fait 4 octets, alors le compilateur doit aller chercher 4 octets à partir du vingtième octet en partant du début de "x". Si "x" était un tableau de char, le compilateur n'irait chercher qu'un seul octet, et ce serait le cinquième, pas le vingtième.
Le C permet un typage jusqu'à un certain point, mais ses règles ne sont pas assez fines pour être vraiment générique, et on doit souvent passer par une magouille : soit un "void *", soit un cast explicite (le cas le plus standard, c'est quand on veut faire une forme d'héritage : on remplace un pointeur vers une structure par un pointeur vers une autre, qui commence par les mêmes champs). En cas de magouille, on perd la "sécurité" (le compilateur ne peut plus faire de vérification) et éventuellement des performances (comme le compilateur ne sait plus qui est quoi, il doit adopter un profil bas).
Les zélotes des langages fortement typés à la OCaml font leur promotion sur l'aspect "sécurité", souvent vécu comme trop contraignant par les programmeurs "bas niveau" qui aiment bien les magouilles. Mais rien n'interdit de faire un typage complexe avec des portes de sortie (c'est-à-dire la possibilité de faire des casts). Un exemple de langage avec un typage complexe permettant quand même les magouilles, en les rendant néanmoins inutiles, et favorisant l'optimisation, est le C++. Bon, certes, le C++ a une syntaxe qui confine à l'absurde, et son modèle d'implémentation rend son déploiement difficile, mais c'est un autre débat.
--Thomas Pornin
According to Vincent <10.50@free.fr>:
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne
réflexion en amont sur le code en lui-même plutôt qu'un recours à
des règles strictes et inflexibles... qui me semblent plus réservées au
contrôle - a priori - de la cohérence du code.
Le typage, c'est l'action consistant à analyser les expressions pour
associer un type à toutes les valeurs intermédiaires et finales. Il y
a du typage en C, puisque c'est notamment ça qui permet au compilateur
de savoir où taper en mémoire quand il rencontre "x[5]" : si "x" est de
type "tableau d'int", et que l'int fait 4 octets, alors le compilateur
doit aller chercher 4 octets à partir du vingtième octet en partant du
début de "x". Si "x" était un tableau de char, le compilateur n'irait
chercher qu'un seul octet, et ce serait le cinquième, pas le vingtième.
Le C permet un typage jusqu'à un certain point, mais ses règles ne
sont pas assez fines pour être vraiment générique, et on doit souvent
passer par une magouille : soit un "void *", soit un cast explicite (le
cas le plus standard, c'est quand on veut faire une forme d'héritage :
on remplace un pointeur vers une structure par un pointeur vers une
autre, qui commence par les mêmes champs). En cas de magouille, on perd
la "sécurité" (le compilateur ne peut plus faire de vérification) et
éventuellement des performances (comme le compilateur ne sait plus qui
est quoi, il doit adopter un profil bas).
Les zélotes des langages fortement typés à la OCaml font leur promotion
sur l'aspect "sécurité", souvent vécu comme trop contraignant par
les programmeurs "bas niveau" qui aiment bien les magouilles. Mais
rien n'interdit de faire un typage complexe avec des portes de sortie
(c'est-à-dire la possibilité de faire des casts). Un exemple de langage
avec un typage complexe permettant quand même les magouilles, en les
rendant néanmoins inutiles, et favorisant l'optimisation, est le C++.
Bon, certes, le C++ a une syntaxe qui confine à l'absurde, et son modèle
d'implémentation rend son déploiement difficile, mais c'est un autre
débat.
Mouais. À mon avis, c'est un pis-aller, non ? Il vaut mieux une bonne réflexion en amont sur le code en lui-même plutôt qu'un recours à des règles strictes et inflexibles... qui me semblent plus réservées au contrôle - a priori - de la cohérence du code.
Le typage, c'est l'action consistant à analyser les expressions pour associer un type à toutes les valeurs intermédiaires et finales. Il y a du typage en C, puisque c'est notamment ça qui permet au compilateur de savoir où taper en mémoire quand il rencontre "x[5]" : si "x" est de type "tableau d'int", et que l'int fait 4 octets, alors le compilateur doit aller chercher 4 octets à partir du vingtième octet en partant du début de "x". Si "x" était un tableau de char, le compilateur n'irait chercher qu'un seul octet, et ce serait le cinquième, pas le vingtième.
Le C permet un typage jusqu'à un certain point, mais ses règles ne sont pas assez fines pour être vraiment générique, et on doit souvent passer par une magouille : soit un "void *", soit un cast explicite (le cas le plus standard, c'est quand on veut faire une forme d'héritage : on remplace un pointeur vers une structure par un pointeur vers une autre, qui commence par les mêmes champs). En cas de magouille, on perd la "sécurité" (le compilateur ne peut plus faire de vérification) et éventuellement des performances (comme le compilateur ne sait plus qui est quoi, il doit adopter un profil bas).
Les zélotes des langages fortement typés à la OCaml font leur promotion sur l'aspect "sécurité", souvent vécu comme trop contraignant par les programmeurs "bas niveau" qui aiment bien les magouilles. Mais rien n'interdit de faire un typage complexe avec des portes de sortie (c'est-à-dire la possibilité de faire des casts). Un exemple de langage avec un typage complexe permettant quand même les magouilles, en les rendant néanmoins inutiles, et favorisant l'optimisation, est le C++. Bon, certes, le C++ a une syntaxe qui confine à l'absurde, et son modèle d'implémentation rend son déploiement difficile, mais c'est un autre débat.
--Thomas Pornin
Marwan Burelle
On Tue, 6 Jan 2004 10:07:56 +0000 (UTC) (Thomas Pornin) wrote:
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes de base sont nazes, le programme généré sera naze, c'est tout.
Oui et non, tu peux quand même faire des choses, ça rend pas ton programme meilleur, mais tu peux améliorer certains trucs (le meilleur exemple, c'est la transformation des fonctions récursives terminales en pseudo-boucle, qui ne fait pas forcément beaucoup gagner, mais évite les changement de contexte et les empilements inutiles sur la pile.)
D'un autre côté, il y a toutes les optimisations liées à l'architecture, à la gestion du cache et du pipeline. Un code optimisé peu vraiment être plus rapide (bien sûr, tu ne vas pas changer de classe de complexité, mais bon ... )
Ce qui peut aider le compilateur, c'est quand on lui indique le plus de choses possible sur ce que fait le code, ce qu'il advient de chaque variable et de chaque valeur. Et ce qui permet ça, c'est justement... le typage !
Le typage t'évite également certains aspects de contrôle dynamique et de programmation défensive.
Mais bon, c'est un vaste débat, qui peut tomber dans le troll ... et je ne parlerais donc pas d'analyse de flot pour la sécurité (j'en fait suffisament toutes la journée ;)
On Tue, 6 Jan 2004 10:07:56 +0000 (UTC)
pornin@nerim.net (Thomas Pornin) wrote:
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes
de base sont nazes, le programme généré sera naze, c'est tout.
Oui et non, tu peux quand même faire des choses, ça rend pas ton programme
meilleur, mais tu peux améliorer certains trucs (le meilleur exemple,
c'est la transformation des fonctions récursives terminales en
pseudo-boucle, qui ne fait pas forcément beaucoup gagner, mais évite les
changement de contexte et les empilements inutiles sur la pile.)
D'un autre côté, il y a toutes les optimisations liées à l'architecture, à
la gestion du cache et du pipeline. Un code optimisé peu vraiment être
plus rapide (bien sûr, tu ne vas pas changer de classe de complexité, mais
bon ... )
Ce qui peut aider le compilateur, c'est quand on lui indique le plus
de choses possible sur ce que fait le code, ce qu'il advient de chaque
variable et de chaque valeur. Et ce qui permet ça, c'est justement...
le typage !
Le typage t'évite également certains aspects de contrôle dynamique et de
programmation défensive.
Mais bon, c'est un vaste débat, qui peut tomber dans le troll ... et je
ne parlerais donc pas d'analyse de flot pour la sécurité (j'en fait
suffisament toutes la journée ;)
On Tue, 6 Jan 2004 10:07:56 +0000 (UTC) (Thomas Pornin) wrote:
Le compilateur ne peut pas faire de l'algorithmique. Si les algorithmes de base sont nazes, le programme généré sera naze, c'est tout.
Oui et non, tu peux quand même faire des choses, ça rend pas ton programme meilleur, mais tu peux améliorer certains trucs (le meilleur exemple, c'est la transformation des fonctions récursives terminales en pseudo-boucle, qui ne fait pas forcément beaucoup gagner, mais évite les changement de contexte et les empilements inutiles sur la pile.)
D'un autre côté, il y a toutes les optimisations liées à l'architecture, à la gestion du cache et du pipeline. Un code optimisé peu vraiment être plus rapide (bien sûr, tu ne vas pas changer de classe de complexité, mais bon ... )
Ce qui peut aider le compilateur, c'est quand on lui indique le plus de choses possible sur ce que fait le code, ce qu'il advient de chaque variable et de chaque valeur. Et ce qui permet ça, c'est justement... le typage !
Le typage t'évite également certains aspects de contrôle dynamique et de programmation défensive.
Mais bon, c'est un vaste débat, qui peut tomber dans le troll ... et je ne parlerais donc pas d'analyse de flot pour la sécurité (j'en fait suffisament toutes la journée ;)
On Tue, 6 Jan 2004 13:16:27 +0000 (UTC) (Thomas Pornin) wrote:
Les zélotes des langages fortement typés à la OCaml font leur promotion sur l'aspect "sécurité", souvent vécu comme trop contraignant par les programmeurs "bas niveau" qui aiment bien les magouilles.
"L'aspect sécurité", comme tu dis, est juste une certaine garanti d'éxecution toujours correcte, pas de "segmentation fault" (enfin tu peux en faire avec les références dans certains cas ... et puis avec la nouvelle gorerie des modules récursifs ... )
L'avantage, de mon point vue, est quand même d'éliminer toutes les erreurs "simple" d'éxecution, pour s'occuper des vrais problèmes après, mais comme tu l'as dit, je dois être un zélotes du typage fort ;)
Mais rien n'interdit de faire un typage complexe avec des portes de sortie(c'est-à-dire la possibilité de faire des casts).
Obj.magic ? Marshalling ?
On peut typer les casts (même ceux dans les directions "crades"), mais le sous-typage, finalement, ça résout un peu ce genre de problème ...
Un exemple de langage avec un typage complexe permettant quand même les magouilles, en les rendant néanmoins inutiles, et favorisant l'optimisation, est le C++. Bon, certes, le C++ a une syntaxe qui confine à l'absurde, et son modèle d'implémentation rend son déploiement difficile, mais c'est un autre débat.
À la syntaxe de C++, la face de la Terre aurait-elle été différente si C++ avait une grammaire LALR(1) ...
On Tue, 6 Jan 2004 13:16:27 +0000 (UTC)
pornin@nerim.net (Thomas Pornin) wrote:
Les zélotes des langages fortement typés à la OCaml font leur promotion
sur l'aspect "sécurité", souvent vécu comme trop contraignant par
les programmeurs "bas niveau" qui aiment bien les magouilles.
"L'aspect sécurité", comme tu dis, est juste une certaine garanti
d'éxecution toujours correcte, pas de "segmentation fault" (enfin tu peux
en faire avec les références dans certains cas ... et puis avec la
nouvelle gorerie des modules récursifs ... )
L'avantage, de mon point vue, est quand même d'éliminer toutes les erreurs
"simple" d'éxecution, pour s'occuper des vrais problèmes après, mais comme
tu l'as dit, je dois être un zélotes du typage fort ;)
Mais rien n'interdit de faire un typage complexe avec des portes de
sortie(c'est-à-dire la possibilité de faire des casts).
Obj.magic ? Marshalling ?
On peut typer les casts (même ceux dans les directions "crades"), mais le
sous-typage, finalement, ça résout un peu ce genre de problème ...
Un exemple de langage avec un typage complexe permettant quand même les
magouilles, en les rendant néanmoins inutiles, et favorisant
l'optimisation, est le C++. Bon, certes, le C++ a une syntaxe qui
confine à l'absurde, et son modèle d'implémentation rend son
déploiement difficile, mais c'est un autre débat.
À la syntaxe de C++, la face de la Terre aurait-elle été différente si C++
avait une grammaire LALR(1) ...
On Tue, 6 Jan 2004 13:16:27 +0000 (UTC) (Thomas Pornin) wrote:
Les zélotes des langages fortement typés à la OCaml font leur promotion sur l'aspect "sécurité", souvent vécu comme trop contraignant par les programmeurs "bas niveau" qui aiment bien les magouilles.
"L'aspect sécurité", comme tu dis, est juste une certaine garanti d'éxecution toujours correcte, pas de "segmentation fault" (enfin tu peux en faire avec les références dans certains cas ... et puis avec la nouvelle gorerie des modules récursifs ... )
L'avantage, de mon point vue, est quand même d'éliminer toutes les erreurs "simple" d'éxecution, pour s'occuper des vrais problèmes après, mais comme tu l'as dit, je dois être un zélotes du typage fort ;)
Mais rien n'interdit de faire un typage complexe avec des portes de sortie(c'est-à-dire la possibilité de faire des casts).
Obj.magic ? Marshalling ?
On peut typer les casts (même ceux dans les directions "crades"), mais le sous-typage, finalement, ça résout un peu ce genre de problème ...
Un exemple de langage avec un typage complexe permettant quand même les magouilles, en les rendant néanmoins inutiles, et favorisant l'optimisation, est le C++. Bon, certes, le C++ a une syntaxe qui confine à l'absurde, et son modèle d'implémentation rend son déploiement difficile, mais c'est un autre débat.
À la syntaxe de C++, la face de la Terre aurait-elle été différente si C++ avait une grammaire LALR(1) ...
