Discussion :

[floyer]

Si tu fais du doublement chaîné, ça se fait très rapidement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

c->next->previous = c; // pseudo code

Ok. Et je présumes que comme tu utilises un GC, l'allocation te coûte presque rien.

Comme l’allocation ne coute rien, pourquoi s’embêter à essayer de réutiliser de la mémoire avec des manipulation de pointeur loin d’être évidentes ? (je rappelle qu’en guise de pointeur, j’ai une profondeur dans la pile et un index calculé à l’analyse du code... alors que la pile n’existe pas encore... difficile de créer alors les pointeurs retours, surtout qu’une variable a typiquement plusieurs expressions l’utilisant.... ce n’est pas juste un unique pointeur retour. Faudrait-il que let a=b aille chercher dans la liste des expressions utilisant b, notre a pour la retirer... c’est déjà trop complexe dans un cas simple... une fonction utilisant b peut être appelée plusieurs fois.... le cas commence alors à être franchement compliqué).

Si les concepteurs d’Haskell on évité de faire ce genre d’optimisation, c’est bien parce que ce n’est pas aussi simple). Alors qu’en Haskell, l’opérateur de modification de tableau // (absent de M) gagnerait à pouvoir être en O(1) lorsque possible.

[Mat.M]

Il fallait 6 heures au COBOL pour passer l'un d'entre eux, il fallait 6 jours au JAVA pour faire pareil. Sur 5% de la volumétrie. Faites le calcul.

la différence entre Java et COBOL c'est le garbage collector

Les gens recrutés pour faire du JAVA - dont je n'ai aucune raison de penser qu'ils étaient par essence moins bons - n'ont pas réussi à faire un truc qui marche et qui soit d'une performance acceptable.

le problème des langages objets c'est qu'il faut instancier en interne des tas d'objets que la Virtual Java Machine doit gérer lors de chaque opération.
Si vous faites la moindre opération la JVM regarde s'il n'y a pas une exception levée donc ça finit par peser sur les performances.
En COBOL que je ne connais pas on accède directement aux disques,enregistrer des données d'un compte bancaire c'est quasiment octet sur octet.
Bref ce que tu est en train d'expliquer.

[floyer]

Les exceptions peuvent être gérées avec des instructions comparables aux setjump/longjump... donc juste un léger overhead dans les parties «*try*» et «*finaly*» du try{...} finaly {...} catch ... ensuite, le code s’exécute sans overhead. C’est l’intérêt par rapport à l’usage de fonctions qui retournent des codes d’erreurs qu’il faut tester à chaque appel.

Il aurait été surprenant que Barn Stroustrup ait intégré les exceptions dans C++ si cela ralentissait le code ainsi.

[Mat.M]

oui je suis d'accord cependant ça fait tout de même quelques instructions en plus.
Ce que je voulais dire c'est que COBOL est vraiment plus approprié pour le bancaire par exemple.

[floyer]

Plutôt moins d’instructions : un gros try { } autour d’un ensemble d’instructions qui font des IO plutôt qu’un test d’erreur après chaque IO... On peut préférer l’usage des exceptions.

En revanche, la JVM va tester chaque objet avant usage afin de lever une exception NullPointerException si besoin. Un bon JIT va limiter le test à un par objet et ne pas retester plusieurs fois le même objet, donc on pourrait être légèrement moins efficace qu’en C++ (là c’est l’OS qui arrête le processus brutalement - Core Dump !).

Après, il est possible que la réécriture en Java ait changé la pile logicielle profondément. Si on a à droite du COBOL et des fichiers plats et à gauche du Java et des accès base de données via un ORM... pas sûr que Java soit le seul responsable.

[Pyramidev]

@floyer : en C++, lancer une exception, ce n'est pas juste un petit longjump. Il faut trouver le bon bloc catch, qui peut être plusieurs niveaux au dessus dans le code appelant. Et, quand on remonte dans la pile, il faut au passage appeler les destructeurs de toutes les variables locales. Pour compliquer le tout, la sélection du bon bloc catch se fait par un mécanisme de sous-typage et fait intervenir le RTTI.

Les exceptions du C++ ne respectent par le principe no overhead du C++. Pour cette raison, Herb Sutter avait soumis sa proposition P0709R0 intitulée Zero-overhead deterministic exceptions: Throwing values.

[Neckara]

