COMPTOIR
register

Composé par ————— —— 13622 vues

Quand le prix de la RAM s'emballe, c'est GCC qui se fait la malle !

En voilà une nouvelle qui fera rire plus d'un ! Eric S Raymond (ESR pour les intimes), un gourou américain de l'Open Source, s'est mis en tête de mettre à jour le gestionnaire de version GCC, la fameuse suite de compilation sous licence GNU. En effet, les développeurs devaient utiliser SVN, un logiciel libre datant de de l'an 2000, depuis éclipsé par Git, comme en témoigne le récent rachat de Github par la Raymonde.

 

Fort de son expérience avec la migration d'Emacs, un logiciel de traitement de texte en ligne de commande, ESR avait refusé gentiment l'utilisation de fermes de compilation, préférant son système personnel, plus facile d'accès et plus optimisé selon ses dires. Il faut dire que l'opération est complexe et sa machine préparée à ce genre de tâche, atteignant selon ses dire plus de 50% de performances supplémentaires en terme de temps de compilation.

 

Cependant tout ne s'est pas vraiment déroulé comme prévu. Un fois le dernier bug résolu, pas moyen de terminer la migration. La cause du bazar ? Les 64 Go de RAM, qui montrent leurs faiblesses lors de la génération de la nouvelle version de GCC comportant plus de 250 000 commits (les sous-versions les plus petites possibles permises par git). Étant donné les prix "monstrueux" de la DDR4, un upgrade n'est apparemment pas à l'ordre du jour... Dommage ! Le problème profond serait résolu soit par un changement de langage de programmation depuis du Python vers du Go, soit par un découpage et une répartition des tâche sur des accélérateurs dédiés tels des GPGPU (les cartes graphiques dédiées aux calculs scientifiques). Pour le moment, réduire au maximum les applications lancées, notamment le navigateur internet, semble suffire ; ouf ! (Source : Phoronix)

 

gcc logo

Un poil avant ?

La partouze Intel / AMD se poursuit, qui entre chez qui ?

Un peu plus tard ...

NAND 3D 96L : la 5ème génération de V-NAND désormais produite en masse chez Samsung

Les 16 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Hamster1er, le Samedi 14 Juillet 2018 à 09h38  
par UpsiloNIX le Jeudi 12 Juillet 2018 à 08h57
1/ Tu apprendras le sens de équivalent
2/ Oui des Tesla avec NVSwitches c'est mieux (et encore ça dépend de l'utilisation), mais les scientifiques n'ont pas un budget illimité (en France en tout cas) => Se rabattre sur des modèles grand public peut-être très intéressant pour un rapport P/P.
3/ Merci pour ton intervention inutile
+1
Que ce soit dans le public ou dans le privé d'ailleurs.
Si on peut faire tourner ce qu'on veut avec les mêmes perfs et la même précision pour 3x moins cher, on va pas se gêner xD
par UpsiloNIX, le Jeudi 12 Juillet 2018 à 08h57  
par Un ragoteur Gaulois embusqué le Jeudi 12 Juillet 2018 à 08h08
1/ Tu apprendras le sens de équivalent
2/ Oui des Tesla avec NVSwitches c'est mieux (et encore ça dépend de l'utilisation), mais les scientifiques n'ont pas un budget illimité (en France en tout cas) => Se rabattre sur des modèles grand public peut-être très intéressant pour un rapport P/P.
3/ Merci pour ton intervention inutile
par Un ragoteur Gaulois embusqué, le Jeudi 12 Juillet 2018 à 08h08  
par UpsiloNIX le Mercredi 11 Juillet 2018 à 10h35
GPGPU [...] A partir du moment où tu as du CUDA Opencl(ou équivalent) dedans tu peux utiliser ton GPU pour ça. Pas mal de scientifiques utilisent des 1080 Ti ou des Titan Tesla avec NVSwitches pour ça justement
par UpsiloNIX, le Mercredi 11 Juillet 2018 à 12h39  
par Nicolas D. le Mercredi 11 Juillet 2018 à 11h52
A l'exception de la double précision castrée des modèles grand public chez NVIDIA oui . D'ailleurs, PNY avait rajouté il y a peu stopper la garantie si les cartes avaient servi au minage de données !
Oui aussi ! Après le calcul en double précision reste dédié à un usage assez spécifique. Oui, mais calcul scientifique et minage ce n'est pas la même chose (Bien que pour PNY ce serait impossible de faire la différence entre les deux).
L'année dernière j'étais justement l'ingé en charge du montage d'un cluster GPGPU pour des chercheurs, 28x1080 Ti (de chez PNY justement ), et ça passait en garantie. Bon Dell a râlé, soit disant que des GTX dans un datacenter c'est pas supporté, mais bon ils voulait nous vendre des Tesla 6x plus cher, pour ~ les mêmes perfs au final (Simple et demi précision).
par Nicolas D., le Mercredi 11 Juillet 2018 à 11h52  
par UpsiloNIX le Mercredi 11 Juillet 2018 à 10h35
GPGPU c'est juste une méthode d'utiliser un GPU pour des calculs "génériques", ce n'est pas des cartes graphiques spéciales. A partir du moment où tu as du CUDA (ou équivalent) dedans tu peux utiliser ton GPU pour ça. Pas mal de scientifiques utilisent des 1080 Ti ou des Titan pour ça justement
A l'exception de la double précision castrée des modèles grand public chez NVIDIA oui . D'ailleurs, PNY avait rajouté il y a peu stopper la garantie si les cartes avaient servi au minage de données !
par UpsiloNIX, le Mercredi 11 Juillet 2018 à 10h35  
par Un ragoteur qui draille embusqué le Mardi 10 Juillet 2018 à 22h03
> soit par un découpage et une répartition des tâche sur des accélérateurs dédiés tels des GPGPU (les cartes graphiques dédiées aux calculs scientifiques).
GPGPU c'est juste une méthode d'utiliser un GPU pour des calculs "génériques", ce n'est pas des cartes graphiques spéciales. A partir du moment où tu as du CUDA (ou équivalent) dedans tu peux utiliser ton GPU pour ça. Pas mal de scientifiques utilisent des 1080 Ti ou des Titan pour ça justement
par Un médecin des ragots embusqué, le Mardi 10 Juillet 2018 à 22h17  
par Un ragoteur qui draille embusqué le Mardi 10 Juillet 2018 à 22h03
De ce que j'en comprend sa "chirurgie de dépôt" a une énorme working sets et une grosse compléxité algorithmique qui l'empêche d'être bien parallélisée.
De ce que j'en ai compris, ESR travaille comme un manouche et se plaint que le matos ne soit pas assez performant pour son bricolage artisanal qui scale très mal sur GCC qui soit dit en passant est un pot pourri de compilateurs qui mériterait d'être défriché.
par Un ragoteur qui draille embusqué, le Mardi 10 Juillet 2018 à 22h03  
> soit par un découpage et une répartition des tâche sur des accélérateurs dédiés tels des GPGPU (les cartes graphiques dédiées aux calculs scientifiques).

