Plus que le confort que ça propose, c'est surtout une façon de pouvoir lire agréablement un peu partout dans le monde, surtout dans les pays où les livres coûtent un bras (quand tu les trouves). C'est ça qui m'a fait acheter un Kindle/Kobo.

Par contre on aimerait bien pouvoir lire la série d'un livre dans les menus, hein Amazon. C''est mon seul reproche à mon Kindle.

salut je poste ma question ici car flemme de crée un topic

voila j'utilise git pour les cours (epitech rpz sisi ) et je redouble ma première année mais la est pas la question

enfaîte j'ai appris que l'école allais supprimer mon repo git pour pas que je recup mes projet alors j'aimerais tousse les clone avant

mais y'en a pas mal dont j'ai oublier le nom donc exit-il une commande qui liste tout les repo que j'ai crée sur git ?

Je pensais à ça mais sur un ordinateur portable ARM, on a un BIOS ? On peut y installer l'OS que l'on veut ? (en respectant l'architecture bien évidemment).

Si oui, hormis la taille des périphériques de stockage qui avoisinent 64 Go tout au plus, ça peut-être comme un RPi avec clavier/souris/écran/haut-parleurs intégrés et en choisissant une bonne distribution/un bon système, on peut vraiment obtenir une machine performante pour trois fois rien, non ?

Je me prend pour exemple (c'est valable pour les utilisateurs de la distribution Gentoo aussi par exemple) mais étant utilisateur d'un système d'exploitation qui utilise un gestionnaire de paquet source, hormis la lenteur liée à la compilation, j'ai accès à la totalité des logiciels disponible sur amd64 quelque soit mon architecture quand bien même il faut un repo spécial pour chaque architecture sur une distribution classique de chez GNU/Linux comme Debian, Arch Linux et tout autre distribution utilisant un gestionnaire de paquets pré-compilés et que s'il manque un logiciel, tu dois te débrouiller pour le compiler. Je ne sais pas ce qu'il en est de ces dépôts et si l'on peut encore se plaindre du manque de paquet et/ou de maintenance dans le cadre des dernières versions des architectures ARM mais si c'est bien fait, alors peut-être que prendre un PC plus petit utilisant une architecture ARM deviendrait intéressant !

mais y'en a pas mal dont j'ai oublier le nom donc exit-il une commande qui liste tout les repo que j'ai crée sur git ?

Pas dans git en tout cas. Mais souvent les serveurs git ont une interface web qui te permet de lister tous les projets.

Je pensais à ça mais sur un ordinateur portable ARM, on a un BIOS ? On peut y installer l'OS que l'on veut ? (en respectant l'architecture bien évidemment).

Il n'y a pas de BIOS sur ARM, mais des systemes de boot custom. Ce qui est assez le bordel.

Si oui, hormis la taille des périphériques de stockage qui avoisinent 64 Go tout au plus, ça peut-être comme un RPi avec clavier/souris/écran/haut-parleurs intégrés et en choisissant une bonne distribution/un bon système, on peut vraiment obtenir une machine performante pour trois fois rien, non ?

J'ai du mal a y croire. Les processeurs ARM sont en moyenne assez a la ramasse compare a ton x64 prefere. J'ai cause pas mal avec quelqu'un qui cherche a construire des noeuds de calcul a base d'arm. Et basiquement la structure des systemes de memoire est un probleme. Ca fait qu'il y a plein de probleme de performance dans les systemes d'IO.

Ces mecs la en parlait par exemple:

Evaluation of Emerging Energy-Efficient Heterogeneous Computing Platforms for Biomolecular and Cellular Simulation Workloads. by John E. Stone, Michael J. Hallock, James C. Phillips, Joseph R. Peterson, Zaida Luthey-Schulten, Klaus Schulten. in IPDPSW 2016

Apres, ca pourait se regler avec le temps. Mais pour l'instant j'ai du mal a y croire.

Du fait que tous les types de simulations se parallélisent pas vraiment de manière optimale (m'est déjà arrivé avec GROMACS d'être forcé à me limiter à 8 threads), avoir des coeurs assez puissants, c'est assez important pour un cluster.

Oui, ca depend beaucoup du type de simulation que tu fais. Cependant la simulation mecanique, ce genre de chose, ca scale plutot bien quand meme.

En fait la subtilité dans la mécanique, c'est les algos de neighbour search (pour savoir si on cut-off ou pas, avant de calculer les interactions), qui eux scalent pas toujours. (C'est d'autant plus con que ça peut dépendre de l'état de la simulation.)

Au passage, Godrik, tu penses quoi des clusters de GPUs ? (en dehors des APIs)

Lenheim

Le truc neuf, c'est quand quand tu meurs, tu perds tout ce que tu possèdes, avec les niveaux gagnés (eux serviront à augmenter tes stats de base), et que quand tu finis le donjon tu perds quand même tout tes niveaux. C'est un peu n'importe quoi ce jeu, mais il est cool.

Torneko no Daibōken Fushigi no Dungeon (1993) - SNES

Tu te lèves le matin, tu prépares ton sac et tu pars dans le donjon. Que tu en ressortes conscient ou assomé, tirés dehors par les ennemis, tu seras toujours niveau 1 quand tu rentreras dans le donjon le matin suivant et pas de stats, rien, tu es niveau 1 comme lors de ta toute première partie.

Étage 10, tu trouves un coffre qui te permet de garder 50 % de ton argent en cas de perte de la partie parce que le but du jeu (et l'objectif de Torneko dans la série Dragon Quest) c'est d'avoir le plus grand magasin du monde.

Le truc c'est que si tu reviens en vie, tu as le droit de garder quatre objets à emmener dans ta prochaine partie (tu peux tout aussi bien les laisser en lieu sûr à la maison pour ne pas les perdre mais tu es toujours limité à 4 au total). Ce que tu ne gardes pas sera vendu pour améliorer la boutique.

Torneko a besoin de manger (du pain), il trouvera aussi des parchemins qui améliorent l'épée ou le bouclier de +1, des parchemins pour découvrir l'étage, un autre pour voir les ennemis sur la carte etc... Pas de potion mais des herbes qui ont des effets et qui peuvent soit être mangés, soit être lancés sur des ennemis. Des flèches aussi (tu as déjà un arc). Des bijoux dont l'over-cheaté "belly" qui fait que tu n'as plus faim pendant que tu le portes. Les objets peuvent être uncursed ou cursed (blessed n'existe pas) et belly en négatif fait mal donc parchemin d'identification obligatoire pour pas jouer sa session à la roulette russe en enfilant cette bague.

BREF, c'est un jeu qui se rapproche énormément du classique Rogue tout en restant très accessible. Il est aussi très difficile.

C'est le premier jeu de la série Fushigi no Dungeon (donjon mystère en France) et le mec sortait à peine de Rogue en créant la série et ce jeu, c'est pourquoi il est très proche d'un Rogue.

Ah ça a l'air sympa, perso j'ai joué qu'aux pokemon et ils étaient plutôt ennuyant j'ai trouvé, donc je me suis pas attardé dessus.

En fait la subtilité dans la mécanique, c'est les algos de neighbour search (pour savoir si on cut-off ou pas, avant de calculer les interactions), qui eux scalent pas toujours. (C'est d'autant plus con que ça peut dépendre de l'état de la simulation.)

Je vois.

Au passage, Godrik, tu penses quoi des clusters de GPUs ? (en dehors des APIs)

Bah j'en pense que ca a les memes problemes que les GPU en general. Un GPU ca a peu de memoire. (Les grosses cartes on 16GB de nos jours.) Donc si tes donnees ne tiennent pas sur 16GB, il va falloir streamer le probleme depuis la memoire de l'hote jusqu'a la memoire du GPU. Et du coup, tu payes la latence de PCI-express et la potentiellement la bande passante limite.

La bande passante GDDR->SM est eleve sur le GPU, tout comme l'est le flop-rating du GPU. La question est souvent est ce que le calcul est assez dense pour pouvoir compenser le cout du bus CPU-GPU. Et dans plein de cas, c'est completement amorti. Les gens de deep learning font ca regulierement ou tu peux streamer ton jeu de donnee et faire ton training en meme temps. Sur les calcul super lineaire sur des graphes, tu as tendance a t'y retrouver aussi. Mais je trouve que souvent les gens ont trop la foi dans leur GPU. Souvent ils comparent une implementation matlab toute pourrie a une implementation GPU faites au petit oignon, et ils disent "regarde ca va beaucoup plus vite". Mais si tu avais fait l'implementation CPU sur autre chose que matlab, ca aurait ete beaucoup vite aussi. Apres les GPUs ont une perf en crete plus eleve que les CPU. Donc clairement il y a du potentielle. Cependant, je reste assez interesse par regarder les nouveau Phi de Intel. qui remplace le CPU et sont donc connecte directement a la DRAM systeme. J'avais joue avec la version precedente (KNF et KNC) en accelerateur, mais je n'ai pas encore eu le temps de jouer avec un KNL en version hote.

Ca ne repond pas a la question du cluster de GPU. Le je pense qu'il faut commencer a faire bien attention a ce que l'on veut faire. Si tu paques 8 GPU dans une seule machine sur deux bus PCI-express, tu te retrouves avec plein de probleme potentiel de bande passante. Il te faut des problemes relativement gras en calcul et leger en comm et en donne pour que ca marche. Parecque tu te retrouve a avoir 8 GPU sur les memes bus PCI-express, en general 2 bus PCI-express sur ces machines la. Donc tu te tapes 4 GPU sur un bus PCI-express de 16GB/s, soit 4GB/s par GPU. Quand tu vois qu'un GPU moderne ca te sort de l'ordre de 1 TFlop/s, ca veut dire qu'il te faut un calcul de plus de 250 flops par octet pour que la machine soit utile.

Tu te retrouve aussi avec un probleme de bande passante vers ton systeme de fichier. Si tu commence a tenir 32GB/s de traffic entre le CPU et le GPU, il te faut probablement un systeme de fichier qui peux bouger de l'ordre de 5GB/s ou 10GB/s. Et la ca devient chaud. 5GB/s, il va te falloir de l'ordre de 5 SSD sur la machine pour suivre, ou il te faut pouvoir tapper un systeme de fichier distribuer a 40Gb/s, Donc il te faute une carte 100Gb ethernet (ce qui n'est pas un probleme), mais il te faut aussi une archi de stockage assez bourin pour arriver a suivre.

Donc au final, mettre 8 GPU dans une machine je trouve ca un peu trop dedie. Je prefererais probablement 2 machines avec 4 GPU, ou 4 machines avec 2GPU pour avoir une machine un peu plus generaliste. C'est ce que les gens commence a faire. A part NVIDIA et son DGX1 pour faire du deep learning, personne ne pense serieusement mettre autant de GPU dans une seule machine.

Apres les gros clusters de GPU, a la titan de oak ridge. Les gens se rendent compte que c'est putain de difficile a utiliser. Et ca demande de reecrire a peu pres tous les codes. Donc c'est casse couille. Mais en terme de flop/W ou de BP/W, c'est relativement imbattable.

C'est Godrik parle de GPU

Fuck, voilà qui était technique.

Un ami m'avait conseillé à l'époque lors d'un cours de parallélisation (on avait le choix entre diverses APIs pour nous spécialiser) de regarder du côté des GPUs parce que y a encore peu de gens qui les utilisent (et du coup, pas/peu de file d'attente). Maintenant, j'ai l'impression que parmi les logiciels les plus utilisés (du moins du côté des clusters du CSC à Espoo), beaucoup ont une version CUDA ou GPU plus général, donc cet avantage disparaît.

En effet, on a eu un effet similaire a la fac. Notre premier cluster de GPU etait essentiellement vide tout le temps. Il y avait 3 mecs dans toute la fac qui avait du code qui utilisaient du GPU, et 1 mec qui en ecrivait. Du coup c'etait la fete si tu avais un code GPU. Tu avait 192 GPU pour toi tout seul. Maintenant il y a vachement plus de package qui ont un support gpu. L'avantage qu'il faut y voir, c'est que maintenant ton code tourne plus vite qu'avant et donc tu attends moins longtemps en moyenne pour faire un calcul de la meme taille.

Cote API, c'est en effet un bordel incroyable. NVIDIA poussait CUDA avant et AMD poussait OpenCL. On dirait que AMD arrete OpenCL et comme a pousse leur truc a eux. NVIDIA commence a dire que openacc c'est tres bien pour 90% de l'utilisation. En meme temps, il y a eu une dizaine de middleware qui se sont developpe sur ces API la. Et les FPGA commencent a exposer une interface OpenCL. Donc c'est le bowdel

Quels sont vos réactions/avis (calmes et mesurés) par rapport au projet PipeWire ?

Le 22 septembre 2017 à 15:05:24 MaoMeth a écrit :
Quels sont vos réactions/avis (calmes et mesurés) par rapport au projet PipeWire ?

J'ai pas bien compris ce que c'est. Mais en meme temps, il y a clairement des probleme de tearing et de synchro sur pas mal de technologie audio/video sous linux. donc si ca peut aider, ca pourrait etre pas mal.

D'ailleurs j'ai jamais fait attention à ce détail mais la synchronisation verticale d'un jeu ne fonctionne pas sur Linux il me semble, on bloque bien les FPS à 60 mais l'image déchire quand même.

Faut que je vérifie si c'est vrai

Je viens de voir ça sur Reddit :

En 2010 j'avais déjà le même problème.
Oh Ubuntu, que de bon souvenir (le singulier est voulu).

Ah oui c'est visuel comme problème quand même

Je laisse ça là, ça intéresse sûrement du monde ici : https://savecodeshare.eu/

Je suppose que la plupart d'entre vous êtes au courant mais on ne sait jamais. Je serai heureux de faire découvrir cette initiative à une seule personne.

Avec des petits liens pour les gourmands :

https://blog.mozilla.org/blog/2017/09/11/copyright-vote-change-europes-internet/
http://april.org/savecodeshare-une-campagne-pour-proteger-les-forges-logicielles-et-les-communautes-du-libre
https://www.laquadrature.net/fr/node/10288

EDIT: j'avais oublié un lien désolé

J'ai très envie d'une PS Vita, ça vaut le coup ? Il y a du jeu intéressant dessus ?