En admettant une masse totale de la croute continentale de 2 x 10²² kg, une proportion d’uranium naturel dans la croute terrestre de 2,7 grammes par tonne (c’est beaucoup), une énergie de combustion de l’uranium naturel (après traitement et tout) de 5,6 x 10⁸ J/g et une irradiance solaire moyenne sur la surface de la Terre (nuit comprise) de 340 W/m². Si on imagine que par magie on récupère l’intégralité de l’uranium de la croute continentale (ce qui est une hypothèse absurde) et qu’on brule tout d’un coup dans des réacteurs nucléaires, on produit environ 3 x 10²⁸ joules. C’est l’équivalent de seulement 5000 ans d’irradiation solaire.
Quant à cette comparaison :
Un réacteur ne sert qu'à ralentir une explosion atomique et on produit l'énergie thermique d'une explosion entre chaque rechargement de combustible.
Elle est encore moins pertinente que si je disais : « Un bruleur de gazinière/chaudière a gaz ne sert qu’à ralentir une explosion de gaz, et on produit l’énergie thermique d’une explosion en permanence, en alimentant en permanence en combustible ». Je dis moins pertinent parce qu’il est effectivement possible de provoquer une explosion avec du gaz de ville ou en bouteille, alors que les technologies de réacteurs nucléaires civils ne permettent absolument pas de produire des explosions nucléaires – pour cela il faudrait quel le combustible soit beaucoup plus enrichi ; c’est d’ailleurs tout le sujet des discussions autour du nucléaire Iranien.
Quant au premier paragraphe, des affirmations sans sources ne valent rien.
Je ne dis pas qu’on ne doit pas s’opposer à des technologies. Je dis juste que si c’est le cas, il faut le faire avec des vrais arguments qui tiennent la route, et pas des dogmes tirés d’on ne sais où (enfin si, on sait d’où : des vielles associations antinucléaires militaire qui, voyant la dénucléarisation du monde, se sont attaquées au nucléaire civil sans se rendre compte que les arguments ne fonctionnent plus parce que les principes et conditions de fonctionnement ne sont pas les mêmes.
Comme déjà dit plus haut, c'est un nom propre (plus exactement un nom de marque) donc par définition il n'y a pas de faute dedans.
Pour répondre à la question « Pourquoi cette graphie » : le média s'appelait à l'origine (en aout 2000) INpact Hardware, avec cette graphie. Probablement parce que c'est un jeu de mots entre « impact » et « informatique », si j'en crois cette vieille interview.
Ensuite, INpact Hardware est devenu PC INpact, puis Next INpact, puis INpact Hardware a ressuscité en parallèle de Next INpact, puis est re-mort (son contenu a été fusionné dans Next INpact), et aujourd'hui Next INpact risque de disparaitre lui aussi.
Non, je me suis fait la même réflexion, mais j'ai pas le courage d'initier une vraie dépêche – si c'est juste pour mettre un titre en mode « démerdez-vous pour le contenu », pour moi c'est juste un manque de respect.
J'en lancerai une avec la traduction de l'annonce si j'ai le temps ce WE.
Ce dont tu parles a été testé avec brio en Finlande : fournir des logements pérennes aux sans-abris coute non moins cher que de les héberger en urgence. En plus, en leur fournissant un logement donc une adresse et des installations sanitaires, ça a beaucoup facilité leur réintégration dans la société.
La notion de « séparation des budgets » a aussi un gros impact.
Un exemple classique : la ville doit faire des travaux sur ses réseaux d’égouts, d’eau et d’électricité, dans un même trottoir. On sait ce que qui coute cher dans ces travaux, c’est d’ouvrir et refermer le trottoir, le reste c’est assez trivial.
Le problème étant que, comme les budgets « égouts », « réseau d’eau » et « réseau d’électricité » sont séparés et étanches, on va se retrouver à ouvrir et refermer ledit trottoir trois fois au lieu de mutualiser l’opération et de faire les trois remplacements des trois réseaux d’un coup. Avec tout ce que ça implique en terme de dépenses et d’emmerdement du voisinage.
Ça fonctionne pareil avec les travaux dans les batiments publics – pensez aux batiments historiques classés pour lesquels « démonter les boiseries pour accéder aux réseaux et y faire un travail trivial » coute une fortune.
Sans compter les budgets « qu’il faut absolument dépenser sinon on aura moins l’année prochaine », quitte à faire n’importe quoi avec (valable aussi dans le privé).
Ça existe vraiment les liseuses qui ont besoin d'un accès permanent (ou même au démarrage) à Internet ? Parce que pour moi ça casse quand même 95% de l'intérêt du truc.
L’un des problèmes avec les métiers de l’informatique dans des administrations, c’est que les salaires sont complètement déconnectés du marché du privé – à la fois parce que les paies dans le privé se sont envolées, et que les barèmes des fonctionnaires sont à peu près bloqués depuis des années.
Résultat, les quelques offres que je vois qui pourraient me concerner (développement/conception, > 10 ans d’expérience) sont complètement déconnectées du marché et proposent à peine un salaire de débutant pour des CDD. Résultat : même si le poste pourrait être intéressant, je ne postule pas tant je peux avoir mieux ailleurs. C’est pareil pour les postes orientés « connaissances métier appliquées à l’informatique ». Une ancienne collègue, sur un projet destiné à la fonction publique, a été démarchée par une entité publique pour faire le même genre de boulot que ce qu’elle faisait dans le public, et a refusé parce qu’elle aurait vu son salaire divisé quasiment par deux.
Une autre conséquence malheureuse, c’est que beaucoup de bons informaticiens fuient la fonction publique… avec ce que ça veut implique pour beaucoup de ceux qui restent : quelques-uns de bons et suffisamment attachés à la fonction publique pour rester malgré les conditions, et beaucoup d’anciens plus à jour, ou de trop mauvais pour être embauchés dans le privé. C’est l’une des (trop nombreuses) conditions qui fait aussi que, en tant qu’entreprise privée, travaillera avec le public est généralement une purge – avec les paiements ultra tardifs, l’immense résistance au changement, la politique à tous les étages et les lourdeurs administratives.
De mon côté j'ai plein d'expériences et de témoignages contraires : si tu vas voir directement les contrôleurs directement après être monté dans le train c'est bon (mais ton billet te coûtera plus cher pour cause de "frais d'émission à bord du train"). Par contre si tu attends qu'ils contrôlent, là c'est trop tard. Et ils rappellent souvent à l'occasion des contrôles : en cas de problème connu avec le billet (genre tu sais que tu n'en as pas…) si tu viens les chercher c'est OK, si tu attends qu'ils passent ils partent du principe que tu as fraudé.
Ceci n'est valable que pour la SNCF ; les TER sont adossés aux régions et peuvent avoir des règles différentes.
Encore faut-il qu’il y ait un « ailleurs » qui recrute… ce qui n’est pas forcément le cas dans le ferroviaire, selon où tu habites.
D’autre part : oui, la SNCF perds massivement des employés au profit de la concurrence (qu’elle soit elle-même ferroviaire, ou d’autres industries qui emploient les mêmes métiers, dans les cas où ça s’applique).
La SNCF recrute énormément, dans tous les domaines et partout en France. C’est l’occasion pour qui veut de se trouver un poste dans cette « planque de branleurs qui passent leur vie à faire grève », d’après certains. Ou de se rendre compte que les conditions de travail proposées ne sont peut-être pas si géniales que ça, et que certaines grèves sont peut-être bien justifiées.
Pour la petite histoire, j'ai utilisé ab parce que c'est ce que j'avais sous la main. Comme l'observation du comportement de l'application testée me montrait que l'application était bien limitée par le CPU avec cet outil, je n'ai pas eu besoin d'aller plus loin.
Mais effectivement pour des langages plus performants (en particulier dès que l'application testée est multithreadée) ab ne suffit plus, comme mentionné dans le journal.
Ça montre aussi que lancer des tests sans surveiller le comportement de l'application ne sert à rien, puisque ça ne permet pas d'en déduire quoi que ce soit quand aux résultats observés.
Enfin, le simple terme "tenir la charge" n'a pas de sens en soi. Par exemple ici, il faudrait vraiment un programme très créatif pour qu'il soit incapable de tenir la charge réelle qui va lui être demandée, même en imaginant l'héberger sur une brouette comme un premier Rapsberry Pi. En ce sens, un programme comme ab peut très bien prouver que les performances mesurées sont "très largement suffisantes", même si faussées parce qu'on atteint les limites de l'outil de mesure.
Non mais ça c’est un cas particulier pour une seule classe, dans la vie c’est un usage ultra-minoritaire de Java, et ça n’est absolument pas de ce cas dont je parle…
Il existe donc réellement des personnes qui utilisent des makefiles avec Java ?
Personnellement je ne me rappelle plus la dernière fois ou j’ai utilisé autre chose que Maven, Gradle ou très rarement Ant. Et oui, ce couplage à des toolings lourdingues peut clairement être listé dans les inconvénients de Java.
Ensuite ça n’est pas la question. Elle n’est pas de « chercher la solution la plus simple pour répondre au besoin » mais précisément de « vérifier si Java est vraiment une usine à gaz pour ce genre de cas ».
Je confirme, la classe date de Java 6 mais est peu utilisée. D’une part parce qu’elle est d’assez bas niveau et donc peu pratique pour des projets un peu complexe, d’autre part parce que c’est une API en com.sun.* que beaucoup de gens (y compris des outils automatiques !) confondent avec une API en sun.*, ces dernières ne devant pas être utilisées parce que privées (et supprimées des dernières versions de Java). Les API en com.sun.* sont pourtant standard (on les retrouve dans toutes les implémentations de Java, mêmes celles historiquement IBM) et sont simplement déconseillées dans quelques usages précis.
J’ai fait aussi un test rapide avec des outils plus « industriels » pour ce genre d’application (un microserveur minimaliste), comme vert.x. On a un peu moins de code un peu plus clair, et des performances sensiblement identiques (même la consommation RAM, ce qui m’a surpris). C’est aussi un facteur qui explique le manque d’intérêt pour HttpServer.
Je n’ai pas lancé le benchmark PHP, parce que j’ai complètement la flemme d’installer PHP juste pour ça sur le nouveau serveur, et de configurer un nouvel endpoint qui réponde en HTTP(non S) juste pour ça. Je sais juste que la version actuelle est « très largement suffisante en conditions réelles ».
D’ailleurs, j’ai dit une connerie, elle ne fait pas 3 lignes mais 2 – il n’y a bas de balise fermante :
Et c’est lancé avec un proxy socket Unix vers PHP-FPM.
La métrique du nombre de lignes était là parce que l’une des critiques très souvent faites à Java est que c’est un langage verbeux. Ça s’entends bien sûr en tant que « lignes correctement formatées », pas des one-liners idiots.
Pas de quoi, on la retrouve encore très souvent (y compris dans des prétendus « papiers de recherche sur l’état de l’art de la performance de la JVM », qui perdent d’un coup pas mal de crédibilité).
Cf les commentaires de l'article sur Zeste de Savoir : tout dépend de ce que tu appelles beaucoup plus efficace. En consommation RAM, plutôt oui. En débit en sortie ou en complexité de code, pas tant que ça (si, y'a une implémentation en C/C++ qui est beaucoup plus rapide mais beaucoup plus complexe).
Tu saurais dire quel processeur tu as, et l'occupation CPU que tu obtiens pendant le test ? Ça m'étonne de voir une telle différence alors que les deux programmes tournent sur des JVM.
Il faudrait regarder la consommation CPU et mémoire du serveur Python.
Sur les implémentations mono-thread, Java est à la louche 1.5x à 2x plus lent que les implémentations compilées. Par contre, les implémentations peuvent être multi-thread par défaut, ce qui fait très vite monter les performances mesurées si on ne fait pas gaffe.
Certes, mais les années 90, c’est plus « il y a 25 ans » que « il y a 15 ans », et le web a énormément changé entre ces deux dates. L’optimisation à mort du web dans les années 90, clairement oui. Au milieu des années 2000, c’était déjà beaucoup moins le cas.
[^] # Re: VErdissement
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Le label « vert » européen n'est plus réservé aux énergies renouvelables. Évalué à 3.
Deux ordres de grandeur :
Quant à cette comparaison :
Elle est encore moins pertinente que si je disais : « Un bruleur de gazinière/chaudière a gaz ne sert qu’à ralentir une explosion de gaz, et on produit l’énergie thermique d’une explosion en permanence, en alimentant en permanence en combustible ». Je dis moins pertinent parce qu’il est effectivement possible de provoquer une explosion avec du gaz de ville ou en bouteille, alors que les technologies de réacteurs nucléaires civils ne permettent absolument pas de produire des explosions nucléaires – pour cela il faudrait quel le combustible soit beaucoup plus enrichi ; c’est d’ailleurs tout le sujet des discussions autour du nucléaire Iranien.
Quant au premier paragraphe, des affirmations sans sources ne valent rien.
Je ne dis pas qu’on ne doit pas s’opposer à des technologies. Je dis juste que si c’est le cas, il faut le faire avec des vrais arguments qui tiennent la route, et pas des dogmes tirés d’on ne sais où (enfin si, on sait d’où : des vielles associations antinucléaires militaire qui, voyant la dénucléarisation du monde, se sont attaquées au nucléaire civil sans se rendre compte que les arguments ne fonctionnent plus parce que les principes et conditions de fonctionnement ne sont pas les mêmes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Inportent
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Next INpact lance un S.O.S.. Évalué à 10.
Comme déjà dit plus haut, c'est un nom propre (plus exactement un nom de marque) donc par définition il n'y a pas de faute dedans.
Pour répondre à la question « Pourquoi cette graphie » : le média s'appelait à l'origine (en aout 2000) INpact Hardware, avec cette graphie. Probablement parce que c'est un jeu de mots entre « impact » et « informatique », si j'en crois cette vieille interview.
Ensuite, INpact Hardware est devenu PC INpact, puis Next INpact, puis INpact Hardware a ressuscité en parallèle de Next INpact, puis est re-mort (son contenu a été fusionné dans Next INpact), et aujourd'hui Next INpact risque de disparaitre lui aussi.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et aussi…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Darktable 4.0.0 est sorti. Évalué à 5.
Non, je me suis fait la même réflexion, mais j'ai pas le courage d'initier une vraie dépêche – si c'est juste pour mettre un titre en mode « démerdez-vous pour le contenu », pour moi c'est juste un manque de respect.
J'en lancerai une avec la traduction de l'annonce si j'ai le temps ce WE.
La connaissance libre : https://zestedesavoir.com
# Et aussi…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Darktable 4.0.0 est sorti. Évalué à 4.
Quelques mots en français, et des vidéos de présentation des nouveautés : https://darktable.fr/posts/2022/07/darktable-4-0-0/
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un problème d’adéquation avec le marché privé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Doctolib présente sa base de données à Devoxx 2022 et c'est flippant. Évalué à 7.
Ce dont tu parles a été testé avec brio en Finlande : fournir des logements pérennes aux sans-abris coute non moins cher que de les héberger en urgence. En plus, en leur fournissant un logement donc une adresse et des installations sanitaires, ça a beaucoup facilité leur réintégration dans la société.
La notion de « séparation des budgets » a aussi un gros impact.
Un exemple classique : la ville doit faire des travaux sur ses réseaux d’égouts, d’eau et d’électricité, dans un même trottoir. On sait ce que qui coute cher dans ces travaux, c’est d’ouvrir et refermer le trottoir, le reste c’est assez trivial.
Le problème étant que, comme les budgets « égouts », « réseau d’eau » et « réseau d’électricité » sont séparés et étanches, on va se retrouver à ouvrir et refermer ledit trottoir trois fois au lieu de mutualiser l’opération et de faire les trois remplacements des trois réseaux d’un coup. Avec tout ce que ça implique en terme de dépenses et d’emmerdement du voisinage.
Ça fonctionne pareil avec les travaux dans les batiments publics – pensez aux batiments historiques classés pour lesquels « démonter les boiseries pour accéder aux réseaux et y faire un travail trivial » coute une fortune.
Sans compter les budgets « qu’il faut absolument dépenser sinon on aura moins l’année prochaine », quitte à faire n’importe quoi avec (valable aussi dans le privé).
La connaissance libre : https://zestedesavoir.com
# C’est un wrapper autour de JavaScriptCore
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Bun, un autre interpréteur javascript en Zig. Évalué à 4.
Cf https://github.com/Jarred-Sumner/bun#Reference
Au moins ça change des wrappers autour de V8 :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Minitel 3.0
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Panne générale sur Office 365 ?. Évalué à 8.
Ça existe vraiment les liseuses qui ont besoin d'un accès permanent (ou même au démarrage) à Internet ? Parce que pour moi ça casse quand même 95% de l'intérêt du truc.
La connaissance libre : https://zestedesavoir.com
[^] # Un problème d’adéquation avec le marché privé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Doctolib présente sa base de données à Devoxx 2022 et c'est flippant. Évalué à 6.
L’un des problèmes avec les métiers de l’informatique dans des administrations, c’est que les salaires sont complètement déconnectés du marché du privé – à la fois parce que les paies dans le privé se sont envolées, et que les barèmes des fonctionnaires sont à peu près bloqués depuis des années.
Résultat, les quelques offres que je vois qui pourraient me concerner (développement/conception, > 10 ans d’expérience) sont complètement déconnectées du marché et proposent à peine un salaire de débutant pour des CDD. Résultat : même si le poste pourrait être intéressant, je ne postule pas tant je peux avoir mieux ailleurs. C’est pareil pour les postes orientés « connaissances métier appliquées à l’informatique ». Une ancienne collègue, sur un projet destiné à la fonction publique, a été démarchée par une entité publique pour faire le même genre de boulot que ce qu’elle faisait dans le public, et a refusé parce qu’elle aurait vu son salaire divisé quasiment par deux.
Une autre conséquence malheureuse, c’est que beaucoup de bons informaticiens fuient la fonction publique… avec ce que ça veut implique pour beaucoup de ceux qui restent : quelques-uns de bons et suffisamment attachés à la fonction publique pour rester malgré les conditions, et beaucoup d’anciens plus à jour, ou de trop mauvais pour être embauchés dans le privé. C’est l’une des (trop nombreuses) conditions qui fait aussi que, en tant qu’entreprise privée, travaillera avec le public est généralement une purge – avec les paiements ultra tardifs, l’immense résistance au changement, la politique à tous les étages et les lourdeurs administratives.
La connaissance libre : https://zestedesavoir.com
[^] # Re: PV assuré
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Testons la concurrence à la concurrence à la SNCF. Évalué à 6.
De mon côté j'ai plein d'expériences et de témoignages contraires : si tu vas voir directement les contrôleurs directement après être monté dans le train c'est bon (mais ton billet te coûtera plus cher pour cause de "frais d'émission à bord du train"). Par contre si tu attends qu'ils contrôlent, là c'est trop tard. Et ils rappellent souvent à l'occasion des contrôles : en cas de problème connu avec le billet (genre tu sais que tu n'en as pas…) si tu viens les chercher c'est OK, si tu attends qu'ils passent ils partent du principe que tu as fraudé.
Ceci n'est valable que pour la SNCF ; les TER sont adossés aux régions et peuvent avoir des règles différentes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La SNCF recrute énormément, dans tous les domaines et partout en France
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Testons la concurrence à la SNCF. Évalué à 7.
Encore faut-il qu’il y ait un « ailleurs » qui recrute… ce qui n’est pas forcément le cas dans le ferroviaire, selon où tu habites.
D’autre part : oui, la SNCF perds massivement des employés au profit de la concurrence (qu’elle soit elle-même ferroviaire, ou d’autres industries qui emploient les mêmes métiers, dans les cas où ça s’applique).
La connaissance libre : https://zestedesavoir.com
# La SNCF recrute énormément, dans tous les domaines et partout en France
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Testons la concurrence à la SNCF. Évalué à 10.
La SNCF recrute énormément, dans tous les domaines et partout en France. C’est l’occasion pour qui veut de se trouver un poste dans cette « planque de branleurs qui passent leur vie à faire grève », d’après certains. Ou de se rendre compte que les conditions de travail proposées ne sont peut-être pas si géniales que ça, et que certaines grèves sont peut-être bien justifiées.
La connaissance libre : https://zestedesavoir.com
[^] # Re: ab = mauvais
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Pour la petite histoire, j'ai utilisé
abparce que c'est ce que j'avais sous la main. Comme l'observation du comportement de l'application testée me montrait que l'application était bien limitée par le CPU avec cet outil, je n'ai pas eu besoin d'aller plus loin.Mais effectivement pour des langages plus performants (en particulier dès que l'application testée est multithreadée)
abne suffit plus, comme mentionné dans le journal.Ça montre aussi que lancer des tests sans surveiller le comportement de l'application ne sert à rien, puisque ça ne permet pas d'en déduire quoi que ce soit quand aux résultats observés.
Enfin, le simple terme "tenir la charge" n'a pas de sens en soi. Par exemple ici, il faudrait vraiment un programme très créatif pour qu'il soit incapable de tenir la charge réelle qui va lui être demandée, même en imaginant l'héberger sur une brouette comme un premier Rapsberry Pi. En ce sens, un programme comme
abpeut très bien prouver que les performances mesurées sont "très largement suffisantes", même si faussées parce qu'on atteint les limites de l'outil de mesure.La connaissance libre : https://zestedesavoir.com
[^] # Re: Version Rust
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 2. Dernière modification le 14 juin 2022 à 17:37.
Non mais ça c’est un cas particulier pour une seule classe, dans la vie c’est un usage ultra-minoritaire de Java, et ça n’est absolument pas de ce cas dont je parle…
La connaissance libre : https://zestedesavoir.com
[^] # Re: Version Rust
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Il existe donc réellement des personnes qui utilisent des makefiles avec Java ?
Personnellement je ne me rappelle plus la dernière fois ou j’ai utilisé autre chose que Maven, Gradle ou très rarement Ant. Et oui, ce couplage à des toolings lourdingues peut clairement être listé dans les inconvénients de Java.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pourquoi une redirection?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 6.
Pour commencer, j’utilise Nginx et pas Apache.
Ensuite ça n’est pas la question. Elle n’est pas de « chercher la solution la plus simple pour répondre au besoin » mais précisément de « vérifier si Java est vraiment une usine à gaz pour ce genre de cas ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Record
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Peut-être, mais pour moi ça sort de ce qu'est censé être un Record.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java pur ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Je confirme, la classe date de Java 6 mais est peu utilisée. D’une part parce qu’elle est d’assez bas niveau et donc peu pratique pour des projets un peu complexe, d’autre part parce que c’est une API en
com.sun.*que beaucoup de gens (y compris des outils automatiques !) confondent avec une API ensun.*, ces dernières ne devant pas être utilisées parce que privées (et supprimées des dernières versions de Java). Les API encom.sun.*sont pourtant standard (on les retrouve dans toutes les implémentations de Java, mêmes celles historiquement IBM) et sont simplement déconseillées dans quelques usages précis.J’ai fait aussi un test rapide avec des outils plus « industriels » pour ce genre d’application (un microserveur minimaliste), comme vert.x. On a un peu moins de code un peu plus clair, et des performances sensiblement identiques (même la consommation RAM, ce qui m’a surpris). C’est aussi un facteur qui explique le manque d’intérêt pour
HttpServer.La connaissance libre : https://zestedesavoir.com
[^] # Re: PHP ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Je n’ai pas lancé le benchmark PHP, parce que j’ai complètement la flemme d’installer PHP juste pour ça sur le nouveau serveur, et de configurer un nouvel endpoint qui réponde en HTTP(non S) juste pour ça. Je sais juste que la version actuelle est « très largement suffisante en conditions réelles ».
D’ailleurs, j’ai dit une connerie, elle ne fait pas 3 lignes mais 2 – il n’y a bas de balise fermante :
Et c’est lancé avec un proxy socket Unix vers PHP-FPM.
La métrique du nombre de lignes était là parce que l’une des critiques très souvent faites à Java est que c’est un langage verbeux. Ça s’entends bien sûr en tant que « lignes correctement formatées », pas des one-liners idiots.
La connaissance libre : https://zestedesavoir.com
[^] # Re: native-image
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Pas de quoi, on la retrouve encore très souvent (y compris dans des prétendus « papiers de recherche sur l’état de l’art de la performance de la JVM », qui perdent d’un coup pas mal de crédibilité).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Rust et C
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 5.
Cf les commentaires de l'article sur Zeste de Savoir : tout dépend de ce que tu appelles beaucoup plus efficace. En consommation RAM, plutôt oui. En débit en sortie ou en complexité de code, pas tant que ça (si, y'a une implémentation en C/C++ qui est beaucoup plus rapide mais beaucoup plus complexe).
La connaissance libre : https://zestedesavoir.com
[^] # Re: native-image
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4. Dernière modification le 13 juin 2022 à 14:19.
L'option
-server(s'il s'agit bien d'elle) ne sert plus à rien sur les JVM HotSpot et dérivées 64 bits, la JVM "server" est la seule qui existe encore.Et j'ai la flemme d'installer PHP sur le nouveau serveur et d'autoriser une connexion en HTTP simple pour faire le test.
La connaissance libre : https://zestedesavoir.com
[^] # Re: En groovy (sans optimisations)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4.
Personnellement je dois explicitement définir l'exécuteur pour que mon code devienne multithread. C'est une ligne à ajouter, mais sans elle le code est monothread (GC exclus).
La connaissance libre : https://zestedesavoir.com
[^] # Re: En groovy (sans optimisations)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Tu saurais dire quel processeur tu as, et l'occupation CPU que tu obtiens pendant le test ? Ça m'étonne de voir une telle différence alors que les deux programmes tournent sur des JVM.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est beaucoup ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 3.
Il faudrait regarder la consommation CPU et mémoire du serveur Python.
Sur les implémentations mono-thread, Java est à la louche 1.5x à 2x plus lent que les implémentations compilées. Par contre, les implémentations peuvent être multi-thread par défaut, ce qui fait très vite monter les performances mesurées si on ne fait pas gaffe.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Tristitude ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Comment s’appelle ce design web ?. Évalué à 3. Dernière modification le 13 juin 2022 à 12:17.
Certes, mais les années 90, c’est plus « il y a 25 ans » que « il y a 15 ans », et le web a énormément changé entre ces deux dates. L’optimisation à mort du web dans les années 90, clairement oui. Au milieu des années 2000, c’était déjà beaucoup moins le cas.
La connaissance libre : https://zestedesavoir.com