0 Membres et 1 Invité sur ce sujet
Cette semaine dans MLC@HomeNotes pour le 24 novembre 2020Un résumé hebdomadaire des nouvelles et des notes pour MLC@HomeRésumé BoincNetwork a fait un podcast présentant MLC@Home! Vous pouvez écouter l'épisode, y compris certains commentaires de vos administrateurs MLC, à l' adresse https://www.boinc.network/episode/mlchome . Merci à tous ceux de BoincNetwork de s'intéresser à nous.La semaine dernière, nous avons pivoté vers l'analyse et l'écriture. Cependant, nous avons pris une dernière fissure au niveau du support Linux / CUDA, et étonnamment, cela semble avoir fait l'affaire. Nous avons publié le support Linux / CUDA dans la file d'attente principale mlds-gpu. Il y a cependant des compromis avec le nouveau client, en particulier en ce qui concerne l'espace disque requis.Nous avons également publié la prise en charge des GPU Linux / ROCm AMD pour mldstest, mais elle n'est actuellement activée que pour les GPU VEGA 56/64 et nécessite un noyau Linux 5.0.0 ou supérieur. Veuillez consulter le lien dans la section Actualités ci-dessous pour plus de détails.Nous avons également passé du temps à réviser la page du jeu de données MLDS sur le site Web principal. Ce n'est toujours pas parfait, mais un peu moins obsolète qu'il ne l'était, et se prépare à publier davantage les premiers ensembles de données. Avec cela et quelques analyses supplémentaires, nous travaillons à notre premier article sur l'ensemble de données. Plus de nouvelles ci-dessous. Nouvelles : Plus de détails sur la prise en charge des GPU Linux mis à jour, à la fois CUDA et ROCm, et c'est ici: https://www.mlcathome.org/mlcathome/forum_thread.php?id=127 (cadre en bas *).Les derniers clients GPU suppriment l'exigence AppImage. Les clients CPU l'utilisent toujours, mais il peut être judicieux de le déposer là aussi. Voir le fil ci-dessus pour les compromis associés.DS1 + DS2 continuent de progresser vers l'achèvement. Il ne reste plus que les unités de travail Parity et EightBit ! Continuez !La progression de DS3 approche le jalon 2, 1000x100 .. approchant les 100000 réseaux DS3 formés. Cela aidera certainement à notre analyse continue. C'est agréable de voir le tableau de bord en bas de https://www.mlcathome.org/ passer du jaune au vert !Mise à jour la page de l'ensemble de données MLDS ici : https://www.mlcathome.org/mlds.html , vous pouvez voir comment nous prévoyons actuellement de diviser les ensembles de données pour la publication.Nous avons commencé à rédiger un article sur le jeu de données cette semaine et espérons revenir à la préparation du jeu de données 4 cette semaine.Instantané de l' état du projet :(notez que ces chiffres sont approximatifs) - Tâches * Tâches prêtes à envoyer : 28803 * Tâches en cours : 19629 - Utilisateurs * avec crédit : 1251 * Enregistré au cours des dernières 24 heures : 57 - Hôtes * avec crédit récent : 2156 * Enregistré au cours des dernières 24 heures : 19 - GigaFLOPS actuel 36126,42 Progression des ensembles de données 1 et 2 :CiterSingleDirectMachine 10002/10004EightBitMachine 10001/10006SingleInvertMachine 10001/10003SimpleXORMachine 10000/10002ParityMachine 1031/10005ParitéModifié 348/10005EightBitModifié 6910/10006SimpleXORModified 10005/10005SingleDirectModifié 10004/10004SingleInvertModifié 10002/10002 Progression des ensembles de données 3 :CiterGlobalement (jusqu'à présent): 75935/84376Jalon 1, 100x100: 10000/10000Jalon 2, 100x1000: 75935/100000Jalon 3: 100x10000: 75935/1000000Notes TWIM de la semaine dernière: 17 novembre 2020Merci encore à tous nos bénévoles !- La page d'accueil des administrateurs MLC@Home : https://www.mlcathome.org/Twitter: @MLCHome2Citer* Plus de détails sur la prise en charge des GPU Linux mis à jour, à la fois CUDA et ROCmNous avons apporté quelques modifications aux clients Linux dans mldstest et nous obtenons de meilleurs résultats, mais avec quelques compromis. Cependant, il semble que nous ayons beaucoup plus de chance avec le support GPU sous Linux maintenant!Voici un court journal des modifications pour 9.80 dans mldstest : - Suppression du regroupement appimage, maintenant nous expédions simplement le binaire brut et les bibliothèques (cela a quelques compromis ...) - Mise à jour vers PyTorch 1.7 - Les clients GPU nécessitent la libc 2.27 ou supérieure (Ubuntu 18.04+) - CUDA 10.2 ou supérieur pour NVIDIA - Prenez d'abord en charge les GPU AMD !Plus de bundlingLe gros changement est que le client GPU 9.80 en test n'est plus fourni avec AppImage. C'est bien en ce sens que cela supprime la dépendance d'avoir FUSE disponible et configuré sur votre système, et le bit étrange où l'application cliente monte en fait un système de fichiers squashfs en mémoire dans / tmp sur votre système. Il supprime également une source d'erreur possible sur le système.L'inconvénient est la taille des bibliothèques que nous devons expédier. CUDA est énorme. Notre binaire lui-même fait 8,6 Mo, mais la bibliothèque libtorch_cuda fait 1,9 Go, et plusieurs autres bibliothèques portent la taille totale de l'application + bibliothèque à 3 Go. Avec AppImage, ces bibliothèques ont été compressées et stockées sur le disque dans un système de fichiers squashfs, ce qui a réduit l'exigence sur le disque à environ 900 Mo-1,6 Go (selon la version). Pire encore, ces fichiers doivent être téléchargés dans le répertoire du projet, puis copiés dans chaque répertoire en cours d'exécution (je ne sais pas pourquoi BOINC ne fait pas de liaison ici, il nous manque peut-être un paramètre?), Donc ils prennent deux fois plus espace disque lors de son utilisation. Plus si vous avez plus d'un GPU.Donc, en substance, nous avons échangé beaucoup plus d'espace disque pour un client plus simple qui semble mieux fonctionner sur plus de systèmes. Dans l'ensemble, nous pensons que c'est une victoire, et cela facilitera le débogage, mais surtout du côté du GPU, le coup d'espace disque n'est pas trivial. Les futures applications de processeur pourraient également s'éloigner de appimage, mais en raison du fait que les gens ont beaucoup plus de threads de processeur que de GPU, l'équation de compromis d'espace disque pourrait être différente. Prise en charge desGPU AMD La prise en charge de ROCm est ici, mais il y a quelques mises en garde. Le plus important est que c'est seulement pris en charge par les cartes discrètes basées sur VEGA pour le moment, ce qui signifie VEGA56 / 64, Radeon VII, plusieurs cartes MIxxx. NAVI1 et NAVI2 ne sont pas entièrement pris en charge par ROCm, la prise en charge des graphiques discrets POLARIS est (temporairement) interrompue dans ROCm 3.9, et devrait être corrigée lors de la sortie de ROCm 4.0 (annoncé la semaine dernière). Quand ROCm 4.0 sortira, je re-tournerai le client rocm avec ce qui devrait également permettre le crunching GPU basé sur POLARIS (RX 550,560,570,580,590). Les APU ne sont pas pris en charge. Windows n'est pas pris en charge.Actuellement, le serveur ne servira que les WU ROCm aux machines avec "Radeon RX Vega" dans leur chaîne d'identifiant hôte / os et (une fois que nous aurons implémenté une correction de bogue dans le code de base de boinc) exécutera le noyau 5.0.0 ou supérieur.Pour le moment, le support ROCm est plus lent que CUDA, mais toujours plus rapide que CPU.Mise à jour des exigencesPour CUDA:capacité de calcul 3,5 ou plus4 Go de RAM (2 Go autorisés mais peut-être trop peu pour certains WU)CUDA 10.2 ou supérieur (et pilote compatible 455+)GLIBC 2.27+ (Ubuntu 18.04+, Debian 10+, CentOS 8+, Fedora 28+, ou équivalent)Pour ROCm:carte graphique discrète basée sur Radeon VEGA (POLARIS à venir)4 Go de RAM (2 Go autorisés mais peut-être trop peu pour certains WU)Kernel 5.0.0 ou supérieurGLIBC 2.27+ (Ubuntu 18.04+, Debian 10 +, CentOS 8+, Fedora 28+ ou équivalent)Utilisation du processeurTous ces frameworks utilisent plusieurs threads CPU lorsqu'ils parlent au CPU. Sur ROCm et CUDA, la somme totale des pics d'utilisation du processeur dépasse 100% pour un processeur (j'ai personnellement observé des pics d'utilisation d'environ 120%). Les tentatives pour limiter cela jusqu'à présent ont échoué et ont un effet sur les performances. Mais pour être un bon citoyen de la BOINC, nous continuerons de nous attaquer et de voir si nous pouvons le ramener à un niveau raisonnable.Résultats à ce jourDepuis l'activation de ces deux clients de tests la nuit dernière, nous constatons un taux de réussite> 98% sur AMDROCM et CUDA ! .. si les choses continuent à bien se passer, nous passerons le client CUDA à mlds-gpu. le client ROCm restera dans mldstest un bt plus longtemps jusqu'à ce que ROCM 4.0 soit publié.Donc, si vous pouvez tester, faites-le !
SingleDirectMachine 10002/10004EightBitMachine 10001/10006SingleInvertMachine 10001/10003SimpleXORMachine 10000/10002ParityMachine 1031/10005ParitéModifié 348/10005EightBitModifié 6910/10006SimpleXORModified 10005/10005SingleDirectModifié 10004/10004SingleInvertModifié 10002/10002
Globalement (jusqu'à présent): 75935/84376Jalon 1, 100x100: 10000/10000Jalon 2, 100x1000: 75935/100000Jalon 3: 100x10000: 75935/1000000
* Plus de détails sur la prise en charge des GPU Linux mis à jour, à la fois CUDA et ROCmNous avons apporté quelques modifications aux clients Linux dans mldstest et nous obtenons de meilleurs résultats, mais avec quelques compromis. Cependant, il semble que nous ayons beaucoup plus de chance avec le support GPU sous Linux maintenant!Voici un court journal des modifications pour 9.80 dans mldstest : - Suppression du regroupement appimage, maintenant nous expédions simplement le binaire brut et les bibliothèques (cela a quelques compromis ...) - Mise à jour vers PyTorch 1.7 - Les clients GPU nécessitent la libc 2.27 ou supérieure (Ubuntu 18.04+) - CUDA 10.2 ou supérieur pour NVIDIA - Prenez d'abord en charge les GPU AMD !Plus de bundlingLe gros changement est que le client GPU 9.80 en test n'est plus fourni avec AppImage. C'est bien en ce sens que cela supprime la dépendance d'avoir FUSE disponible et configuré sur votre système, et le bit étrange où l'application cliente monte en fait un système de fichiers squashfs en mémoire dans / tmp sur votre système. Il supprime également une source d'erreur possible sur le système.L'inconvénient est la taille des bibliothèques que nous devons expédier. CUDA est énorme. Notre binaire lui-même fait 8,6 Mo, mais la bibliothèque libtorch_cuda fait 1,9 Go, et plusieurs autres bibliothèques portent la taille totale de l'application + bibliothèque à 3 Go. Avec AppImage, ces bibliothèques ont été compressées et stockées sur le disque dans un système de fichiers squashfs, ce qui a réduit l'exigence sur le disque à environ 900 Mo-1,6 Go (selon la version). Pire encore, ces fichiers doivent être téléchargés dans le répertoire du projet, puis copiés dans chaque répertoire en cours d'exécution (je ne sais pas pourquoi BOINC ne fait pas de liaison ici, il nous manque peut-être un paramètre?), Donc ils prennent deux fois plus espace disque lors de son utilisation. Plus si vous avez plus d'un GPU.Donc, en substance, nous avons échangé beaucoup plus d'espace disque pour un client plus simple qui semble mieux fonctionner sur plus de systèmes. Dans l'ensemble, nous pensons que c'est une victoire, et cela facilitera le débogage, mais surtout du côté du GPU, le coup d'espace disque n'est pas trivial. Les futures applications de processeur pourraient également s'éloigner de appimage, mais en raison du fait que les gens ont beaucoup plus de threads de processeur que de GPU, l'équation de compromis d'espace disque pourrait être différente. Prise en charge desGPU AMD La prise en charge de ROCm est ici, mais il y a quelques mises en garde. Le plus important est que c'est seulement pris en charge par les cartes discrètes basées sur VEGA pour le moment, ce qui signifie VEGA56 / 64, Radeon VII, plusieurs cartes MIxxx. NAVI1 et NAVI2 ne sont pas entièrement pris en charge par ROCm, la prise en charge des graphiques discrets POLARIS est (temporairement) interrompue dans ROCm 3.9, et devrait être corrigée lors de la sortie de ROCm 4.0 (annoncé la semaine dernière). Quand ROCm 4.0 sortira, je re-tournerai le client rocm avec ce qui devrait également permettre le crunching GPU basé sur POLARIS (RX 550,560,570,580,590). Les APU ne sont pas pris en charge. Windows n'est pas pris en charge.Actuellement, le serveur ne servira que les WU ROCm aux machines avec "Radeon RX Vega" dans leur chaîne d'identifiant hôte / os et (une fois que nous aurons implémenté une correction de bogue dans le code de base de boinc) exécutera le noyau 5.0.0 ou supérieur.Pour le moment, le support ROCm est plus lent que CUDA, mais toujours plus rapide que CPU.Mise à jour des exigencesPour CUDA:capacité de calcul 3,5 ou plus4 Go de RAM (2 Go autorisés mais peut-être trop peu pour certains WU)CUDA 10.2 ou supérieur (et pilote compatible 455+)GLIBC 2.27+ (Ubuntu 18.04+, Debian 10+, CentOS 8+, Fedora 28+, ou équivalent)Pour ROCm:carte graphique discrète basée sur Radeon VEGA (POLARIS à venir)4 Go de RAM (2 Go autorisés mais peut-être trop peu pour certains WU)Kernel 5.0.0 ou supérieurGLIBC 2.27+ (Ubuntu 18.04+, Debian 10 +, CentOS 8+, Fedora 28+ ou équivalent)Utilisation du processeurTous ces frameworks utilisent plusieurs threads CPU lorsqu'ils parlent au CPU. Sur ROCm et CUDA, la somme totale des pics d'utilisation du processeur dépasse 100% pour un processeur (j'ai personnellement observé des pics d'utilisation d'environ 120%). Les tentatives pour limiter cela jusqu'à présent ont échoué et ont un effet sur les performances. Mais pour être un bon citoyen de la BOINC, nous continuerons de nous attaquer et de voir si nous pouvons le ramener à un niveau raisonnable.Résultats à ce jourDepuis l'activation de ces deux clients de tests la nuit dernière, nous constatons un taux de réussite> 98% sur AMDROCM et CUDA ! .. si les choses continuent à bien se passer, nous passerons le client CUDA à mlds-gpu. le client ROCm restera dans mldstest un bt plus longtemps jusqu'à ce que ROCM 4.0 soit publié.Donc, si vous pouvez tester, faites-le !
Cette semaine dans MLC@HomeNotes pour le 30 novembre 2020Un résumé hebdomadaire des nouvelles et des notes pour MLC@HomeRésumé Seulement une courte mise à jour cette semaine, car nous avons effectué une analyse sur les données collectées jusqu'à présent en préparation d'un article, et c'était un week-end de vacances dans notre partie du monde. Le nouveau client Linux / CUDA semble bien fonctionner, nous pouvons donc arrêter de spammer le fil d'actualité avec une mise à jour chaque semaine. Plus d'informations dans les actualités ci-dessous.Nouvelles : Plus de détails sur la prise en charge du GPU Linux mis à jour, à la fois CUDA et ROCm, et c'est ici, y compris une discussion récente sur l'utilisation du disque du nouveau client: https://www.mlcathome.org/mlcathome/forum_thread.php?id=127 .DS1 et DS2 continuent vers l'achèvement. Nous avons modifié certains des WU pour qu'ils expirent prématurément s'ils ne semblent pas converger, dans l'espoir de pousser nos recherches vers des chemins plus susceptibles de converger bientôt. EightBitModified n'est qu'à quelques milliers de minutes de l'achèvement !Les progrès de DS3 approchent de l'étape 2, 1 000 x 100 .. 100 000 réseaux DS3 formés. Cela aidera certainement à notre analyse continue. C'est agréable de voir le tableau de bord en bas de https://www.mlcathome.org/ passer du jaune au vert !En analysant les données DS3 jusqu'à présent, nous avons découvert que l'ensemble de données lui-même est très volumineux (environ 100 Go pour seulement 500 x 100). Cela ralentit quelque peu l'analyse, mais c'est un bon problème à avoir. Nous pouvons réduire cela de manière significative dans une version, mais parfois traiter autant de données prend juste du temps.Nous avons créé les ensembles de données DS1-100, DS1-500, DS1-1000, DS2-100, DS3-100, DS3-500 en interne, et les nettoyons et analysons les résultats. Nous espérons avoir quelques résultats (préliminaires) à partager avec la communauté, comme nous l'avons déjà publié, d'ici quelques jours.Instantané de l' état du projet :(notez que ces chiffres sont approximatifs) - Tâches * Tâches prêtes à envoyer : 45843 * Tâches en cours : 18569 - Utilisateurs * avec crédit : 1318 * Enregistré au cours des dernières 24 heures : 43 - Hôtes * avec crédit récent : 2228 * Enregistré au cours des dernières 24 heures : 60 - GigaFLOPS actuel 37671.35 Progression des ensembles de données 1 et 2 :CiterSingleDirectMachine 10002/10004EightBitMachine 10001/10006SingleInvertMachine 10001/10003SimpleXORMachine 10000/10002ParityMachine 1091/10005ParityModified 391/10005EightBitModified 7750/10006SimpleXORModified 10005/10005SingleDirectModified 10004/10004SingleInvertModified 10002/10002 Progression des ensembles de données 3 :CiterOverall (so far): 82873/101488Milestone 1, 100x100: 10000/10000Milestone 2, 100x1000: 82873/100000Milestone 3: 100x10000: 82873/1000000Notes TWIM de la semaine dernière: 23 novembre 2020Merci encore à tous nos bénévoles !- La page d'accueil des administrateurs MLC@Home : https://www.mlcathome.org/Twitter: @MLCHome2
SingleDirectMachine 10002/10004EightBitMachine 10001/10006SingleInvertMachine 10001/10003SimpleXORMachine 10000/10002ParityMachine 1091/10005ParityModified 391/10005EightBitModified 7750/10006SimpleXORModified 10005/10005SingleDirectModified 10004/10004SingleInvertModified 10002/10002
Overall (so far): 82873/101488Milestone 1, 100x100: 10000/10000Milestone 2, 100x1000: 82873/100000Milestone 3: 100x10000: 82873/1000000
Cette semaine dans MLC@HomeNotes pour le 8 décembre 2020Un résumé hebdomadaire des nouvelles et des notes pour MLC@HomeRésumé Beaucoup d'analyses des résultats, d'écriture sur papier et de combats avec LaTeX cette semaine. La bonne nouvelle est que, comme publié sur Twitter, l'ensemble de données 3 montre des réseaux similaires se regroupant dans l'espace de pondération de la même manière que les ensembles de données 1 et 2. C'est un bon résultat et actuellement en cours de rédaction dans le cadre d'un "article sur les ensembles de données" que nous préparons lorsque nous publierons les ensembles de données au public. Nous formons actuellement notre propre classificateur de réseau de neurones pour classer quels réseaux DS3 ont été formés avec quelles données DS3 en fonction uniquement de leurs poids, et nous avons de grands espoirs de bons résultats là-bas étant donné le regroupement dans le graphique lié.Ce fut une semaine relativement calme sur les forums, mais de grands sauts dans les progrès de WU! Nous sommes à moins de 900 réseaux pour terminer les réseaux EightBitModified pour DS2, à moins de 9000 réseaux pour terminer l'étape 2 de DS3 et à moins de 80 réseaux ParityModified pour terminer DS2-500. Merci encore àtous nos bénévoles.Nouvelles : DS1 et DS2 continuent vers l'achèvement. Il en reste moins d'un millier pour EightBitModified, ne laissant que ParityMachine / Modified pour DS1 et DS2.Les progrès de DS3 approchent de l'étape 2, 1 000 x 100 .. 100 000 réseaux DS3 formés. Cela aidera certainement à notre analyse continue. C'est agréable de voir le tableau de bord en bas de https://www.mlcathome.org/ passer du jaune au vert !Nous avons créé les ensembles de données DS1-100, DS1-500, DS1-1000, DS2-100, DS3-100, DS3-500 en interne, et les nettoyons et analysons les résultats. Nous aimerions avoir au moins DS2-500, DS2-1000 et DS3-1000 au plus vite pour notre analyse (DS2-1000 pourrait être un peu extensible).Une fois que le jeu de données 3 aura atteint le jalon 2 (100x10000), nous mettrons probablement DS3 en pause pour nous concentrer uniquement sur l'achèvement des WU de parité pour terminer DS1 et DS2.Nous n'avons pas parlé de DS4 depuis un moment, mais le travail progresse sur le client mis à jour pour gérer les CNN. Attendez-vous à ce que cela soit publié pendant ou juste après les vacances.Instantané de l'état du projet :(notez que ces chiffres sont approximatifs) - Tâches * Tâches prêtes à envoyer : 22937 * Tâches en cours : 21142 - Utilisateurs * avec crédit : 1406 * Enregistré au cours des dernières 24 heures : 63 - Hôtes * avec crédit récent : 2314 * Enregistré au cours des dernières 24 heures : 25 - GigaFLOPS actuel 44334.91 Progression des ensembles de données 1 et 2 :CiterSingleDirectMachine 10002/10004EightBitMachine 10001/10006SingleInvertMachine 10001/10003SimpleXORMachine 10000/10002ParityMachine 1179/10005ParityModified 428/10005EightBitModified 9155/10006SimpleXORModified 10005/10005SingleDirectModified 10004/10004SingleInvertModified 10002/10002 Progression des ensembles de données 3 :CiterOverall (so far): 91044/101488Milestone 1, 100x100: 10000/10000Milestone 2, 100x1000: 91044/100000Milestone 3: 100x10000: 91044/1000000Notes TWIM de la semaine dernière: 30 novembre 2020Merci encore à tous nos bénévoles !- La page d'accueil des administrateurs MLC@Home : https://www.mlcathome.org/Twitter: @MLCHome2
SingleDirectMachine 10002/10004EightBitMachine 10001/10006SingleInvertMachine 10001/10003SimpleXORMachine 10000/10002ParityMachine 1179/10005ParityModified 428/10005EightBitModified 9155/10006SimpleXORModified 10005/10005SingleDirectModified 10004/10004SingleInvertModified 10002/10002
Overall (so far): 91044/101488Milestone 1, 100x100: 10000/10000Milestone 2, 100x1000: 91044/100000Milestone 3: 100x10000: 91044/1000000
Cette semaine dans MLC@HomeNotes pour le 22 décembre 2020Un résumé hebdomadaire des nouvelles et des notes pour MLC@HomeRésumé Bonnes vacances de MLC!TWIM Notes fera une pause pour les vacances, sauf s'il y a quelque chose d'urgent à mettre à jour, ce sera la dernière mise à jour pour 2020.Quelques notes cette semaine : * Nous sommes maintenant plus de 1 500 bénévoles indépendants!* Nous aimerions vraiment obtenir DS2 avec un seuil de 1000 entrées pour chaque type de réseau pour l'analyse, ce qui signifie que nous avons rééquilibré certains WU pour donner la priorité aux WU à parité modifiée. À cette fin, nous avons rempli la file d'attente des tâches du GPU avec des WU ParityModified à double longueur (le crédit est double en conséquence). Cela signifie que les temps d'exécution augmenteront pour les GPU, bien qu'il y ait encore beaucoup d'anciens WUs en cours de travail, vous pouvez donc travailler plus vieux ou plus récent pendant un certain temps.* En conséquence, nous avons rempli la file d'attente de travail du processeur avec des WU de l'ensemble de données 3 pour continuer à progresser.* Le changement ci-dessus a conduit à deux problèmes connus qui ont été trouvés et résolus cette semaine. Premièrement, les premiers WU plus longs échouaient à la validation jusqu'au processus de validation que nous avons mis à jour, et le calcul du crédit a été désactivé pendant quelques jours (en faveur des utilisateurs). Les deux problèmes ont maintenant été corrigés, grâce à ceux qui ont signalé ces problèmes sur le forum.* Pendant la pause, notre principal effort est de continuer à travailler sur l'analyse, la rédaction papier et la refonte de l'architecture pour simplifier la logique de validation et d'assimilation backend en arrière-plan pour aider à éviter que des problèmes comme les deux qui ont frappé cette semaine ne se produisent à l'avenir. .Aperçu de l'état du projet :(notez que ces chiffres sont approximatifs)Notes TWIM de la semaine dernière: 14 décembre 2020Merci encore à tous nos bénévoles !- La page d'accueil des administrateurs MLC@Home : https://www.mlcathome.org/Twitter: @MLCHome2
Cette semaine dans MLC@HomeNotes pour le 28 décembre 2020Un résumé hebdomadaire des nouvelles et des notes pour MLC@HomeRésumé Bonnes vacances et bonne année de la part de MLC !Nous avons donc décidé de publier une mise à jour cette semaine de toute façon, tout d'abord, nous avons franchi l'étape 2 de l'ensemble de données 3, c'est-à-dire 1000 réseaux formés pour chacun des 100 automates générés aléatoirement! Il s'agit d'une étape importante et rend l'analyse beaucoup plus intéressante! Un autre changement important visible par l'utilisateur est que le site Web et le projet se trouvent désormais derrière un CDN. Cette énormémentréduit les besoins en bande passante sur le serveur et accélère considérablement les téléchargements des clients, et il semble y avoir peu d'effets négatifs sur le projet dans son ensemble. Si vous constatez des problèmes, veuillez les publier sur le forum afin qu'ils puissent être résolus.Enfin, nous avons remarqué un afflux important de nouveaux bénévoles au cours de la semaine dernière. Bienvenue! Et merci de soutenir le travail scientifique que nous essayons de faire.Plus de nouvelles ci-dessous: * Nous travaillons sur la refonte d'une grande partie des machines en coulisse pour la validation et l'assimilation pour mettre à jour notre gestion de NaN. * Nos WU mis à jour pour essayer de franchir le seuil de 1000 réseaux pour tous les WU DS2 semblent avoir un effet positif, avec près de 100 nouveaux réseaux terminés la semaine dernière. Nous continuerons ainsi jusqu'à ce que nous franchissions ce seuil. * Pendant la pause, notre principal effort est de continuer à travailler sur l'analyse, la rédaction papier, une nouvelle version du client ROCM, et de continuer à préparer DS4.Aperçu de l'état du projet :(notez que ces chiffres sont approximatifs)Notes TWIM de la semaine dernière: 22 décembre 2020Merci encore à tous nos bénévoles !- La page d'accueil des administrateurs MLC@Home : https://www.mlcathome.org/Twitter: @MLCHome2
Cette semaine dans MLC@HomeNotes pour le 5 janvier 2021 Un résumé hebdomadaire des nouvelles et des notes pour MLC@HomeRésumé Bonne année 2021 ! La semaine dernière a marqué le 6e anniversaire de ce projet, nous voulions donc revenir sur le chemin parcouru, évaluer ce qui s'est bien passé, trouver les domaines à améliorer et parler de l'avenir. Dans l'ensemble, la réponse de la communauté a été incroyable et nous avons le sentiment d'avoir construit une base vraiment solide pour comprendre et évaluer les réseaux de neurones. Nous énumérerons certaines de nos pensées ci-dessous, et nous vous encourageons, la communauté, à commenter ci-dessous avec vos pensées. Le bon - Le travail réel terminé : Vous, la communauté, avez formé plus de 260 000 réseaux de neurones pour ce projet, modélisant 110 types d'automates / machines différents, et d'autres sont en préparation. Lorsque DS3 sera terminé, nous aurons plus de 1 000 000 de réseaux formés. Il s'agit vraiment d'une contribution unique à la science et constitue une base d'étude incroyable pour les années à venir. Je peux déjà voir 3 ou 4 nouvelles lignes de recherche provenant de ce seul jeu de données. - Engagement de la communauté : Nous avons fait un effort particulier pour atteindre la communauté, avec des mises à jour hebdomadaires et en essayant d'être actif sur les forums et sur Twitter. Nous sommes un petit projet d'un petit laboratoire dans une petite école. Bien que cela puisse toujours être mieux, nous aimerions penser que cela a été un plus. De plus, nous avons reçu le soutien des développeurs BOINC et de la communauté en général via le serveur BOINCNetwork Discord et les listes de diffusion BOINC, qui ont été extrêmement utiles pour que le projet soit opérationnel en premier lieu. - La technologie : nous tirons parti de l'infrastructure BOINC et de son fonctionnement même si nos WU sont un peu hors du commun pour elle. Nous prenons en charge 2 des trois principaux systèmes d'exploitation, sur x86 et ARM, et les GPU de NVidia et AMD. Sont-ils parfaits? à peine . Il y a beaucoup à faire et nous essayons de les améliorer. Mais pendant 6 mois, nous dirons que c'est un très bon début dans l'ensemble. Le côté serveur s'est bien déroulé, car le nouveau serveur vers lequel nous avons déménagé il y a quelques mois a été d'une réelle aide. Fait amusant, pendant les premiers mois, ce projet a été exécuté sur un vieux thinkpad .. vous vous contentez de ce que vous avez. Domaines à améliorer : - Publiez des articles et publiez un ensemble de données : vous méritez une publication rapide de l'ensemble de données que vous avez aidé à créer. Nous voulions vraiment que cela soit disponible maintenant, et nous estimons que nous avons maintenant suffisamment de données pour le faire. Mais il faut du temps pour écrire et du temps pour organiser / préparer / documenter l'ensemble de données pour la publication, et franchement, cela prend plus de temps que prévu. C'est sur nous, et nous y travaillons. Nous devrions envisager des jours ou des semaines, pas des mois. - Plates - formes plus prises en charge : Nous recherchons des développeurs ayant une expérience C ++ qui peuvent nous aider à prendre en charge de nouvelles plates-formes, en particulier OSX et Android. - Plus de collaborateurs du côté de la science : COVID a vraiment rendu cela encore plus difficile. Je vais être honnête, de nombreux chercheurs en ML à qui j'ai proposé cette idée n'étaient pas très intéressés dès le début car a) ils étaient sceptiques quant au fait que le système fonctionnerait et / ou que les gens feraient du bénévolat, b) nous ne soutenions pas les GPU et ou c) étaient intéressés mais n'avaient pas le temps. Maintenant que nous le faisons, et que notre réserve de bénévoles a augmenté en général, nous devons nous réengager. Les résultats publiés aideront notre cas. - Il s'agit toujours d'une opération à une personne : si je peux me permettre une minute personnelle, la plupart de ce qui précède est dû au fait qu'il s'agit encore d'une opération à une personne pour la plupart, et à une personne qui n'est qu'un doctorant à temps partiel avec un emploi à temps plein et une famille en plus de diriger ce projet. Ce n'est pas comme si j'étais un étudiant diplômé régulier qui pouvait passer des heures par jour dans un laboratoire et écrire, que ce soit du code ou des articles. Je vole tout le temps que je peux la nuit et le week-end. Faire un doctorat à temps partiel est déjà assez difficile, choisir de créer, développer, surveiller et modérer tout un projet informatique de bénévolat en plus de cela est franchement un peu fou. Mais je suis passionné par le travail que nous faisons ici et je veux le voir réussir. Et je suis convaincu que ce sera le cas. Remarque: j'essaie de dire «nous» lorsque j'agis en tant qu'administrateur de projet parce que je sens que finalement il y aura plus que moi, mais ce n'est pas (encore) le cas.Ce que l'avenir nous réserve : - MLDS : Publiez, les deux premières séries d'ensembles de données et un article ou deux. C'est notre priorité absolue. - MLDS : DS4 passera à la formation des CNN pour la classification des images, ce qui conduira à un tout nouvel ensemble d'idées et de questions. - Il est important que MLC se développe et continue de se développer au-delà de l'application MLDS. Par conséquent, engagez-vous avec de nouveaux chercheurs et des axes de recherche qui se prêtent à notre architecture de projet unique. La recherche d'hyperparamètres et d'architecture semble parfaitement adaptée à notre système. Il y a beaucoup plus de choses que nous pourrions mentionner, comme les modifications apportées aux validations (certaines bonnes, certaines… sans erreur), la réalisation d'un podcast sur le projet, la générosité que nous avons reçue des autres administrateurs du projet pour nous aider à prendre pied sous nous. Et, bien sûr, des badges. En tant qu'administrateurs, nous avons beaucoup appris sur la façon de gérer un projet, et malgré quelques trébuchements, nous espérons que vous trouverez la science convaincante, le projet intéressant et la communauté accueillante. À 6 mois, nous sommes sur le point d'obtenir de vrais résultats, qui devraient nourrir beaucoup plus de science intéressante. Merci à tous nos bénévoles pour avoir contribué à faire avancer la science de l'apprentissage automatique et nous espérons vous donner des raisons de continuer à nous soutenir pendant de nombreuses années. Si vous avez des commentaires, veuillez les laisser dans les commentaires ci-dessous.Aperçu de l'état du projet :(notez que ces chiffres sont approximatifs)Notes TWIM de la semaine dernière: 28 décembre 2020Merci encore à tous nos bénévoles !- La page d'accueil des administrateurs MLC@Home : https://www.mlcathome.org/Twitter: @MLCHome2