Je n'ai pas l'impression que c'est ce qu'il dit :
"The truth is we're near the bleeding edge of what conventional tools
and hardware can handle gracefully. Most jobs with working sets as
big as this one's do only comparatively dumb operations that can be
parallellized and thrown on a GPU or supercomputer. Most jobs with
the algorithmic complexity of repository surgery have *much* smaller
working sets. The combination of both extrema is hard."

Si je traduis grossièrement :
"La vérité est que nous sommes près de la limite de ce que les outils conventionnels et le matériel peuvent gérer sans soucis.
La plupart des tâches avec un ensemble de travail aussi gros que celui-ci effectuent des opérations de comparaisons assez bêtes qui peuvent être parallélisées et exécutées sur un GPU ou un supercalculateur.
La plupart des tâches avec la compléxité algorithmique de cette chirurgie de dépôt ont de beaucoup plus petits ensembles de travail.
La combinaison des deux extrême est compliqué."

De ce que j'en comprend sa "chirurgie de dépôt" a une énorme working sets et une grosse compléxité algorithmique qui l'empêche d'être bien parallélisée.
par Xorg, le Mardi 10 Juillet 2018 à 22h02  
par Nicolas D. le Mardi 10 Juillet 2018 à 20h56
Le comique probablement, ça change un peu des spec techniques et autres non ?
Bah, je n'ai jamais vu Phoronix comme un média humoristique. L'humour, c'est la marque de fabrique de CDH, mais sur Phoronix, j'ai plutôt été habitué à des détails techniques sans humour.

C'est sans doute une certaine forme de jalousie, car le type est là "Hen c'est pas assez 64Go de DDR4 !". Et à côté de ça, il y a des gens qui n'ont "que" 8Go de DDR3.
par Un ragoteur sans nom embusqué, le Mardi 10 Juillet 2018 à 21h29  
par Xorg le Mardi 10 Juillet 2018 à 18h49
Déjà hier, quand j'ai lu cet article sur Phoronix, je n'ai pas compris pourquoi Michael Larabel a écrit un article à ce sujet : ce n'est pas ce qu'on peut qualifier d'un problème majeur. Oui, c'est gênant (voire comique), mais diverses solutions ont été proposées à ESR.
Après, je ne suis pas un expert de la conversion SVN vers Git, mais pour que ça pompe autant de RAM, c'est très certainement que le Python n'est pas adapté à ce genre de tâche.
ESR est plutôt à côté de ses pompes et l'âge n'aide pas...
par Nicolas D., le Mardi 10 Juillet 2018 à 20h56  
par Xorg le Mardi 10 Juillet 2018 à 18h49
Déjà hier, quand j'ai lu cet article sur Phoronix, je n'ai pas compris pourquoi Michael Larabel a écrit un article à ce sujet : ce n'est pas ce qu'on peut qualifier d'un problème majeur. Oui, c'est gênant (voire comique), mais diverses solutions ont été proposées à ESR.
Le comique probablement, ça change un peu des spec techniques et autres non ?
par Un alsacien à l'heure embusqué, le Mardi 10 Juillet 2018 à 19h43  
D'ailleurs, le Python est-il adapté à quoi que ce soit ?

Ne me cherchez pas je suis déjà sorti !