Non pas du tout justement, puisque AlphaZero est plus fort que Alpha Go. Le programme consiste en un parcours d'arbre, un système de deep learning, et les règles du jeu, c'est tout.
Il n'est absolument pas question de traitement de masse, tu as 20 ans de retard. Le traitement de masse c'était deep blue d'IBM (minmax amélioré). Lors d'une partie, Deep blue évlue des millions de fois plus de position par seconde que Alpha Zero (parcours d'arbre montecarlo (?) avec statistique trouvé par apprentissage). Celui-ci est pourtant infiniment meilleur joueur.
L'article de l'express est assez mauvais. On dirait que l'auteur a une vision très très vague de ce qu'est le machine learning et le deep learning. Il en tire des conclusions qui sortent de nul part.
"La véritable IA n'existera jamais, car le monde est inconnaissable."
"Il n'est pas rationnel d'être à 100% rationnel, or un ordinateur est à 100% rationnel."
"Ceux qui tireront leur épingle du jeu seront ceux qui continueront d'ajouter de la valeur. … Bref, de tous les métiers relevant de la création. "
Comme si une large de part de la création n'était pas simplement un agrégat de solution existante adapté aux contraintes externe !
Et c'est le travail de l'éditeur de liens : il scanne les .o et construit un arbre de dépendance pour n'inclure dans les exécutables que le code effectivement appelé. C'est pour ça que (avec certains linkers anciens), il fallait spécifier deux fois des .a (ou .lib) en cas de dépendances tordues…
De mémoire, les linkers ne scannaient rien du tout, il ne faisait qu’agglomérer les .o que l'on lui donnait, et donnait une adresse mémoire au objet du .o.
Si un programme "Hello World" qui ne demande qu'un "printf" se retrouve lié statiquement avec une bibliothèque de plusieurs Mo, pour le coup, c'est du code mort facilement éliminable en liant uniquemnt "printf" et ses fonctions dépendantes.
Justement non. Ce n'est pas simple. Historiquement les compilateurs fonctionnaient toujours par morceau pour gérer la pénurie de mémoire des ordinateur (d'où les .o du C). Pour enlever les fonctions inutiles, il faut être capable de détecter toutes les appels de fonction en scannant le code entier. J'imagine qu'aujourd'hui on doit pouvoir décortiquer en mémoire, un programme entier, mais cela donne forcément une taille limite.
Je me rappelle d'un hello-world avec une boite de dialogue en Lisaac, celui-ci, comme le go, récupérait tout le code et en faisait de la bouillis. Au final, le binaire faisait 12ko.
Je propose de ne garder que la section "titre" qui devient cliquable. Je propose d'ajouter un "+" devant le lien pour dérouler le contenu actuel qui est situer en dessous.
Pour réduire la taille des binaires, il faut être capable de détecter le code objet inutile. En toute logique, Go (golang) possède toutes l'information pour faire le ménage. Encore faut-il accepter le surcout à la compilation.
Je suis un peu dubitatif sur la taille verticale que prend un "lien" sur mon écran large. J'imagine qu'il ne doit pas être difficile de faire une organisation plus "en table", 4 liens à l'écran à la fois, c'est très peu.
C'est totalement pifométrique, mais d'idée que je me fais d'un recyclage des appareils électroniques dans le futur, c'est une énorme broyeuse qui te produit de très fines particules qui sont ensuite triées pour former un "minerais" enrichi dans tel ou tel composé. Ça me parait plus viable qu'un démontage manuel qui ne permet pas de résoudre le problème.
Le trie serait du pure délire vu le nombre de matières différentes.
Vous connaissez http://www.horizon-computing.com/ ? Il poste régulièrement ici. Ils sont orienté serveur, vous devriez partagé des trucs, ils font aussi de l'open hardware.
Dans l'idée, cela serait plus un portable mieux recyclable que la moyenne ont on aurait besoin. Cela me fait penser à des matelas, dont les couches de mousses n'étaient plus collés pour être mieux recyclable en fin de vie.
Je préfère la version précédente avec le module "masse storage" à mettre dans un PC. Ou d'avoir un cordon SATA pour booter le pc de bureau.
Communication en Wi-Fi ac entre écrans et base Open Computer en mode mobilité
Je ne comprends pas, on parle de "hdmi sans fil" ou de wifi IP, parce que dans ce cas, tous les softs ont a être écrit. Au mieux, tu peux faire du client serveur entre la tablette et le socle, mais bon, je ne sais pas si wayland par le réseau fonctionne, et si xfree fonctionne encore et si il fonctionne avec du tactile.
Les machins modulaires ont un problème de base : les connecteurs coutent une blinde. Donc, c'est difficile de justifier autre chose qu'un connecteur ultra-standard (DRAM, SATA, PCIe, USB).
Par contre, si vous faites des portables, il y a un truc vraiment génial à faire. On a besoin de mobilité 20% du temps, avoir son PC avec soi, en réunion, à l'extérieur. Le reste du temps, on bosse à son bureau. Or l’extrême mobilité (PC de 1 kg et pas une brique de 3 kg sans alim) est incompatible avec de la grosse puissance de calcul (cpu de 25W, vs 95W). Certain gère ça avec 2 machines, mais il faut dupliquer l'ensemble de son espace de travail, ce qui est très très très chiant. L'idéal serait de bénéficier des mêmes données et des mêmes logiciels entre les 2 machines.
En gros, le portable deviendrait le disque dur principal d'un PC de bureau.
Justement, le fait que go ne fasse qu'un seul binaire sans dépendance facilite surtout la vie d'un serveur. C'est un des problèmes que voulaient régler les ingénieurs Google qui codaient avant en C++.
Les outils pourraient être écrit en ocaml, c'est le cas de nombreux compilateurs. Mais j'imagine que la complexité qui pourrait être géré par Ocaml n'est pas assez grande dans ce genre d'outil pour justifier le surcout de développement. Ensuite, il me semble que Rust dispose de beaucoup des constructions sympa fonctionnelles.
Go n'est pas fait pour ça. Go, c'est pour faire du serveur web applicatif, pas un outils en ligne de commande, même si c'est possible, bien sûr.
Je n'avais pas pensé à ce cas de figure, bien sûr, je pensais à transmettre un message complet par channel pour ne surtout pas avoir de partage de mémoire. C'est le principe de base du partage par message.
Avez-vous expliqué le problème, ici :https://blog.golang.org/toward-go2 ou même pour le go actuel ? Faire un "deep cloning", pour le passage par référence, est quand même une sacré bonne raison.
Mais Rust a un avantage sans prix : La thread safety garantie à la compilation, ce que Go ne pourra jamais offrir.
Comment ils font ça ? Avec go, si on utilise que les channels pour communiquer entre goroutine et pas de lock, il n'y a pas de problème potentiel.
Le cas général, est complexe surtout si on rajoute le garbage collector au milieu. Un des moyens serait d'envoyer des bouts de mémoire en lecture seul, et transmettre la gestion de ce bout de mémoire pour le détruire. Il existe une théorie dont j'ai oublié le nom qui permet de faire ça, mais cela rend le code très complexe (à chaque affectation, la sémantique est que la donnée est transmise et n'existe plus dans la variable d'origine).
Pour m'y mettre depuis 1 an, go est vraiment puissant. Son système de typage par interface permet une réutilisation dingue. L'exemple typique sont des lib évoluées qui utilisent l'interface de base des mux http. Ainsi on peut injecter le tout dans une autre lib qui ne connait que la lib de base.
Pour moi, il manque surtout des types sommes (ou union en Rust).
Il est fait pour écrire des serveurs web applicatif qui monte bien en charge. En dehors de ce cas d'usage, il n'est pas l'ultime solution.
Une fonction cyclique est une fonction qui est exécutée toutes les millisecondes par exemple.
Si ton nombre de threads est lié au nombre de requêtes que tu reçois, tu augmente la latence avec l'augmentation du nombre de requêtes.
A moins d'avoir un sacré bon scheduler, l'augmentation ne sera pas linéaire du tout. Une fois que n est bien plus grand que le nombre de cpu, "l'overhead" de gestion grandit avec le nombre de changements de contexte, etc…
[^] # Re: L'ordinateur est rationnel, et alors ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 5.
Non pas du tout justement, puisque AlphaZero est plus fort que Alpha Go. Le programme consiste en un parcours d'arbre, un système de deep learning, et les règles du jeu, c'est tout.
"La première sécurité est la liberté"
[^] # Re: Bêtise naturelle
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 6.
Il n'est absolument pas question de traitement de masse, tu as 20 ans de retard. Le traitement de masse c'était deep blue d'IBM (minmax amélioré). Lors d'une partie, Deep blue évlue des millions de fois plus de position par seconde que Alpha Zero (parcours d'arbre montecarlo (?) avec statistique trouvé par apprentissage). Celui-ci est pourtant infiniment meilleur joueur.
"La première sécurité est la liberté"
[^] # Re: L'ordinateur est rationnel, et alors ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 3.
Comment expliques-tu alors la créativité de alphazero dans le jeu d'échec et de Go ?
"La première sécurité est la liberté"
# mauvais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 10.
L'article de l'express est assez mauvais. On dirait que l'auteur a une vision très très vague de ce qu'est le machine learning et le deep learning. Il en tire des conclusions qui sortent de nul part.
Comme si une large de part de la création n'était pas simplement un agrégat de solution existante adapté aux contraintes externe !
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
De mémoire, les linkers ne scannaient rien du tout, il ne faisait qu’agglomérer les .o que l'on lui donnait, et donnait une adresse mémoire au objet du .o.
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
Justement non. Ce n'est pas simple. Historiquement les compilateurs fonctionnaient toujours par morceau pour gérer la pénurie de mémoire des ordinateur (d'où les .o du C). Pour enlever les fonctions inutiles, il faut être capable de détecter toutes les appels de fonction en scannant le code entier. J'imagine qu'aujourd'hui on doit pouvoir décortiquer en mémoire, un programme entier, mais cela donne forcément une taille limite.
Je me rappelle d'un hello-world avec une boite de dialogue en Lisaac, celui-ci, comme le go, récupérait tout le code et en faisait de la bouillis. Au final, le binaire faisait 12ko.
"La première sécurité est la liberté"
[^] # Re: taille verticale ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment la rubrique « liens » est arrivée. Évalué à 5.
Je propose de ne garder que la section "titre" qui devient cliquable. Je propose d'ajouter un "+" devant le lien pour dérouler le contenu actuel qui est situer en dessous.
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
Il faut retrouver l'histoire de dev de GOLD le nouveau linker de GCC qui fait ses optimisations de code mort. C'est un problème assez complexe.
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
Pour réduire la taille des binaires, il faut être capable de détecter le code objet inutile. En toute logique, Go (golang) possède toutes l'information pour faire le ménage. Encore faut-il accepter le surcout à la compilation.
"La première sécurité est la liberté"
# taille verticale ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment la rubrique « liens » est arrivée. Évalué à 6.
Je suis un peu dubitatif sur la taille verticale que prend un "lien" sur mon écran large. J'imagine qu'il ne doit pas être difficile de faire une organisation plus "en table", 4 liens à l'écran à la fois, c'est très peu.
"La première sécurité est la liberté"
[^] # Re: Réparation, à quel coût?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Présentation de l’Open Computer : un ordinateur portable Modulaire sous GNU/Linux. Évalué à 5.
Le trie serait du pure délire vu le nombre de matières différentes.
"La première sécurité est la liberté"
[^] # Re: Comme de bien entendu
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Présentation de l’Open Computer : un ordinateur portable Modulaire sous GNU/Linux. Évalué à 7.
Vous connaissez http://www.horizon-computing.com/ ? Il poste régulièrement ici. Ils sont orienté serveur, vous devriez partagé des trucs, ils font aussi de l'open hardware.
cf par exemple le bios libre : https://linuxfr.org/users/vejmarie/journaux/l-epopee-nerf
https://linuxfr.org/users/vejmarie
"La première sécurité est la liberté"
[^] # Re: Réparation, à quel coût?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Présentation de l’Open Computer : un ordinateur portable Modulaire sous GNU/Linux. Évalué à 3.
Dans l'idée, cela serait plus un portable mieux recyclable que la moyenne ont on aurait besoin. Cela me fait penser à des matelas, dont les couches de mousses n'étaient plus collés pour être mieux recyclable en fin de vie.
"La première sécurité est la liberté"
[^] # Re: innovations
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Présentation de l’Open Computer : un ordinateur portable Modulaire sous GNU/Linux. Évalué à 5.
C'est plus de l'usage tablette que PC.
Je préfère la version précédente avec le module "masse storage" à mettre dans un PC. Ou d'avoir un cordon SATA pour booter le pc de bureau.
Je ne comprends pas, on parle de "hdmi sans fil" ou de wifi IP, parce que dans ce cas, tous les softs ont a être écrit. Au mieux, tu peux faire du client serveur entre la tablette et le socle, mais bon, je ne sais pas si wayland par le réseau fonctionne, et si xfree fonctionne encore et si il fonctionne avec du tactile.
"La première sécurité est la liberté"
# innovations
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Présentation de l’Open Computer : un ordinateur portable Modulaire sous GNU/Linux. Évalué à 10.
Les machins modulaires ont un problème de base : les connecteurs coutent une blinde. Donc, c'est difficile de justifier autre chose qu'un connecteur ultra-standard (DRAM, SATA, PCIe, USB).
Par contre, si vous faites des portables, il y a un truc vraiment génial à faire. On a besoin de mobilité 20% du temps, avoir son PC avec soi, en réunion, à l'extérieur. Le reste du temps, on bosse à son bureau. Or l’extrême mobilité (PC de 1 kg et pas une brique de 3 kg sans alim) est incompatible avec de la grosse puissance de calcul (cpu de 25W, vs 95W). Certain gère ça avec 2 machines, mais il faut dupliquer l'ensemble de son espace de travail, ce qui est très très très chiant. L'idéal serait de bénéficier des mêmes données et des mêmes logiciels entre les 2 machines.
En gros, le portable deviendrait le disque dur principal d'un PC de bureau.
"La première sécurité est la liberté"
[^] # Re: Multi-licences pour plaire à tout le monde, c'est possible ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utilité des CLA quand on fait du libre et que du libre. Évalué à 4.
Oui, c'est pas mal. Je crois que c'est mozila qui avait commencé avec les double ou triple licence.
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 6.
Justement, le fait que go ne fasse qu'un seul binaire sans dépendance facilite surtout la vie d'un serveur. C'est un des problèmes que voulaient régler les ingénieurs Google qui codaient avant en C++.
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 5.
Ce que je veux dire c'est que la communauté autour du langage, et les bibliothèques disponibles sont très axé web.
Mais c'est un langage générique, on peut tout faire avec, le travail sera simplement moins prémâché.
"La première sécurité est la liberté"
# langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 1.
Les outils pourraient être écrit en ocaml, c'est le cas de nombreux compilateurs. Mais j'imagine que la complexité qui pourrait être géré par Ocaml n'est pas assez grande dans ce genre d'outil pour justifier le surcout de développement. Ensuite, il me semble que Rust dispose de beaucoup des constructions sympa fonctionnelles.
Go n'est pas fait pour ça. Go, c'est pour faire du serveur web applicatif, pas un outils en ligne de commande, même si c'est possible, bien sûr.
"La première sécurité est la liberté"
[^] # Re: PHP…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Etude comparée de la popularité des langages de programmation sur linuxfr. Évalué à 9.
Je ne suis pas d'accord. Javascript est tout aussi pourris que PHP.
Python n'a jamais prétendu pouvoir être utilisé pour faire des (gros) logiciels.
"La première sécurité est la liberté"
[^] # Re: Go ou Rust côté backend, système ou embarqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La ronde (boucle?) des langages. Évalué à 3.
non, mais le go actuel pourrait fournir une fonction de base Clone(dst, org) qui pourrait aider à faire le travail.
"La première sécurité est la liberté"
[^] # Re: Go ou Rust côté backend, système ou embarqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La ronde (boucle?) des langages. Évalué à 3.
Je n'avais pas pensé à ce cas de figure, bien sûr, je pensais à transmettre un message complet par channel pour ne surtout pas avoir de partage de mémoire. C'est le principe de base du partage par message.
Avez-vous expliqué le problème, ici :https://blog.golang.org/toward-go2 ou même pour le go actuel ? Faire un "deep cloning", pour le passage par référence, est quand même une sacré bonne raison.
"La première sécurité est la liberté"
[^] # Re: Go ou Rust côté backend, système ou embarqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La ronde (boucle?) des langages. Évalué à 3.
Comment ils font ça ? Avec go, si on utilise que les channels pour communiquer entre goroutine et pas de lock, il n'y a pas de problème potentiel.
Le cas général, est complexe surtout si on rajoute le garbage collector au milieu. Un des moyens serait d'envoyer des bouts de mémoire en lecture seul, et transmettre la gestion de ce bout de mémoire pour le détruire. Il existe une théorie dont j'ai oublié le nom qui permet de faire ça, mais cela rend le code très complexe (à chaque affectation, la sémantique est que la donnée est transmise et n'existe plus dans la variable d'origine).
"La première sécurité est la liberté"
[^] # Re: Go ou Rust côté backend, système ou embarqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La ronde (boucle?) des langages. Évalué à 10.
Pour m'y mettre depuis 1 an, go est vraiment puissant. Son système de typage par interface permet une réutilisation dingue. L'exemple typique sont des lib évoluées qui utilisent l'interface de base des mux http. Ainsi on peut injecter le tout dans une autre lib qui ne connait que la lib de base.
Pour moi, il manque surtout des types sommes (ou union en Rust).
Il est fait pour écrire des serveurs web applicatif qui monte bien en charge. En dehors de ce cas d'usage, il n'est pas l'ultime solution.
"La première sécurité est la liberté"
[^] # Re: Vieille solution
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 3.
Une fonction cyclique est une fonction qui est exécutée toutes les millisecondes par exemple.
A moins d'avoir un sacré bon scheduler, l'augmentation ne sera pas linéaire du tout. Une fois que n est bien plus grand que le nombre de cpu, "l'overhead" de gestion grandit avec le nombre de changements de contexte, etc…
"La première sécurité est la liberté"