ckyl a écrit 3877 commentaires

La semaine dernière, après six mois de négociation, le patronat des sociétés d’ingénierie et de conseil et des bureaux d’études (Syntec et Cinov) a signé avec la CFDT et la CGC (56 % de leurs salariés à elles deux)

56% de salariés syndiqués dans le syntec o_O C

a me semble pas très crédible comme première phrase d'un article. Ca ne serait pas 56% des syndiqués par hasard ?

indiquant que le syntec et deux syndicats ont signé un accord vous permettant de ne pas décrocher votre téléphone ni lire vos mails une fois parti du boulot.

Ça me semble un raccourcis un peu rapide. Ça ne s'applique qu'aux cadres en forfait jour, soit en position 3 minimum, et ça touche donc beaucoup beaucoup moins de personnes. Avec les forfaits jour il y a en effet un problème qu'il n'y a aucune limite et que les gens qui ne sont pas en position de force peuvent se faire broyer par des boîtes non réglo à long terme. C'était un point légal qui traînait depuis un moment: http://www.courriercadres.com/emploi/droit-du-travail/le-forfait-jours-est-il-mort-03122013

Pour les autres c'étaient déjà normal de respecter ses horaires et ça ne change rien.

Maintenant rappelez vous les enfants, bien faire son travail d'ingé ce n'est pas combattre le feu 15h par jour mais faire en sorte d'être parti à 18h par ce que tout roule comme prévu. Don't work hard, work intelligent

Tiens puisque le monsieur à eu un peu d'exposition ces dernières semaines:

http://channel9.msdn.com/Events/Build/2014/3-642
http://research.microsoft.com/en-us/um/people/lamport/pubs/state-machine.pdf (preface)
http://www.wired.com/2013/01/code-bugs-programming-why-we-need-specs/

Alors il faut savoir que dans la plupart des cas, c'est tout à fait négociable, j'ai déjà vu le cas (certes pas majoritaire) de l'expert embauché en CDD à salaire « aligné » sur le privé.

Tu as des exemples d'IE avec des contrats à 48-60K plus compensation de la précarité (10% min en vrai tu vas le monnayer plus cher) ?

Mais bon, faire des statistiques sur une ou deux personnes…

Il suffit de suivre les liens que j'ai donné pour faire le calcul.

Autrement tu n'as clairement pas 25% de cotisation salariale dans le privé. Au final ça va se jouer sous les 3%. On est donc très loin du "**surtout que 2500 euros brut à l'INRIA ça fait pas beaucoup moins en net**". Ca va faire grosso modo 1K de différence, faut juste pas que les gens se fasse de fausses idées ?

Enfin, il faut croire que je lis trop de blogs/sites anglo-saxons ou j'ai l'impression que là-bas le design (au sens artistique) de web site à l'air de s'être vraiment développé. Il n'y a donc en France aucun souci du design, aucun intérêt pour la chose esthétique et de la partie graphique ?

Personne n'a dit que le besoin n'existait pas. La question est simple: Comment tu développes une activité économiquement viable. Ça demande de comprendre son métier, les clients et l'écosystème économique qui relie les deux pour trouver un positionnement.

Franchement vu tes différents commentaires j'attendrais un peu avant de faire quoi que ce soit…

J'ai fait un CDD à l'INRIA Grenoble, c'est très bien payé en effet,

Ce n'est pas "très bien payé".

Pour un débutant c'est payé au prix ou un poil en dessous du marché d'un CDI dans le privée. Pour quelqu'un qui a de l'expérience c'est juste une énorme blague.

On compare à des CDD d'un an renouvelable. Et ne pas oublier que la prime de précarité n'existe pas pour les contractuels, c'est inclus dans le prix. La vision est peut être un peu différente si tu es dans une zone géographique à bas coût vu que les salaires son nationaux.

