Arf non au contraire. J’ai souhaité préciser que si la sync est bien plus rapide avec durs c’est parce que rust est plus performant que nodejs, si je ne l’avais pas précisé on pourrait penser que j’ai mieux coder la sync que toi, ce dont je doute fort 
La compétition c’est pas mon truc 
1 Like
Oui mais je ne suis pas sûr que ce soit pour ça, l’algorithme utilisé joue un rôle majeur. Selon les opérations que je fais sur la synchro, je peux effectivement descendre à quelques secondes.
Par exemple il semble que tu stockes les DU dans un fichier à part, c’est peut-être justement là que tu gagnes beaucoup en performances (et ce serait bien vu ! je vais tester cela aussi).
Bof, l’algorithmie n’est pas le code, tu peux très bien avoir choisi un algo plus efficace. Et ce serait tant mieux, car je pourrais aussi en faire profiter DuniterTS.
Moi non plus ! Sauf quand c’est bon enfant, là j’aime beaucoup 
4 Likes
Je n’ai pas parallélisé au maximum, actuellement la sync prend 5,9 secondes sur mon pc, si je me fait chier a parallélisé au max je peut descendre en dessous de 3 secondes. mais je ne me ferai pas chier a le faire car de toute façon la phase de download prendra plus que 6 secondes don ce serait un gain inutile.
Ce que je veut dire c’est qu’a algo équivalent rust est forcément plus rapide que node.
C’est certainement vrai, quoique, mais en l’occurrence je pense que les algos sont très différents et donc que la comparaison n’était pas justifiée. J’ai vu ta remarque un peu comme du Node bashing, ce qui n’est justement pas un esprit bon enfant.
Ce qui est est perception fausse, mais pour comprendre ce point il faut étudier NodeJS et comprendre là où il est plus efficace que du C++ ou du Rust.
Les gars qui ont produit NodeJS ne l’ont pas fait pour JavaScript, il se trouve qu’ils ont prit ce langage mais c’est un peu un hasard et le fondement de ce projet est ailleurs.
1 Like
Note : j’ai déplacé ces posts sur un autre sujet pour éviter de polluer le sujet initial.
Je ne crache sur aucun langage, d’ailleurs j’ai pris plaisir a faire du Nodejs
Simplement, en vue des connaissances que j’ai de fondements de ses différents langages il me semble que Rust sera toujours plus rapide a algo équivalent car il fait des optimisations poussés jusqu’a niveau assembleur. Et aussi car il n’y a pas de runtime.
Donc aussi optimisée et efficace que soit la VM Node, elle perd forcément un temps à l’interprétation.
Ce qui permet en contre parti un codage plus simple et plus rapide. Comme je l’ai dit aux rml11, Rust a aussi sont lot d’inconvénients (long a coder, dur à apprendre). Il ne s’agit donc pas de confronter Rust et Node pour savoir si l’un serait mieux que l’autre, ils ont chacun leurs avantages et inconvénients.
Les gars de Node prétendent que non, précisément car les threads ont eux-mêmes un coût de création (CPU + mémoire).
Sur des applications à forte I/O, typiquement une application réseau, Node permet de tenir une charge plus importante que du Java précisément car le modèle standard en Java pour le web est 1 requête = 1 thread. Et pourtant Java est largement plus rapide que du JS à l’exécution.
Si donc Rust suit la même logique en créant des threads à tout va, il se peut qu’il ne soit pas toujours le plus rapide.
1 Like
Je ne connais pas les logiques Rust ou Node, mais un thread, ça se réutilise. Typiquement en java par des Executors plutôt que par du new Thread. 
1 Like
Cool, ce serait intéressant de faire des tests comparatifs sur une grosse quantité de requêtes réseau
Après Java possède un runtime et est beaucoup plus lent que du C++ c’est pourquoi il n’est pas utilisé pour les jeux temps réel par exemple. A voir donc, mais mon intuition me dit que le petit gain qu’obtient Node en ne gérant pas de threads ne compense pas sa perte en vitesse d’exécution face a du Rust.
Ceci étant, seul l’expérience nous permettra de le savoir !
1 Like
Pour la crate wot on à utilisé rayon, qui crée autant de threads qu’il y a de coeurs, répartie les taches sur chaqu’un des threads et fonctionne par work-stealing : si je n’ai plus de travail dans ma file d’attente, je vais piquer dans celle de mes voisins. C’est beaucoup plus efficace que la création d’un thread à tout va.
En fait, je ne sais même pas si Rust expose les threads dans sa bibliothèque standard 
Je pense que c’est plutôt différentes crates qui proposent différents fonctionnement au dessus des API système.
2 Likes
Voilà, il y a plein de choses possible à faire avec les threads. Go fonctionne encore différemment.
Au final un même algorithme peut être traité différemment selon le meta-algorithme qui le traite, qui lui joue avec les threads et les cœurs de la machine. Et les performances selon les cas d’utilisation pourront être très différentes.
Bref je ne vais pas épiloguer davantage ni même chercher à montrer qu’il est possible de trouver des cas où Rust est plus lent, seulement dire qu’il ne s’agit pas d’une espèce de Graal en termes de performances par le simple fait d’être une application Rust. Ce serait juste faux.
3 Likes
D’ailleur le borrowchecker de Rust et l’absence de GC est en même temps un avantage et un désavantage : il permet d’avoir du code safe et sans runtime, mais rend complexe (et demande l’utilisation de code unsafe) la réalisation de certaines structures de données disponibles dans d’autres langages. Chaque langage à ses spécificités, avantages et inconvénients.
Ben j’ai pas mal cherché parce que perso je n’y croyais pas, et a ce jours je n’ai pas encore trouver d’exemple ou Rust est plus lent, c’est… décontenançant
Si rust est top, même converti en webassembly, peut-être qu’un jour il y aura un Gvu en rust pour les script serveur + webassembly+webgl+webcl, le front également généré depuis rust…
Mais très longtemps avant ça, j’aurais écrit un hello-world en rust 
(et peutêtre quelques bench rust, go, nodejs, et es6, webassembly, webcl aussi).
Rdv dans 5 ans !
1 Like
C’est tellement ça 
1 Like
Après les deux mondes ne sont pas étanches. Si un morceau de l’implémentation en NodeJS bloque, il reste la possibilité d’y injecter un peu de Rust
Oui, d’ailleurs historiquement les parties intenses en utilisation CPU ont été écrites en C++ pour Duniter.
Mais Eloïs a déjà commencé à migrer le module de WoT en Rust.
1 Like
Il semble que les gars de Node est raison sur ce point, et d’ailleurs des dev de bibliothèques Rust en on tenu compte, pour preuve la description de la crate Rust ws que je vais utiliser pour WS2P :
This library provides an implementation of WebSockets, RFC6455 using MIO. It allows for handling multiple connections on a single thread, and even spawning new client connections on the same thread. This makes for very fast and resource efficient WebSockets.
NodeJS est-il vraiment singleThreaded ? Pas tout à fait on dirait. Y a crypto en exemple dans la vidéo.
Ignorez le fait que c’est un gars de Microsoft qui bosse sur un Mac pour promouvoir NodeJS.
Y a des gens bizarres partout.
En cherchant plus d’info, je suis tombé sur ce lien qui semble bien expliquer les particularités de l’Event Loop de NodeJS (gérée par la libuv).
https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
Bref, bien connaître les subtilités de son langage et faire du profilage aide à optimiser les performances.
HS : On a les mêmes problématiques en Python : https://www.youtube.com/watch?v=MCs5OvhV9S4
Des développeurs, car je suppose que ce ne sont pas toujours les mêmes. Quand ils en tiennent compte c’est tant mieux, quand ce n’est pas le cas des optimisations sont possibles.
Quoi qu’il en soit dès qu’il y a du code intense en CPU non géré par du C++ asynchrone derrière, NodeJS est vite à la ramasse en comparaison de C++ ou Rust. Typiquement pour le calcul de WoT.
J’ai aussi le cas au niveau de la synchro, car je fais massivement des insertion dans Loki qui est du code JS pur. Certes la synchro est réalisée une seule fois et donc ce n’est pas si gênant (je descend à 30’ maintenant), mais c’est révélateur de limites à utiliser du JS synchrone. Pour être le plus performant possible, il faut en fait utiliser … le moins de JS possible. 
1 Like