YBoy360 a écrit 727 commentaires

C'est un résumé un peu succinct, le gars en question à commis Braid, ce qu'il dit n'est pas totalement infondé, ne serait-ce que pour cette raison :).

I use Arch BTW

Quelle JVM usitlises-tu ?

Il y a eut beaucoup d'amélioration concernant le RPi, celle par défaut n'est pas performante.

Les tél Android ne sont pas tellement plus puissant qu'un RPi, les applications ne mettent pas beaucoup de temps pour se lancer.

I use Arch BTW

Juste pour te donner un ordre d'idée, nous optimisions la façon dont les bibliothèques étaient chargées, et à froid, sans charger de modèle, CATIA V5 c'est 1,6 Gio dans la RAM. Je ne connais pas de logiciel plus conséquent… en 2005, en 32-bit.

I use Arch BTW

C'était il y a longtemps, Android c'est Linux (du C), avec un Desktop et un runtime en C. Il doit y avoir du C++, mais ce n'est pas la majorité du code.

Je pense par exemple que Freecad est plus long à compiler (ou Chromium, voir KDE). Moi je parlais de CATIA V4 et V5, DELMIA, Enovia, avec les test-cases, et c'était il y a plus de 15 ans (mais sur des machines sur-puissantes, avec 8 CPU)… Il y avait 85 000 binaires à recompiler et à linker … En plus de cela, certains outils utilisé par des gros client (PSA, Renault, WV, Ford, Airbus ..) étaient développés par dessus CATIA, et les clients n'avaient pas nécessairement les sources. Par contre, ça doit linker, ton compilateur et les options que tu choisis doivent ne pas changer, ou ne pas modifier l'ABI. Il y avait des dépendances cycliques (à la Rust, pas de formward déclaration en Rust), qui t'obligeait à linker 2 fois.

C'était le panard, j'ai pris mon pied à faire de l'optimisation CPU et GPU, avec un CPU moins puissant, on éclatait Intel, IBM and co. Bref, c'était tout une époque.. Je voulais m'occuper du portage Linux, je ne sais pas ou s'en est. Billou à donné un très TRÈS gros chèque pour nous faire partir…

I use Arch BTW

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.

I use Arch BTW

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.

I use Arch BTW

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.

I use Arch BTW

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.

I use Arch BTW

À 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.

I use Arch BTW

Je suis sceptique

I use Arch BTW

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.

I use Arch BTW

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 …

I use Arch BTW

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…

I use Arch BTW

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.

I use Arch BTW

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.

I use Arch BTW

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.

I use Arch BTW

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.

I use Arch BTW

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…

I use Arch BTW

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)

I use Arch BTW

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.

I use Arch BTW

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

I use Arch BTW

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 ?

I use Arch BTW

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.

I use Arch BTW

À 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.

I use Arch BTW

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

I use Arch BTW