Par contre en échange tu as de très bonne conditions de travail, la possibilité de faire des choses que tu ne ferais pas dans l'industrie, la possibilité d'aller à des confs etc. qui t'ouvriront de nombreuses portes plus tard. Bref si tu choisis bien ton équipe et que tu te bouges le cul, c'est un bon tremplin pour l'avenir. Au prochain saut tu as fait des choses que les autres n'ont pas fait et tu as donc toujours un coup d'avance. Et au final tu rattrapes très largement ton salaire.

Pour quelqu'un qui à de l'XP et de l'expertise je n'y vois aucun intérêt sauf une motivation intrinsèque ou chercher les conditions de travail qu'offre l'INRIA & co.

surtout que 2500 euros brut à l'INRIA ça fait pas beaucoup moins en net (et oui l'état paie moins de charge salariales :)

Tu as une source ? Si je regarde mes veilles feuilles de paie c'est kif kif au privé, t'es vers 20% sachant que tu ne cotises pas aux caisses cadres (et au passage c'est toi qui paye les cotisation salariales même si c'est pas toi qui fait le chèque).

D'ailleurs si tu compares http://vosdroits.service-public.fr/particuliers/F2302.xhtml et http://vosdroits.service-public.fr/particuliers/F469.xhtml c'est à vue de pif la même chose moins les caisses spéciales.

Ce dont tu parles ce sont des CDD de contractuels ce qui est différent des postes permanents de fonctionnaires. De toute facon à Bruxelle…

Les CDD sont cools pour les jeunes diplomé le ratio salaire/interet est bon si tu tombes dans une bonne équipe. Les postes permanent faut avoir la foi…

Non, sous Linux malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…

Non, sous Linux, par défaut, malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…

A posteriori l'exemple que j'ai choisi n'est pas forcément le plus pertinent ni le plus facile à comprendre (et la phrase ne veut rien dire).

Le sens initial de la phrase était quelque chose du genre: Tu as un objet en version 1 qui se fait accéder fréquemment et de manière standard. Tout va bien. En v2 tu ajoutes un champ comme un compteur d'accès, un timestamp qui va être écrit par un autre thread. Les performances en lecture des autres threads s'écroulent.

L'exemple n'est pas forcément bien choisi car dans la réalité le false sharing ne s'observe que sur des structures sensibles et largement optimisées au préalable. Autrement il se retrouve largement noyé dans la "lenteur" générale. Un exemple réel bien plus simple est dispo là.

À propos de la JVM : il y a quand même un petit truc spécifique (enfin, il y a peut-être le même problème pour la machine virtuelle Microsoft) concernant la récursion terminale (Tail Call Optimization)

La récursion terminale ne pose aucun problème sur la JVM. C'est un choix du langage ou non de l'implémenter. Scala le fait pas exemple.

Pour le TCO par contre ce n'est actuellement pas possible sur la JVM. Ca n'a jamais été une priorité et ca n'a donc pas été fait. En gros les problèmes à résoudre sont:
- La spec actuelle dit qu'il ne faut pas jouer avec la stack frame courante, c'est pourtant ce que le TCO fait
- On perd les stack trace. Ce n'est pas un problème en soit mais ca change un peu de ce qui existe actuellement
- Actuellement certains mécanisme repose sur les stack frame notament le bytecode verifier et les security manager. Ca peut se résoudre mais ca demande du travail.

Donc en gros oui la JVM à clairement des limites pour le TCO. Maintenant en pratique ce n'est pas non plus extrêment bloquant il y a souvent des alternatives.

John rose avait bossé sur un patch et Oracle en parlait dans sa roadmap à long terme en 2012 mais je ne sais pas si c'est toujours vivant ou pas:
https://wiki.openjdk.java.net/display/mlvm/TailCalls
http://wiki.jvmlangsummit.com/Why_Tailcalls

ilog a été acheté en 2009

Je sais ;)

IBM en France c'est 11000 personne en tout. Il n'y à que 700 dev, tous au france lab et tous issu d'Ilog.