Comme l’allocation ne coute rien, pourquoi s’embêter à essayer de réutiliser de la mémoire avec des manipulation de pointeur loin d’être évidentes ?

J'ai trop l'habitude du C/C++ sans GC.

[el_slapper]

(.../...)EDIT: si ton estimation est correcte, imagine, 5 jours de devs un peu intensif que tu rentabilises en 2 mois. Après, tu as 3 jours par mois "libre" où tu pourras sortir la tête de l'eau… et faire d'autres trucs du genre.
Si tu as 2-3 trucs du genre, ça te fais 9 jours par mois de gagnés (sur 21 jours de travail), c'est énorme. Déjà rien que 3 jours, ça te fais 14% de temps "libre" sur ton mois.
Si tu trouves 7 trucs du genre, t'as même plus besoin de travailler dans le mois ! Et si t'en trouves encore plus, tu devras travailler un nombre de jour négatif !

Tu prêches un convaincu. D'ailleurs, à la fin de cette mission, je me tournais les pouces(après 3 ans de dur labeur, hein, 2 mois de calme, c'était bien mérité). Mais il faut bien voir que justement, arriver à caser en loucedé les 5 jours nécessaires à la maintenance, ce n'était pas possible. J'étais monitoré en permanence. Le plus que j'ai réussi à faire, c'est 8 heures au lieu de 4(un truc qui avait lieu 20 fois par an, après avoir mis en place un outillage, la charge est tombée de 4 heures à 30 minutes). J'ai quand même fini par faire ce truc, mais dans un contexte projet, ou j'ai glissé en "préliminaires nécessaires" carrément 8 jours pour faire ce truc là en plus. Ils n'y ont vu que du feu.....jusqu'au moment ou ils ont vu le truc tourner en test, et j'ai eu droit à 30 minutes d'engueulade au téléphone sous le thème "ce n'était pas demandé! tu as volé la banque!". C'est ça, le contexte, et j'ai tendance à penser que c'est généralisé - je ne suis pas mal tombé, c'est partout pareil.

Glutinus en parle mieux que moi(dans d'autres fils - il est passé par les mêmes clients que moi, et il est très fort pour mettre en mots ses expériences), mais dans le monde corporate, tu as souvent des petits chefs dont l'obsession est de te contrôler, pas que tu sois performant. Et c'est toute la chaîne hiérarchique qui est comme ça. Ma chef directe m'aurait bien laissé faire ça(elle avait compris ce qui se passait), mais ses managers ne l'auraient jamais laissé faire, et l'auraient virée pour manque de contrôle de l'activité de son équipe. Donc elle passait le message. Ne faire que des activités directement vendables par les managers, qui puissent frimer auprès de la direction sur le thème "regardez, on a augmenté le temps directement utile des devs, et réduit le temps inutile"(oui, la maintenance préventive, dans ce monde là, c'est inutile. Kafka, est-tu là?)

Dans ce genre de contextes, ben, tu fais au mieux en fonction de ce que tu peux faire. Tout ce que tu peux mettre en place comme bonnes pratiques, tu le mets en place. Mais tu ne t'offusques pas quand d'autres sont soigneusement ignorées. Un peu d'amélioration est mieux que pas d'amélioration du tout. C'est pour ça que ton purisme est souvent mal perçu - des gens qui subissent ce genre de management à longueur de journée n'ont pas tous la patience d'expliquer ça à quelqu'un qui ne connait pas notre monde. Le code parfait, c'est souvent un vœu pieux. Moi j'ai la chance que ma nouvelle crèmerie est plus sérieuse. J'ai vu une scène ou les devs ont demandé 15 jours d'interruption du projet pour faire de la refonte et de la maintenance préventive, et la réponse de la chef a été "OK, je mets à jour le planning". Chez 90% des clients, cette réponse est de la science fiction.

la différence entre Java et COBOL c'est le garbage collector

pas seulement, mais ça joue certainement.

le problème des langages objets c'est qu'il faut instancier en interne des tas d'objets que la Virtual Java Machine doit gérer lors de chaque opération.
Si vous faites la moindre opération la JVM regarde s'il n'y a pas une exception levée donc ça finit par peser sur les performances.
En COBOL que je ne connais pas on accède directement aux disques,enregistrer des données d'un compte bancaire c'est quasiment octet sur octet.
Bref ce que tu est en train d'expliquer.

