Salut à tous.
Désolé pour mes erreurs concernant le web dynamique alors que je savais que Node.js est coté serveur.
Mais quand on parle javascript, j'ai tendance à voir cela coté client.
destroyedlolo a écrit :Le code de l'interpréteur Lua est réentrant (une fois en mémoire, exécuté autant de fois que nécessaire).
La réentrance, c'est comme sur les gros systèmes IBM.
D'une part, il y a séparation entre la partie consacrée aux données et la partie instruction (l'exécutable).
D'autre part, on ne charge qu'une seule fois l'exécutable, mais autant de parties consacrées aux données qu'il y a de tâches ou d'instance comme on dit maintenant.
Bud Spencer a écrit :NodeSj n’est pas un interpréteur mais un compilateur jit ce qui fait une énorme différence.
JIT = just-in-time ou la compilation à la volée.
Bytecode = code intermédiaire entre les instructions machines et le code source, qui n'est pas directement exécutable.
D'accord, je comprends mieux. En fait, il y a compilation dans un pseudo langage et celui-ci est interprété puis exécuté.
Je connaissais ce principe qui a été élaboré pour la première fois avec le langage pascal.
En effet, le source est compilé dans un pseudo code, qui lui-même sera interprété sur la machine.
Et il est portable d'une machine à une autre car il n'y a que l'interpréteur à réécrire.
Bud Spencer a écrit :NodeJS est capable de traiter une multitude de taches différentes dans un même thread
Un thread, c'est une tâche en français.
Vous vouliez certainement dire, "NodeJS est capable de traiter une multitude de tâches différentes dans un même
processus".
Bud Spencer a écrit :des méthodes synchrone (en c, c++,php ou tout ce que tu eux d'autre) sont bloquantes à chaque attente. C'est ca la force et la particularité de NodeJS et aucun des langage que tu utilises ne fait ça.
C'est faux car je ne parle pas de méthodes synchrones quand je fais du 'c/c++', mais bien d'asynchrone.
A priori, Node.js n'est pas mieux que la programmation parallèle dite aussi concurrent programming en anglais.
Peut-être que l'écriture d'un programme est plus simple à mettre en oeuvre.
Bud Spencer a écrit :Il est monothread et nativement asynchrone donc il n'as pas besoin de créer autant de thread que de besoins simultanés,
S'il est mono tâche, le seule mode d'exécution est bien le synchrone, car une tâche dépend de la fin d’une autre tâche.
Bud Spencer a écrit :Pour en avoir fait en c++ pendant quelques années je peux te dire que c'est un sacré merdier à gérer.
J'en ai fait aussi, mais pas professionnellement, sous windows, et je n'ai pas trouvé cela si compliqué.
Il fait juste créer un moniteur, pour s'organiser autour de la gestion des tâches.
Pour ce faire, j'ai utilisé la technique du râteau, qui consiste à attendre la fin d'une multitude de tâche, pour entreprendre la suite.
Comme par exemple découper un calcul en sous-calcul et attendre la fin de ceux-ci pour faire la synthèse.
Bud Spencer a écrit :La scalabilité c'est la capacité qu'a ton programme a accuser de la charge sans broncher, ou en tous cas, le moins possible.
Normalement, c'est le système d'exploitation qui gère la pile des demandes, et doit donc être capable de faire du multithreading.
Par contre, pour éviter le goulot d'étranglement, voire le débordement de la pile, c'est l'application qui doit gérer cela.
Dans mon moniteur, je gérais le nombre de tâches qui devait s'exécuter ou être en attente, par l'usage des sémaphores.
Bud Spencer a écrit :L'exemple des latences de connexion a un sgdb en est un.
Il y a un goulot d'étranglement dans la gestion d'un SGBD.
Cela se traduit par "transaction-isolation = SERIALIZABLE" en MySql qui oblige de faire passer les requêtes les unes après les autres.
Cela dépend aussi comment le SGBD sait gérer ces concurrences. Ce n'est pas le cas de MySql, mais c'est le cas de Microsoft SQL Server.
Si c'est le cas alors oui, on peut avoir des traitements parallèles puisque les accès ne se font pas sur des "sections critiques".
Donc non, cela n'a rien à voir avec Node.js puisque le problème se situe dans le SGBD.
Bud Spencer a écrit :Faire du multiprocess ou du multithreading n'est pas par définition vraiment scalable puisque tu es de toutes façon obligé de limiter le nombre de thread ou de process pour ne pas que ton système s'effondre
C'est le cas de n'importe quel système d'exploitation puisque ceux-ci font du multithreading. En ces termes, le node.js ne peut pas être scalable.
Bud Spencer a écrit :Lent par rapport a quoi et pourquoi faire ?
J'ai fait un petit programme en 'C/C++' et un autre en Node.js qui font exactement la même chose.
Comparativement, le Node.js est beaucoup plus lent sur ma raspberry, peut-être à cause de la phase de démarrage.
Bud Spencer a écrit :Tu plaisantes ?
Pas du tout. Je parle du langage javascript, pas des autres framework qui reposent sur du javascript.
Même si le jquery repose sur du javascript, ce n'est pas pour autant du javascript puisque la syntaxe est différente.
-->
Penser ‘Thread’ pour simplifier vos programmes
J'ai vu votre excellent billet, en réponse de ce que vous aviez dit dans cet autre billet :
-->
La Saga Blink : Un Raspberry pour faire clignoter une LED !
Bud Spencer a écrit :Gérer proprement du multithreading en c++ n'est pas a la porté d'un débutant alors que ce genre de chose est très facile a faire avec NodeJS
J'aurai aimé voir votre version Node.js afin de le comparer avec l'exemple donné par "Patrice SEIBEL".
Bud Spencer a écrit :dire que nodejs est gourmand en quoi que soit, c'est du grand n'importe quoi
Je n'ai pas dit qu'il était gourmand mais lent. Et comme il est asynchrone, il n'est pas temps réel.
Bud Spencer a écrit :Visiblement, tu prévois juste de débuter en électronique (et je t'en félicite, tu vas voir, c'est génial), et tu ne connais absolument rien de NodeJS.
Je ne connais strictement rien en électronique et encore moins dans le langage Node.js.
J'ai fait un peu de Javascript dans le cadre du HTML dynamique, et c'est vrai, je n'ai pas du tout aimé ce langage.
Bud Spencer a écrit :Comment peux-tu prétendre que NodeJS ne se prête pas a l'électronique ?
Je n'ai pas dit cela. Je me pose simplement la question de la pertinence du choix de Node.js, que je ne connais pas, par rapport à un langage que je connais comme le 'C/C++' pour faire de l’électronique.
Bud Spencer a écrit :Va voir l'exemple du datalogger que j'ai mis dans le tuto des app dynamique.
Je l'ai déjà lu ! Et c'est vrai que ce sujet est fort intéressant.
Bud Spencer a écrit :Ca m'avait pris 2 ou 3 heures avec NodeJS. Combien de temps penses tu qu'il te faudrait pour arriver au meme résultat (si tu y arrives…) avec n'importe lequel des langages que tu utilises ?
Plus de temps certainement mais le problème, selon moi, n'est pas une question de temps mais de maîtrise de ce je désire entreprendre.
Comme je ne connais pas le langage Node.js, cela me sera plus pénible que de faire du 'C/C++'.
Bud Spencer a écrit :Pour répondre a ta question si il y a un intérêt à apprendre NodeJS, c'est a toi de juger pour toi.
Tu aurais dû commencer par là, l'intérêt de ce langage dans l'électronique.
Pour reprendre les propos de destroyedlolo, doit-je me concentrer sur Node.js ou bien sur LUA dans le cadre électronique, bien sûr ?
Bud Spencer a écrit :Je te dirais juste que si vraiment tu maîtrises le c, le c++ et le php, il n'y a pas grand chose à apprendre de plus syntaxiquement.
C'est déjà un point positif !
Bud Spencer a écrit :Le plus gros à faire, c'est de te familiariser avec son asynchronisme, c'est tout.
Tu voulais dire me familiariser avec la logique de l'écriture des programmes en Node.js.
@+