YBoy360 a écrit 713 commentaires

J'ajoute que la consommation électrique lié au transport, à la compression et décompression est plus élevée que pour Netflix, car il est simple de créer des caches chez les opérateurs pour Netflix. De plus, Netflix pourrait faire du broadcast pour les films les plus regardés, chose impossible pour le jeu vidéo.

Non, faible latence impossible de faire tourner sur un cloud en France un jeu pour un joueur en Corée..

Comme je l'ai dit, il n'y a pas de gains via mutualisation, au contraire, plus de ressources globales allouées. Car de toutes les manières tu as besoin d'une cg, donc ton jeu il va utiliser 2 cg.

Le cloud gaming made in MS, c'est même pas du full HD, en même pas 30 FPS. Mon Steam Deck fait fonctionner les jeux en HD à 60 FPS. Je joue avec les options en medium à 40 FPS pour consommer encore moins.

Le rapport performances par watt est gagnant, et crois le ou non, je ne joue plus en 4k sur ma machine de guerre, le Steam Deck propose un bien plus grand confort que mon pc. Hors nombre de pixels, et FPS dans certains jeux, il ne me sert plus qu'à travailler.

Dans l'empreinte écologique il faut aussi prendre en compte le transport de l'information avec une faible latence et le fonctionnement des algorithmes de compression décompression.

Il n'y a pas de mutualisation de carte graphique, puisqu'il en faut une pour afficher l'information à l'écran moins puissante, certe, mais même une carte graphique bas de gamme fait tourner les jeux aujourd'hui. Par exemple le Steam Deck sous Linux fait tourner les jeux dans de très bonnes conditions avec 15 watts pour le système, écran inclus…

Pour moi clairement ça n'est pas du tout écologique.

L'intérêt du pilote NVM Express est de montrer qu'il atteint presque les même performances que celle du pilote C existant.

Qu'est-ce qui permet de dire que ce serait lent ? J'ai beau aimer Java et le C, je vois pas ce qui en Rust ferait que c'est plus lent qu'en C…

Les performances devrait atteindre celle du C avec directives pragma (ça ne s'appelle plus comme cela maintenant, ce sont les __attribute__, __restrict__ de gcc par exemple), c'est à dire celle du C fait par des vrais, des développeurs du noyau, qui n'ont pas peur de se balader en tongs en hiver à Helsinki.

Le fait de donner plus de précisions au compilateur sur la gestion de la mémoire, comme on le ferait avec les directives du compilateur en C permet au contraire plus d'optimisations out of the box (comme on dit).

J'enrage aussi beaucoup contre Gradle, mais au final c'est un outil de dingue.

Juste un point :

Même configurés à fond de leurs capacités, les meilleurs IDE n’ont pas les moyens de donner des conseils pertinents.

Dans le cas de Gradle, il n'y a pas de support de l'IDE (du moins elle est empirique comme tu l'indiques), car les DLS statiquement typés de Groovy sont apparus après. La version Kotlin est statiquement typée de ce que j'en comprends (j'utilise très peu kotlin dans Gradle).

Pas mal des points que tu soulèves dépendent de ce problème, mais globalement je suis d'accord avec toi, tout système de build t'impose un cadre et des conventions, Gradle est gavé de conventions pas toujours claires, pour nos projets, ça pose bien des soucis.

Cela dit, lorsque l'on respecte ces conventions, on gagne finalement du temps. On peut aussi créer des extensions simplement, donc l'exotisme du build d'un projet particulier est un problème solvable selon moi, d'autant plus que les plugins Gradle récents sont faciles à lire (peut-être pas tous, mais c'est ce que j'ai constaté d'une manière générale).

Et le fait de respecter des conventions facilite le partage.

Pouvoir sur n'importe qu'elle OS, sans avoir a installer d'autres dépendances que Java faire :

$ ./gradlew shadowJar

Élimine bien des critiques (AMHA)..

D'autant plus qu'il y a des combo-multiples dans l'article en lien (bien que ce soit intéressant) :

• ça semble être spécifique à .Net (quoi que l'on doivent pouvoir pré-allouer dans la crèmerie d'en face) ;
• il y a des benchmarks, cool, qu'on comprend, mais les explications sont volontairement succinctes ;
• le code met les accolades aux mauvais endroits ;
• les conventions de nommage …

Bref, dommage qu'on ne soit pas vendredi, en effet… Si quelqu'un veut profiler tout ça pour la lecture du soir, ce serait sympa.

ça existe encore sur la Switch, non?

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

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.

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.

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.

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 :).

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.

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.

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…

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.