ça, et si le développeur a un peu trop garni ses getters-setters, tu as un bon début d'explication. Le passage à un tout base(et donc une explosion des temps d'I/O chers à Neckara) au lieu de se trimballer des fichiers plats est sans doute aussi un complément d'explication valable. Les bases SQL servent pour les opérations unitaires en journée, mais les batches de nuit sont souvent plus brutaux que ça : on décharge la base dans un fichier plat, on droppe la table(oui, on droppe la table de production toute les nuits), on traite le fichier plat(et on lui fait subir un nombre impressionnant de transformation, simples unitairement, mais nombreuses, et dont l’enchaînement est complexe), et la sortie sert de référence pour recréer la base. Donc les problèmes de performance de la base, en batch, on s'en fout. Seules comptent les I/O fichier plat, normalement bien supérieures si le tri a bien été fait(ce qui est généralement le cas).

Et comme les gens qui ont fait la migration n'ont pas été assez futés pour comprendre ça, je subodore qu'ils n'étaient pas non plus capables de faire du fonctionnel dans les règles de l'art. Retour à la case départ.

[Neckara]

C'est surtout qu'il faut distinguer ce qu'on peut et devrait faire (can/should), et ce qu'on peut faire (may).


Ce sont des décisions stupides qui s’appuient sur rien d'autre que l'incompétence de votre hiérarchie dont vous êtes les premières victimes à vous retrouver la tête sous l'eau une grande partie de votre temps.
Tout cela, non pas du fait de restrictions techniques, budgetaires, ou de temps, mais simplement de l'incompétence de vos supérieurs.

Le fait qu'il vous force à faire cela ne retire rien au caractère stupide de leur ordre, et je suis persuadé que si vous aviez le choix, vous ne prendriez pas les décisions qu'ils ont pris.
Leur méthode managériale a 1 siècle de retard, et est contre-productive, faut pas s'étonner si derrière les recrutements sont difficiles ou si les personnes ne restent pas très longtemps.



Dans le publique il est vrai qu'on a l'avantage de pouvoir envoyer chier nos supérieurs et que la hiérarchie n'y est pas très importante.

[el_slapper]

C'est surtout qu'il faut distinguer ce qu'on peut et devrait faire (can/should), et ce qu'on peut faire (may).

100% d'accord sur ce point là.

Ce sont des décisions stupides qui s’appuient sur rien d'autre que l'incompétence de votre hiérarchie dont vous êtes les premières victimes à vous retrouver la tête sous l'eau une grande partie de votre temps.
Tout cela, non pas du fait de restrictions techniques, budgetaires, ou de temps, mais simplement de l'incompétence de vos supérieurs.

la plupart des fils sur les sous forums "Actualités" et "Emploi" tournent précisément autour de ce thème. Ce n'est pas un hasard. J'ajouterais juste que cans certains cas, c'est l'incompétence des clients qui nous met dedans. Quand on installe un hôpital sérieux, ou les informaticiens sont compétents, la direction volontaire, et ou le non-sens n'est pas toléré, ça se passe bien, même si on a plein de trucs compliqués à faire. Quand on installe un hôpital qui est en pleine gueguerre politique interne, et qui de surcroît manque de ressources internes, on sait d'avance que ça va mal se passer.

Le fait qu'il vous force à faire cela ne retire rien au caractère stupide de leur ordre, et je suis persuadé que si vous aviez le choix, vous ne prendriez pas les décisions qu'ils ont pris.
Leur méthode managériale a 1 siècle de retard, et est contre-productive, faut pas s'étonner si derrière les recrutements sont difficiles ou si les personnes ne restent pas très longtemps.

C'est presque partout pareil, hein. Encore une fois, les problèmes de recrutement de cadre sont communs à toute l'Europe - dès qu'on a besoin de compétences un peu précises et pas d'un débutant prometteur. Un expert en comptabilité médicale, ou en administration du patient, ça ne se trouve pas d'un claquement de doigts, et ça ne se forme pas rapidement non plus. Et pour le deuxième profil, notre branche italienne en a besoin pour hier sans faute d'un bon paquet. Pour le premier profil, il nous en faut un en France, et c'est déjà fort compliqué. Avant même de parler de conditions de travail.

Dans le publique il est vrai qu'on a l'avantage de pouvoir envoyer chier nos supérieurs et que la hiérarchie n'y est pas très importante.

