Je suis libéral et j'ai besoin d'aide

[L'affreux]

?

Ben dès que tu veux faire deux choses en même temps, en C, c'est la croix et la bannière avec une artillerie super pas pratique. Il y a des cas de verrous mortels inévitables, c'est à peu près intestable, etc. Les threads Java ou C# ont une syntaxe plus sympa mais toujours sur le même principe avec les mêmes inconvénients.

La programmation asynchrone sur un seul thread permet de faire du parallèlisme de manière bien moins aléatoire. Dans les versions récentes de JavaScript elle est devenue tellement pratique qu'on l'utilise pour tout tout le temps. Elle est de loin plus performante dès que le rôle du programme est de faire des I/O, ce qui est le cas de la plupart des projets informatiques.

[Noob]

C'est un avantage, ça, pas un inconvénient. Ça effarouche les nigauds.

en effet, mais crois moi que la théorie des catégories c'est pas mal non plus pour effaroucher les nigauds.

Et on est dans un autre univers en terme d'expressivité du code.

[h16]

Ben dès que tu veux faire deux choses en même temps, en C, c'est la croix et la bannière avec une artillerie super pas pratique. Il y a des cas de verrous mortels inévitables, c'est à peu près intestable, etc. Les threads Java ou C# ont une syntaxe plus sympa mais toujours sur le même principe avec les mêmes inconvénients.

La programmation asynchrone sur un seul thread permet de faire du parallèlisme de manière bien moins aléatoire. Dans les versions récentes de JavaScript elle est devenue tellement pratique qu'on l'utilise pour tout tout le temps. Elle est de loin plus performante dès que le rôle du programme est de faire des I/O, ce qui est le cas de la plupart des projets informatiques.

Ah ok, je ne voyais pas de quoi tu voulais parler.

Il y a quand même eu des progrès en matière de frameworks même en C, mais pour donner une idée, il faut bien voir que tous les moteurs de jeu (paye ton parallélisme) sont écrits en C ou C++ et ça marche plutôt pas mal.

[L'affreux]

Effectivement mais les jeux c'est clairement du calcul lourd, peu d'I/O.

Prends par exemple un cas de traitement simple : écrire un programme qui scanne un répertoire, puis charge les fichiers textes dedans, puis les affiche.

En programmation synchrone, voici la séquence :

 

lecture du répertoire (puis) lecture fichier 1 (puis) lecture fichier 2 (puis) ... lecture fichier N (puis) affichage

Le temps d'exécution total est la somme des temps des I/O plus epsilon (l'exécution des instructions du programme lui-même).

En asynchrone :

 

                             lecture fichier 1
lecture du répertoire (puis) lecture fichier 2 (puis) affichage
                             ...
                             lecture fichier N

Le temps d'exécution total est celui de la lecture du répertoire + celui du fichier le plus long plus epsilon (le programme lui-même). Sur un disque dur local, ça charge plus le disque bien sûr mais on y gagne du temps tout de même. Sur des I/O vers des machines distantes le programme synchrone se fait exploser.

Jusqu'à il y a peu, cette puissance de l'asynchrone était contrebalancée en JavaScript par une faiblesse de la syntaxe qui menait bien vite aux "callbacks hell" (et aux bugs). Ce n'est plus le cas. Maintenant ce langage est une tuerie. Et d'autant plus avec les typages de TypeScript.

[Noob]

Nous, on nous a pas laissé le choix ici. Mon chef ne jure que par le fortran. Donc tous les utilitaires maison sont codés en fortran.

Je m'en fous en fait. Je suis pas une codeuse, moi, c'est un outil, point barre. Et dans l'ensemble c'est un langage relativement correct à apprendre et gérable pour reprendre le code de quelqu'un d'autre et le modifier.

C'est vrai que pour tout ce qui est calcul numérique fortran a toujours eu une bonne réputation, mais j'ai tendance à penser que les langages comme le C ou même de plus haut niveau comme python qui délègues les calculs à des bibliothèques comme numpy/Lapack sont largement au point.  De toute façon à partir d'une certaine taille de problème le langage avec lequel tu interagis ne sert que de driver pour des opérations hyper optimisées fournies par un paquet de bibliothèques.

De la même manière que coder en C pour CUDA ou en python ça revient à peu près au même si c'est le le gpu qui est saturé en premier.

[h16]

Effectivement mais les jeux c'est clairement du calcul lourd, peu d'I/O.

Ahem broum broumahem non. Hint : c'est tellement i/o intensif qu'on a développé des cartes graphiques exprès. Et pour le disque dur, l'augmentation de la RAM a pas mal joué à compenser le chargement à la volée, mais ça n'a pas toujours été vrai et tout ce qui est streaming et cie., c'est aussi très io intensif.

[L'affreux]

Ahem broum broumahem non. Hint : c'est tellement i/o intensif qu'on a développé des cartes graphiques exprès.

Pas mon avis. Les I/O vers la mémoire vidéo ne sont pas le cœur du problème. Les jeux 3D c'est du calcul et les cartes graphiques déchargent le CPU d'une partie des calculs. Je ne suis pas joueur ni développeur de jeux, mais il me semble que lorsqu'on joue, la charge du CPU peut dépasser 25% ou même 50% et ça reste habituel. Ceux qui ont des cartes graphiques faibles chargent d'ailleurs encore plus leur CPU.

Si l'un de mes programmes fait monter le CPU à 10% je me pose des questions. Un programme de manipulation des I/O (vers une base de données, des fichiers, des Web services) passe son temps à glander.

EDIT: Cela dit, si comme je l'imagine les librairies modernes (WebGL...) fournissent des abstractions capables d'être traduites en ordres pour les cartes graphiques (donc des I/O) alors je prends le pari que JavaScript viendra aussi conquérir les jeux vidéos. Si tu veux un exemple dans la section "clients lourds", compare VS Code et WebStorm. JavaScript est sorti de son berceau Web et il a un solide appétit.

[Rübezahl]

C'est vrai que pour tout ce qui est calcul numérique fortran a toujours eu une bonne réputation, mais j'ai tendance à penser que les langages comme le C ou même de plus haut niveau comme python qui délègues les calculs à des bibliothèques comme numpy/Lapack sont largement au point.  De toute façon à partir d'une certaine taille de problème le langage avec lequel tu interagis ne sert que de driver pour des opérations hyper optimisées fournies par un paquet de bibliothèques.

Exactement le cas eg pour R.

De facto tu appelles des biblis C, ex calcul matriciel, fruit de centaines d'hommes/années de travail et hyper optimisées.

[Adrian]

Pour l'analyse numérique il y a Julia aussi en rapide

[h16]

Pas mon avis. Les I/O vers la mémoire vidéo ne sont pas le cœur du problème. Les jeux 3D c'est du calcul et les cartes graphiques déchargent le CPU d'une partie des calculs. Je ne suis pas joueur ni développeur de jeux, mais il me semble que lorsqu'on joue, la charge du CPU peut dépasser 25% ou même 50% et ça reste habituel. Ceux qui ont des cartes graphiques faibles chargent d'ailleurs encore plus leur CPU.

Qu'il y ait des calculs, c'est évident, mais la partie IO est très importante aussi. De nos jours, tout est préchargé en RAM (y'a des blobs de 1 ou 2 Go qui sont grimpés, mais ça, c'est de l'IO de base maousse au départ, là où il y a quelques années, c'était chargé à la volée). On peut aussi parler des jeux en "mondes ouverts" où le chargement du terrain est quasi permanent (donc i/o sur le disque quasi sans arrêt).

EDIT: Cela dit, si comme je l'imagine les librairies modernes (WebGL...) fournissent des abstractions capables d'être traduites en ordres pour les cartes graphiques (donc des I/O) alors je prends le pari que JavaScript viendra aussi conquérir les jeux vidéos. Si tu veux un exemple dans la section "clients lourds", compare VS Code et WebStorm. JavaScript est sorti de son berceau Web et il a un solide appétit.

Mhmmh on peut tout imaginer mais vu le pognon investi sur les moteurs en C (on parle en dizaines de millions d'euros sur chaque engine, hein), j'ai tendance à penser que la traduction de ces mêmes engines en js n'est pas pour tout de suite (et j'ai du mal à cerner l'intérêt).

[FabriceM]

Tout ça fait un bien vilain HS.

 

Et avec tout ça, personne n'a rebondit sur les magnifiques compétences du pole emploi.

 

Ces geeks. Incorrigibles. Toujours à rêver en code ASCII, à laisser leur testostérone se déchainer quand on attaque leur langage fétiche et à bander en revoyant leur code.

[L'affreux]

Qu'il y ait des calculs, c'est évident, mais la partie IO est très importante aussi. De nos jours, tout est préchargé en RAM (y'a des blobs de 1 ou 2 Go qui sont grimpés, mais ça, c'est de l'IO de base maousse au départ, là où il y a quelques années, c'était chargé à la volée). On peut aussi parler des jeux en "mondes ouverts" où le chargement du terrain est quasi permanent (donc i/o sur le disque quasi sans arrêt).

Certes mais les I/O vers la RAM ça ne compte pas ! Du moins pas pour comparer la programmation synchrone et asynchrone. L'accès à la RAM est toujours synchrone. Si un bout de code a besoin d'accéder à un buffer, bah il attend. Si on veut de la RAM asynchrone on se tourne par exemple vers Redis mais c'est autre chose.

 

(et j'ai du mal à cerner l'intérêt).

Yes.

Le déploiement sur tout supports y compris les navigateurs…

L'un des gros atouts de JS est certainement que les VM sont déjà installées partout.

En outre, c'est un sport d'équipe. Pas de dépendance de la plateforme vis-à-vis d'un méchant Oracle.

[ttoinou]

La programmation asynchrone sur un seul thread permet de faire du parallèlisme de manière bien moins aléatoire. Dans les versions récentes de JavaScript elle est devenue tellement pratique qu'on l'utilise pour tout tout le temps. Elle est de loin plus performante dès que le rôle du programme est de faire des I/O, ce qui est le cas de la plupart des projets informatiques.

 

Nodejs est monothreadé (même si tu as l'impression que tu fais de la prog asynchrone). A moins que tu ne parles des webworkers mais ce n'est pas encore très utilisé

 

EDIT : j'ai rien dis c'est plus compliqué ^^ en tout cas la complexité nous est cachée

[Mathieu_D]

Ces fourbes chez MongoDB il faut écrire les fonctions Mapreduce en Javascipt.

[h16]

Certes mais les I/O vers la RAM ça ne compte pas ! Du moins pas pour comparer la programmation synchrone et asynchrone. L'accès à la RAM est toujours synchrone.

Pour ta gouverne, in fine, l'accès à un disque est toujours synchrone. Si un bout de code veut des datas sur le disque, il attend son tour dans la file. Il n'y a qu'une écriture, ou une lecture à un moment donné.

[cedric.org]

Qu'il y ait des calculs, c'est évident, mais la partie IO est très importante aussi. De nos jours, tout est préchargé en RAM (y'a des blobs de 1 ou 2 Go qui sont grimpés, mais ça, c'est de l'IO de base maousse au départ, là où il y a quelques années, c'était chargé à la volée). On peut aussi parler des jeux en "mondes ouverts" où le chargement du terrain est quasi permanent (donc i/o sur le disque quasi sans arrêt).

Mhmmh on peut tout imaginer mais vu le pognon investi sur les moteurs en C (on parle en dizaines de millions d'euros sur chaque engine, hein), j'ai tendance à penser que la traduction de ces mêmes engines en js n'est pas pour tout de suite (et j'ai du mal à cerner l'intérêt).

Transpilation. Le futur n'est pas forcément full js, au contraire même.

[L'affreux]

Pour ta gouverne, in fine, l'accès à un disque est toujours synchrone. Si un bout de code veut des datas sur le disque, il attend son tour dans la file. Il n'y a qu'une écriture, ou une lecture à un moment donné.

Ah oui c'est juste.

La programmation asynchrone introduit une abstraction en fait.

Par exemple la fonction "fs.readFile" dans Node.js relaie nécessairement l'attente I/O sur un pool de threads.

Il faut voir une VM JS comme une sorte de bureau dans lequel tout est organisé pour qu'un seul gars (thread) soit capable d'abattre le travail fait habituellement par des centaines d'employés. Pour que ça marche, il délègue tout ce qui prend du temps. Et ce qui prend le plus de temps, ce sont les I/O, mais au fond le raccourci "asynchrone parce que I/O" est inexact. Asynchrone implique en fait : "entouré de pools de threads spécialisés".

Le JS est nécessairement construit sur des langages de plus bas niveau multithreadés, en pratique C ou C++. Ce mode d'organisation est néanmoins un nouveau paradigme. Il résout l'essentiel des soucis de la programmation parallèle : plus besoin de verrous (donc encore moins mortels), et un code testable dont l'exécution n'a plus rien d'aléatoire. Il offre une facilité dans l'organisation du parallélisme qui le rend supérieur, en performance, à la programmation synchrone multithreadée, pour une large gamme de besoins.

[h16]

Le JS est nécessairement construit sur des langages de plus bas niveau multithreadés, en pratique C ou C++. Ce mode d'organisation est néanmoins un nouveau paradigme. Il résout l'essentiel des soucis de la programmation parallèle : plus besoin de verrous (donc encore moins mortels), et un code testable dont l'exécution n'a plus rien d'aléatoire. Il offre une facilité dans l'organisation du parallélisme qui le rend supérieur, en performance, à la programmation synchrone multithreadée, pour une large gamme de besoins.

Oui, pour les choses comme les IHM, le web, etc... c'est clair qu'utiliser exclusivement du C, c'est trop lourd.