Oui, et tant que tu n'as pas de problèmes de santé ni de gosses, tout se passe bien. Pour tout le reste, il y a master card: crèche (pas toutes les boites proposent quelque chose, loin de là), maternelle (souvent — toujours ? — privées), fac, santé en règle générale, etc.
Exemple à la con : une amie ingénieur en génie des procédés (elle a un bachelor of science, pas un master) bosse dans le New Hampshire. Tous les ans il faut renouveler l'enregistrement de sa voiture : 600$. On pourrait dire, « boah, c'est pas grand chose », et c'est vrai. Mais il y a aussi les impôts locaux, le loyer (elle paie ~900$/mois pour un ~50-55m²). Dans son domaine, un Master n'apporte pas grand chose, et il faut tenter le Ph.D pour voir un vrai changement dans le salaire (incidemment, c'est aussi vrai pour l'informatique dans plein de boites aux US, de nos jours — enfin de ce que je vois). Du coup quand je vois les gens parler de « tu touches Xk$ / an », souvent je pense qu'on oublie le nombre d'années passées en école doctorale, payé ~24k$/an (ici, la plupart des thésards restent au moins 5 ans).
Il a toujours le droit de souscrire à l'assurance en question, mais sa boite ne paie plus sa part. Heureusement pour lui, il bénéficie de celle de sa femme (médecin). Quelqu'un d'autre aurait pu se retrouver dans la merde juste à cause du prix à payer par mois pour avoir les mêmes bénéfices que procure cette assurance. Comme il était déjà client, mon pote n'a pas de problème, tant que quelqu'un paie (s'il avait tenté de contracter une assurance avec comme condition pré-existante « leucémie », il n'est pas dit qu'il eut réussi…).
Oui, j'allais dire que quand t'es en Californie et que tu gagnes (disons) 200k$/an, mais que tu paies ~2000k$/mois (le cas d'un pote qui vient d'être embauché chez Apple, à Cupertino — sauf que lui gagne ~150k$ en tant que « junior »), après les taxes et tout, il reste quand même beaucoup moins… Petit calcul : 2000 × 12 = 24k$. Il reste donc ~116k$/an à mon pote; sauf qu'en fait, il faut mettre une partie de son salaire de côté pour le 401k dont parlait PbPG plus tôt (hé oui dans son cas, y'a un plan 401K, mais il faut le soustraire de sa paie…); les impôts locaux sont très élevés; etc. Bref, la paie est bien plus élevée aux US, mais pour avoir le même niveau de « services » que ce qui est proposé en France (retraite, santé, éducation) il faut souvent payer presqu'autant que ce qui est prélevé sur le salaire côté patron. Malgré tout, un ingénieur compétent gagne plus au final que « le même » en France. Juste pas tant que ça.
Même avec une bonne mutuelle, ça ne suffit pas forcément. J'ai un pote parti à Seattle, qui a eu la malchance d'avoir une leucémie, mais qui, dans sa malchance a quand même eu le bol d'avoir une femme qui bosse dans le meilleur hôpital pour traiter son type de leucémie particulier. Il bossait aussi pour une boite qui couvrait déjà énormément les frais médicaux… Mais pas complètement (il y a des plafonds au-delà desquels les individus doivent y mettre de leur poche). Bref. Il est en ce moment en rémission, mais a du coup perdu son job (car malade plus de X mois¹).
De façon générale, à cause de la façon dont le système US de santé fonctionne, ce qui en France (et en général dans le reste de l'Europe) coûte très peu et est le plus souvent couvert par la sécu ou une mutuelle, peut se révéler extrêmement coûteux aux USA. Une amie devait passer une radio. On lui a réclamé 1000$. Soit le prix d'un A/R en France depuis les USA. Truc qu'elle aurait pu faire: puisqu'elle était encore couverte par la sécu, au final cela aurait eu le double effet kisscool de lui permettre de revoir sa famille pendant un jour ou deux²… Les plafonds des assurances maladies sont vite atteints. En règle générale, oui, le système US favorise les plus riches : plus on est élevé dans la hiérarchie d'une boite, meilleure est la couverture pour tout. Mais il y a aussi des plafonds pour tout, et étant donné les prix bien plus élevés qu'en France pour tout ce qui est médical, on y arrive assez vite dès qu'on dépasse le simple rhume (j'exagère, je sais).
Pour ce qui est des enfants, il faut tout de même compter entre 50k$ et 150k$ minimum (en fonction de la fac, et suivant si l'on paie le tarif « in-state » ou « out-of-state ») par enfant pour tout ce qui est éducation supérieure, rien qu'en frais d'inscription pour obtenir une licence (qui dure 4 ans aux US — ensuite le plus souvent au niveau master/thèse, le directeur/mentor se charge de payer les frais pour l'étudiant). En règle générale, l'étudiant travaille pendant ses études pour se payer la chambre étudiante ou l'appart, la bouffe, l'assurance maladie qui n'est pas trop chère — dans la fac où je bosse, je crois qu'ils paient ~250$ / an pour l'équivalent d'une assurance qui couvre façon LMDE. Tous les étudiants américains que je côtoie ici, y compris ceux qui sont en « grad school » (c'est-à-dire en master/thèse, avec une orientation de recherche, et qui bossent dans mon labo) ont toujours une partie de leur crédit à rembourser. Les frais d'inscriptions des facs augmentent largement plus que l'inflation chaque année. Par exemple, l'université où je bosse est passée l'an dernier de ~7000$/an pour un in-state à ~11000$ de frais d'inscription. Similairement, les out-of-state devaient auparavant payer ~20000$/an, et désormais ~30000$/an. Cette bulle explosera sans doute à terme, mais je pense qu'elle va encore enfler quelques années.
Concernant la bouffe, oui, elle est moins chère — à condition de ne pas trop chercher à faire gaffe à comment elle a été produite. Si on veut de la bouffe avec à peu près les mêmes garanties qu'en France, on se retrouve avec un prix relativement comparable (ça reste tout de même moins cher aux USA). En règle générale, les besoins de base (bouffe, loyer, vêtement) sont moins chers qu'en France, tant qu'on est pas regardant sur la provenance/la qualité (les murs sont en papier dans la plupart des complexes d'appartements).
Par contre, je trouve qu'on oublie un peu facilement d'autres trucs vachement plus chers aux USA. Les câblo-opérateurs règnent en maîtres, et le font payer très cher : pour avoir un débit plus ou moins équivalent à ce qu'on a avec l'ADSL en France, je paie ~75$ tous les mois. Le téléphone, c'est encore pire : je paie ~95$ / mois. Ça comprend voix et SMS illimités, data 4G (Web) jusqu'à 2Gio de téléchargement (montant et descendant cumulés), puis bande-passante limitée au-delà. Je paie aussi ~10$/mois supplémentaire pour avoir le droit de téléphoner sur des lignes fixes sans autre surcoût à l'étranger. Le tethering est possible si on paie ~15$/mois supplémentaire, et faire office de routeur wifi est aussi possible si on paie le prix (~10$/mois je crois). Bien entendu, si je réinstalle une version « vanilla » d'Android sur le smartphone, les logiciels de mon opérateur ne bloqueront plus les deux dernières options… Ce que je vais faire d'ici 2 mois, quand la garantie aura expiré. En France on ne paie que si on appelle (en national), alors qu'aux US on paie quand on émet et quand on reçoit — et c'est aussi valable pour les SMS³.
Bref, ce qui en France coûte en cumulé (en prenant Free comme exemple, mais on pourrait prendre d'autres opérateurs) ~50€ (abo internet + mobile) coûte ~150$ ici aux USA. Même en faisant la conversion Euro-Dollar, on y perd clairement. Il y a d'autres exemples du même genre que je n'ai pas en tête en ce moment; je les retrouverai sans doute plus tard…
[1] En pratique, ils auraient préféré le garder car il était bientôt remis, et chercher un remplaçant prend du temps et en règle générale coûte des sous. Mais la politique de la (grosse) boite en question fait qu'au bout de X mois en congé maladie, un employé est automatiquement viré.
[2] Elle a réussi à se débrouiller autrement, et à faire baisser le prix, par je ne sais plus quelle magouille.
[3] Autant pour la voix sur mobile je peux comprendre le principe — on paie pour le droit d'être joint n'importe où — autant pour les SMS ça m'énerve un chouïa: même si le SMS n'est pas sollicité, on paie quand même : avec un coup de téléphone, j'ai le choix de ne pas décrocher…
Je suppose que ton « tu » ne m'est pas adressé. Après tout, je suis aux USA depuis un petit bout de temps… :-P
Sinon je suis content de savoir que ce genre d'opportunités (et de tests) existent, mais j'avoue que lorsque j'étais sorti d'école d'ingénieur, ce qu'on me montrait comme opportunités pour faire du dév, c'était quand même plutôt les boulots payés 30k€—35k€ pour des débutants, et ~40k€—45k€ pour ~5 ans d'expérience. Bref, sans forcément parler de super hauts salaires, je connaissais peu de dévs qui pouvaient se vanter de toucher 60k€, même avec de l'expérience (j'en connais quelques uns quand même).
Pour ce qui est des entretiens d'embauche, j'ai déjà vécu le couple <entretien téléphonique technique, visite d'une journée sur place>. Durant la journée d'entretiens, j'ai eu droit à une discussion avec le VP of engineering, 4 sessions techniques, un déjeuner avec d'autres ingés… Et en effet, je n'ai pas eu à payer un centime (avion, hôtel, voiture de location, tout était aux frais de la boite). Mais j'ai l'impression que dans pas mal de boites franchouillardes, et surtout en IdF (avec les transports en commun, tout ça), souvent c'est pas trop trop le cas.
Je bosse de temps en temps avec [Jack Dennis]. Il a 81 ans, et continue de coder. Là, il est en train de terminer un simulateur pour une architecture multi/many core, avec un langage de programmation qui cible son jeu d'instruction, etc.
Il existe un bouquin, Coders at Work qui recueille un ensemble d'entretiens avec des « nouveaux » (Jamie Zawinski, dév. Netscape à la grande époque), des moins nouveaux (Joe Armstrong, inventeur de Erlang; Guy Steele, co-créateur de Scheme, « formalisateur » du langage Java, créateur de Fortress, et plein d'autres trucs) et des vénérables (Donald Knuth, mathématicien/informaticien, inventeur de TeX — entre autres). Beaucoup des gens interrogés ont largement passé 50 ans. Et pourtant une grande partie d'entre eux continuent de développer. Certes, je parle de gens qui sont relativement exceptionnels. Pourtant, mon expérience (statistiquement non significative, je le sais bien) me fait penser que les « vrais programmeurs¹ » n'arrêtent jamais vraiment de programmer, et ne perdent pas forcément de leur acuité…
Tout ce que je voulais dire, c'est que C99/C11/C3001 ne seront sans doute jamais mis en place dans Visual C++ parce que ce n'est pas ce que veut faire Microsoft…
Il ne supporteront jamais C99, ils ne sont pas intéressés. Si C++ et C ont des standards qui se recouvrent, tant mieux pour les développeurs C. Sinon, tant pis.
Hé, psssst! pBpG ! Je te pertinente beaucoup sur ces fils de discussion, mais au risque de répéter ce que t'ont déjà dit d'autres gens plein de fois, steup, utilise la syntaxe de citation :
Perso, je n'alloue rien pour un PDF. Je fais un mmap et je laisse l'OS faire son boulot.
Je pige pas bien. mmap est utilisé en sous-main (avec brk) pour allouer la mémoire sous Linux. Ensuite, mmap peut échouer, et du coup tu dois tester la sortie en erreur.
Note : je sais bien que tu veux dire que tu utilises mmap pour mapper le fichier PDF en mémoire. Sauf que, il serait aussi tout à fait envisageable que le PDF soit généré à la volée, et fasse effectivement ~20Mio…
Dans tous les cas, ton mmap peut potentiellement échouer, et dans ce cas, il faut bien signaler au client qu'une erreur s'est produite. En quoi cela change-t-il d'une allocation mémoire qui échoue ?
Si on a vraiment besoin de faire de grosses allocations, il faudrait AMHA utiliser des huge pages et ça ne se gère pas de la même manière.
Deux remarques générales :
Utiliser les huge pages ne change pas le fait que malloc rendra toujours une adresse valide sous Linux (allocation optimiste), et donc que la valeur de retour sera presque tout le temps inutile (mais pas à ignorer si tu veux que ton code soit portable — il existe d'autres systèmes qui allouent la mémoire avec une stratégie différente).
Les huge pages sont utiles pour éviter la fragmentation mémoire et réduire les TLB miss. C'est tout (et en fait c'est déjà énorme pour un code qui cherche la haute performance et qui est memory bound). Ça ne joue pas sur l'allocation en elle-même.
En ce qui concerne Linux en particulier, la façon dont les huge pages sont implémentées tiens du gros hack (on doit spécifier le nombre de grandes pages qu'on veut allouer au boot, pour s'assurer de la contiguïté de la mémoire physique), et c'est géré plus ou moins via les mêmes mécanismes que pour les segments de mémoire partagée (en tout cas c'était le cas il n'y a pas si longtemps).
Pendant sa thèse, Alan Cox avait publié un article très bien sur les « superpages » et comment les allouer. Il avait fait ses tests sur Alpha avec FreeBSD. L'idée est de découper la mémoire virtuelle en utilisant la taille maximale des pages du système (sur x64 : 4Mio). Si la charge de la machine et le « profil » des programmes qui tourne dessus requièrent des allocations plus petites, une superpage est ensuite redécoupée en utilisant la taille de page directement inférieure à celle courante. Les différentes pages sont affectées aux pools pour chaque taille. Évidemment, le système doit essayer de recycler au maximum les pages de taille inférieure, pour limiter la fragmentation de la mémoire virtuelle. De même, si un ensemble de « petites » pages sont contiguës en mémoire, le système doit essayer de les « upgrader » vers le pool des pages de taille supérieure. Ce genre de méthode est très pratique sur les machines qui ont des tailles de page configurables (il y avait un microcode sur Alpha qui permettait de le faire; sur Itanium la taille des pages est arbitraire et configurable aussi; etc.).
[à propos d'un vieux serveur en zone sécurisée] il fallait probablement 2 kilos de paperasse en 4 exemplaires rien que pour changer une souris, alors ils faisaient avec je pense.
Ou bien ils n'avaient plus le code source de l'application de simulation. Ce n'est pas complètement une blague : c'est vraiment arrivé dans des endroits très, très sécurisés…
Ça fait des années (genre, facilement 10 ans) qu'utiliser testing et pas stable suffit pour avoir une Debian pas trop à la ramasse en termes de versions des softs tout en étant stable.
Note que je ne suis pas un zélote de Debian, mais il me semble important de le souligner.
Je ne suis pas d'accord. Des générations entières de futurs informaticiens ont appris la programmation grâce à BASIC. Je vois deux façons d'apprendre à programmer :
Soit tu commences vraiment tout en bas, façon Programming from the Ground Up, où on commence par l'assembleur, et quelque part on apprend un peu façon « physique/électronique ». Je trouve la démarche intéressante (c'est plus ou moins comme ça que j'ai commencé), et ça a l'avantage que, si la méthode fonctionne avec celui qui la reçoit, comprendre le concept de pointeur est souvent extrêmement aisé.
Soit on commence façon « top-down », et donc avec un aspect plus abstrait et mathématique. Dans ce cas, l'important est l'expression d'algorithmes, ce que permet Python facilement. Il ne faut pas oublier qui est visé : un étudiant qui ne connaît sans doute pas grand chose à l'informatique, et qui se fout un peu de la performance — l'important est l'apprentissage.
En pratique, durant mes études j'ai alterné entre les deux méthodes, et ça m'a plutôt pas trop mal réussi.
Et bien maintenant tu sais : même en lycée généraliste, on utilise des outils de DAO/CAO pour la filière Sciences de l'Ingénieur. :-) En gros, si tu choisis SI en tronc commun de 1è/Terminale scientifique, tu laisses tomber les SVT, et tu as 4 heures de mécanique et 4 heures d'électronique à la place (1h de cours magistral de chaque, et 3h de TP de chaque). J'ai fait du dessin industriel depuis ma seconde (j'avais pris une option « techno » en 2nde : TSA, Techniques des Systèmes Automatisés), et avoir un soft de type SolidWorks pour mieux visualiser ce qu'on apprend en théorie (on ne fait que de la méca statique, mais malgré tout, ça reste rigolo de pouvoir voir les forces à l'œuvre sur nos études de cas), c'est jamais gâché.
À noter que le tronc commun SI est une spécialité en soi (coeff 9 au bac divisé en coeff 6 à l'écrit, et un TP noté de 4h, coeff 3), mais qu'on a aussi le droit de passer une spécialité en plus (physique-chimie ou maths). Et si savoir utiliser AutoCAD/SolidWorks c'est cool, ça n'a absolument aucune espèce d'impact à l'écrit ou pendant les TP, puisque tout se fait au stylo/crayon/gomme — l'horreur pour moi, qui est plutôt du genre bordélique, avec des traits qui dépassent tout le temps, des traces de gomme…
Je m'étais un peu douté lorsque tu as mentionné Catia. :-) Malgré tout, tu répondais à un post qui, lui, parlait des « profs de techno ».
Ensuite, même avec les histoires de différence Catia v4/v5, je pense qu'il y a un souci : soit tu as bien compris les concepts derrière Catia, et dans ce cas, quelqu'un devrait passer un à deux jours pour te former sur la différence entre les deux versions (ou en tout cas, tu devrais avoir une liste de questions sur « comment faire ceci ou cela », et un collègue devrait te répondre); soit tu n'as pas compris, et dans ce cas-là, v4 ou v5, ça ne change pas grand chose : tu auras d'autres difficultés à surmonter entre temps.
J'ai bien conscience qu'être efficace dès le « jour 1 » avec le logiciel utilisé dans une boite est un plus. Pour autant, si la boite ne peut pas consacrer deux jours à un ingénieur junior (dont on sait qu'il ne sera de toute manière pas réellement productif avant un à deux mois de toutes façon), disons une demi-journée/une journée avec un ingé qui sait déjà comment ça marche, et une autre journée pour s'auto-former et s'adapter à une version différente), y'a baleine sous gravillon.
Le problème est plus complexe que cela. L'objectif, pour les élèves ne consiste pas seulement à faire tourner un assemblage de cubes, mais est aussi de leur apprendre l'utilisation d'un logiciel très utilisé dans le monde de l'entreprise.
C'est un peu de la foutaise honnêtement. Si on parle de lycées autres que professionnels, ils n'ont par définition pas de vocation à former de futurs techniciens. En France, en lycée techno, tu vas normalement évoluer vers un BTS (ou un CAP). En lycée général, ce sera la fac (générale ou IUT), l’école d’ingénieur/de commerce, ou éventuellement le BTS.
Lorsque j’étais au lycée il y a maintenant un peu beaucoup longtemps, j'étais en tronc commun technologie industrielle (aujourd'hui appelé sciences de l'ingénieur). Nous utilisions AutoCAD (sous DOS, v8 ou 9 je crois), histoire de comprendre comment fonctionnait un logiciel de DAO. Par contre, nous étions déjà bien "en retard" question version, puisque AutoCAD 13 ou 14 (pour Windows 9x/NT) était sorti. Parce que l'important c'est de comprendre les principes des logiciels de DAO, pas de nous former sur les versions disponibles en entreprise (de la même façon qu'apprendre les bases d'un logiciel de traitement de texte se fait aussi bien avec OpenOffice 2.x, LibreOffice 3.y, ou MS Word 2003, 2007, ou 2010…).
Pour SolidWorks, j'ai été l'un des premiers utilisateurs de mon lycée (qui venait d'acheter une licence—une seule, sur un PC unique). A l'époque, il n'y avait absolument aucun logiciel libre pour faire la même chose—que ce soit pour la DAO ou la CAO [1]. Par contre je suis certain qu'ils ne mettaient pas à jour leurs versions des qu'une nouvelle était dispo—pas de raison de le faire dans un cadre pédagogique, et puis une licence, ça coûte des sous.
Bref, si tu as besoin d'un outil et qu'il n'est pas disponible pour ta plate-forme, alors bien entendu utiliser du proprio n'est pas débile. Mais il ne faut pas justifier l'utilisation d'un soft propriétaire au lycée ou au collège sous prétexte que c'est ce qui est utilisé en entreprise.
[1]je vous parle d'un temps que les moins de vingt ans ne peuvent pas connaitre, occupes qu'ils étaient à courir dans la cour de récré en maternelle ou primaire… [2]
[2] Même maintenant je ne suis pas certain qu'il y ait beaucoup de softs au même niveau que SolidWorks en termes de fonctionnalités / ergonomie
35000 USD / an (bruts) c'est même pas le prix d'un codeur junior dans la plupart des états US… Disons que pour 6-8 mois de travail, oui, ça te paie un programmeur à plein temps.
Je n’étais pas à cette conférence, donc je ne vois pas bien de quoi tu veux parler. Par contre le memory wall, comme le dit bien le slide "page 4", est un truc "connu" depuis 95, qui est devenu bien plus important depuis que les processeurs sont devenus multi-cœur. Je ne dis pas que la mémoire (latence, bande passante) n'est pas un facteur limitant. C'est un fait.
Je dis par contre que dire que les I/O ne sont pas limitants, c'est de la blague. Lors de la simulation proprement dite, c'est plus ou moins vrai : on tente au maximum de tout mettre en mémoire (parce que si on arrive à un point où le programme va en swap, alors tout est fichu). Et évidemment, on cherche absolument à limiter les communications : malgré les avancées en termes de réseaux d'interconnexion et de latences, ces dernières coûtent énormément a l'application en termes de temps d'exécution si elles ne sont pas correctement orchestrées (d'où, par exemple, l'emphase sur l'utilisation de primitives MPI asynchrones, mais qui rendent les applications bien plus compliquées a débugger).
Dans la présentation que tu pointes, il est dit qu'en 1989 on collectait 10 Gio de données; qu'en 2010 on monte à 1 Tio, etc. Moi je te dis que dans pas mal de simulations faites dans les labos du DOE, 1 Tio, c'est le minimum généré. Je suis presque certain que dans pas mal de labos du CEA c'est vrai aussi.
Un autre exemple : je bosse pas mal avec des simulateurs de processeurs dans le cadre de mes recherches. Simuler environ 10 secondes de calcul, avec toutes les traces à fond, ça représente plusieurs heures de simulation (entre 2 et 4 minimum), et plusieurs dizaines voire centaines de gigaoctets.
Demande à n'importe qui faisant du HPC sur des calculateurs nationaux ou internationaux tu comprendras que les IO sont loin d'être limitant.
Ça c'est faux. Les entrées-sorties SONT limitantes, car de plus en plus de simulations HPC ont l'une ou l'autre de ces caractéristiques:
Elles ont des modèles physiques de plus en plus détaillés (conséquence de la capacité à faire du weak scaling, i.e. à augmenter la part de parallélisme à mesure que tu augmentes la tailles des entrées)
Elles commencent à proposer pas mal de d'options d'interactions, sans nécessairement aller jusqu'au temps réel, et donc de changer certains paramètres au fur et à mesure de l'exécution du programme
Elles proposent des framework de visualisation de plus en plus complexes, qui nécessitent énormément d'informations en sortie → on parle de Pio (peta-octets), voire plus dans certains cas.
J'oublie sans doute d'autres aspects. Dans tous les cas, les I/O, ce n'est pas que dumper des données sur le disque, c'est aussi un problème de contention sur les réseaux spécialisés (Infiniband, Quadrics, etc.). Le memory wall reste un vrai problème, mais le nouveau qui fait bien chier, c'est le power wall/_heat wall_ : l'énergie consommée par les nouveaux calculateurs est bien trop importante, et il faut absolument changer notre façon de faire des supercalculateurs.
J'étais à un workshop il y a 2 ans, qui parlait des modèles d'exécutions/de programmation pour le HPC, ce qui implique aussi entre autres les innovations pour la matériel. Vers la fin de la journée, tout le monde avait parlé. L'une des remarques qui a été faite par deux responsables du département de l'énergie US, c'est « Vous nous avez parlé d'exprimer le parallélisme, de correctement gérer la mémoire, de parfaitement occuper tous les milliers/millions de cœurs d'une machine, et c'est effectivement très important. Pour autant, n'oubliez pas les I/O. »
Le DOE, le DOD, le CEA, etc., ont des processus qui accumulent de plus en plus de données, et les systèmes de fichiers (même Lustre) ne sont pas forcément très très doués pour gérer la quantité de données produites.
Tu as essayé de lancer FF dans une VM Windows? C'est qu'à moitié une blague en fait. On avait déjà eu des surprises, du genre FF-Win-dans-VM (ou p'tet Wine ?) qui va plus vite que FF-natif-Linux (y'avaient de « bonnes » raisons, telles que la profile-guided optim activée dans la version MSVC++, mais quand même). Et apparemment ils avaient mieux optimisés FF-Linux. J'aimerais bien savoir sur FF-Win-dans-Linux a le même comportement RAMophage.
[^] # Re: Pourquoi les gens comprennent aussi bien l'économie que les (pseudo-)experts ?
Posté par lasher . En réponse au journal L'économie cette méconnue. Évalué à 3.
Pour un certain temps, un oiseau qui plane peut parfaitement être assimilé à un « appareil volant à ailes fixes ».
[^] # Re: qui sait
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Oui, et tant que tu n'as pas de problèmes de santé ni de gosses, tout se passe bien. Pour tout le reste, il y a master card: crèche (pas toutes les boites proposent quelque chose, loin de là), maternelle (souvent — toujours ? — privées), fac, santé en règle générale, etc.
Exemple à la con : une amie ingénieur en génie des procédés (elle a un bachelor of science, pas un master) bosse dans le New Hampshire. Tous les ans il faut renouveler l'enregistrement de sa voiture : 600$. On pourrait dire, « boah, c'est pas grand chose », et c'est vrai. Mais il y a aussi les impôts locaux, le loyer (elle paie ~900$/mois pour un ~50-55m²). Dans son domaine, un Master n'apporte pas grand chose, et il faut tenter le Ph.D pour voir un vrai changement dans le salaire (incidemment, c'est aussi vrai pour l'informatique dans plein de boites aux US, de nos jours — enfin de ce que je vois). Du coup quand je vois les gens parler de « tu touches Xk$ / an », souvent je pense qu'on oublie le nombre d'années passées en école doctorale, payé ~24k$/an (ici, la plupart des thésards restent au moins 5 ans).
[^] # Re: qui sait
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 2.
Il a toujours le droit de souscrire à l'assurance en question, mais sa boite ne paie plus sa part. Heureusement pour lui, il bénéficie de celle de sa femme (médecin). Quelqu'un d'autre aurait pu se retrouver dans la merde juste à cause du prix à payer par mois pour avoir les mêmes bénéfices que procure cette assurance. Comme il était déjà client, mon pote n'a pas de problème, tant que quelqu'un paie (s'il avait tenté de contracter une assurance avec comme condition pré-existante « leucémie », il n'est pas dit qu'il eut réussi…).
[^] # Re: qui sait
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Oui, j'allais dire que quand t'es en Californie et que tu gagnes (disons) 200k$/an, mais que tu paies ~2000k$/mois (le cas d'un pote qui vient d'être embauché chez Apple, à Cupertino — sauf que lui gagne ~150k$ en tant que « junior »), après les taxes et tout, il reste quand même beaucoup moins… Petit calcul : 2000 × 12 = 24k$. Il reste donc ~116k$/an à mon pote; sauf qu'en fait, il faut mettre une partie de son salaire de côté pour le 401k dont parlait PbPG plus tôt (hé oui dans son cas, y'a un plan 401K, mais il faut le soustraire de sa paie…); les impôts locaux sont très élevés; etc. Bref, la paie est bien plus élevée aux US, mais pour avoir le même niveau de « services » que ce qui est proposé en France (retraite, santé, éducation) il faut souvent payer presqu'autant que ce qui est prélevé sur le salaire côté patron. Malgré tout, un ingénieur compétent gagne plus au final que « le même » en France. Juste pas tant que ça.
[^] # Re: qui sait
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 6.
Même avec une bonne mutuelle, ça ne suffit pas forcément. J'ai un pote parti à Seattle, qui a eu la malchance d'avoir une leucémie, mais qui, dans sa malchance a quand même eu le bol d'avoir une femme qui bosse dans le meilleur hôpital pour traiter son type de leucémie particulier. Il bossait aussi pour une boite qui couvrait déjà énormément les frais médicaux… Mais pas complètement (il y a des plafonds au-delà desquels les individus doivent y mettre de leur poche). Bref. Il est en ce moment en rémission, mais a du coup perdu son job (car malade plus de X mois¹).
De façon générale, à cause de la façon dont le système US de santé fonctionne, ce qui en France (et en général dans le reste de l'Europe) coûte très peu et est le plus souvent couvert par la sécu ou une mutuelle, peut se révéler extrêmement coûteux aux USA. Une amie devait passer une radio. On lui a réclamé 1000$. Soit le prix d'un A/R en France depuis les USA. Truc qu'elle aurait pu faire: puisqu'elle était encore couverte par la sécu, au final cela aurait eu le double effet kisscool de lui permettre de revoir sa famille pendant un jour ou deux²… Les plafonds des assurances maladies sont vite atteints. En règle générale, oui, le système US favorise les plus riches : plus on est élevé dans la hiérarchie d'une boite, meilleure est la couverture pour tout. Mais il y a aussi des plafonds pour tout, et étant donné les prix bien plus élevés qu'en France pour tout ce qui est médical, on y arrive assez vite dès qu'on dépasse le simple rhume (j'exagère, je sais).
Pour ce qui est des enfants, il faut tout de même compter entre 50k$ et 150k$ minimum (en fonction de la fac, et suivant si l'on paie le tarif « in-state » ou « out-of-state ») par enfant pour tout ce qui est éducation supérieure, rien qu'en frais d'inscription pour obtenir une licence (qui dure 4 ans aux US — ensuite le plus souvent au niveau master/thèse, le directeur/mentor se charge de payer les frais pour l'étudiant). En règle générale, l'étudiant travaille pendant ses études pour se payer la chambre étudiante ou l'appart, la bouffe, l'assurance maladie qui n'est pas trop chère — dans la fac où je bosse, je crois qu'ils paient ~250$ / an pour l'équivalent d'une assurance qui couvre façon LMDE. Tous les étudiants américains que je côtoie ici, y compris ceux qui sont en « grad school » (c'est-à-dire en master/thèse, avec une orientation de recherche, et qui bossent dans mon labo) ont toujours une partie de leur crédit à rembourser. Les frais d'inscriptions des facs augmentent largement plus que l'inflation chaque année. Par exemple, l'université où je bosse est passée l'an dernier de ~7000$/an pour un in-state à ~11000$ de frais d'inscription. Similairement, les out-of-state devaient auparavant payer ~20000$/an, et désormais ~30000$/an. Cette bulle explosera sans doute à terme, mais je pense qu'elle va encore enfler quelques années.
Concernant la bouffe, oui, elle est moins chère — à condition de ne pas trop chercher à faire gaffe à comment elle a été produite. Si on veut de la bouffe avec à peu près les mêmes garanties qu'en France, on se retrouve avec un prix relativement comparable (ça reste tout de même moins cher aux USA). En règle générale, les besoins de base (bouffe, loyer, vêtement) sont moins chers qu'en France, tant qu'on est pas regardant sur la provenance/la qualité (les murs sont en papier dans la plupart des complexes d'appartements).
Par contre, je trouve qu'on oublie un peu facilement d'autres trucs vachement plus chers aux USA. Les câblo-opérateurs règnent en maîtres, et le font payer très cher : pour avoir un débit plus ou moins équivalent à ce qu'on a avec l'ADSL en France, je paie ~75$ tous les mois. Le téléphone, c'est encore pire : je paie ~95$ / mois. Ça comprend voix et SMS illimités, data 4G (Web) jusqu'à 2Gio de téléchargement (montant et descendant cumulés), puis bande-passante limitée au-delà. Je paie aussi ~10$/mois supplémentaire pour avoir le droit de téléphoner sur des lignes fixes sans autre surcoût à l'étranger. Le tethering est possible si on paie ~15$/mois supplémentaire, et faire office de routeur wifi est aussi possible si on paie le prix (~10$/mois je crois). Bien entendu, si je réinstalle une version « vanilla » d'Android sur le smartphone, les logiciels de mon opérateur ne bloqueront plus les deux dernières options… Ce que je vais faire d'ici 2 mois, quand la garantie aura expiré. En France on ne paie que si on appelle (en national), alors qu'aux US on paie quand on émet et quand on reçoit — et c'est aussi valable pour les SMS³.
Bref, ce qui en France coûte en cumulé (en prenant Free comme exemple, mais on pourrait prendre d'autres opérateurs) ~50€ (abo internet + mobile) coûte ~150$ ici aux USA. Même en faisant la conversion Euro-Dollar, on y perd clairement. Il y a d'autres exemples du même genre que je n'ai pas en tête en ce moment; je les retrouverai sans doute plus tard…
[1] En pratique, ils auraient préféré le garder car il était bientôt remis, et chercher un remplaçant prend du temps et en règle générale coûte des sous. Mais la politique de la (grosse) boite en question fait qu'au bout de X mois en congé maladie, un employé est automatiquement viré.
[2] Elle a réussi à se débrouiller autrement, et à faire baisser le prix, par je ne sais plus quelle magouille.
[3] Autant pour la voix sur mobile je peux comprendre le principe — on paie pour le droit d'être joint n'importe où — autant pour les SMS ça m'énerve un chouïa: même si le SMS n'est pas sollicité, on paie quand même : avec un coup de téléphone, j'ai le choix de ne pas décrocher…
[^] # Re: qui sait
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Je suppose que ton « tu » ne m'est pas adressé. Après tout, je suis aux USA depuis un petit bout de temps… :-P
Sinon je suis content de savoir que ce genre d'opportunités (et de tests) existent, mais j'avoue que lorsque j'étais sorti d'école d'ingénieur, ce qu'on me montrait comme opportunités pour faire du dév, c'était quand même plutôt les boulots payés 30k€—35k€ pour des débutants, et ~40k€—45k€ pour ~5 ans d'expérience. Bref, sans forcément parler de super hauts salaires, je connaissais peu de dévs qui pouvaient se vanter de toucher 60k€, même avec de l'expérience (j'en connais quelques uns quand même).
Pour ce qui est des entretiens d'embauche, j'ai déjà vécu le couple <entretien téléphonique technique, visite d'une journée sur place>. Durant la journée d'entretiens, j'ai eu droit à une discussion avec le VP of engineering, 4 sessions techniques, un déjeuner avec d'autres ingés… Et en effet, je n'ai pas eu à payer un centime (avion, hôtel, voiture de location, tout était aux frais de la boite). Mais j'ai l'impression que dans pas mal de boites franchouillardes, et surtout en IdF (avec les transports en commun, tout ça), souvent c'est pas trop trop le cas.
[^] # Re: Précisions nécessaires
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Je bosse de temps en temps avec [Jack Dennis]. Il a 81 ans, et continue de coder. Là, il est en train de terminer un simulateur pour une architecture multi/many core, avec un langage de programmation qui cible son jeu d'instruction, etc.
Il existe un bouquin, Coders at Work qui recueille un ensemble d'entretiens avec des « nouveaux » (Jamie Zawinski, dév. Netscape à la grande époque), des moins nouveaux (Joe Armstrong, inventeur de Erlang; Guy Steele, co-créateur de Scheme, « formalisateur » du langage Java, créateur de Fortress, et plein d'autres trucs) et des vénérables (Donald Knuth, mathématicien/informaticien, inventeur de TeX — entre autres). Beaucoup des gens interrogés ont largement passé 50 ans. Et pourtant une grande partie d'entre eux continuent de développer. Certes, je parle de gens qui sont relativement exceptionnels. Pourtant, mon expérience (statistiquement non significative, je le sais bien) me fait penser que les « vrais programmeurs¹ » n'arrêtent jamais vraiment de programmer, et ne perdent pas forcément de leur acuité…
[1] Je ne m'inclus pas dans cette catégorie.
[^] # Re: qui sait
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
Juste une question bête : depuis combien de temps travailles-tu aux USA (je crois que c'est le cas en ce moment) ?
J'ai quand même l'impression que le recrutement (surtout dans les grosses boites françaises) est très très différent de ce qui se pratique aux US…
[^] # Re: hint: PHP
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Tout ce que je voulais dire, c'est que C99/C11/C3001 ne seront sans doute jamais mis en place dans Visual C++ parce que ce n'est pas ce que veut faire Microsoft…
[^] # Re: hint: PHP
Posté par lasher . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
Il ne supporteront jamais C99, ils ne sont pas intéressés. Si C++ et C ont des standards qui se recouvrent, tant mieux pour les développeurs C. Sinon, tant pis.
[^] # Re: Laissez malloc tranquille !
Posté par lasher . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 10.
Hé, psssst! pBpG ! Je te pertinente beaucoup sur ces fils de discussion, mais au risque de répéter ce que t'ont déjà dit d'autres gens plein de fois, steup, utilise la syntaxe de citation :
> [la citation]
[une ligne vide]
[ton texte]
Mes yeux te remercient d'avance ! :)
[^] # Re: Laissez malloc tranquille !
Posté par lasher . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 5.
Je pige pas bien.
mmapest utilisé en sous-main (avecbrk) pour allouer la mémoire sous Linux. Ensuite,mmappeut échouer, et du coup tu dois tester la sortie en erreur.Note : je sais bien que tu veux dire que tu utilises mmap pour mapper le fichier PDF en mémoire. Sauf que, il serait aussi tout à fait envisageable que le PDF soit généré à la volée, et fasse effectivement ~20Mio…
Dans tous les cas, ton mmap peut potentiellement échouer, et dans ce cas, il faut bien signaler au client qu'une erreur s'est produite. En quoi cela change-t-il d'une allocation mémoire qui échoue ?
[^] # Re: Laissez malloc tranquille !
Posté par lasher . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
Deux remarques générales :
En ce qui concerne Linux en particulier, la façon dont les huge pages sont implémentées tiens du gros hack (on doit spécifier le nombre de grandes pages qu'on veut allouer au boot, pour s'assurer de la contiguïté de la mémoire physique), et c'est géré plus ou moins via les mêmes mécanismes que pour les segments de mémoire partagée (en tout cas c'était le cas il n'y a pas si longtemps).
Pendant sa thèse, Alan Cox avait publié un article très bien sur les « superpages » et comment les allouer. Il avait fait ses tests sur Alpha avec FreeBSD. L'idée est de découper la mémoire virtuelle en utilisant la taille maximale des pages du système (sur x64 : 4Mio). Si la charge de la machine et le « profil » des programmes qui tourne dessus requièrent des allocations plus petites, une superpage est ensuite redécoupée en utilisant la taille de page directement inférieure à celle courante. Les différentes pages sont affectées aux pools pour chaque taille. Évidemment, le système doit essayer de recycler au maximum les pages de taille inférieure, pour limiter la fragmentation de la mémoire virtuelle. De même, si un ensemble de « petites » pages sont contiguës en mémoire, le système doit essayer de les « upgrader » vers le pool des pages de taille supérieure. Ce genre de méthode est très pratique sur les machines qui ont des tailles de page configurables (il y avait un microcode sur Alpha qui permettait de le faire; sur Itanium la taille des pages est arbitraire et configurable aussi; etc.).
[^] # Re: Unix propriétaires
Posté par lasher . En réponse au journal Ma frise chronologique personnelle en informatique. Évalué à 3.
Ou bien ils n'avaient plus le code source de l'application de simulation. Ce n'est pas complètement une blague : c'est vraiment arrivé dans des endroits très, très sécurisés…
[^] # Re: Précision sur F2FS
Posté par lasher . En réponse à la dépêche Sortie de Linux 3.12. Évalué à 8.
Ça fait des années (genre, facilement 10 ans) qu'utiliser
testinget passtablesuffit pour avoir une Debian pas trop à la ramasse en termes de versions des softs tout en étant stable.Note que je ne suis pas un zélote de Debian, mais il me semble important de le souligner.
[^] # Re: Logiciels libres et enseignement de l'informatique
Posté par lasher . En réponse à la dépêche Des Inspecteurs Généraux de l'Éducation Nationale en table ronde chez Microsoft. Évalué à 7.
Je ne suis pas d'accord. Des générations entières de futurs informaticiens ont appris la programmation grâce à BASIC. Je vois deux façons d'apprendre à programmer :
En pratique, durant mes études j'ai alterné entre les deux méthodes, et ça m'a plutôt pas trop mal réussi.
[^] # Re: le libre à l'école, oui, mais par quel biais ?
Posté par lasher . En réponse à la dépêche Des Inspecteurs Généraux de l'Éducation Nationale en table ronde chez Microsoft. Évalué à 3.
Et bien maintenant tu sais : même en lycée généraliste, on utilise des outils de DAO/CAO pour la filière Sciences de l'Ingénieur. :-) En gros, si tu choisis SI en tronc commun de 1è/Terminale scientifique, tu laisses tomber les SVT, et tu as 4 heures de mécanique et 4 heures d'électronique à la place (1h de cours magistral de chaque, et 3h de TP de chaque). J'ai fait du dessin industriel depuis ma seconde (j'avais pris une option « techno » en 2nde : TSA, Techniques des Systèmes Automatisés), et avoir un soft de type SolidWorks pour mieux visualiser ce qu'on apprend en théorie (on ne fait que de la méca statique, mais malgré tout, ça reste rigolo de pouvoir voir les forces à l'œuvre sur nos études de cas), c'est jamais gâché.
À noter que le tronc commun SI est une spécialité en soi (coeff 9 au bac divisé en coeff 6 à l'écrit, et un TP noté de 4h, coeff 3), mais qu'on a aussi le droit de passer une spécialité en plus (physique-chimie ou maths). Et si savoir utiliser AutoCAD/SolidWorks c'est cool, ça n'a absolument aucune espèce d'impact à l'écrit ou pendant les TP, puisque tout se fait au stylo/crayon/gomme — l'horreur pour moi, qui est plutôt du genre bordélique, avec des traits qui dépassent tout le temps, des traces de gomme…
[^] # Re: le libre à l'école, oui, mais par quel biais ?
Posté par lasher . En réponse à la dépêche Des Inspecteurs Généraux de l'Éducation Nationale en table ronde chez Microsoft. Évalué à 5.
Je m'étais un peu douté lorsque tu as mentionné Catia. :-) Malgré tout, tu répondais à un post qui, lui, parlait des « profs de techno ».
Ensuite, même avec les histoires de différence Catia v4/v5, je pense qu'il y a un souci : soit tu as bien compris les concepts derrière Catia, et dans ce cas, quelqu'un devrait passer un à deux jours pour te former sur la différence entre les deux versions (ou en tout cas, tu devrais avoir une liste de questions sur « comment faire ceci ou cela », et un collègue devrait te répondre); soit tu n'as pas compris, et dans ce cas-là, v4 ou v5, ça ne change pas grand chose : tu auras d'autres difficultés à surmonter entre temps.
J'ai bien conscience qu'être efficace dès le « jour 1 » avec le logiciel utilisé dans une boite est un plus. Pour autant, si la boite ne peut pas consacrer deux jours à un ingénieur junior (dont on sait qu'il ne sera de toute manière pas réellement productif avant un à deux mois de toutes façon), disons une demi-journée/une journée avec un ingé qui sait déjà comment ça marche, et une autre journée pour s'auto-former et s'adapter à une version différente), y'a baleine sous gravillon.
[^] # Re: le libre à l'école, oui, mais par quel biais ?
Posté par lasher . En réponse à la dépêche Des Inspecteurs Généraux de l'Éducation Nationale en table ronde chez Microsoft. Évalué à 8.
C'est un peu de la foutaise honnêtement. Si on parle de lycées autres que professionnels, ils n'ont par définition pas de vocation à former de futurs techniciens. En France, en lycée techno, tu vas normalement évoluer vers un BTS (ou un CAP). En lycée général, ce sera la fac (générale ou IUT), l’école d’ingénieur/de commerce, ou éventuellement le BTS.
Lorsque j’étais au lycée il y a maintenant un peu beaucoup longtemps, j'étais en tronc commun technologie industrielle (aujourd'hui appelé sciences de l'ingénieur). Nous utilisions AutoCAD (sous DOS, v8 ou 9 je crois), histoire de comprendre comment fonctionnait un logiciel de DAO. Par contre, nous étions déjà bien "en retard" question version, puisque AutoCAD 13 ou 14 (pour Windows 9x/NT) était sorti. Parce que l'important c'est de comprendre les principes des logiciels de DAO, pas de nous former sur les versions disponibles en entreprise (de la même façon qu'apprendre les bases d'un logiciel de traitement de texte se fait aussi bien avec OpenOffice 2.x, LibreOffice 3.y, ou MS Word 2003, 2007, ou 2010…).
Pour SolidWorks, j'ai été l'un des premiers utilisateurs de mon lycée (qui venait d'acheter une licence—une seule, sur un PC unique). A l'époque, il n'y avait absolument aucun logiciel libre pour faire la même chose—que ce soit pour la DAO ou la CAO [1]. Par contre je suis certain qu'ils ne mettaient pas à jour leurs versions des qu'une nouvelle était dispo—pas de raison de le faire dans un cadre pédagogique, et puis une licence, ça coûte des sous.
Bref, si tu as besoin d'un outil et qu'il n'est pas disponible pour ta plate-forme, alors bien entendu utiliser du proprio n'est pas débile. Mais il ne faut pas justifier l'utilisation d'un soft propriétaire au lycée ou au collège sous prétexte que c'est ce qui est utilisé en entreprise.
[1]je vous parle d'un temps que les moins de vingt ans ne peuvent pas connaitre, occupes qu'ils étaient à courir dans la cour de récré en maternelle ou primaire… [2]
[2] Même maintenant je ne suis pas certain qu'il y ait beaucoup de softs au même niveau que SolidWorks en termes de fonctionnalités / ergonomie
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par lasher . En réponse à la dépêche Haiku est vivant. Évalué à 2.
35000 USD / an (bruts) c'est même pas le prix d'un codeur junior dans la plupart des états US… Disons que pour 6-8 mois de travail, oui, ça te paie un programmeur à plein temps.
[^] # Re: Et MPI ?
Posté par lasher . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 2.
Ah, mea maxima culpa donc. J'avais pourtant relu ta réponse pour justement éviter … ben exactement ceci. :)
[^] # Re: Et MPI ?
Posté par lasher . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 1.
Je n’étais pas à cette conférence, donc je ne vois pas bien de quoi tu veux parler. Par contre le memory wall, comme le dit bien le slide "page 4", est un truc "connu" depuis 95, qui est devenu bien plus important depuis que les processeurs sont devenus multi-cœur. Je ne dis pas que la mémoire (latence, bande passante) n'est pas un facteur limitant. C'est un fait.
Je dis par contre que dire que les I/O ne sont pas limitants, c'est de la blague. Lors de la simulation proprement dite, c'est plus ou moins vrai : on tente au maximum de tout mettre en mémoire (parce que si on arrive à un point où le programme va en swap, alors tout est fichu). Et évidemment, on cherche absolument à limiter les communications : malgré les avancées en termes de réseaux d'interconnexion et de latences, ces dernières coûtent énormément a l'application en termes de temps d'exécution si elles ne sont pas correctement orchestrées (d'où, par exemple, l'emphase sur l'utilisation de primitives MPI asynchrones, mais qui rendent les applications bien plus compliquées a débugger).
Dans la présentation que tu pointes, il est dit qu'en 1989 on collectait 10 Gio de données; qu'en 2010 on monte à 1 Tio, etc. Moi je te dis que dans pas mal de simulations faites dans les labos du DOE, 1 Tio, c'est le minimum généré. Je suis presque certain que dans pas mal de labos du CEA c'est vrai aussi.
Un autre exemple : je bosse pas mal avec des simulateurs de processeurs dans le cadre de mes recherches. Simuler environ 10 secondes de calcul, avec toutes les traces à fond, ça représente plusieurs heures de simulation (entre 2 et 4 minimum), et plusieurs dizaines voire centaines de gigaoctets.
[^] # Re: Et MPI ?
Posté par lasher . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 5.
Ça c'est faux. Les entrées-sorties SONT limitantes, car de plus en plus de simulations HPC ont l'une ou l'autre de ces caractéristiques:
J'oublie sans doute d'autres aspects. Dans tous les cas, les I/O, ce n'est pas que dumper des données sur le disque, c'est aussi un problème de contention sur les réseaux spécialisés (Infiniband, Quadrics, etc.). Le memory wall reste un vrai problème, mais le nouveau qui fait bien chier, c'est le power wall/_heat wall_ : l'énergie consommée par les nouveaux calculateurs est bien trop importante, et il faut absolument changer notre façon de faire des supercalculateurs.
J'étais à un workshop il y a 2 ans, qui parlait des modèles d'exécutions/de programmation pour le HPC, ce qui implique aussi entre autres les innovations pour la matériel. Vers la fin de la journée, tout le monde avait parlé. L'une des remarques qui a été faite par deux responsables du département de l'énergie US, c'est « Vous nous avez parlé d'exprimer le parallélisme, de correctement gérer la mémoire, de parfaitement occuper tous les milliers/millions de cœurs d'une machine, et c'est effectivement très important. Pour autant, n'oubliez pas les I/O. »
Le DOE, le DOD, le CEA, etc., ont des processus qui accumulent de plus en plus de données, et les systèmes de fichiers (même Lustre) ne sont pas forcément très très doués pour gérer la quantité de données produites.
[^] # Re: Quel est le problème ?
Posté par lasher . En réponse au journal Bye bye Feedly. Évalué à 1.
Et pour Stéphane ? Certes, 99% de ceux-ci sont des hommes. Mais il existe des Stéphane femmes.
Dans tous les cas, ton argument ressemble beaucoup à un "si tu n'as rien à te reprocher, pourquoi le caches-tu ?"
[^] # Re: Intérêt
Posté par lasher . En réponse à la dépêche Haiku est vivant. Évalué à 4.
Tu as essayé de lancer FF dans une VM Windows? C'est qu'à moitié une blague en fait. On avait déjà eu des surprises, du genre FF-Win-dans-VM (ou p'tet Wine ?) qui va plus vite que FF-natif-Linux (y'avaient de « bonnes » raisons, telles que la profile-guided optim activée dans la version MSVC++, mais quand même). Et apparemment ils avaient mieux optimisés FF-Linux. J'aimerais bien savoir sur FF-Win-dans-Linux a le même comportement RAMophage.