On 2011-07-15, pehache wrote: > Le 15/07/11 23:32, Nicolas George a écrit : >> pehache , dans le message, a écrit : >>> A condition d'avoir l'utilité de ces registres d'une part, et à >> >> Ah oui, si ton programme se contente de faire 2+2, ça ne sert pas à >> grand chose. > > Gros malin, il y a quantité de codes qui ne font pas des opérations > forcément très complexes sur les données, mais qui le font sur de > gros volumes et/ou qui les répètent un grand nombre de fois. > > Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de > registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses, si tu as 2 fois plus de registres généraux, tu peux toujours faire 2 fois plus d'additions à la fois.
Tu prêches dans le désert ma soeur !! Le pehache tient la multiplication par deux pour opération satanique. Il aurait mieux valu rester sur l'exemple de frère Nicolas qui dans sa grande pitié envers pehache en était resté à l'addition.
>>> condition que l'optimiseur du compilateur sache en faire bon usage >>> par rapport au code source. >> >> gcc sait faire. > > certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus de registres possible.
Le pehache n'est pas dans le doute. Il ne connaît pas ce sombre sentiment qui torture, questionne et contraint à progresser. Le pehache est sous l'emprise de Satan : il reste accroché à ses certitudes rassurantes comme une moule (sauf votre respect ma soeur) à son rocher.
-- Windows: Microsoft's tax on computer illiterates. Hugo (né il y a 1 490 229 169 secondes)
Le 16-07-2011, Helena <lna57005@gmail.com> a écrit :
On 2011-07-15, pehache <pehache.7@gmail.com> wrote:
> Le 15/07/11 23:32, Nicolas George a écrit :
>> pehache , dans le message<98bo5hF23lU1@mid.individual.net>, a écrit :
>>> A condition d'avoir l'utilité de ces registres d'une part, et à
>>
>> Ah oui, si ton programme se contente de faire 2+2, ça ne sert pas à
>> grand chose.
>
> Gros malin, il y a quantité de codes qui ne font pas des opérations
> forcément très complexes sur les données, mais qui le font sur de
> gros volumes et/ou qui les répètent un grand nombre de fois.
>
> Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de
> registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce
genre de choses, si tu as 2 fois plus de registres généraux, tu peux
toujours faire 2 fois plus d'additions à la fois.
Tu prêches dans le désert ma soeur !!
Le pehache tient la multiplication par deux pour opération satanique. Il
aurait mieux valu rester sur l'exemple de frère Nicolas qui dans sa
grande pitié envers pehache en était resté à l'addition.
>>> condition que l'optimiseur du compilateur sache en faire bon usage
>>> par rapport au code source.
>>
>> gcc sait faire.
>
> certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le
plus de registres possible.
Le pehache n'est pas dans le doute. Il ne connaît pas ce sombre
sentiment qui torture, questionne et contraint à progresser.
Le pehache est sous l'emprise de Satan : il reste accroché à ses
certitudes rassurantes comme une moule (sauf votre respect ma soeur) à
son rocher.
--
Windows: Microsoft's tax on computer illiterates.
Hugo (né il y a 1 490 229 169 secondes)
On 2011-07-15, pehache wrote: > Le 15/07/11 23:32, Nicolas George a écrit : >> pehache , dans le message, a écrit : >>> A condition d'avoir l'utilité de ces registres d'une part, et à >> >> Ah oui, si ton programme se contente de faire 2+2, ça ne sert pas à >> grand chose. > > Gros malin, il y a quantité de codes qui ne font pas des opérations > forcément très complexes sur les données, mais qui le font sur de > gros volumes et/ou qui les répètent un grand nombre de fois. > > Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de > registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses, si tu as 2 fois plus de registres généraux, tu peux toujours faire 2 fois plus d'additions à la fois.
Tu prêches dans le désert ma soeur !! Le pehache tient la multiplication par deux pour opération satanique. Il aurait mieux valu rester sur l'exemple de frère Nicolas qui dans sa grande pitié envers pehache en était resté à l'addition.
>>> condition que l'optimiseur du compilateur sache en faire bon usage >>> par rapport au code source. >> >> gcc sait faire. > > certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus de registres possible.
Le pehache n'est pas dans le doute. Il ne connaît pas ce sombre sentiment qui torture, questionne et contraint à progresser. Le pehache est sous l'emprise de Satan : il reste accroché à ses certitudes rassurantes comme une moule (sauf votre respect ma soeur) à son rocher.
-- Windows: Microsoft's tax on computer illiterates. Hugo (né il y a 1 490 229 169 secondes)
pehache
Le 16/07/11 10:56, Helena a écrit :
Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
si tu as 2 fois plus de registres généraux, tu peux toujours faire 2 fois plus d'additions à la fois.
Non. Avoir plus de registres permet de conserver certains résultats pour les réutiliser un peu plus tard, au lieu d'avoir à les relire depuis la mémoire.
gcc sait faire.
certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus de registres possible.
A te lire, écrire un optimiseur doit être d'une simplicité biblique.
Sauf qu'un code écrit pour favoriser la vectorisation, par exemple, ne va pas forcément utiliser de nombreux registres une fois compilé. Dans certains cas, le compilateur pourrait avoir avoir avantage à casser la vectorisation et réarranger l'ordre des opérations de telle sorte à favoriser l'utilisation de plus de registres pour minimiser les transferts depuis la mémoire, mais à part peut-être dans quelques cas simples et canoniques, je doute qu'ils le fassent souvent.
-- pehache
Le 16/07/11 10:56, Helena a écrit :
Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de
registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre
de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
si tu as 2 fois plus de registres généraux, tu peux toujours
faire 2 fois plus d'additions à la fois.
Non. Avoir plus de registres permet de conserver certains résultats pour
les réutiliser un peu plus tard, au lieu d'avoir à les relire depuis la
mémoire.
gcc sait faire.
certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus
de registres possible.
A te lire, écrire un optimiseur doit être d'une simplicité biblique.
Sauf qu'un code écrit pour favoriser la vectorisation, par exemple, ne
va pas forcément utiliser de nombreux registres une fois compilé. Dans
certains cas, le compilateur pourrait avoir avoir avantage à casser la
vectorisation et réarranger l'ordre des opérations de telle sorte à
favoriser l'utilisation de plus de registres pour minimiser les
transferts depuis la mémoire, mais à part peut-être dans quelques cas
simples et canoniques, je doute qu'ils le fassent souvent.
Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
si tu as 2 fois plus de registres généraux, tu peux toujours faire 2 fois plus d'additions à la fois.
Non. Avoir plus de registres permet de conserver certains résultats pour les réutiliser un peu plus tard, au lieu d'avoir à les relire depuis la mémoire.
gcc sait faire.
certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus de registres possible.
A te lire, écrire un optimiseur doit être d'une simplicité biblique.
Sauf qu'un code écrit pour favoriser la vectorisation, par exemple, ne va pas forcément utiliser de nombreux registres une fois compilé. Dans certains cas, le compilateur pourrait avoir avoir avantage à casser la vectorisation et réarranger l'ordre des opérations de telle sorte à favoriser l'utilisation de plus de registres pour minimiser les transferts depuis la mémoire, mais à part peut-être dans quelques cas simples et canoniques, je doute qu'ils le fassent souvent.
-- pehache
jp willm
Le 16/07/2011 10:56, Pascale a écrit :
Pas de souci, j'ai bien créé une partition étendue (:
Ouf ! :o)
Je t'ai préparé une petite sélection d'accessoires qui peuvent servir :
Merci, plein de mercis à toi ! Je vais passer tout ça à ma fille. Elle s'en va demain, elle n'a encore qu'une connaissance très superficielle d'Ubuntu, mais bon, en résumé, ça marche, et finalement, je la trouve moins empotée qu'avec Windows !
Merci, plein de mercis à toi !
Je vais passer tout ça à ma fille. Elle s'en va demain, elle n'a encore
qu'une connaissance très superficielle d'Ubuntu, mais bon, en résumé, ça
marche, et finalement, je la trouve moins empotée qu'avec Windows !
Merci, plein de mercis à toi ! Je vais passer tout ça à ma fille. Elle s'en va demain, elle n'a encore qu'une connaissance très superficielle d'Ubuntu, mais bon, en résumé, ça marche, et finalement, je la trouve moins empotée qu'avec Windows !
-- Pascale http://www.la-grille-verte.net
jp willm
Le 16/07/2011 22:57, Pascale a écrit :
Merci, plein de mercis à toi !
:o)
J'ai été aidé et rectifié par les autres intervenants.
Donc nous avons fait un travail d'équipe.
Je vais passer tout ça à ma fille. Elle s'en va demain, elle n'a encore qu'une connaissance très superficielle d'Ubuntu, mais bon, en résumé, ça marche,
Merci de nous faire part des résultats et de tes conclusions ; cela nous encourage grandement !
et finalement, je la trouve moins empotée qu'avec Windows !
J'ai constaté le même progrès chez la plupart des autres personnes venant de windows ;o)
C'est finalement normal, car dans un système unix/linux les éléments sont agencés logiquement et "brique" après "brique" on comprend progressivement l'ensemble.
@+
-- http://perso.orange.fr/willms/index.html
Le 16/07/2011 22:57, Pascale a écrit :
Merci, plein de mercis à toi !
:o)
J'ai été aidé et rectifié par les autres intervenants.
Donc nous avons fait un travail d'équipe.
Je vais passer tout ça à ma fille. Elle s'en va demain, elle n'a encore
qu'une connaissance très superficielle d'Ubuntu, mais bon, en résumé, ça
marche,
Merci de nous faire part des résultats et de tes conclusions ; cela nous
encourage grandement !
et finalement, je la trouve moins empotée qu'avec Windows !
J'ai constaté le même progrès chez la plupart des autres personnes
venant de windows ;o)
C'est finalement normal, car dans un système unix/linux les éléments
sont agencés logiquement et "brique" après "brique" on comprend
progressivement l'ensemble.
J'ai été aidé et rectifié par les autres intervenants.
Donc nous avons fait un travail d'équipe.
Je vais passer tout ça à ma fille. Elle s'en va demain, elle n'a encore qu'une connaissance très superficielle d'Ubuntu, mais bon, en résumé, ça marche,
Merci de nous faire part des résultats et de tes conclusions ; cela nous encourage grandement !
et finalement, je la trouve moins empotée qu'avec Windows !
J'ai constaté le même progrès chez la plupart des autres personnes venant de windows ;o)
C'est finalement normal, car dans un système unix/linux les éléments sont agencés logiquement et "brique" après "brique" on comprend progressivement l'ensemble.
@+
-- http://perso.orange.fr/willms/index.html
Man-d
Le 2011-07-17 02:37, jp willm a écrit :
Le 16/07/2011 22:57, Pascale a écrit : et finalement, je la trouve moins empotée qu'avec Windows !
J'ai constaté le même progrès chez la plupart des autres personnes venant de windows ;o)
C'est finalement normal, car dans un système unix/linux les éléments sont agencés logiquement et "brique" après "brique" on comprend progressivement l'ensemble.
mmh comme avec un système ouvert et transparent fait par ses utilisateurs ? :)
-- man-d
Le 2011-07-17 02:37, jp willm a écrit :
Le 16/07/2011 22:57, Pascale a écrit :
et finalement, je la trouve moins empotée qu'avec Windows !
J'ai constaté le même progrès chez la plupart des autres personnes
venant de windows ;o)
C'est finalement normal, car dans un système unix/linux les éléments
sont agencés logiquement et "brique" après "brique" on comprend
progressivement l'ensemble.
mmh comme avec un système ouvert et transparent fait par ses
utilisateurs ? :)
Le 16/07/2011 22:57, Pascale a écrit : et finalement, je la trouve moins empotée qu'avec Windows !
J'ai constaté le même progrès chez la plupart des autres personnes venant de windows ;o)
C'est finalement normal, car dans un système unix/linux les éléments sont agencés logiquement et "brique" après "brique" on comprend progressivement l'ensemble.
mmh comme avec un système ouvert et transparent fait par ses utilisateurs ? :)
-- man-d
jp willm
Le 17/07/2011 09:06, Man-d a écrit :
mmh comme avec un système ouvert et transparent fait par ses utilisateurs ? :)
Très juste :o)
-- http://perso.orange.fr/willms/index.html
Le 17/07/2011 09:06, Man-d a écrit :
mmh comme avec un système ouvert et transparent fait par ses
utilisateurs ? :)
mmh comme avec un système ouvert et transparent fait par ses utilisateurs ? :)
Très juste :o)
-- http://perso.orange.fr/willms/index.html
Helena
On 2011-07-16, pehache wrote:
Le 16/07/11 10:56, Helena a écrit :
Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
Tout n'est pas vectorisable.
si tu as 2 fois plus de registres généraux, tu peux toujours faire 2 fois plus d'additions à la fois.
Non.
Si.
Avoir plus de registres permet de conserver certains résultats pour les réutiliser un peu plus tard, au lieu d'avoir à les relire depuis la mémoire.
Aussi.
gcc sait faire.
certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus de registres possible.
A te lire, écrire un optimiseur doit être d'une simplicité biblique.
Apprends à lire.
Sauf qu'un code écrit pour favoriser la vectorisation, par exemple, ne va pas forcément utiliser de nombreux registres une fois compilé. Dans certains cas, le compilateur pourrait avoir avoir avantage à casser la vectorisation et réarranger l'ordre des opérations de telle sorte à favoriser l'utilisation de plus de registres pour minimiser les transferts depuis la mémoire, mais à part peut-être dans quelques cas simples et canoniques, je doute qu'ils le fassent souvent.
C'est sûr que si ça ne marche pas dans un cas particulier, ça ne doit pas marcher dans le cas général...
-- helena
On 2011-07-16, pehache <pehache.7@gmail.com> wrote:
Le 16/07/11 10:56, Helena a écrit :
Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de
registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre
de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
Tout n'est pas vectorisable.
si tu as 2 fois plus de registres généraux, tu peux toujours
faire 2 fois plus d'additions à la fois.
Non.
Si.
Avoir plus de registres permet de conserver certains résultats pour
les réutiliser un peu plus tard, au lieu d'avoir à les relire depuis la
mémoire.
Aussi.
gcc sait faire.
certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus
de registres possible.
A te lire, écrire un optimiseur doit être d'une simplicité biblique.
Apprends à lire.
Sauf qu'un code écrit pour favoriser la vectorisation, par exemple, ne
va pas forcément utiliser de nombreux registres une fois compilé. Dans
certains cas, le compilateur pourrait avoir avoir avantage à casser la
vectorisation et réarranger l'ordre des opérations de telle sorte à
favoriser l'utilisation de plus de registres pour minimiser les
transferts depuis la mémoire, mais à part peut-être dans quelques cas
simples et canoniques, je doute qu'ils le fassent souvent.
C'est sûr que si ça ne marche pas dans un cas particulier, ça ne doit pas
marcher dans le cas général...
Donc déjà, tous ces codes ne tirent pas avantage d'un plus nombre de registres.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
Tout n'est pas vectorisable.
si tu as 2 fois plus de registres généraux, tu peux toujours faire 2 fois plus d'additions à la fois.
Non.
Si.
Avoir plus de registres permet de conserver certains résultats pour les réutiliser un peu plus tard, au lieu d'avoir à les relire depuis la mémoire.
Aussi.
gcc sait faire.
certainement, certainement...
Tu te doutes bien que tout compilateur qui se respecte utilise le plus de registres possible.
A te lire, écrire un optimiseur doit être d'une simplicité biblique.
Apprends à lire.
Sauf qu'un code écrit pour favoriser la vectorisation, par exemple, ne va pas forcément utiliser de nombreux registres une fois compilé. Dans certains cas, le compilateur pourrait avoir avoir avantage à casser la vectorisation et réarranger l'ordre des opérations de telle sorte à favoriser l'utilisation de plus de registres pour minimiser les transferts depuis la mémoire, mais à part peut-être dans quelques cas simples et canoniques, je doute qu'ils le fassent souvent.
C'est sûr que si ça ne marche pas dans un cas particulier, ça ne doit pas marcher dans le cas général...
-- helena
pehache
Le 18/07/11 08:33, Helena a écrit :
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
Tout n'est pas vectorisable.
Je sais bien, mais ca représente néanmoins de très nombreux codes en HPC. Et les unités vectorielles existent aussi bien en ia32 qu'en x86_64, ça ne fait donc pas une différence à ce niveau.
-- pehache
Le 18/07/11 08:33, Helena a écrit :
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre
de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
Tout n'est pas vectorisable.
Je sais bien, mais ca représente néanmoins de très nombreux codes en
HPC. Et les unités vectorielles existent aussi bien en ia32 qu'en
x86_64, ça ne fait donc pas une différence à ce niveau.
Gros malin, outre l'existance d'unités de calcul vectoriel pour ce genre de choses,
Et elles n'existent pas en ia32, ces unités vectorielles ??
Tout n'est pas vectorisable.
Je sais bien, mais ca représente néanmoins de très nombreux codes en HPC. Et les unités vectorielles existent aussi bien en ia32 qu'en x86_64, ça ne fait donc pas une différence à ce niveau.
