YBoy360 a écrit 673 commentaires

De mon expérience chez ESI Group, Dassault System et Sun Microsystems (ça date, mais le but était d'optimiser au max …):

• Taille du binaire bien plus importante (peut-être problématique sur les gros programmes genre CATIA, car l'augmentation de taille n'a pas d'impacte sur de petits programmes) ;
• Le compilateur est coincé pour certaines optimisations (chez Dassault, on déconseillait les returns, il n'en fallait qu'un par méthode) ;
• Très mauvais d'abuser des exceptions dans un cadre multi-threadé (voir C++ exceptions are becoming more and more problematic) ;
• Grandes disparités dans la façon de gérer les exceptions en fonction de la plateforme ;
• …

Je ne veux pas dire de bêtises, j'ajouterai la compatibilité binaire (snif) encore plus complexe à maintenir sur les très très gros projets, où l'on n'a pas accès à toutes les sources et où l'on ne compile jamais tout sur 1 seule machine.

Sauf que cela date de bien avant l'existence de Google cette pratique, et qu'elle est totalement justifiée.

Ça froisse peut-être les adorateurs de stroutproute.. Désolé pour eux.

Qt est encore plus stricte. Les vrais dev n'utilise pas d'exception en C++, ni de rtti. C'est un problème d'implémentation par les compilateurs. Pas un problème lié au langage. Je ne te fais pas la leçon.

Moi le truc qui m'horripile bien plus que le gâchis d'énergie, qui m'horripile déjà pas mal, c'est l'artificialisation des sols, bien plus nocive sur le long et très long terme que les gaz à effet de serre (selon moi). Le gouvernement impose aux communes 0 m2 net de sol artificiel pour 2030, je trouve cela très courageux, fasse à tous les élus locaux (écolo ou pas) qui sont poussés par les promoteurs immobiliers (argent très facile, il suffit de rendre une terre agricole constructible et basta, x10 dans la poche, ils peuvent collectionner les belles voitures et les montrer à Turbo, avec leurs potes les notaires).

Voir un hyper, avec parking non enterré, qui va vider la ville pour annexer des hectares de terre agricole en maisons individuelles mal isolées … La boucle est bouclé.

Nous ne nous rendons pas compte de l'importance des carences de l'agriculture en France, nous exportons du blé (pollution), importons de la viande qui consomme ce blé (pollution), nous sommes dépendant de l'extérieur, car des économistes dans les années 80 ont totalement délaissé le secteur agricole, ou l'on apprenait que l'agriculture et l'industrie devaient laisser place au secteur tertiaire et aux "services" (les gens dans des bureaux et tout fonctionne…). Aujourd'hui, on est même pas capable de subvenir à nos besoins en graines de moutarde, demain, en cas de crise agricole sévère, les gens qui descendront dans la rue seront vraiment énervés. L'on peut se passer de pas mal de chose, mais pas longtemps de ne pas manger.

À voir, si Dart avait pu tuer le JavaScript, je m'en porterai pas plus mal… Heureusement pour certains, on est pas obligé de tuer pour survivre. Chacun sa place.

Je suis sceptique

Pour faire des optimisations pendant le runtime?

J'anticipe, pourquoi laisser gérer la mémoire automatiquement : pour pouvoir la défragmenter au runtime? Pour optimiser les accès contiguë, pour éviter des tlb misses, pour faire du prefetch…

La mémoire virtuelle a à voir, question de point de vue. Certaines plateforme ne gère pas la mémoire virtuelle de façon câblée, elle peut être programmable, elle peut ralentir les accès mémoire (je parle de la gestion de l'adresse, pas du temps d'accès memoire)… Ça n'est pas totalement différent.

Tu as 16 cœurs ?

Oui, soit 32 thread HW (2 thread par cœur). Je l'ai acheté pour le "работаю" y a pas longtemps …

Et sur ta machine, quel est le temps CPU en mono-thread des processus Java, wrk avec Java, puis Rust, et enfin wrk avec Rust ?

Le test avec ab me donne quasi es mêmes résultats.

Lorsque je fais un vmstat (je sais c'est grossier), voici en gros le temps cpu avec la version Java multi-thread:

procs ----------mémoire---------- -échange- -----io---- -système- ------cpu-----
 r  b   swpd  libre tampon  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 22876588 169192 3754992    0    0     0   120 2752 3430  0  0 100  0  0
 5  0      0 22853456 169192 3755752    0    0     0     0 31732 282378  5  8 87  0  0
 4  0      0 22855772 169192 3755272    0    0     0     0 25935 356583  3  9 88  0  0
 4  0      0 22850504 169192 3755536    0    0     0     0 27205 375689  3  9 88  0  0
 4  0      0 22847880 169200 3755536    0    0     0   128 26307 392497  3  9 88  0  0
 4  0      0 22854760 169200 3755696    0    0     0     0 26645 387530  3  9 88  0  0
 5  0      0 22858052 169208 3755152    0    0     0    48 26583 382465  3  9 87  0  0
 3  0      0 22861584 169208 3756016    0    0     0     0 29299 367593  3 10 87  0  0
 4  0      0 22865088 169208 3755664    0    0     0     0 26797 309219  4  9 87  0  0
 4  0      0 22857348 169208 3755216    0    0     0    76 27135 322763  4  9 87  0  0
 4  0      0 22866680 169208 3755856    0    0     0   100 25179 384999  3  9 87  0  0
 0  0      0 22867748 169208 3754832    0    0     0     0 9974 98889  1  2 97  0  0

Le CPU n'est occupé qu'a 12 %, et wrk prend autant de temps CPU que le processus Java…

Chez moi, wrk prend 30 % de temps CPU de plus que le processus Java. Difficile donc de déduire quoi que ce soit, quelque soit le nombre de thread que je choisisse, la limite semble identique et le temps CPU pratiquement constant.

Ce que l'on peut dire, c'est que ce bench est mal parallélisé en Java, avec ce code.

En version mono-thread:

Requests/sec:  43544.29
Transfer/sec:      5.92MB

En multi-thread:

Requests/sec:  76680.75
Transfer/sec:     10.43MB

J'utilise les paramètres par défaut pour la JVM. Pour passer en version multi-thread, voici le code:

package fr.spacefox.avatar;

import com.sun.net.httpserver.HttpServer;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.util.Random;

public class AvatarHttpServer {

    private final Random random = new Random();
    private final int port;
    private final int imgCount;

    public AvatarHttpServer(final int port, final int imgCount) {
        this.port = port;
        this.imgCount = imgCount;
    }

    public void run() throws IOException {
        var server = HttpServer.create(new InetSocketAddress(port), 0);
        server.createContext("/", exchange -> {
            exchange.getResponseHeaders().add(
                    "Location",
                    "https://avatar.spacefox.fr/Renard-" + (random.nextInt(imgCount) + 1) + ".png");
            exchange.sendResponseHeaders(302, -1);
        });
        server.setExecutor(java.util.concurrent.Executors.newCachedThreadPool());
        //server.setExecutor(java.util.concurrent.Executors.newFixedThreadPool(16));
        server.start();
    }

    public static void main(String[] args) throws IOException {
        new AvatarHttpServer(Integer.parseInt(args[0]), Integer.parseInt(args[1])).run();
    }
}

que j'ai repris du précédant journal.

La JVM va maximiser le "Throughput" (ou débit), au détriment de la charge CPU et mémoire. Elle va tout faire pour aller le plus vite possible, quitte à recompiler le code à la volé (charge CPU supplémentaire), ou ne pas désallouer lorsque la mémoire n'est plus utilisée.

C'est complexe à faire avec d'autres langages qui vont chercher à maximiser la vitesse, sans doute en utilisant moins de ressources.

Oui, globalement d'accord, le résultat dépend grandement de la Jvm et donc prévisible. Seule la section :

exchange -> {
     exchange.getResponseHeaders().add(
          "Location",
          "https://avatar.spacefox.fr/Renard-" + (random.nextInt(imgCount) + 1) + ".png");
          exchange.sendResponseHeaders(302, -1);
     }

s'exécute à chaque requête. Difficile d'optimiser le code, on peut jouer seulement sur les paramètres de la JVM. Cela dit, je ne sais pas si le contexte est multi-threadé ou non. J'ai testé pour le fun avec Graalvm, aucune différence.

En quoi est-ce pire ?

N'as t-on pas le droit d'utiliser le langage que l'on veut sur la JVM ?

À part complexifier l'utilisation de GraalVM, je vois pas d’inconvénients…

La pertinence de ce test vient du fait que ce n'est pas le même parseur que celui de Java, même si la syntaxe est compatible, tu n'as pas besoin de compiler (même si tu peux le faire), et contrairement aux idées reçues, ce n'est pas tellement plus lent pour une application de type serveur. L'exemple ne se prête pas aux démonstration pédantique de syntaxe.

Et tu as pas mal d'apport potentiel lié à Groovy… Comme les DSL.

J'ai un CPU très rapide par rapport à son enveloppe thermique (105 watts) :

$ cat /proc/cpuinfo
. . .
processor       : 31
vendor_id       : AuthenticAMD
cpu family      : 25
model           : 33
model name      : AMD Ryzen 9 5950X 16-Core Processor
stepping        : 2
microcode       : 0xa201205
cpu MHz         : 3276.090
. . .

Clairement le CPU utilise plus d'un core. Si j'ai le temps, j'essaierais de voir si c'est le GC qui utilisent toutes les autres threads… Es-tu sûr que ce soit mono-threadé hors GC ? Je n'ai pas bien compris l'explication.

Sur la documentation de Class HttpServer ce n'est pas monothreadé de ce que je comprends…

Pour info, après un second round (j’exécute le tout dans Intellij, avec pleins de choses ouvertes, comme Steam):

Requests per second:    44935.38 [#/sec] (mean)

Dans Main.groovy

import com.sun.net.httpserver.HttpServer
import groovy.transform.CompileStatic

@CompileStatic
static void run(int port, int imgCount) {
  final random = new Random()
  final server = HttpServer.create(new InetSocketAddress(port), 0)
  server.createContext("/", exchange -> {
    exchange.getResponseHeaders().add(
            "Location",
            "https://avatar.spacefox.fr/Renard-" + (random.nextInt(imgCount) + 1) + ".png")
    exchange.sendResponseHeaders(302, -1)
  })
  server.start()
}

final port = Integer.parseInt(args[0])
final imgCount = Integer.parseInt(args[1])
run(port, imgCount)

Pour le démarrer, j'utilise Groovy 4.0.3 :

export JAVA_HOME=~/.jdks/corretto-17.0.3/
$GROOVY_INSTALL/bin/groovy src/main/groovy/Main.groovy 6666 21

Requests per second: 39136.05 #/sec

j't'éclate ton serveur… Mais merci quand même.

Autant pour moi, ce n'est pas du https..

Et en https, ça donne quoi ?

Il faudrait tester exactement le même programme et sur la même machine. Que donne le programme Java sur ta machine ?

J'ai pris ma journée d'hier à installer HoloISO.

C'est la distribution de la Steam Deck, extraite à partir de l'image recovery de la console, sur un de mes PC avec une carte ATIAMD.

Cette distribution est basée sur Arch Linux. Je voulais bidouiller un peu pour bidouiller ensuite la console (et oui, j'en ai une), après installation, tout marche sur ce PC.

Cette distribution utilise Xorg et Plasma 5.23 et boot sur l'environnement gaming de la console. En modifiant la configuration de SDDM pour booter sur Plasma, et celle de Pacman pour ajouter les sources officielles (et kde-testing), Et bah encore une fois, tout marche : Plasma 5.24.90, avec Wayland et OBS Studio (0,2 % de CPU pour l'enregistrement d'un écran 4K …), SAUF l’environnement de la console.

Ce qui m'a impressionné :
- Pas de changement de contexte Framebuffer <-> Wayland Ou serveur X au boot;
- Temps mis pour booter depuis grub est vraiment faible ;
- Et Plasma 5.25 beta, c'est une tuerie …

Je passe sur l'utilisation de Proton en version expérimentale (ça fonctionne vraiment très bien sur les jeux Windows, 4K60FPS sur les quelques gros jeux que j'ai pu tester, avec Mesa), la principale différence avec une Arch classique, c'est juste que les miroirs de Valves ont des versions figées, et un repo pour l’environnement desktop "console".

J'admire la façon dont ça a été fait. Rien à dire, je pensais au début qu'il y aurait du custom dans tous les sens, en fait, c'est une Arch avec Steam et Proton, point. J'aurais aussi pu installer une Arch classique, mais je voulais tester l'image de la console.

À partir du moment où un langage te permet de créer un module noyau, ou être utiliser dans un firmware, c'est du bas niveau. Cela dit, le C++ dispose aussi de bibliothèques de haut niveau, tel Qt, qui ajoute au C++ les signaux /slots par exemple (mais est-ce du C++ ?).

Un langage de haut niveau, en plus d'être peu recommandable pour le développement de firmware, devrait te permettre limiter l'accès aux ressources systèmes, définir le degré l'isolation des bibliothèques nativement, gérer ses dépendances comme un grand, qu'il soit "sécurisable" directement par l'administrateur ou l'utilisateur simplement, et pas par le développeur. Il y en a bien un, ça commence par J et ça fini par a, mais c'est plus une plateforme qu'un langage.

Tu devrais remplacer Java et Go par PHP dans ton commentaire… ça serait déjà pas mal.

Je sais pas trop ce que tu veux dire par « aspect performance », mais lancer une exception c’est loin d’être cheap, le stack unwinding, capturer la stack trace etc a un coût certain. En pratique, pour beaucoup d’application, ça va pas faire une différence notable, mais c’est pas gratuit, que ce soit en c++ ou en java.

Il y a 2 aspects liés à la gestion des exceptions :

• le coût d'une levée d'exception, comme tu le signales,
• le coût de gestion de celles-ci dans le binaire (binaire plus gros).

En C++, le coût de gestion était élevé à mon époque, tout le monde n'activait pas la gestion de celles-ci (d'où des incompatibilités sur certaines plateformes). En gros, ça revient à ajouter des return spéciaux supplémentaires, et l'une des règles de codage en C++ était de minimiser le nombre de return dans le corps des méthodes. Je crois qu'en Java, le coût de gestion est plus négligeable car il peut y avoir des optimisations au runtime, et la Jvm est stack-based (un peu comme du C++ sur du x86), donc peu d'impact d'un return.

Le lancement d'une exception dans le cas normal arrive rarement. Donc même si le coût est élevé, tu perds au final peu de performances. C'est différent de systématiquement encapsuler ton résultat. Mais oui, c'est pas forcément significatif en terme d'impacte sur la plupart du code que l'on rencontre.

En Java, tu es obligé d'attraper la plupart des exceptions.

Pas en Groovy. Dans le cadre d'un serveur d'application qui intègre un connecteur FreeCAD, Solr, LibreOffice, sans compter la gestion des données persistantes, la problématique de la sécurité, la validation des données… c'est peut-être un avantage. Tu n'as certainement pas envie de traiter tous les cas de figure si le formulaire contient un fichier à uploader et peu lever un nombre d'exception conséquent lors de la sauvegarde de ce formulaire.

D'ailleurs, vu par l'utilisateur, le cas ou une exception est non catchée sur un serveur d'application c'est que la requête retourne un code 501 et que les données persistantes ne sont pas modifiées. C'est donc "limité". L'application continue de tourner. C'est difficile d'anticiper un comportement correcte suite à certaines erreurs. Moi, c'est mon tél ou ma boite mail qui vont recevoir les insultes, personne ne va en mourir dans mon cas (à moins d'être susceptible ou dépressif). Mais je ne vois pas comment on peut faire mieux.

Il n'y a quasiment pas de try … catch dans notre code, excepté pour ne pas interrompre l'initialisation du serveur si l'erreur est tolérable, lors de l'initialisation des services, lorsque le service est initialisé AVANT son utilisation (pas de lazy-init). Bref, au final, je n'ai pas quasiment pas de code de gestion d'erreur, mais nombre d'erreur soit sont traitées par le framework lui-même, soit on ne peut rien en faire et seulement prévenir l'administrateur…

C'est inspirant cette façon de faire des présentations… 1h pour ne pas faire de try catch.

Ce qui est intéressant c'est la volonté de formuler tous les cas de figure pour la gestion d'erreurs et d'y associer une syntaxe.

Ce qui me gène avec cette approche :

• l'aspect performance, on ne retourne pas directement un résultat, mais un objet virtuel, qui contient soit le résultat, soit une erreur. C'est un inconvénient par rapport au fait de dissocier le résultat et l'erreur ;
• "do or do not, there is no try", j'ai besoin de savoir pourquoi ;
• Au final je ne trouve pas forcément la syntax simple ;
• Enfin et surtout, la validation des données N'EST PAS une erreur.

En ce qui me concerne, nous utilisons groovy et Java, qui propose avec les enum des possibilités proches. Pour le cas présenter (validation d'un objet, sequence de traitement, gestion des erreurs associées) :

• La validation des données nécessite un validator dans la classe implémentant l'objet, aucun cas de gestion de cette aspect n'apparait dans le code métier, c'est le FW qui décore les actions pour retourner l'information à l'utilisateur ;
• Le reste sont des exceptions.

Les exceptions constituent les erreurs non prévisibles, comme un problème réseau, disque plein, et d'autres aspect, comme la sécurité. Je comprends mal l'intérêt de ne pas utiliser les exceptions..

Je n'ai pas bien compris ce qu'était une gestion élégante d'erreur avec un union une interface encapsulant 2 types…

Ce n'est pas plus propre de séparer le résultat et la gestion d'erreur ?