"Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur."
Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
"- compilateur : des perfs pour quoi faire ?"
Pour rien. Personne ne se plaind du temps de compilation de C++, et personne n'a créé go pour aider se coté là.
"- navigateur internet... le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables."
Juste mdr. Regarde la taille du code source de Mozilla ! C'est plus gros que Linux.
"Pour l'histoire du cache, ce n'est pas un argument, juste un fait."
Tu n'as à alors rien compris au supposer avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
[^] # Re: Et les compilateurs?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 1.
"Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur."
Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
"- compilateur : des perfs pour quoi faire ?"
Pour rien. Personne ne se plaind du temps de compilation de C++, et personne n'a créé go pour aider se coté là.
"- navigateur internet... le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables."
Juste mdr. Regarde la taille du code source de Mozilla ! C'est plus gros que Linux.
"Pour l'histoire du cache, ce n'est pas un argument, juste un fait."
Tu n'as à alors rien compris au supposer avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
"La première sécurité est la liberté"