Ce qui pose d'autres problèmes. En hôpital public, les médecins chefs de service sont des barons féodaux au pouvoir absolu, et voient l'informatique comme un moyen de tracer leur boulot(ce qui est vrai), et donc de nuire à leur pouvoir absolu(ce qui est possible). Ledit pouvoir leur permet certainement d'être plus efficace dans leur activité de tous les jours, mais il est aussi nuisible pour des actions qui dépassent leur périmètre habituel(comme l'informatisation).

Je ne sais pas si c'est pareil dans ton domaine, hein. Mais il faut voir les deux cotés de la médaille.

[floyer]

@floyer : en C++, lancer une exception, ce n'est pas juste un petit longjump. Il faut trouver le bon bloc catch, qui peut être plusieurs niveaux au dessus dans le code appelant. Et, quand on remonte dans la pile, il faut au passage appeler les destructeurs de toutes les variables locales. Pour compliquer le tout, la sélection du bon bloc catch se fait par un mécanisme de sous-typage et fait intervenir le RTTI.

Les exceptions du C++ ne respectent par le principe no overhead du C++. Pour cette raison, Herb Sutter avait soumis sa proposition P0709R0 intitulée Zero-overhead deterministic exceptions: Throwing values.

Merci pour le document.

Effectivement, je n’avais pas pensé à l’appel des destructeurs. Si à chaque création d’objet sur la pile, il y a un try/finaly implicite pour s’assurer de la destruction d’objet, cela est préjudiciable.

C’est peut-être l’avantage de Java où les objets sont détruits par le GC... il n’y a pas ces précautions à prendre. De plus la signature des fonctions précise si elle peuvent retourner un exception.

[Mat.M]

@Neckara : tout à fait cependant pour les personnes qui ne le saurait pas ,il y a une sorte d"équivalent en C++ 11 au GC je crois que c'est les smart pointers ou là

Mais je ne m'y suis pas trop penché là-dessus

Il me semble que pour allouer des objets sous Direct3d 11 c'est une obligation d'utiliser ce genre d'objets

[Neckara]

@Neckara : tout à fait cependant pour les personnes qui ne le saurait pas ,il y a une sorte d"équivalent en C++ 11 au GC je crois que c'est les smart pointers ou là

Non, ils permettent la libération automatique à la disparition des références, mais ne sont pas équivalent au GC. En effet, ils ne permettent pas de réutiliser lors d'une nouvelle allocation des espaces mémoires qui viennent d'être libérés. Ce qu'un GC fait normalement il me semble.

Ils sont utiles pour libérer la mémoire lorsque cela est nécessaire, sans faire de fuite mémoire, ou sans double libération de la mémoire, mais ne permettent pas de diminuer le nombre d'allocation mémoire (appels systèmes).

[floyer]

Un malloc (C) ou new (C++) ne provoque pas nécessairement un appel système. La bibliothèque demande au système une quantité suffisante pour plusieurs allocations (il en est de même avec les langages avec GC... il faut bien demander au système de la mémoire pour en avoir).

En revanche, un malloc/new doit chercher un espace vide, là ou un langage avec GC place tout à la fin sachant qu’au GC, tout sera compacté. Un langage avec GC peut donc être très efficace s’il y a une multitude d’allocations (exemple : constitution d’une liste ou d’un arbre).

Les smart pointeur (share_pointer) utilisent simplement des compteurs... une structure récursive qui fait une boucle peut générer une fuite mémoire. Cependant, lorsque le compteur passe à 0, on a un « delete » automatique et la mémoire est réutilisable.

[Neckara]

Un malloc (C) ou new (C++) ne provoque pas nécessairement un appel système. La bibliothèque demande au système une quantité suffisante pour plusieurs allocations (il en est de même avec les langages avec GC... il faut bien demander au système de la mémoire pour en avoir).

Tu as plus de détails sur ça ?
Cela fonctionne comment ? Il alloue une page entière et va piocher dedans, ou il réserve, e.g. 2x la quantité de données demandée un peu comme std::vector ?


Je suis en train de regarder le fonctionnement de malloc, et en effet, il gère lui-même la mémoire disponible via une liste chaînée, un peu comme le fait les filesystèmes il me semble. Je pensais à tord que cette opération était faite via l'OS via un appel système.

[floyer]

