J'en parlai il y a déjà 1 an et demi, mais il semble que le problème - insoluble - de l'invasion du multicoeur inquiète sérieusement l'industrie.
Dans cet article de LMI, un analyste de Gartner tire la sonette d'alarme sur l'avenir du logiciel sur les serveurs.
Le problème n'est même plus de réussir à faire des logiciel capable de faire leur boulot de manière performante avec 32,64,... 512 processus/thread, le problème est que les OS eux-même, en particulier sur x86 gèrent avec difficulté des architecture multicoeur.
Comment vas t-on solutionner cet épineux problème, jusqu'où va aller la multiplication des coeurs dans les processeurs ? 16, car après cela posera trop de problèmes de communication ?
Va t-on assister à l'émergence des langages http://shootout.alioth.debian.org/gp4/benchmark.php?test=thr(...)">qui gèrent correctement le parallélisme (Erlang, Smalltalk, Haskell, etc...) ?
Les hyperviseurs vont ils suivre ?
Plein de question qui supposent beaucoup de changements de perspectives dans l'industrie...
Journal Le multicoeur va vraiment devenir problématique
6
fév.
2009
# Le multicoeur va vraiment devenir problématique
Posté par IsNotGood . Évalué à 10.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par totof2000 . Évalué à 10.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Dabowl_92 . Évalué à 1.
Paralléliser au maximum est une bonne chose mais induit des risques d'incohérence puisque une page peut être accédée par plusieurs cpu en même temps, donc plus on ajoute de cpu/coeur, plus il faut gérer les accès concurrents, et plus on peut perdre en performances.
D'après ce que j'ai pu lire sur le sujet, il existe bon nombre d'algorithme et bon nombre de chercheurs ce sont déjà penché sur le sujet, donc finalement j'ai un peu de mal à voir en quoi augmenter le nb de coeur pose un pb :
est-ce que les algo de gestion de concurrence sont devenus inefficaces ?
Pour illustrer mes propos, le document ci-après illustre quelques algorithme de gestion de concurrence :
http://arcad.essi.fr/cours/systeme2/96-cnam-coherence.pdf
Le document date un peu mais finalement l'informatique est un phénomène cyclique ou l'on revient souvent en arrière sur d'anciennes théories :)
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 6.
Une implémentation efficace d'un algo -- qui plus est parallèle -- va devoir finir par tenir compte de certains aspects matériels. Par exemple, les préchargeurs matériels sur les processeurs sont une mâne providentielle pour beaucoup d'usages, mais peuvent provoquer une perte de performance, car ils peuvent introduire en grande quantité du trafic de cohérence de cache inutile.
De toute façon le multicore est là pour rester, car l'équation concernant la dissipation thermique n'est pas prête d'être révisée. Donc pas la peine de rêver : pour les cinq à dix prochaines années au moins, on va manger du multicore. Autant se faire à la loi d'Amdahl (et à son pendant, celle de Gustafson). Grosso modo, elle dit ceci :
Pour une implémentation parallèle de la résolution d'un problème et une taille des entrées donnés, on a
Accélération = 1 / (Par/Nproc + 1-Par),
où Par = le temps pris par la totalité du code parallèle, 1-Par est la part purement séquentielle, Nproc est le nombre de tâches parallèles exécutées concurremment.
Pour faire simple, si j'ai parallélisé mon code à 80% (0.8), et que j'ai 16 processeurs/coeurs, on a :
Accélération = 1 / (0.8/16 + 1-0.8) = 4
Gustafson est un peu plus optimiste et rappelle que nous allons bosser sur des problèmes de plus en plus gros avec la même machine, et que donc si on fait grossir la part du problème, ce qui faisait avant 80% de parallélisation fera sans doute 85, 90% ou même plus.
Dans tous les cas, un algo parallèle a tous les problèmes d'un algo séquentiel, avec en plus la part de communications et la contention sur les ressources "rares" (bus mémoire[s], entrées/sorties, etc).
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par fcartegnie . Évalué à 10.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par IsNotGood . Évalué à 3.
Arrêtez avec les critiques débiles sur x86.
Du journal :
- "le problème est que les OS eux-même, en particulier sur x86 gèrent avec difficulté des architecture multicoeur."
Sur quoi est fondé ce truc ?
Même Cray fournit du x86.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par galactikboulay . Évalué à 5.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par qstone . Évalué à 3.
Je ne vois pas non plus le rapport entre le jeu d'instruction (qui concerne chaque processeur de manière indépendante) et le multiprocessing (géré par un composant "externe", les APIC sur x86 si ma mémoire est bonne).
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par galactikboulay . Évalué à 6.
Le nombre de registres disponibles (8 en 16/32, et encore avec 6 concrètement utilisables) est à mourrir de rire. C'est à peine mieux en x86_64, puisque pour utiliser les 8 registres supplémentaires (total de 16 donc), il faut utiliser un préfixe...
Alors c'est sûr, ce n'est pas spécifique au SMP, ça prouve que c'est juste une architecture de merde.
Ensuite pour ton information, l'APIC ça ne "gère" pas le SMP dans l'ensemble, ça permet l'aiguillage des interruptions vers les différents CPU dans un système SMP.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par chimrod (site web personnel) . Évalué à 1.
a = b + c :
ld [b] ; pile : b
fadd [c] ; pile : b+c(a)
fst [a] ; pile : b+c(a)
z = b + a
ld [b] ; pile : a|b
fadd ; pile a+b
fstp[z] ; pile vide
Il est quand même présent depuis longtemps, donc à moins que tu ne codes en 286 tu cherches quand même à te compliquer la vie... ( En plus ça accélère le process puisque le CPU est déchargé pendant ce temps... )
Le vrai problème du x86 c'est de ne pas avoir pu imposer que tous les opérandes ne travaillent qu'avec les accumulateurs, et devoir conserver ce vieil héritage du chargement des données en mémoire. ( et de devoir emuler les instructions pour les rendre compatibles... )
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Guillaume Knispel . Évalué à 4.
(en confondant au passage machine à 3 adresse et machine à pile, même s'il est vrai que le FPU est une espèce d'hybride nauséabond entre machine à pile et machine à adresses).
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Troy McClure (site web personnel) . Évalué à 3.
(et sinon avec AVX intel re-invente les instructions à trois operandes)
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par JoeltheLion (site web personnel) . Évalué à 4.
Et c'est sans doute parce que c'est une architecture "de merde" que les x86 ont écrasé leurs concurrents pendant tant d'années.
Moi, personellement, j'en ai rien à cirer du nombre de registres ou de la facilité à les gérer. Ce qui m'intéresse (et 98% des développeurs), c'est la performance des applications écrites en C. Et si les performances sont à la hauteur, c'est bien la preuve que l'architecture est tout à fait utilisable.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par plagiats . Évalué à 0.
\_o< ~~
Ah ! On me souffle dans l'oreillette hors série que Python ne gère pas le multicoeur. Veuillez poursuivre.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Alex . Évalué à 2.
???
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par ckyl . Évalué à 2.
En gros tu peux faire des threads en python mais ça ne te permettra pas d'exploiter plusieurs cœurs en même temps. Ça peut toujours améliorer le débit de ton appli en ne restant pas bloqué bêtement sur des IO.
D'autres implémentation que CPython pourrait proposer un vrai threading.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Alex . Évalué à 2.
Python semble proposé des modules spécifiques pour cela, de plus la bonne vieille méthode du fork est tout aussi valable.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Larry Cow . Évalué à 3.
Largement, pour moi. Autant les threads sont rapidement incontournables quand on vise la réactivité (l'approche BeOS d'avoir un fil d'exécution par fenêtre, ça serait ingérable avec des fork()s). Par contre, pour des traitements "lourds", fork()er reste bon marché. Et beaucoup plus "simple" à implémenter/débugguer (bon, c'est pas tant le fork lui-même que les algos utilisés dans ce genre de cas).
Pour de la bureautique de base, l'utilisateur va tout naturellement utiliser plusieurs programmes distincts (de très nombreux, même, vu la tendance actuelle) qui sauront tout à fait se répartir entre les coeurs.
En fait, j'ai du mal à voir où est le problème, je crois.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ensuite, on bosse pour la plupart sur x86 et on est bien content qu'il marche bien. C'est pas pour cela qu'il faut le bénir.
J'ai fait très peu d'assembleur mais le x86 était déjà une horreur. J'espère que le x86_64 est mieux.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par M . Évalué à 5.
Mais aussi parce qu'il etait retro-compatible :
les personnes ayant acheté des logiciels proprios, ayant développé du code optimisé en assembleur, ... pouvait toujours le faire tourné sur les nouveaux cpu sans rien acheté de nouveau ni revalider leur code.
PS : du coté de arm [1] ca commence aussi à devenir le bordel :
il y a le mode 32 bits classiques, le mode thumb (instruction réduite tenant sur 16 bits), le mode thumb2 (ou les instructions sont de taille variable 16 ou 32 bits), et toutes les instructions dsp, SIMD qui ont été ajouté au fil des nouvelles versions...
[1] http://en.wikipedia.org/wiki/ARM_architecture
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Sytoka Modon (site web personnel) . Évalué à -3.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par M . Évalué à 4.
La majeur partie des evolutions ont été fait par ARM pas intel...
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Depuis, Intel a revendu sa partie ARM à Marvell et pousse sa stratégie x86 au maximum sur les plate-bande d'ARM avec l'ATOM.
Ceci dis, je ne suis pas sur que le monde ARM soit aussi complexe que le seul x86 ! Si tu rajoutes la partie AMD64, l'x86 a largement une longueur d'avance en terme de bordel. Si mes souvenirs sont bon, le x86 boote encore en 16bits au niveau du BIOS ?
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Ontologia (site web personnel) . Évalué à 4.
Par contre il y a un truc absolument génial sur l'x86, c'est la gestion de la mémoire. C'est une tuerie : les 4 ring, la segmentation, la gestion de la mémoire paginée, bref le 386, c'est génialement pensé.
Pour le reste...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par M . Évalué à 4.
Oui, mais bon est-ce réellement utilisé ?
Déja la segmentation on dirait pas.
Qui utilise les 4 rings ? Linux en utilise 2, Windows 3 ?
Je préfère largement une bête table mmu avec un mode user/superviseur.
PS : ce qui est une tuerie (un vrai merdier), c'est les differents mode du x86 : real mode, unreal mode, protected mode, virtual mode, ...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je me souviens qu'en 98-99, l'Alpha était un grand espoir. J'en ai eu un entre les mains et c'était du bonheur. Mais on ne les trouvais plus ensuite ou alors a des prix défiant toute concurrence...
Si mes souvenirs sont bons, Windows tournait aussi sur Alpha (mais pas chez nous, on tournait déjà sous debian).
Des arguments de compatibilité sont donnés pour expliquer la force de l'x86, mais il y a encore peu, il y avait plus de processeur de la gamme ARM de fabriqué que de dérivée x86 ! Je n'ai pas les chiffres actuels.
Apple n'a pas arrêter de changer de processeur et est toujours là avec son OS qui monte, qui monte...
Le x86 arrive sur sa fin, le amd64 le remplace progressivement. Même s'il y a un mode compatible, pour moi, ce sont quand même deux processeurs différents, on le voit bien, c'est pas la même version de Linux, de Windows...
Donc, l'OS dominant Windows va être obligé de passer en grande série sur Windows64 et les éditeurs seront obligé de suivre. La compatibilité sera cassé comme elle l'a été entre Windows 3.11 et Windows 95. Et Windows 64 sera encore l'OS dominant car Linux n'a pas encore assez de part de marché pour renverser la tendance, l'échéance me semble trop proche.
Sinon, il y a comme dis plus bas l'Itanium d'Intel mais, pour en avoir une machine Itanium, il ne doit pas y avoir le dixième (centième) des moyens de l'amd64 sur l'Itanium. Si cela continue ainsi, l'Itanium va mourrir gentilement. A mon sens, Intel est en train de fusionner les deux gammes Itanium et amd64, le chipset sera commun, les cartes mères... On va pouvoir faire des vrais machines SMP avec de l'amd64. Je ne sais pas ce qu'il va rester à l'Itanium, le rôle d'un coprocesseur ?
Bref, le x86 a encore de l'avenir devant lui mais comme pour le 8086 avant lui, il sera la mais va doucement disparaitre pour laisser la place a l'amd64.
PS : comme debian, je préfère l'appellation amd64 a x86_64 car c'est une creation AMD et non Intel. L'appellation amd64 redonne donc a AMD ce qui est a AMD.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Gniarf . Évalué à 0.
alors l'amd64 devrait s'appeller intel64 parce que bon, dans ce cas faudrait aussi que AMD rende ce qui est à Intel...
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par thedude . Évalué à 3.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Serge Julien . Évalué à 6.
Moins cher, je veux bien, mais en terme de rapidité, il n'y avait pas photo. Je me souviens avoir utilisé Windows NT4 en 96-97 sur des machines DEC Alpha, c'était incroyablement rapide (et encore plus avec Digital UNIX, je faisais du Fortran). Même les applis Windows compilées pour x86 pouvaient tourner avec un émulateur (FX!32), et elles étaient à peine moins rapides que sur des archis natives.
Non, à mon avis, ce qui a vraiment tué l'Alpha, c'est le rachat de DEC par Compaq, puis de Compaq par HP. Le produit a subi une concurrence interne et a été mis sur une voie de garage.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Gniarf . Évalué à 2.
dont de la mémoire très rapide... et hors de prix
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par ZeroHeure (site web personnel) . Évalué à 4.
D'après un ami, ancien cadre de digital:
Le PDG et le consei d'administration ont volontairement fait couler DEC. On s'est longtemps demandé pourquoi. On a compris après la vente à Compaq et Intel: les stock-options, le montant des (nouvelles) dividendes, ... l'argent du rachat quoi.
c'est le rachat de DEC par Compaq
Si mes souvenirs sont bons, la division processeur (l'alpha donc) a été rachetée par Intel.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par cedric . Évalué à 3.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Hé ! On ne parle pas du moyen-âge ;-) À l'époque on avait des environnements de bureau très utilisables, à coté desquels le multi-tâche des Windows, que ce soit 3.1x ou NT, faisait réellement pitié. Et je ne parle pas des serveurs !
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par ZeroHeure (site web personnel) . Évalué à 3.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Littleboy . Évalué à 4.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Antoine . Évalué à 5.
Bien sûr que si, il y a encore des points de comparaison.
Sun continue à développer des processeurs Sparc, et IBM des processeurs POWER. Par ailleurs Intel lui-même développe une architecture concurrente depuis 15 ans, l'Itanium.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Antoine . Évalué à 1.
Les Sparc sont à la ramasse, quant aux processeurs POWER il faudrait voir le budget de la division processeurs d'IBM, je ne pense pas que ce soit minuscule. De plus les processeurs POWER ont une dissipation thermique énorme.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 3.
Euh non. Vraiment pas. Le POWER n'a vraiment pas la même dissipation thermique que le powerpc. D'ailleurs, dans les calculateurs de type Blue Gene, on utilise des PowerPC de faible fréquence, et pas des POWER 6 à 4 GHz...
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par JoeltheLion (site web personnel) . Évalué à 1.
Le compilateur lui n'en a pas rien à foutre. Le jeux d'instruction et le nombre de registres sont des facteurs vraiment important dans les phases d'optimisation. Avec une telle architecture :
- les capacités de parallélisation au niveau des instructions (superscalar) sont gravement impactées
- la réutilisation des valeurs dans les registres est compromise [2]
- l'utilisation de la cache du processeur n'est pas optimale
Je suis bien au courant, mais toute ma réponse tient dans la réponse de Nicolas Boulay:
Si l'alpha est mort, c'est bien parce que le coeur x86 était plus rapide ou à peine moins rapide mais beaucoup moins chère.
Les registres en plus, c'est peut être pratique, mais c'est sans doute aussi plus cher. Si avec un bon compilo, on arrive presque aux mêmes performances avec moins de registres et pour moins cher, quel intérêt d'en avoir plus?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Antoine . Évalué à 3.
Tu viens de décrire le x86-64. Sauf que l'amélioration de performances est plutôt de l'ordre de 10 à 30%, il me semble.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Sur un athlon avec 3 décodeurs, 5 unité d'executions, l'ilp moyen est de 1.9...
Donc, ce genre de problème est minime. (Je rappelle qu'un cache miss, c'est 100 cycles de perdu)
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Dans ton exemple, je pense que les 6 instructions sont exécutables en parallèle car les mov sont simplifiables et revienne à ton deuxième cas (les seuls vrais dépendances sont les read after write).
Sinon cela coute cher, c'est bien pour ça que Intel va introduire la notation à 3 registres dans une prochaine révision du SSE.
(ne pas oublier aussi que la notation à 2 registres sauve 3 à 4 bits par instructions ! cela participe à la grande compacité du code x86, et donc à l'efficacité de son cache instruction à comparer avec les caches itanium !)
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 6.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Les systèmes de renomages de registre permet de voir plus de registres mais nécessite beaucoup de silicium.
Donc, pour avoir la même performance, il faut plus de Si, mais cela prends moins de place dans le mots d'instruction, donc cela diminue la taille des programmes. Ce n'est pas simple !
"La première sécurité est la liberté"
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Gniarf . Évalué à 2.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 4.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par lasher . Évalué à 3.
D'accord aussi pour la question des instructions prédicatées. Maintenant avec les VLIW on a quand même eu droit à tout un tas d'algos « spécifiques » pour la transformation de code (supertraces/superblocs/hyperblocs entre autres). La plupart du temps, elles nécessitent assez de mémoire pour en profiter (car on doit générer beaucoup de versions différentes des mêmes blocs d'instructions initiaux), mais sur une machine telle que l'Itanium 2 (surtout le Montecito, avec ses 1 Mo de L2I) ce n'était pas trop un problème.
Ça n'empêche pas que sur une machine out-of-order, les codes « pourris » -- ie dont le code machine/assembleur a été mal ordonnancé, l'allocation des registres pas forcément bien fichue [1] se débrouillent pas trop mal, mais les codes bien fichus en pâtissent...
[1] Bon ok, sur x86, avec ses 16 registres généraux et ses 16 registres SSE donc très spécialisés, c'est pas forcément le plus simple pour l'alloc des registres.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Guillaume Knispel . Évalué à 4.
Non c'est à cause de Windows.
Ça reste de la merde (même si c'est vrai que c'est rapide, enfin tout dépend de ta mesure, si tu calcul des rapports puissance / prix ou puissance / conso tu trouveras que c'est pas si rapide que ça, sauf qu'en France on s'en fiche grâce à toutes nos centrales nucléaires -- de toute manière pour la plupart des gens qui veulent Windows, ils ont au final pas le choix, donc fin du débat).
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Antoine . Évalué à 3.
Et, au final, on s'en contrefout, puisque c'est le compilateur qui fait le boulot.
Par ailleurs le journal est juste un troll de première classe, l'architecture x86 n'est pas pire que les autres pour faire du multicoeur (Linus Torvalds semble même penser que son modèle de cohérence mémoire -- memory ordering model -- est plus sain que celui d'autres architectures).
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par IsNotGood . Évalué à 3.
Mais x86 des années 80 n'est pas celui d'aujourd'hui.
Entre autre, les efforts sont maintenant sur x86_64. Certe ce dernier est compatible x86, mais un x86 est tout petit à côté d'un x86_64 (qui doit avoir MMX2, SSE3, etc).
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Antoine . Évalué à 3.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Gniarf . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Où est le problème ?
Posté par Francois G. (site web personnel) . Évalué à 7.
Il n'y a que Gartner qui peut faire des prévisions de ce genre...
Pour le reste, quand il y a eu un "problème", il y a toujours eu des solutions.
Que l'on ait pas la solution "parfaite" aujourd'hui pour les ordinateurs de demain, cela n'est pas un problème ... à mon avis.
Et comme tu le dis, dans ton journal, on a déjà le début d'éléments théoriques.
Ce qui est plutôt bon signe à ce stade.
[^] # Re: Où est le problème ?
Posté par Ontologia (site web personnel) . Évalué à 7.
J'aime ça, je trouve ça marrant, et j'aime pas vivre au jour le jour ('fin si, de plus en plus et c'est pas plus mal). Si c'est ton truc de pas te poser de questions, parce que c'est "imprévisible", bahh, c'est cool pour toi :-)
Et comme tu le dis, dans ton journal, on a déjà le début d'éléments théoriques.
Ce qui est plutôt bon signe à ce stade.
Pas faux, mais il restent des problèmes... La théorie, c'est bien, mais dans une SSII j'en connais peu qui s'y connaissent un minimum..
- Comment apprend t-on au dev moyen à coder avec des threads... en java ? (oui je sais, ya leur nouveau fork/join)
- Comment on debug sur des logiciels multithreadé et donc très peu déterministe ?
- On fait comment pour gérer les perfs ? Gérer le partage de mémoire ? etc...
- Combien de temps ça va mettre d'avoir de la gestion automatique de parallélisme dans les langages/framework mainstream ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Où est le problème ?
Posté par Anonyme . Évalué à 3.
Il suffit d'utiliser des outils modernes tel que le Fortran! :D
[^] # Re: Où est le problème ?
Posté par Gniarf . Évalué à 2.
[^] # Re: Où est le problème ?
Posté par Anonyme . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Où est le problème ?
Posté par Jerome Herman . Évalué à 7.
On lui apprend pas, soit on le passe sur un autre paradigme (programmation fonctionelle), soit on lui met un framework qui gère çà à sa place.
Comment on debug sur des logiciels multithreadé et donc très peu déterministe ?
Dans une VM en évaluation multi-état. On va se retrouver avec de plus en plus de routeur d'info à la centralisateur COM/shm ou autre RMI. Après c'est assez lourd, mais comme ca n'interressera que les devs de framework et pas les devs moyens, ca devrait passer.
On fait comment pour gérer les perfs ? Gérer le partage de mémoire ? etc...
On fait pas, on laisse de CPU et le noyeau se débrouiller tous seuls, et surtout, surtout on ne s'en mêle pas. Il y a plus grand monde capable de battre la gestion mémoire ou l'allocation de perf d'un système sur une application quelconque. (N.B : et arréter de coder des systèmes de gestion du cache mémoire aussi...)
Combien de temps ça va mettre d'avoir de la gestion automatique de parallélisme dans les langages/framework mainstream ?
Si par Framework mainstream on parle de .Net ou de J2EE 1.3+, c'est déjà fait.
[^] # Re: Où est le problème ?
Posté par Bruno Muller . Évalué à 2.
On fait pas, on laisse de CPU et le noyeau se débrouiller tous seuls, et surtout, surtout on ne s'en mêle pas. Il y a plus grand monde capable de battre la gestion mémoire ou l'allocation de perf d'un système sur une application quelconque. (N.B : et arréter de coder des systèmes de gestion du cache mémoire aussi...)
Complètement d'accord :)
Et à ce sujet, voir cette page http://varnish.projects.linpro.no/wiki/ArchitectNotes que je trouve très instructive.
[^] # Re: Où est le problème ?
Posté par Guillaume Knispel . Évalué à 1.
1) arrêtons de faire manuellement X, Y ou Z car c'est toujours mieux fait automatiquement.
2) tous les logiciels de la galaxie sont de haut niveau et doivent être écrit en C# / Java / Whatever.
Les années passent est c'est une vision toujours autant approximative et partielle (bon allez je suis gentil donc j'ajoute : presque ;)
[^] # Re: Où est le problème ?
Posté par lasher . Évalué à 2.
Grâce à tout ce merdier multicore, je pense que j'aurai du boulot pour encore quelques années.
Les outils qui gèrent le multicore existent pourtant en partie, mais malheureusement ne sont pas libres : DDT et Total View par exemple (qui ont aussi plein de défauts) sont des debuggers fait exprès pour les programmes parallèles (ils comprennent même MPI et OpenMP).
gdb gère les threads POSIX, et DDD (qui a récemment repris son dév) est capable d'en tirer parti.
C'est pas encore la joie, mais ça avance. Il existe tout un tas d'outils pour analyser la mémoire (ValGrind et Acumem [non-libre] sur x86 par ex).
C'est loin d'être suffisant, mais je pense qu'il faudra encore 5 ans mini pour avoir des outils utilisables par des non-experts pour trouver les bugs ET améliorer les perfs. Mais ça va venir, nécessairement.
[^] # Re: Où est le problème ?
Posté par Psychofox (Mastodon) . Évalué à 7.
Quand tu achètes un serveur, tu n'as plus que du multicoeur. Et des fois, quand tu changes de serveur, c'est pour des questions de performances. Quand tu te retrouves avec une vieille application monothread dont tu sais pertinemment que l'éditeur ne pourra pas tout recoder en multithread dans les mois qui viennent, et que tes performances sont en baisses (nombre d'utilisateurs plus grands, base énorme, etc...) et que tu te rends compte que tu ne peux améliorer les perfs que marginalement (plus de mémoire, disques plus rapide, mais cpu pas plus rapide, voire plus lents), t'as l'impression de t'être fait rouler.
L'avantage c'est que parfois, quand ta boite a un département developpement efficace, c'est un peu le coup de pied au cul qui peut te permettre de redevelopper ce dont tu as besoin et t'affranchir d'un éditeur tiers de solution propriétaire. Mais ça ne se fait pas en un jour et c'est toujours au détriment d'autre chose.
En tout cas c'est une réalité que l'on vit déjà dans ma boite (les applications de plus de 10 ans, c'est fréquent).
[^] # Re: Où est le problème ?
Posté par steckdenis (site web personnel) . Évalué à 7.
L'avantage du multi-coeur est tout de même significatif. Même avec des programmes de 10 ans, c'est un pur bonheur de pouvoir en lancer plusieurs sans aucun ralentissement, ou presque (et sur ce point, les 3 OS principaux se débrouillent encore pas trop mal).
J'ai eu l'occasion d'utiliser deux ordinateurs, dont les processeurs allaient à la même vitesse, en étant de la même architecture, et avec presque la même configuration matérielle. Sur le premier, quand j'ai démarré GIMP pendant que je compilais un programme, la compilation a été fortement ralentie, et GIMP aussi.
Sur le deuxième, tout s'est magnifiquement bien passé, et les deux tâches étaient aussi rapide que si l'ordinateur était occupé à ne rien faire.
De même, sur les serveurs, quand on utilise des applications modernes (donc moins de 15 ans), on n'a pas ce problème. Ca fait très longtemps que les serveurs sont équipés de plusieurs processeurs. La preuve : Linux gère parfaitement le multi-coeur, et Microsoft a annoncé en grande pompe que Windows NT 4 gérait le multi-processeur.
Par exemple, Apache lance plusieurs processus en même temps, et même il y a pas mal de temps, avoir deux processeurs signifiait qu'il y en avait 1 pour MySQL/PgSQL/etc et un autre pour Apache et le reste.
Bref, je n'ai jamais connu de problèmes avec le multi-coeur et le multi-processeurs, et mon père monte des ordinateurs avec 2 Quand Core dedans (donc 8 coeurs), et ça marche magnifiquement bien (c'est pour du montage vidéo temps réel).
A plus.
[^] # Re: Où est le problème ?
Posté par Psychofox (Mastodon) . Évalué à 0.
Pour moi l'exemple de gimp sur un desktop pendant une compilation n'est pas significatif de ce genre de problématiques. Sur un desktop, on a tendance à faire beaucoup de chose en même temps : musique, navigateur web + autres applis. Sur un serveur on multiplie en général moins les usage, à la fois pour des questions de performances mais aussi de sécurité. Et toute les applications ne prennent pas autant avantage d'un multicoeur comme ton exemple d'Apache.
Une base Oracle par exemple peut tirer avantage de plusieurs coeurs, mais jusqu'à une certaines limite. Mais quand on parle de serveurs actuellement sur le marché avec 128 coeurs, on est déjà très loin de cette limite. Ces machines ne trouvent leur avantage que dans la virtualisation, mais ça n'en fait pas des bêtes de course.
[^] # Re: Où est le problème ?
Posté par georgeswwbush . Évalué à 1.
Foutaise !!!
Au contraire: chaque connexion à une instance Oracle correspond à un nouveau processus/thread démarré sur le système (en mode serveur dédié, donc par défaut), donc bénéficie parfaitement du nombre de CPU.... plus il y en a, mieux c'est !!! (indépendamment du reste: IO, bus, mémoire, etc...)
Et même en paramétrant un peu, pour des requêtes DSS, on peut utiliser le Parallel Query Option: une même requête SQL est divisée pour être exécutée en paralléle par plusieurs slaves....
[^] # Re: Où est le problème ?
Posté par ckyl . Évalué à 1.
Et bien sur Oracle à une architecture shared nothing entre tout ces threads qui devine le résultat de ta requête grâce à un oracle.... Rappelle moi de ne jamais t'embaucher pour bosser sur une appli parallèle.
http://forge.mysql.com/w/images/7/73/Mysqlscale.pdf pour te faire un peu de culture. C'est une introduction, c'est un peu plus compliqué dans la réalité.
Même si c'était le cas, les OS actuels galèrent pas mal si tu augmentes significativement le nombre de coeurs. Genre simplement pour se partager une carte réseau et réussir à saturer du 10Gb. On peut aussi aller jouer dans le VFS ou dans le VMM si tu veux aussi.
[^] # Re: Où est le problème ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Au dela de 1024 ceurs, il faut aussi que les codes tournent... mais bon, j'ai vu un 'vrai' code tourner sur plus de 10000 coeurs en restant efficace. Cela fait plaisir de voir que cela marche. La limite n'est pas encore la.
[^] # Re: Où est le problème ?
Posté par ckyl . Évalué à 3.
De mémoire il me semble que tu bosses dans le HPC. Dans ce contexte oui, pour du code dédié à un hardware et qui fait des choses assez "limité" ca fonctionne. Le multicore expose les problèmes que l'on a dans le HPC depuis quelques dizaines d'années...
Dire qu'actuellement les OS sont capables de scaler linéairement sur 1024 cores pour une charge de travail généraliste n'est pas vrai.
Le premier papier intéressant qui me vient à l'esprit est corey, qui à des propositions intéressantes pour des archis fortement multicore: http://www.mit.edu/~y_z/papers/corey-osdi08.pdf
[^] # Re: Où est le problème ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ensuite, il est clair que le mode de fonctionnement n'est pas exactement le même sur un bureau que sur une machine de calcul.
[^] # Re: Où est le problème ?
Posté par Antoine . Évalué à 5.
C'est vraiment n'importe quoi là (bis).
Au contraire, un serveur par construction va souvent devoir servir plusieurs utilisateurs à la fois et de façon indépendante, ce qui est tout de même un vecteur idéal de parallélisation.
Après, si l'appli utilisée ne le permet pas, c'est qu'elle a été écrite par des guignols (bis repetita, cf. plus haut).
[^] # Re: Où est le problème ?
Posté par Psychofox (Mastodon) . Évalué à 3.
oui c'est bien ce que je dis. Et dans la vrai vie, et en entreprise, on est aussi confronté à des . Et lâ-bas on n'a pas vraiment le droit de leur donner des claques, donc il faut faire avec et trouver les solutions la où elles sont.
[^] # Re: Où est le problème ?
Posté par IsNotGood . Évalué à 2.
Il n'y a rien de nouveau ici. Après qu'il y ait des gogos qui croit l'inverse...
[^] # Re: Où est le problème ?
Posté par Jerome Herman . Évalué à 0.
C'est clair, il vaut beaucoup mieux avoir une opération synchrone qui bloque le processeur d'un coté en attendant (par exemple) un retour I/O ou une synchro du cache que de pouvoir faire autre chose sur un autre processeur en attendant.
Par exemple il vaut nettement mieux faire tourner à la queue leu leu 200 processus dont une dizaine font de petites opérations mais qui requièrent un appel système avec changement de contexte à la clef, que de faire tourner les mêmes processus chacun dans leur coin sur des processeurs séparés.
Il n'y a rien de nouveau ici. Après qu'il y ait des gogos qui croit l'inverse...
Elle est longue la liste des gogos... A moins que tu ne sois encore sur un OS monotache mono utilisateur.
[^] # Re: Où est le problème ?
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Où est le problème ?
Posté par Jerome Herman . Évalué à 2.
Je n'ai jamais dit que c'était tranché, c'est juste que d'entendre se faire traiter de "gogos" les gens qui pensent que 4 processeurs de puissance X c'est mieux qu'un processeur de puissance 4X m'a un peu hérissé.
En applications réseaux, qui représentent quand même aujourd'hui une grosse part des applications existantes, sur les applications multi-threads on a quand même des gains par coeur/processeur qui sont très proche des 100% voir au delà (dès qu'il y a assez de processeurs pour limiter les besoins en context switch, ca a tendance à dépoter pas mal)
[^] # Re: Où est le problème ?
Posté par Guillaume Knispel . Évalué à 2.
Après selon l'application précise la balance peut pencher d'un coté ou de l'autre, selon des critères qu'on peut trouver parfois surprenant (par exemple pour mitiger des problèmes de fiabilités je préfère qu'un programme massivement multithreadé et codé avec les pieds tourne sur un mono-cpu mono-coeur et Linux non preempt).
[^] # Re: Où est le problème ?
Posté par Jerome Herman . Évalué à 2.
Vu la longueur des pipelines des CPU modernes ce sont quand même au minimum trente cycles qui partent à la poubelle à chaque changement de contexte.
Même si ca n'est pas si grave, c'est quand même un beau gaspillage.
Après pour les programmes codés avec les pieds et qui nécessitent une synchro fréquente des threads je suis d'accord avec toi. Pour le reste je suis plus mitigé, surtout quand il y a une VM (.Net, python ou Java) au millieu.
[^] # Re: Où est le problème ?
Posté par briaeros007 . Évalué à 3.
Si toutes les données tiennent dans le cache L1 avec un X/4 , alors qu'elles ne tennaient pas avec un X, tu "risque" de passer en super scalaire (que l'augmentation perfs de ton soft par rapport à si il tournait sur un seul core soit supérieur au nombre de cores).
[^] # Re: Où est le problème ?
Posté par Antoine . Évalué à 9.
Heu... c'est quoi ton OS ?
Parce que n'importe quel OS digne de ce nom va ordonnancer un autre processus si le processus actuel se trouve bloqué à attendre un retour I/O.
[^] # Re: Où est le problème ?
Posté par Jerome Herman . Évalué à 4.
Parce que n'importe quel OS digne de ce nom va ordonnancer un autre processus si le processus actuel se trouve bloqué à attendre un retour I/O.
Pour être exact n'importe quel OS digne de ce nom va relancer un ordononancement des taches avec context switch à la clef, ce qui
1) est horriblement couteux en terme de perfs
2) est mathématiquement impossible à optimiser (ca revient à répondre à la question "quand un programme va-t-il finir")
3) n'est de toutes les façons pas toujours possible (Il est assez mauvais de passer la main à un autre périph quand on en pleine initialisation d'un périphérique, par exemple)
[^] # Re: Où est le problème ?
Posté par qstone . Évalué à 7.
Exemple vécu pour une appli web/flash à la google maps, pour 200 utilisateurs réguliers : 1 serveur frontal+2 serveurs d'applis en load balancing, chaque machine devant être au minimum des bipro avec 8Go de RAM. Soit.
Puis tu découvres que :
- l'appli (censée être du J2EE) fait son load balancing elle-même, et très mal,
- le prestataire a fait l'install sur des serveurs windows 32 bits (mal barré pour mettre 8Go de RAM). Personne dans la boite ne s'est posé la question de la compatibilité 64 bits de leur produit,
- l'appli n'est pas multi-threadée, et le soit-disant serveur J2EE non plus !
Ah merde, pour développer vaut mieux savoir développer... Ca fait un choc !
En programmation j'ai fait mes armes sur un Amstrad CPC, et quand je suis arrivé sur PC je n'arrivais pas à comprendre cette manie du "si c'est lent, on boostera la machine". Maintenant je sais expliquer pourquoi ce raisonnement est débile.
[^] # Re: Où est le problème ?
Posté par totof2000 . Évalué à 10.
Pas si débile que ça si on considère les couts d'optimisation d'une appli ...
Compte combien ça peut couter de réduire la consommation mémoire/CPU d'une appli et combien ça coute d'ajouter une barrette de RAM dans un serveur (je ne parle pas la des applis embarquées que l'on déploie massivement ou le cout n'est pas le même).
Parfois c'est le coup de poker, parce qu'on ne sait pas forcément ce que ça va donner mais dans beaucoup de cas ça coute moins cher d'acheter des CPU ou de la RAM plutot que de payer quelqu'un à optimiser une appli.
[^] # Re: Où est le problème ?
Posté par Antoine . Évalué à 3.
Heu... c'est un peu n'importe quoi là.
Les serveurs multiprocesseurs, ça existe depuis des décennies, donc si ton appli est une appli serveur et que l'éditeur n'est pas totalement minable, elle devrait déjà être capable de tirer parti de plusieurs processeurs ou coeurs.
# perf
Posté par TImaniac (site web personnel) . Évalué à 5.
Pour s'en convaincre on peut regarder le shootout à cette adresse :
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)
Les benchs à base de langages réputés "lents" (parcque à base de VM, les langages interprétés sont encore vraiment à la ramasse) se rapprochent des perfs des langages "rapides" (C/++ & co).
Ce ne sont plus les perfs du langage en soit qui font la différence, mais les algos mis en oeuvre. Les possibilités du langages restent bien entendus une part non négligeable du bench globale, mais il est intéressant de voir qu'il y a encore du chemin à faire au niveau algorithmique pour obtenir des programmes plus performant avec des multi-cores.
Et la bonne nouvelle, c'est qu'on ne va pas être obligé de codé en C/C++ pour systématiquement recherché les perfs (troll : et visiblement, pas en Lisaac non plus :-p http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...) )
[^] # Re: perf
Posté par Ontologia (site web personnel) . Évalué à 3.
C'est exactement ça.
Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads et font souvent de bien meilleur choix que lorsqu'on code à la main.
Quand on code à la main, on va souvent faire n thread pour n espace d'exécution distinct. Un système automatique va faire n thread pour m espace d'exécution, n < m , sachant que bien évidemment, les espaces d'exécution ne n'exécutent pas tous en même temps.
La commutation entre thread prend du temps, donc ces langages, qui sont à VM, vont plus vite sur ce genre de code.
Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.
(PS : Pour Lisaac, COP, en cours d'implémentation (modulo les cours, les TER à gérer), utilise le même genre de mécanisme que SmallTalk/Haskel/Mozart/Erlang, mais en compilé...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: perf
Posté par TImaniac (site web personnel) . Évalué à 5.
On est pas tout à fait en phase. Moi ce que je disais au contraire, c'est que l'impact du langage est beaucoup moins important dans un contexte multi-thread : c'est l'algo mis en oeuvre par le programmeur qui fait le gros de la différence.
Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.
Au contraire, quand tu vois le bench, on s'apercoit que les langages C# ou Java n'ont pas à rougir des perfs des langages bas niveaux, parcque la différence se fait au niveau de la qualité des algos mis en oeuvre par les programmeurs. Mais en soit la base technique des langages C# ou Java est adapté au contexte multi-core.
Le seul véritable critère important dans le langage, c'est le fait qu'il mette à disposition du programmeur l'accès aux fonctionnalités multi-core natives de l'OS/machine sous-jacent. Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.
Sinon effectivement, si les langages veulent se différencier dans la course au multi-thread, c'est en proposant des nouvelles constructions pour automatiser la répartition sur plusieurs threads. Bien souvent ca se fait à l'aide de bibliothèques, et non directement dans le langage. (pour parler de mon église, on peut citer TPL http://en.wikipedia.org/wiki/Task_Parallel_Library )
Dans tous les cas, ces éventuelles "aides" au programmeur ne pourront que s'appuyer sur les compétences du programmeur : si l'algo est pas adapté, il sera pas parallélisable, quelque soit le langage. Bref, le programmeur va de nouveau devoir réfléchir, et ca c'est bien, ca laisse beaucoup de chemin d'évolution possible.
[^] # Re: perf
Posté par 태 (site web personnel) . Évalué à 2.
Dans le shootout, tous les langages utilisent le même algorithme.
[^] # Re: perf
Posté par TImaniac (site web personnel) . Évalué à 2.
Y'a des contraintes que l'algo doit respecter, mais il y a pas mal de liberté dans la mise en oeuvre.
Il suffit de voir que la plupart des programmes ont changés d'implémentation dans leur version "multi-core" pour justement tirer parti des nouvelles machines quad-core utilisées dans le shootout.
[^] # Re: perf
Posté par Larry Cow . Évalué à 3.
C'est vrai que le GIL - qui dans un contexte mono-coeur était une foutue bonne idée - prend des airs de boulet rouillé dans ces conditions. Ceci dit, le module multiprocessing de Python2.6 (installable dans Python2.5 pour ceux qui veulent) limite sensiblement la casse.
[^] # Re: perf
Posté par TImaniac (site web personnel) . Évalué à 2.
Gérer la communication inter-process, c'est non seulement beaucoup moins efficace, mais également beaucoup plus lourd pour le programmeur (faut penser sérialization des données et comm inter-process)
[^] # Re: perf
Posté par Larry Cow . Évalué à 2.
[^] # Re: perf
Posté par Ontologia (site web personnel) . Évalué à 1.
Reprenons, je te parle des benchs sur thread-ring, pas les benchs généraux.
Analysons http://shootout.alioth.debian.org/u32q/benchmark.php?test=th(...)
1.0 Haskell GHC #2 8.88
1.1 Haskell GHC 10.84
1.8 Mozart/Oz 15.91
3.3 Erlang HiPE 29.14
4.0 Smalltalk VisualWorks #2 35.87
7.8 Scheme PLT 69.19
14 Scala 122
16 Pascal Free Pascal 124.66
17 Lisaac 130.07
18 C++ GNU g++ #2 148.56
Nous sommes donc sur un quadricore en 32 bits.
Le meilleur, Haskell, torche en 9s
Mozart, SmallTalk, Erlang suivent de pas trop loin.
J'avoue que je sais pas comment fonction le compilo de sheme.
Ce qui est intéressant, c'est de voir à combien sont les langages qui utilisent du threading "classique" : Scala, Pascal, Lisaac et C++
On voit qu'ils sont largement distancés : les temps de commutation entre thread prennent un temps fou.
122s, c'est plus de 13 fois le score d'Haskell
Ca fait beaucoup.
Ce serait très intéressant de savoir combien de thread réel on a dans chaque cas
Bref, c'est parce ces langages gèrent automatiquement les threads, en n'affectant pas un thread par tâche, mais un thread pour plusieurs tâches (les espaces d'exécutions) qu'ils obtiennent de meilleur perfs.
Effectivement, ce n'est pas tellement le langage en tant que grammaire/whatever qui compte ici, mais l'implémentation : l'interpréteur, la VM, le compilateur.
D'avoir la petite primitive dans la grammaire du langage peut aider.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: perf
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: perf
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: perf
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
C'est un peu le problème de ce genre de bench, le code n'est pas et ne peut pas toujours être homogène.
[^] # Re: perf
Posté par ckyl . Évalué à 7.
Genre http://www.malhar.net/sriram/kilim/ ca tient Erlang en microbench et ca le fracasse en perf sur le code metier. L'optimisation de la VM d'Erlang étant à des années lumières de celle de Java. Le fork/join de la JSR 166y n'obtient pas ses perfs avec une implémentation naïve d'un stagiaire.
On confond un peu tout et n'importe quoi ici. Un modèle de parallélisme donné peut très souvent être implémenté sur n'importe quelle techno. Donc se servir dudit modèle pour venter les performances d'un langage ou d'une VM est absurde.
De même beaucoup ici confondent scalabilité et performance. À scalabilité identique un code plus performant terminera sa tâche plus rapidement quelque soit le nombre de ressources à sa disposition.
Pour le moment tout le monde cherche le bon modèle. Les threads demandent des legendary engineers pour simplement faire du code qui marche [1]. Alors tout le monde propose des nouveaux trucs et un jour peut être on trouvera le truc qui scale, qui a de bonnes perfs, qui est facile à développer et qui est facile à débugger. En cadeau bonus si ca marche en local et en distribué c'est merveilleux. Pour le moment on est dans la phase ou on lance n'importe quoi en l'air et on verra bien ce qui retombe.
Parallèlement il faut réussir à découper son code métier en morceaux parallèles. C'est difficile, et on oublie pas la loi d'Amdah au passage...
[1] On peut, entre autre, lancer un grand jeu sur les memory models de Java, C++, .Net ou sur ceux des processeurs si certains veulent dire le contraire.
[^] # Re: perf
Posté par M . Évalué à 8.
Analysons http://shootout.alioth.debian.org/u32q/benchmark.php?test=th(...)
1.0 Haskell GHC #2 8.88
1.1 Haskell GHC 10.84
1.8 Mozart/Oz 15.91
3.3 Erlang HiPE 29.14
4.0 Smalltalk VisualWorks #2 35.87
7.8 Scheme PLT 69.19
14 Scala 122
16 Pascal Free Pascal 124.66
17 Lisaac 130.07
18 C++ GNU g++ #2 148.56
[...]
Le meilleur, Haskell, torche en 9s
Mais il n'utilise qu'un seul core [1], tout comme Mozart, Smalltalk et Scheme.
Mon petit doit me dit que ce test crée plein de thread qui ne font quasiment rien. Du coup ce test test la rapidité de création de thread, et les implémentations purement userspace gagne haut la main car il n'y a pas tout l'overhead kernel...
Encore une fois les micro bench sont a prendre avec des pincettes...
[1]
x Program & Logs CPU secs Memory KB Size B Elapsed secs ~ CPU Load
1.0 Haskell GHC #2 8.88 2,872 260 8.89 0% 0% 5% 92%
1.1 Haskell GHC 10.84 4,944 304 9.93 52% 49% 0% 0%
1.8 Mozart/Oz 15.91 4,356 340 15.91 0% 0% 0% 100%
3.3 Erlang HiPE 29.14 6,456 273 29.14 61% 0% 37% 11%
4.0 Smalltalk VisualWorks #2 35.87 13,088 566 35.86 0% 0% 100% 0%
7.8 Scheme PLT 69.19 24,412 262 69.19 0% 0% 0% 100%
[^] # Re: perf
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
> Scheme.
A priori, la machine Erlang est capable du multi-coeur depuis quelques années déjà (ele était mono coeur avant).
> Mon petit doit me dit que ce test crée plein de thread qui ne font
> quasiment rien. Du coup ce test test la rapidité de création de thread, et
> les implémentations purement userspace gagne haut la main car il n'y a
> pas tout l'overhead kernel...
On sais bien en utilisant la bibliothèque OpenMP qu'on a intérêt à lancer la boucle parallèle la plus large possible sur le code source, c'est à dire le plus tôt possible et de la fermer le plus tard possible. En effet, le lancement des threads est terrible en terme de performance.
On utilise donc des prama OpenMP de type singleton pour dire que certains passages ne sont pas à faire en parallèle. Cela permet de garder les threads ouvert mais qui ne font rien (sauf un) pour la suite du programme.
Un petit tour du coté d'OpenMP est aussi très intéressant pour comprendre une partie de la problématique.
Il est clair que si la conception du langage fait que le compilateur est capable de faire cela a notre place, c'est génial.
[^] # Re: perf
Posté par Paf . Évalué à 2.
+S Number:
Sets the number of scheduler threads to use when SMP support has been enabled. Valid range is 1-1024. If the Erlang runtime sys-
tem is able to determine the number of processor cores available, the default value will equal the this value; otherwise, the
default value will be one.
This flag will be ignored if the emulator doesn’t have SMP support enabled (see the -smp flag).
Et pour avoir un apercu de l'etat de l'implementation smp par la vm, voir le fil de discussion : http://www.erlang.org/pipermail/erlang-questions/2008-Septem(...)
[^] # Re: perf
Posté par Antoine . Évalué à 4.
Oui, parce que le benchmark est idéal pour favoriser ce genre d'implémentation (créer des tas de petits threads dont chacun ne fait pas grand'chose). C'est loin d'être le cas de toutes les utilisations du multi-threading.
[^] # Re: perf
Posté par Antoine . Évalué à 4.
C'est une affirmation totalement infondée et probablement foireuse. Aucun des langages présentés n'est capable de paralléliser automatiquement un algo.
On voit aussi qu'Erlang n'a pas des performances extraordinaires comparé à, par exemple, OCaml. Pourtant l'implémentation testée (HiPE) est censée produire du code natif, non du bytecode.
[^] # Re: perf
Posté par M . Évalué à 1.
Et pourtant les codec vidéo qui consomme beaucoup (genre h264 sur un flux HD) sont toujours développé en c/c++ avec une parallélisation à la main...
# Erlang
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Les notions de base sont simples, tout est basé sur une notion d'objet immutable et sur de la récursivité. Tout passe par message ou presque. La gestion des erreurs est plutôt par processus indépendant (un calculateur / un superviseur).
En plus Erlang évite la syntaxe du LISP ou de CAMEL. Cela reste a mon sens bien plus clair pour quelqu'un qui vient du monde C / Fortran.
Bref, c'est étonnant qu'un langage ou on écrit
a = 2
a = 3 -> erreur
puisse être aussi performant.
Je vous conseille d'aller voir ce langage, rien que pour la culture générale, c'est passionant.
[^] # Re: Erlang
Posté par hocwp (site web personnel) . Évalué à 3.
Pourquoi tu veux éviter la syntaxe du LISP ? C'est un de ses points forts il me semble.
[^] # Re: Erlang
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Le LISP est plus vieux que le Fortran mais sa syntaxe n'a pas réussi à percer pendant tout ce temps malgré son élégance.
Donc, c'est bien d'avoir un langage fonctionnel comme Erlang avec une autre syntaxe, cela explore d'autre voie de la sociologie humaine.
[^] # Re: Erlang
Posté par Anonyme . Évalué à 1.
[^] # Re: Erlang
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Erlang
Posté par BAud (site web personnel) . Évalué à 5.
[^] # Re: Erlang
Posté par Thomas Douillard . Évalué à 3.
(répondre baud123 (falloir indéterminé (aimer parenthèses ) ) oui )[^] # Re: Erlang
Posté par hocwp (site web personnel) . Évalué à 2.
(répondre baud123 (falloir indéterminé (aimer parenthèses)) oui)L'équivalent en C serait :
répondre(baud123, falloir(indéterminé, aimer (parenthèses)), oui);Même nombre de parenthèses, des virgules et points virgules en plus.
L'équivalent en C, si on l'avait indenté comme ce que tu as fais pour le Lisp, donnerait un truc du genre :
int *
aimer_v =
aimer (&parenthèses);
double float falloir_v
= falloir(indéterminé,
aimer_v);
return
répondre(baud123,
falloir_v, &oui)
;
Et au passage, le code avec les accents ne compile pas en C mais est tout à fait valide en Lisp vu que le compilo supporte l'UTF-8 : http://www.gnu.org/software/clisp/propaganda.html
[^] # Re: Erlang
Posté par 2PetitsVerres . Évalué à 2.
return oui
appelé au bon moment.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Erlang
Posté par hocwp (site web personnel) . Évalué à 1.
# jusqu'où va aller la multiplication des coeurs
Posté par Badeu . Évalué à 3.
Chaque petit groupe de coeurs est réparti dans un petit cluster disposant en interne d'un mécanisme d'interconnection simple, de ram, etc... mais surtout, pour avoir une scalabilité maximum d'un composant d'interfaçage avec un NoC (Network On Chip)[2] permettant les communications entre les clusters.
Les avantage d'une telle architecture sont nombreux, ça va de la gestion fine de l'énergie à la tolérance aux fautes en passant par la possibilité de placer chaque objet logiciel avec précision sur les ressources offertes par une telle architecture.
Bien entendu, une telle architecture demande un peu plus de considérations lors du déploiement d'applications, mais comme le dit un proverbe ... qui peut le plus, peut le moins.
De plus, le projet à aussi une partie concernant le portage de Linux sur la plateforme et enfin, les modèles virtuels du tout sont libre[3]
[1] petite présentation : http://www-asim.lip6.fr/team/seminaires/past_seminar/tsar_ip(...)
[2] network on chip : http://www-asim.lip6.fr/recherche/spin/
[3] soclib : https://www.soclib.fr
# Tu devrais savoir ça
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 9.
Le problème et la solution ne sont pas dans les langages (Erlang, mais avant encore, Multilisp), mais bien dans l'industrie qui n'a rien du tout à foutre des progrès de la recherche. Et c'est pas seulement la faute du département marketing qui serait bien incapable de lire ne serait-ce qu'un abstract d'une publication potable, mais aussi de l'inertie délétère de ces sociétés (entreprises) qui refusent de faire des choix éthiques et moraux, au regard de l'avenir de la société (humaine, cette fois).
Et c'est aussi, selon moi, la faute de la banalisation de l'informatique. On laisse n'importe qui en faire et obtenir un diplôme, et 5 ans plus tard, le gars est chef de projet. C'est foupoudav là… Des formation courtes de techniciens (qui sont techniques) au longues d'ingénieurs (qui peuvent ensuite apprendre une fois employés), aucune ne donne de vision des problèmes de l'informatique. Et pire, ni les uns ni les autres ne vont en fait approfondir et aller fouiller dans les publications scientifiques, parfois vieilles de 10 ou 20 ans, pour trouver la solution qui existe. A la place, les uns vont demander aux autres de coder de la merde car de toute façon, faudra tout récrire dans 5 ans, alors la bonne solution, hein…
Bref. Je milite pour la reconnaissance de l'informatique comme d'une science à l'instar des maths, et pour qu'on scinde clairement les domaines et compétences de ce fourre-tout afin qu'on ait enfin des bons choix faits par les bonnes personnes (et que ma grand-mère arrête de me téléphoner quand son ordi tombe en panne)
--
pas de troll dans le message ci-dessus. Juste de l'exaspération, et un peu d'extrème (car tout le monde sait que PHP n'a pas été créé. C'est une abomination apparue spontanément. Quel humain voudrait un tel langage ?)
[^] # Re: Tu devrais savoir ça
Posté par Antoine . Évalué à 4.
Et c'est quoi, alors, la fameuse solution qui existe ?
(mis à part l'élitisme et la rancoeur, bien sûr :-))
[^] # Re: Tu devrais savoir ça
Posté par Fabimaru (site web personnel) . Évalué à 5.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tu devrais savoir ça
Posté par MrLapinot (site web personnel) . Évalué à 3.
Le succès d'une théorie se mesure à ses applications, c'est-à-dire au fait qu'elle puisse fournir des résultats (théoriques ou pratiques) dans un domaine autre que celui qu'elle définit par elle-même. La théorie de la relativité est un succès, car elle permet de prédir le phénomène astronomique des étoiles cachées qui apparaissent pendant une éclipse : résultat externe, qui n'a pas besoin de la théorie d'Einstein pour être compris, utilisé, observé (même si on ne sait pas l'expliquer autrement). Le pi-calcul, de ce point de vue, c'est un échec.
<troll />
[^] # Re: Tu devrais savoir ça
Posté par MrLapinot (site web personnel) . Évalué à 2.
[^] # Re: Tu devrais savoir ça
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ensuite de quoi, il y a deux niveaux de théorie: celle qui s'applique à la pratique et qui te semble justifiée, et celle dont les résultats s'appliquent à leur tour à la théorie, que tu appelles (à tort) un échec.
Je dis à tort, car l'étude du pi-calcul (et des nombreux autres modèles de la concurrence) ont apporté de nombreux résultats intéressants et utilisables dans la vie de tous les jours. Mais, encore une fois, force est de constater qu'ils ne sont pas à la portée de tout le monde. C'est un fait, et c'est comme ça.
Trod de gens considèrent les résultats en informatique (et en maths) comme "dûs". 1+1=2 "bah oui". Et bien non, pas "bah oui". (et pour la petite note, des algèbres simples comme ça (groupes, idéaux, etc), ca s'utilise en info aussi, sauf qu'on a des programmes entiers à la place des nombres…)
[^] # Re: Tu devrais savoir ça
Posté par MrLapinot (site web personnel) . Évalué à 1.
Non. Je ne considère pas comme un échec la théorie qui s'applique à la théorie. Je considère comme un échec la théorie qui s'applique à elle-même. En effet (et je l'ai dit juste au-dessus, en précisant pourquoi je trollais), le pi-calcul n'est pas un échec, car il s'applique dans d'autres domaines (théoriques) : bio-informatique, cryptographie. Mais en terme de modèle pour les langages de programmations, je ne vois vraiment pas quel crédit donner aux résultats obtenus par le pi-calcul : c'est une bulle inflationniste, qui crée ses concepts pour développer des théorèmes qui vont servir à de nouveaux concepts, sans qu'à aucun moment on ne retouche terre. Le lambda-calcul n'est pas comme ça (il a des interprétations en terme de calculabilité, par exemple, et il a produit des résultats nouveaux et intéressants dans ce domaine).
Mais si tu as un résultat issu du pi-calcul qui parle d'autre chose que du pi-calcul lui-même [1], je serais très intéressé et reverrais sûrement ma position.
[1] (et des protocoles crypto, on est d'accord dessus que c'est un succès du pi-calcul)
[^] # Re: Tu devrais savoir ça
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Bon, la théorie qui s'applique à elle même, c'est une démarche co-inductive, mais pas forcément inutile.
Si on omet le spi-calcul dont tu parles (pour les protocoles cryptographiques), sache que les techniques de preuves d'equivalence dans le pi-calcul (et CCS avant), les bisimulations (quis sont construites par co-induction justement), sont utilisées aussi pour prouver l'intégrité de programmes au sens cryptographique, mais aussi l'equivalence de deux programmes (l'un optimisé l'autre non), ou encore te garantir qu'un programme marchera sur ton linux comme sur mon BSD (par des preuves de congruence). Et ces techniques de preuves découvertes grace aux "calculs de processus" s'appliquent aussi au lambda-calcul et à des languages de plus haut-niveau (genre haskell).
Je crois vraiment qu'on retouche terre. Pas tout le temps, certes. Puis tous les chercheurs ne sont pas d'excellents génies, donc t'as des publis moins bien que d'autres (et des gars qui *veulent* prouver leur conjecture dont on sait qu'elle ne mène à rien).
Pour moi, le PI calcul (avec ses variantes) est un modèle, et il y a encore pas mal à y étudier. Il y a beaucoup de demande ces temps-ci, car justement, ca modélise vachement bien des trucs en biologie et pas mal de bio-informaticiens ou simple biologistes s'y mettent. J'ai pas plus de détails car c'est pas mon trip…
Enfin, une invitation récente que j'ai reçue par une ML à laquelle je suis abonné:
** CMSB 2009
** The 7th Conference on Computational Methods in Systems Biology
** http://cmsb09.cs.unibo.it/
The CMSB (Computational Methods in Systems Biology) conference series was established in 2003 to help catalyze the convergence of modellers, physicists, mathematicians, and theoretical computer scientists (from fields such as language design, concurrency theory, program verification) with molecular biologists, physicians and neuroscientists interested in a systems-level understanding of cellular physiology and pathology.
J'étais loin de penser à ça quand j'étudiais le PI-calcul en classe…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tu devrais savoir ça
Posté par MrLapinot (site web personnel) . Évalué à 2.
Erlang peut être formalisé en termes de pi-calcul [1] mais il n'a pas été inventé à partir du pi-calcul. Les liens entre les deux ont été discutés sur la liste de diffusion [2] où il est apparu qu'il est particulièrement bon pour... implémenter des interpréteurs du pi-calcul [3] !
Quoiqu'il en soit, Erlang doit beaucoup plus à la théorie des files d'attente qu'au pi-calcul. A commencer par son nom [4]. Il est difficile de dire exactement quelles sont les influences ayant présidé à son élaboration, naturellement, mais le contexte dans lequel il a été créé (firme Ericson) autant que l'origine de ses concepteurs et leurs motivations (obtenir un langage qui capture bien les notions usuelles en télécommunications et qui soit distribué pour résister aux pannes) génèrent, à mon sens, une suspicion importante de lecture rétrospective quand on affirme qu' « Erlang est basé sur le pi-calcul, et très fortement ».
Par contre, pour les applications réelles du pi-calcul, je trouve la page wikipedia [5] est assez complète. Mais il ne faut pas se voiler la face : d'occam-π à jocaml, les langages de programmation qui ont essayé d'utiliser le pi-calcul (ou une de ses variantes) sont des échecs. C'est dommage, mais c'est comme ça : ça ne marche pas (ou alors on n'a pas trouvé la bonne syntaxe/approche pour que ça soit utilisable sur des projets sérieux).
Je crois beaucoup plus à la programmation réactive fonctionnelle. L'avenir nous dira bien ce qu'il en est.
[1] http://portal.acm.org/citation.cfm?id=1088375
[2] http://www.erlang.org/ml-archive/erlang-questions/200310/msg(...)
[3] http://erlang.org/pipermail/erlang-questions/2003-November/0(...)
[4] http://en.wikipedia.org/wiki/Agner_Krarup_Erlang
[5] http://en.wikipedia.org/wiki/Pi-calculus#Applications
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tu devrais savoir ça
Posté par MrLapinot (site web personnel) . Évalué à 2.
[^] # Re: Tu devrais savoir ça
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Erlang et le "message passing", c'est plus des Acteurs que du Pi-calcul, mais bon.
[^] # Re: Tu devrais savoir ça
Posté par Ontologia (site web personnel) . Évalué à 5.
Et effectivement, on en revient à la vieille opposition entre chercheurs et ingénieurs en France.
Les ingénieurs pensent que la théorie ça sert à rien, et que les gens formés à la fac sont une bande de théorien (= doux rêveur) incapable d'implémenter une lib ftp en java, et les théorciens pensent que les ingénieurs sont des bidouilleurs de code à pein capable d'implémenter un intranet en java.
Le problème, c'est que c'est pas tout à fait faux...
Autour de moi, j'ai des techniciens hyper forts... mais incapable de faire la différence entre un compilateur et interpréteur.
J'ai réalisé un outil d'automatisation de code ces derniers temps sur lequel j'ai été pas mal force de proposition, et j'ai été assez effaré de constater que pas mal de gens avaient du mal à concevoir que parser un source, analyser son arbre abstrait et générer quelque chose avec, c'était possible...
Des gens très bien, très compétent, parfaitement taillés pour les besoins d'une SSII, mais non, euhhh, c'est quoi un compilateur ?
Effectivement, ça serait pas mal que les écoles d'ingés reviennent un peu plus dans le giron de l'université, et que les universités travaillent un peu plus à ajouter ce qui manque dans la formation pour adapter les étudiants à la gestion de projet, calculs de couts, etc...
De savoir lire les abstract de paper, je ne suis pas sûr que ça soit directement utile, et c'est peut être trop leur demander, mais déjà, s'ils pouvaient avoir les connaissances théoriques de base qu'un Master 1 possède, je pense que ça serait déjà énorme, on perdrait beaucoup moins de temps.
Mais il y a un tel mépris de la théorie, par des gens qui pensent que java est formidable, les framework le sont encore plus, et qui s'extasient des heures durant à faire des usines d'usines d'usines d'objets... que c'est mal baré.
Tant pis, c'est la productivité qui en pâtit...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tu devrais savoir ça
Posté par fredix . Évalué à 2.
En SSII tu trouves un peu tu trouves un peu les déchets de l'informatique. Des gens qui n'ont pour la plupart pas de cursus d'informaticien, qui sont là pour bouffer sans aucune passion du métier, et qui enchainent les missions pourries chez des grands comptes qui ne s'y connaissent pas mieux...
Tant pis, c'est la productivité qui en pâtit...
Non c'est le client qui paye :)
[^] # Re: Tu devrais savoir ça
Posté par fcartegnie . Évalué à 6.
En SSII tu trouves un peu tu trouves un peu les déchets de l'informatique. Des gens qui n'ont pour la plupart pas de cursus d'informaticien, qui sont là pour bouffer sans aucune passion du métier, et qui enchainent les missions pourries chez des grands comptes qui ne s'y connaissent pas mieux...
Notre premier de promo universitaire est partit en SSI au lieu de faire une thèse...
Néanmoins, je connais beaucoup de gens qui n'avaient aucune formation informatique spécifique et qui ont atterri chez A...S.
De même, quand je vois que certains recruteurs n'hésitent pas à m'envoyer des offres, ou même me contacter par téléphone, parce qu'ils ont vu mon profil qqpart sur internet et qu'ils ne comprennent pas la moitié des techs citées ou vont jusque proposer des postes admin windows à des ingé unix ! (c'est "admin" qui les intéresse, pas l'expertise dans la tech!)
Du grand n'importe quoi, oui, je confirme.
[^] # Re: Tu devrais savoir ça
Posté par Larry Cow . Évalué à 2.
Tu connais beaucoup de théoricien qui font des intranets en Java? Alors que des ingénieurs qui savent faire une lib FTP en Java, ça doit encore pouvoir se trouver assez facilement.
Bon après, si tu tiens absolument à mettre du Java dans la négociation...
[^] # Re: Tu devrais savoir ça
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
[^] # Re: Tu devrais savoir ça
Posté par Larry Cow . Évalué à 2.
[^] # Re: Tu devrais savoir ça
Posté par Larry Cow . Évalué à 8.
Avec un peu de "chance", il a même été créé par Java (lequel a eu une relation incestueuse avec Windev quand il était jeune). Car aucun de ceux-là n'a pu être créé par un humain non plus.
[^] # Re: Tu devrais savoir ça
Posté par Gniarf . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.