YBoy360 a écrit 756 commentaires

ça existe encore sur la Switch, non?

Moi, ce sont les modems qui me manquent. Ils feraient de la politique maintenant..

I use Arch BTW

Tu es bien péremptoire, ce n'est pas une question de dépendance, puisque l'un ne peut aller sans l'autre. Nous gratifions constamment le software, alors que le HW est considéré comme une "commodities". On laisse les chinois s'en occuper…

Pourtant, il y a bien plus d'évolution HW qu'il n'y en a en software. On sur-valorise dans le monde occidental d'après MS, le software, les start-up ne font quasi que du software, d'où le déclin qu'il prédit, car la valeur ajoutée au software ne sera plus significative.

Si on prend son exemple de réalisation d'un effet sur une photo, dans un smartphone, la partie logiciel responsable de cet effet, qui est commercialisée, est triviale, comparativement à la partie HW (qui est une commodities).

On pourrait faire un parallèle entre l'art abstrait et l'art figuratif, les chinois détestant l'art abstrait que les Américains ont imposé au 20eme siècle, au détriment des places européenne.

I use Arch BTW

J'adore cette vidéo, on dirait un Monty Python. La mise en scène dans son hôtel en Chine, sa démonstration qui n'a rien à voir avec le sujet, sa conclusion : le software est has-been parce qu'il y a des bugs, alors que ça commençait bien… Même ses exemples laissent à désirer : mon quotidien m'en montre bien plus. Il n'a pas grand chose à dire, mais il le fait, et finalement on regarde, jusqu'au bout, en ce qui me concerne.

Il n'est pas question de formulaires web, ou de certifier son application auprès de la FAA. Si on en reste au 1er degré, le message sous-jacent est que les évolutions software doivent tout au HW, et peu de choses au software en lui même. Et bien jamais on ne me prouvera le contraire. Voilà.. Faudra m'expliquer l'histoire des formulaires.

I use Arch BTW

Et si les formulaires des sites de PME de quartier que j'ai consultés aujourd'hui (avis et sky.fr) avaient pu fonctionner, je m'en porterai pas plus mal.

I use Arch BTW

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