Les appels systèmes ne font que des allocations par pages entières. De plus, comme c’est assez lent, malloc/new préfère faire des allocations de blocs importants qui serviront pour les malloc/new suivants.

En faisant une multitude de malloc(4), j’ai sous Linux, les appels systèmes :

brk(NULL) = 0x55b5629b1000
brk(0x55b5629d2000) = 0x55b5629d2000
brk(0x55b5629f3000) = 0x55b5629f3000
brk(0x55b562a14000) = 0x55b562a14000
brk(0x55b562a35000) = 0x55b562a35000
brk(0x55b562a56000) = 0x55b562a56000

Brk permet de changer la taille du processus et on voit que cela avance par pas de 132ko.

De plus, brk ne permet pas de rendre de la mémoire «*au milieu*», donc un free au milieu ne risque pas de libérer de la mémoire vu du système d’exploitation (la mémoire libérée par free peut servir à un autre malloc). De plus, il y a un seuil qui évite d’appeler brk pour réduire la quantité de mémoire dès le premier petit free placé à la fin.

Pour des allocations plus importantes, il y a mmap qui permet d’allouer des pages qui pourront être libérées indépendamment des autres allocations via munmap.

D’autres systèmes peuvent fonctionner autrement (ex que des mmap plus flexibles que brk pour libérer de la mémoire). L’implémentation de FreeBSD ne semble pas utiliser brk().

Au moins, comme le GC recomptacte tout, il est plus facile de libérer de la mémoire inutilisée.

[Invité]

le problème des langages objets c'est qu'il faut instancier en interne des tas d'objets que la Virtual Java Machine doit gérer lors de chaque opération.

Les langages objets ne se résument pas au modèle Java. En C++, on utilise le plus possible des objets alloués statiquement (sans new/delete) et le compilateur optimise ça aussi bien que si c'était des initialisations de variables et des appels de fonction.

En COBOL que je ne connais pas on accède directement aux disques,enregistrer des données d'un compte bancaire c'est quasiment octet sur octet.

Pour l'anecdote, il n'a pas que cobol dans le bancaire : Jane Street est un gros utilisateur de OCaml et Standard Chartered de Haskell.

[floyer]

Pour les appels de fonction liées aux objets C++, cela ne dépend pas de l’allocation (sur le tas avec new ou statiquement ou dans la pile autrement), mais uniquement du caractère «*virtuel*» de la méthode. Java ne supporte que des méthodes virtuelles (donc pas de virtual pour l’expliciter) et ne peut donc pas utiliser des appels de méthode optimisés.

Par ailleurs sur un langage avec GC on peut se contenter d’allouer n’importe quoi à la fin, ce qui est immédiat : juste un pointeur de fin à incrémenter.

[Pyramidev]

Java ne supporte que des méthodes virtuelles (donc pas de virtual pour l’expliciter) et ne peut donc pas utiliser des appels de méthode optimisés.

Tu oublies, entre autres, le cas des méthodes marquées avec le mot-clef final.

Voici des pages à propos de la machine virtuelle Java Hotspot :

https://wiki.openjdk.java.net/displa...anceTechniques

Extrait :

Static, private, final, and/or "special" invocations are easy to inline.

https://wiki.openjdk.java.net/displa...t/VirtualCalls

Extrait :

It is legal for an invokevirtual bytecode to refer to a final method. A final method need not have a vtable slot allocated. This means that, after linking, an invokevirtual bytecode might in fact collapse into the equivalent of an invokestatic bytecode. The interpreter is prepared to do this.

[el_slapper]

(.../...)Pour l'anecdote, il n'a pas que cobol dans le bancaire : Jane Street est un gros utilisateur de OCaml et Standard Chartered de Haskell.

Pour quelles applications? Moi, je parle essentiellement du noyau comptable et des éléments qui gravitent autour. Sinon, en salles de marché, en France, tu as surtout du C# et du VBA(avec un peu de F# ou de R). Et il y a encore d'autres domaines. Je serais curieux de savoir si c'est pour leur noyau comptable ou pas.

En outre, ils ne recrutent pas sur les mêmes critères - en informatique comptable, il faut avant tout des gens fiables(pour ne pas piquer dans la caisse). En informatique de marché, il faut avant tout des gens rapides(pour analyser plus vite que la concurrence). Ca explique aussi ce genre d'écarts de langages.