Le reste n'est pas du dev et ne dépend pas du software group. Comme le sujet initial parlait des développeurs… Donc la seul présence dev d'IBM en France c'est le rachat d'Ilog et de ne pas avoir viré tout le monde depuis.

Je suis totalement d'accord avec toi.

Les microbenchmark sont juste la pour avoir des exemples de code très concis et obtenir des chiffres facilement pour valider le problème. Ils ne reflètent pas du tout la réalité et ne cherche pas à simuler un problème du monde réel en particulier.

Je suis aussi d'accord que @Contended peut faire potentiellement plus de mal que de bien surtout si des couillons comme moi commence à l'expliquer, ce qui implique qu'il va être abusé dans tous les sens. En pratique 99% des developpeurs ne devraient jamais avoir à y toucher, et pour les autres c'est un usage exceptionnel. Si je vois ca dans du code business je pars en courant de même que si une brique d'infra l'utilise à plus de 1, 2, 5 fois.

Pour ceux qui veulent un exemple plus concret issu du monde réel, LMAX avait très bien documenté le problème sur un ring buffer utilisé pour structure d'échange de donnée entre threads ou typiquement les variable head and tail vont se retrouver sur la même ligne de cache alors qu'elles sont massivement utilisées par des threads différents. Ca se voit par ce que la structure est méchamment optimisée pour ne jamais avoir de lock et une seule barrière mémoire.

Donc oui dans la vraie vie, si tu ne travailles pas sur ce genre de strucuture n'utilise pas @Contented.

Je pense qu'on s'écarte un peu du sujet initial. Évidement utiliser des objets plutôt que des types primitives à un fort impact sur les performances pour les raisons suivantes:

• Coût du cycle de vie d'un objet
• Empreinte mémoire très supérieure qui pourrie tes caches et te fais faire deux fois plus de fetch
• Tu perds la localité d'accès, le pattern d'accès mémoire est moins clean et le proco va avoir plus de mal
• Avoir beaucoup d'objets implique que GC te bouffe du CPU et te nique tes caches
• Etc.

Avoir un cache d'objets pour les entiers ne résout pas ces problème et de toute façon quand ces problèmes commence à se poser c'est que ton cache devrait faire 2³² éléments pour des int… Et ton pattern d'accès mémoire est toujours pourri.

Maintenant oui faire des pools d'objets ou des flyweight ca à un sens dans des cas déterminé. Suffit de regarder ce qui a été fait par twitter pour Netty 4.

en tout cas dans les systèmes multi-threadé à cause des garanties offertes par le Java Memory Model, il y a une Write barrier à chaque exécution d'un constructeur.

Tu as une source. Par ce que AFAIK (et le cookbook de la JSR 133 confirme) en sortie de constructeur c'est une barrière StoreStore qui est requise, et StoreStore sur x86 c'est un No-op vu que c'est déjà garanti par le memory model d'X86…

