je voudrais changer ma config matérielle avec notamment un
Intel Quad-Core i5-750.
Peut-on me dire si une Ubuntu 8.4 exploite correctement ce processeur ?
ou faut-il une version + récente ? ou une autre distrib ?
C'est bien ce que j'appelle de l'optimisation à la marge.
J'essayais de répondre à la question de l'OP. Il faudrait sans doute que celui-ci précise ce qu'il entend par "exploiter correctement ce processeur".
Optimiser ce genre de chose apporte moins
La suite Adobe a la réputation d'être optimisée pour des processeurs Intel. De même, dans le temps, il me semble bien avoir vu deux versions de VirtualDub : une version Intel et une version AMD.
Donc, la distinction semble avoir son importance dans certains domaines précis.
Certes, mais là, ça implique généralement une modification du code.
On Sun, 11 Apr 2010 07:59:00 +0000 (UTC), JKB
<knatschke@koenigsberg.fr>:
C'est bien ce que j'appelle de l'optimisation à la marge.
J'essayais de répondre à la question de l'OP. Il faudrait sans doute
que celui-ci précise ce qu'il entend par "exploiter correctement ce
processeur".
Optimiser ce genre de chose apporte moins
La suite Adobe a la réputation d'être optimisée pour des processeurs
Intel. De même, dans le temps, il me semble bien avoir vu deux
versions de VirtualDub : une version Intel et une version AMD.
Donc, la distinction semble avoir son importance dans certains
domaines précis.
C'est bien ce que j'appelle de l'optimisation à la marge.
J'essayais de répondre à la question de l'OP. Il faudrait sans doute que celui-ci précise ce qu'il entend par "exploiter correctement ce processeur".
Optimiser ce genre de chose apporte moins
La suite Adobe a la réputation d'être optimisée pour des processeurs Intel. De même, dans le temps, il me semble bien avoir vu deux versions de VirtualDub : une version Intel et une version AMD.
Donc, la distinction semble avoir son importance dans certains domaines précis.
Certes, mais là, ça implique généralement une modification du code.
Th.A.C
Le 11/04/2010 01:02, Bernard Meylan a écrit :
Le 11. 04. 10 00:06, Nicolas George a écrit :
C'est ça que ça veut dire, « long term », dans « long term support ».
Copié-collé du forum Ubuntu ( http://forum.ubuntu-fr.org/viewtopic.php?id2044 ):
Une version classique est supportée 18 mois a partir de sa sortie. Supportée = mises à jour de sécurité/bugs mises à disposition des utilisateurs. Ces 18 mois passés, les MAJ n'auront plus lieu.
Une version LTS est elle supportée, non pas 18 mois mais 3 ans pour les utilisateurs "normaux" et 5 ans pour les entreprises. Ce qui en fait donc une version particulièrement stable et très bien adaptée aux serveurs. LTS = long term support = support à long terme.
Bernard
Pour en avoir fait l'expérience récemment, la 8.04 ne marche pas toujours sur des machines récentes. Ca part du boot qui bloque en cours de route jusqu'au problèmes de drivers.
Le LTS c'est plutot une garantie que le système aura des corrections de bug, pas du tout une garantie que ca va marcher sur des machines récentes...
Donc c'est valable pour des machines déja en production, pas pour des nouvelles machines, sauf si la nouvelle machine est compatible...
Le 11/04/2010 01:02, Bernard Meylan a écrit :
Le 11. 04. 10 00:06, Nicolas George a écrit :
C'est ça que ça veut dire, « long term », dans « long term support ».
Copié-collé du forum Ubuntu (
http://forum.ubuntu-fr.org/viewtopic.php?id2044 ):
Une version classique est supportée 18 mois a partir de sa sortie.
Supportée = mises à jour de sécurité/bugs mises à disposition des
utilisateurs.
Ces 18 mois passés, les MAJ n'auront plus lieu.
Une version LTS est elle supportée, non pas 18 mois mais 3 ans pour les
utilisateurs "normaux" et 5 ans pour les entreprises.
Ce qui en fait donc une version particulièrement stable et très bien
adaptée aux serveurs.
LTS = long term support = support à long terme.
Bernard
Pour en avoir fait l'expérience récemment, la 8.04 ne marche pas
toujours sur des machines récentes.
Ca part du boot qui bloque en cours de route jusqu'au problèmes de drivers.
Le LTS c'est plutot une garantie que le système aura des corrections de
bug, pas du tout une garantie que ca va marcher sur des machines récentes...
Donc c'est valable pour des machines déja en production, pas pour des
nouvelles machines, sauf si la nouvelle machine est compatible...
C'est ça que ça veut dire, « long term », dans « long term support ».
Copié-collé du forum Ubuntu ( http://forum.ubuntu-fr.org/viewtopic.php?id2044 ):
Une version classique est supportée 18 mois a partir de sa sortie. Supportée = mises à jour de sécurité/bugs mises à disposition des utilisateurs. Ces 18 mois passés, les MAJ n'auront plus lieu.
Une version LTS est elle supportée, non pas 18 mois mais 3 ans pour les utilisateurs "normaux" et 5 ans pour les entreprises. Ce qui en fait donc une version particulièrement stable et très bien adaptée aux serveurs. LTS = long term support = support à long terme.
Bernard
Pour en avoir fait l'expérience récemment, la 8.04 ne marche pas toujours sur des machines récentes. Ca part du boot qui bloque en cours de route jusqu'au problèmes de drivers.
Le LTS c'est plutot une garantie que le système aura des corrections de bug, pas du tout une garantie que ca va marcher sur des machines récentes...
Donc c'est valable pour des machines déja en production, pas pour des nouvelles machines, sauf si la nouvelle machine est compatible...
pipantal
Le 11/04/2010 02:29, Gump a écrit :
| | Une version LTS est elle supportée, non pas 18 mois mais 3 ans pour les | utilisateurs "normaux" et 5 ans pour les entreprises. | Ce qui en fait donc une version particulièrement stable et très bien | adaptée aux serveurs. | LTS = long term support = support à long terme. |
Oui ... en théorie ! sauf quand on ne peut plus la mettre à jour. La mienne me propose à chaque boot des MAJ. Depuis quelque temps, lorsque je veux le faire, j'ai droit à un message me disant que ce n'est pas possible, sans autre explication ! Alors le LTS, hein ...
Par expérience, un jour sur ma ubuntu j'en avais marre que ma carte video n'accepte pas l'accélération 3D malgré tout mes tentatives.
Je me suis dit, je jette tout et je réinstalle.
Après la réinstallation, non seulement j'ai récupéré une ubuntu bien propre, mais en plus, n'ayant pas reformaté ma partition /home, j'ai retrouvé mon bureau tel qu'il était avant la réinstallation, avec tous mes fichiers et tout et tout, mais j'avais mon accélération 3D qui fonctionnait !!!!
Donc si tu as un problème de stabilité de ton installation avec un bug pour les mises à jour, je te propose, de sauvegarder ton /home pour être bien sûr, et de réinstaller une Ubuntu 8.04LTS si tu veux, ou bien la 9.10 ou bien la 10.04 qui sort dans 18 jours ;)
Le 11/04/2010 02:29, Gump a écrit :
|
| Une version LTS est elle supportée, non pas 18 mois mais 3 ans pour les
| utilisateurs "normaux" et 5 ans pour les entreprises.
| Ce qui en fait donc une version particulièrement stable et très bien
| adaptée aux serveurs.
| LTS = long term support = support à long terme.
|
Oui ... en théorie ! sauf quand on ne peut plus la mettre à jour.
La mienne me propose à chaque boot des MAJ. Depuis quelque temps,
lorsque je veux le faire, j'ai droit à un message me disant que ce n'est pas possible,
sans autre explication ! Alors le LTS, hein ...
Par expérience, un jour sur ma ubuntu j'en avais marre que ma carte
video n'accepte pas l'accélération 3D malgré tout mes tentatives.
Je me suis dit, je jette tout et je réinstalle.
Après la réinstallation, non seulement j'ai récupéré une ubuntu bien
propre, mais en plus, n'ayant pas reformaté ma partition /home, j'ai
retrouvé mon bureau tel qu'il était avant la réinstallation, avec tous
mes fichiers et tout et tout, mais j'avais mon accélération 3D qui
fonctionnait !!!!
Donc si tu as un problème de stabilité de ton installation avec un bug
pour les mises à jour, je te propose, de sauvegarder ton /home pour être
bien sûr, et de réinstaller une Ubuntu 8.04LTS si tu veux, ou bien la
9.10 ou bien la 10.04 qui sort dans 18 jours ;)
| | Une version LTS est elle supportée, non pas 18 mois mais 3 ans pour les | utilisateurs "normaux" et 5 ans pour les entreprises. | Ce qui en fait donc une version particulièrement stable et très bien | adaptée aux serveurs. | LTS = long term support = support à long terme. |
Oui ... en théorie ! sauf quand on ne peut plus la mettre à jour. La mienne me propose à chaque boot des MAJ. Depuis quelque temps, lorsque je veux le faire, j'ai droit à un message me disant que ce n'est pas possible, sans autre explication ! Alors le LTS, hein ...
Par expérience, un jour sur ma ubuntu j'en avais marre que ma carte video n'accepte pas l'accélération 3D malgré tout mes tentatives.
Je me suis dit, je jette tout et je réinstalle.
Après la réinstallation, non seulement j'ai récupéré une ubuntu bien propre, mais en plus, n'ayant pas reformaté ma partition /home, j'ai retrouvé mon bureau tel qu'il était avant la réinstallation, avec tous mes fichiers et tout et tout, mais j'avais mon accélération 3D qui fonctionnait !!!!
Donc si tu as un problème de stabilité de ton installation avec un bug pour les mises à jour, je te propose, de sauvegarder ton /home pour être bien sûr, et de réinstaller une Ubuntu 8.04LTS si tu veux, ou bien la 9.10 ou bien la 10.04 qui sort dans 18 jours ;)
Lucas Levrel
Le 10 avril 2010, JKB a écrit :
Entre un gcc [dr]écent et un icc, je ne vois pas trop la différence, ça va se jouer aux marges. La vraie différence, c'est lorsqu'on a un code optimisé pour utiliser les quatre coeurs avec des vrais morceaux de libpthread dedans.
Oui, et icc vient avec Intel MKL (Math Kernel Library) dont beaucoup de routines sont parallélisées. Ceci dit on doit pouvoir utiliser MKL avec gcc.
icc peut aussi vectoriser et paralléliser automatiquement des boucles (je ne sais pas si gcc le fait).
-- LL
Le 10 avril 2010, JKB a écrit :
Entre un gcc [dr]écent et un icc, je ne vois pas trop la différence,
ça va se jouer aux marges. La vraie différence, c'est lorsqu'on a un
code optimisé pour utiliser les quatre coeurs avec des vrais
morceaux de libpthread dedans.
Oui, et icc vient avec Intel MKL (Math Kernel Library) dont beaucoup de
routines sont parallélisées. Ceci dit on doit pouvoir utiliser MKL avec
gcc.
icc peut aussi vectoriser et paralléliser automatiquement des boucles (je
ne sais pas si gcc le fait).
Entre un gcc [dr]écent et un icc, je ne vois pas trop la différence, ça va se jouer aux marges. La vraie différence, c'est lorsqu'on a un code optimisé pour utiliser les quatre coeurs avec des vrais morceaux de libpthread dedans.
Oui, et icc vient avec Intel MKL (Math Kernel Library) dont beaucoup de routines sont parallélisées. Ceci dit on doit pouvoir utiliser MKL avec gcc.
icc peut aussi vectoriser et paralléliser automatiquement des boucles (je ne sais pas si gcc le fait).
-- LL
JKB
Le 12-04-2010, ? propos de Re: Quad-core 15 et Ubuntu, Lucas Levrel ?crivait dans fr.comp.os.linux.configuration :
Le 10 avril 2010, JKB a écrit :
Entre un gcc [dr]écent et un icc, je ne vois pas trop la différence, ça va se jouer aux marges. La vraie différence, c'est lorsqu'on a un code optimisé pour utiliser les quatre coeurs avec des vrais morceaux de libpthread dedans.
Oui, et icc vient avec Intel MKL (Math Kernel Library) dont beaucoup de routines sont parallélisées. Ceci dit on doit pouvoir utiliser MKL avec gcc.
icc peut aussi vectoriser et paralléliser automatiquement des boucles (je ne sais pas si gcc le fait).
Il y a beaucoup de choses dans gcc-4.5. Très honnêtement, pour faire du calcul intensif, je continue à utiliser gcc parce que c'est d'une part portable, et que d'autre part, même si ce compilo n'est pas optimal sur telle ou telle architecture, je gagne beaucoup à faire des optimisations à la main plutôt qu'à laisser faire le compilo. La parallélisation automatique, c'est bien beau, mais ça ne remplacera jamais un code optimisé aux petits oignons.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 12-04-2010, ? propos de
Re: Quad-core 15 et Ubuntu,
Lucas Levrel ?crivait dans fr.comp.os.linux.configuration :
Le 10 avril 2010, JKB a écrit :
Entre un gcc [dr]écent et un icc, je ne vois pas trop la différence,
ça va se jouer aux marges. La vraie différence, c'est lorsqu'on a un
code optimisé pour utiliser les quatre coeurs avec des vrais
morceaux de libpthread dedans.
Oui, et icc vient avec Intel MKL (Math Kernel Library) dont beaucoup de
routines sont parallélisées. Ceci dit on doit pouvoir utiliser MKL avec
gcc.
icc peut aussi vectoriser et paralléliser automatiquement des boucles (je
ne sais pas si gcc le fait).
Il y a beaucoup de choses dans gcc-4.5. Très honnêtement, pour faire
du calcul intensif, je continue à utiliser gcc parce que c'est d'une
part portable, et que d'autre part, même si ce compilo n'est pas optimal
sur telle ou telle architecture, je gagne beaucoup à faire des
optimisations à la main plutôt qu'à laisser faire le compilo. La
parallélisation automatique, c'est bien beau, mais ça ne remplacera
jamais un code optimisé aux petits oignons.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 12-04-2010, ? propos de Re: Quad-core 15 et Ubuntu, Lucas Levrel ?crivait dans fr.comp.os.linux.configuration :
Le 10 avril 2010, JKB a écrit :
Entre un gcc [dr]écent et un icc, je ne vois pas trop la différence, ça va se jouer aux marges. La vraie différence, c'est lorsqu'on a un code optimisé pour utiliser les quatre coeurs avec des vrais morceaux de libpthread dedans.
Oui, et icc vient avec Intel MKL (Math Kernel Library) dont beaucoup de routines sont parallélisées. Ceci dit on doit pouvoir utiliser MKL avec gcc.
icc peut aussi vectoriser et paralléliser automatiquement des boucles (je ne sais pas si gcc le fait).
Il y a beaucoup de choses dans gcc-4.5. Très honnêtement, pour faire du calcul intensif, je continue à utiliser gcc parce que c'est d'une part portable, et que d'autre part, même si ce compilo n'est pas optimal sur telle ou telle architecture, je gagne beaucoup à faire des optimisations à la main plutôt qu'à laisser faire le compilo. La parallélisation automatique, c'est bien beau, mais ça ne remplacera jamais un code optimisé aux petits oignons.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Lucas Levrel
Le 12 avril 2010, JKB a écrit :
Il y a beaucoup de choses dans gcc-4.5. Très honnêtement, pour faire du calcul intensif, je continue à utiliser gcc parce que c'est d'une part portable, et que d'autre part, même si ce compilo n'est pas optimal sur telle ou telle architecture, je gagne beaucoup à faire des optimisations à la main plutôt qu'à laisser faire le compilo. La parallélisation automatique, c'est bien beau, mais ça ne remplacera jamais un code optimisé aux petits oignons.
Tu as bien raison, mais il faut avoir les compétences pour le faire. Entre un code parallélisé automatiquement et un code pas parallélisé, le premier est quand même plus rapide...
-- LL
Le 12 avril 2010, JKB a écrit :
Il y a beaucoup de choses dans gcc-4.5. Très honnêtement, pour faire
du calcul intensif, je continue à utiliser gcc parce que c'est d'une
part portable, et que d'autre part, même si ce compilo n'est pas optimal
sur telle ou telle architecture, je gagne beaucoup à faire des
optimisations à la main plutôt qu'à laisser faire le compilo. La
parallélisation automatique, c'est bien beau, mais ça ne remplacera
jamais un code optimisé aux petits oignons.
Tu as bien raison, mais il faut avoir les compétences pour le faire. Entre
un code parallélisé automatiquement et un code pas parallélisé, le premier
est quand même plus rapide...
Il y a beaucoup de choses dans gcc-4.5. Très honnêtement, pour faire du calcul intensif, je continue à utiliser gcc parce que c'est d'une part portable, et que d'autre part, même si ce compilo n'est pas optimal sur telle ou telle architecture, je gagne beaucoup à faire des optimisations à la main plutôt qu'à laisser faire le compilo. La parallélisation automatique, c'est bien beau, mais ça ne remplacera jamais un code optimisé aux petits oignons.
Tu as bien raison, mais il faut avoir les compétences pour le faire. Entre un code parallélisé automatiquement et un code pas parallélisé, le premier est quand même plus rapide...