Tu n'as pas besoin d'un build fastdebug, c'est une option product. Par contre il te faut le module hsdis dans ton JDK ou dans ton LD_LIBRARY_PATH. Pour savoir si une option est product ou release il suffit d'aller voir dans le fichier `src/share/vm/runtime/globals.hpp' d'Hotspot.

Pour la marche a suivre c'est la.

De nos jours, avoir 1 Mbps en upload n'est pas inhabituel, ça fait 10 Go par jour soit 3 To/an.
Faut avoir de sacrés besoins de backup pour aller plus loin

Ou juste ne pas avoir envie de laisser tourner sa machine 24/24 et de pourrir sa connexion. Chopper un incrément de 16Go c'est pas inhabituel de nos jours (photos / video). C'est la taille d'une carte mémoire.

On revient dans le cas exceptionnel (comme l'init), moins dérangeant, pas le soucis.

C'est rigolo je viens de tuer le dernier NAS qui me restait pour les backups par ce qu'il ne tenait que 4Mo/s et que ça prenait une éternité pour récupérer les données dessus… C'est beaucoup plus pratique et rapide de mettre un disque dans le mange disque.

Ce qui est encore pas trop mal, c'est sûr qu'après si on veut pas y mettre de sous…

C'est juste une question de ratio.

Sauvegarder 500GB sur Glacier c'est 60€ par an (et du backup sur Glacier c'est pas pratique), 500€ chez S3, et chez tarsnap c'est 1800€. Pour le prix de glacier tu as un disque qui va statistiquement durer 3-8 ans (mais un seul disque).

Excuse moi de faire le calcul.

Avec un gros avertissement : se mettre un réveil tous les x jours et s'y tenir. Désolé de ne pas croire dans l'être humain, sans doute l'expérience ;-)

Non c'est à toi de définir la fraîcheur dont tu as besoin au pire cas. Et pour un particulier en général c'est pas 24h très loin de là. La perspective de sauver 15 ans de données rend souvent acceptable de perdre les X derniers heures/jours/mois.

Après si tu fais pas, tu fais pas. Mais ne vient pas m'expliquer que la sauvegarde en ligne est la seule réponse.

Il y a un truc qui n'apparaît pas dans ton benchmark, c'est que les Integer ont un cache: le boxing va retourner la même instance d'Integer pour un int de la même valeur, entre certaines bornes, et c'est configurable (http://stackoverflow.com/questions/15052216/how-large-is-the-integer-cache). C'est clair que ça reste limité, mais en pratique je pense qu'on y gagne pas mal.

Ca ne change rien sur la perf. Ca permet de ne pas créer trop d'objets, et donc diminuer un peu l'empreinte mémoire et la pression sur le GC, pour les valeurs les plus courantes mais le coût d’exécution est le même. De toute facon si la perf est ton problème, le cache sera toujours beaucoup trop petit.

Autrement l'approche de Scala me semble la plus pragmatique: au niveau du langage il y a des types correspondants aux types primitifs de Java (Int, Long, etc.), mais qui se comportent comme des classes, ont leur propres méthodes, sont utilisables dans les types génériques. Le compilateur se débrouille après pour utiliser les types primitifs au niveau du bytecode (donc pas plus d'overhead).

Je n'écris plus beaucoup de Scala ces derniers temps mais si l'approche semble en effet plus propre, le mécanisme de spécialisation arrive assez vite à ses limites et tu as donc des performances assez imprédictibles pour qui ne sait précisément l'implémentation derrière. Je ne connais pas suffisamment la théorie derrière pour savoir si c'est un problème d'engineering ou théorique.

Du côté de la JVM, on parlait informellement en 2012 d'optimisations pour détecter une suite de box/unbox pour les virer. Identiquement théoriquement je ne sais pas si c'est une jambe de bois.

À ma connaissance aucun langage sur la JVM n'a vraiment résolu le problème et donc que la JVM est le facteur limitant.

Ca intéressait des gens des journaux sur les autres JEP, JDK enhancement proposal, d'OpenJDK 8 ? C'est en général beaucoup plus bas niveau que la syntaxe du langage et API. Ca n'intéresse donc absolument pas les "développeurs struts" mais plutôt les curieux et ceux qui font du code bas niveau (ca permet sûrement aussi au dev C++ de rigoler en disant que ça fait 20 ans qu'ils peuvent gérer ces problèmes de 33 façons différentes mais personne n'est d'accord sur laquelle).

La solution est un tout et c'est à toi de la définir et de t'y tenir. En dehors de la sauvegarde locale qui est complémentaire à la sauvegarde distante il n'y a que deux solutions:

• Utiliser le réseau
• Déplacer un support de stockage

En fonction de la taille totale du backup, de la taille des deltas, de ta connexion internet, du prix que tu es prêt à payer pour tes sauvegardes, redondance nécessaire et de la fraîcheur requise au pire cas tu choisis l'un ou l'autre.

Utiliser le réseau est en effet plus pratique, en général les raisons pour que ça ne soit pas possible sont:

• Connexion trop lente pour envoyer la sauvegarde initiale (certain service propose de recevoir des disques durs)
• Connexion trop lente pour envoyer les incréments
• Connexion trop lente pour récupérer les données dans un temps raisonnable
• Prix au Go trop élevé à partir d'une certaine taille (même glacier te coûte grosso modo le prix d'un disque dur par an)

Et comme il n'y a pas de miracle. Ce qu'il propose est la seule autre alternative…

Par exemple (je ne connais pas).

Perso j'ai opté pour un rack interne type Icy Box IB-168SK-B par ce moins y'a de truc qui traînent sur le bureau mieux je me porte. Mais n'importe quoi de ce genre doit faire l'affaire. Basiquement tu pousses le disque et tu n'as pas à t'embêter avec une alim ou le prix des disques 2.5".

Il reste le problème d'une catastrophe type inondation ou incendie qui pourraient tuer les 3 disques. Mais je pense que ça reste déjà une bonne prévention pour les pannes matérielles ou logicielles.

La solution est très simple par rapport à ce que tu as déjà.

Tu rsync alternativement sur deux disques externes (chiffrés bien entendu) dont un que tu laisses traîner ailleurs. Tu en as donc un "chaud" sous la main pour les petits problème et un "froid" qui peut avoir une semaine / six mois de lag selon tes besoins mais qui assure la pérennité en cas de catastrophe. Solution très pratique pour ceux qui ont à sauvegarder/restaurer des volumes de données incompatibles avec leur connexion internet. Évidement si tu as 500MB de backup, il y a plus fiable/facile…

(Et comme les disques externes c'est cher et relou à manipuler, pour 15€ tu peux avoir un rack pour facilement charger tes disques.)

Il ne faut pas oublier non plus des boites comme Microsoft qui ont la plus grosse présence européenne en France, idem pour IBM.

Pour du dev ?

Pour le dev IBM à une forte présence en France uniquement suite au rachat d'Ilog. Du coup ils se sont retrouvé à devoir les rattacher au software group. C'est une anomalie de l'histoire qui représente ~700 personnes mais on peut pas vraiment dire qu'ils investissent dans le dev en France.

La vraie implentation d'IBM en France c'est juste pour le commercial, IT, service, show case, et proto.

en France je doute que tu trouves un travail technique (développeur, ingé sys…) payé plus de 60 000 Euros bruts annuel.

Heu si. Après c'est clairement pas le gros du marché mais ça existe.

Je suis heureux de voir que les développeurs Java ont découverts les pointeurs de fonctions membre :-D

Houla ne t’emballe pas. Ça va prendre encore quelques années et des montagnes d'horreurs pour en arriver là. En 2014 ils ont pas encore assimilé toute la masse, koff, des changements de Java 7 et sont tellement tout fou devant la révolution qu'est Guava, qu'ils en foutent 20 couches que tu comprends plus rien, que ça fait mal aux yeux et qu'ils font exactement ce que la doc de Guava dit de ne pas faire :)

Le chemin va être long… Par contre y'a plein d'opportunité à prendre pour réécrire des libs avec les nouvelles possibilités. Ca bouge un peu partout et c'est marrant. Tu vois aussi les binding des projets multi-langage sur la JVM devenir plus proche, Java étant toujours l'exception pourrie précédemment.

Heureusement, la JVM sait déjà faire ça bien sur sinon les codes numériques auraient des perfs très très très mauvaises…

Non la JVM ne sait pas faire ça. Tu n'as pas un système de type unifié et les deux mondes sont clos et ne communique que par un système de boxing couteux et dangereux. Les performances des Integer/Long sont désastreuses et leur occupation mémoire démentielle.

On peut faire un benchmark très simple. On va faire la somme d'un tableau d'int puis d'Integer. La troisième variante c'est d'utiliser un Long au lieu d'un long pour maintenir la somme

@OutputTimeUnit(TimeUnit.SECONDS)
@State(Scope.Benchmark)
public class MyBenchmark {

  static final int SIZE = 1_000_000;

  int[] intArray =  IntStream.range(0, SIZE).toArray();

  Integer[] integerArray = IntStream.range(0, SIZE).boxed()
          .collect(Collectors.toList())
          .toArray(new Integer[SIZE]);

  @GenerateMicroBenchmark
  public long testPrimitive() {
    long sum = 0;
    for (int i = 0; i < intArray.length; i++) {
      sum += intArray[i];
    }

    return sum;
  }

  @GenerateMicroBenchmark
  public long testBoxed() {
    long sum = 0;
    for (int i = 0; i < integerArray.length; i++) {
      sum += integerArray[i];
    }

    return sum;
  }

  @GenerateMicroBenchmark
  public long testBoxed2() {
    Long sum = 0L;
    for (int i = 0; i < integerArray.length; i++) {
      sum += integerArray[i];
    }

    return sum;
  }

  public static void main(String[] args) throws RunnerException {
    Options opt = new OptionsBuilder()
            .include(".*" + MyBenchmark.class.getSimpleName() + ".*")
            .forks(1)
            .warmupIterations(5)
            .measurementIterations(5)
            .build();

    new Runner(opt).run();
  }

Voilà le resultat

Benchmark                         Mode   Samples         Mean   Mean error    Units
o.s.MyBenchmark.testBoxed        thrpt         5      430.597       15.005    ops/s
o.s.MyBenchmark.testBoxed2       thrpt         5      120.147        8.491    ops/s
o.s.MyBenchmark.testPrimitive    thrpt         5     3341.320      502.704    ops/s

C'est dix fois plus lent. Et encore dans ces microbenchmark tu ne paies pas le coup du GC qu'une vraie appli a. Entre testBoxed et testBoxed2 une majuscule de différence te rend presque encore 4x plus lent.

Bref actuellement tu as le choix de faire plaisir au programmeur ou au programme… Sachant que ces problèmes remontent jusque dans les API du JDK. Tu as certaines choses de l'API de stream que tu ne peux pas faire pour des int par ce qu'il n'y a pas de type spécialisés.

Certain langages sur la JVM ont un système de type unifié, que la JVM n'a pas, et ont un mécanisme de spécialisation pour essayer que ça ne soit pas trop désastreux en perf. Mais ça doit pas être si trivial par ce qu'on arrive très vite aux limites et tu repasses dans le monde slow-motion assez facilement.

Bref si tu veux faire du Java performant et réussir à tenir plus de 4 entiers en mémoire tu restes sur les types primitifs et tu utilises les structures de données spécialisées trove par exemple. Oracle avait dans sa roadmap un système de type unifié pour Java 9 ou 10 mais pas vu une seule discussion depuis les talks de 2012. En attend pour tout ce qui est sérieux tu reste aux types primitifs et tu pleures sur l'API du JDK.

D'un autre côté ca pousse très dur sur la perf en ce moment avec le retour en force des FFI, du off-the-heap, du code à la C par nos amis traders haute fréquence et base de données distribuées. Ça va être rigolo de voir comment ils vont s'en sortir chez OpenJDK :)

Il me semble qu'on dit exactement la même chose ;)

Maintenant en pratique, ça revient à conclure que l'approche interface n'était pas une bonne solution pour permettre à un système d'évoluer et que la composition de trait/mixin est bien plus flexible. Bien évidement on a gardé les anciens noms et principes.

Vu que ça répond au besoin et qu'il y a sûrement des implications techniques ils se sont arrêtés aux traits stateless. Si quelqu'un a un lien sur une discussion à ce sujet où sur l'exploration des deux approches ça m'intéresse. En tant que dev, les traits de Scala sont très pratiques pour composer des comportement; avec du stateless tu es très vraiment limité c'est dommage de ne pas avoir cette possibilité. Mais c'est un premier pas.

pour que le JIT inline une méthode était quelque chose comme 35 opcodes du bytecode Java.

Valeur par défaut oui. Tu peux jouer avec -XX:MaxInlineSize.