Linux? - Page 250

Hmmm tu as essaye des trucs vraiment serieux dessus ? ou juste un peu de GCC en ligne de commande et "ca marche" ?

Et pour travailler depuis ~10 ans entre x86 et ARM, bien que les puces ARM on fait d'enormes progres, il y a toujours plein de points qui pour des raison obscures (meme en connaissant l'archi) ton code a de bonne perf d'un cote, de moins bonnes de l'autres.

ARM est connu pour avoir une gestion du cache plutot... bizzare et pas forcement super efficiente, en tout cas comme peu l'etre le x86, la MMU ARM est aussi un PitA

La RPi 3 Model B+ est certes moins mal que les précédentes RPi pour faire du dev non trivial, et son gros avantage est qu'elle n'est vraiment pas chère, mais elle manque toujours nettement de puissance brute CPU, de RAM et de bande passante avec la carte SD pour les compilations plus lourdes

J'ai fait acheter une ROCKPro64 (une des diverses boards basées sur un RK3399) et une HiKey970 plus puissante et avec plus de RAM au boulot, ces machines sont d'une toute autre classe que des RPi 3 qu'on a également: le temps de build est divisé par 3 à 5. Cependant, même la HiKey 970 n'a pas la moitié de la vitesse d'un vieux Xeon W d'un modèle qui a presque 10 ans (première génération Core i7 desktop), équipé d'un HDD classique.
Il faudrait voir les perfs que la récente ODROID-N2, un peu moins puissante que la HiKey970, mais beaucoup moins chère, permet d'atteindre. Le rapport performances/prix est certainement meilleur.

Certains diront que vu le prix tu peux facilement les mettre en cluster, mais meme en mettre une infinite est loin de faire une puissante infinie.

Et ca ne change pas que certains bout de code, suivant les archis (ARM ou autre) peux marcher avec de bonne perfs sur une archi, et avoir des perfs abominable sur une autre...

Certains diront que vu le prix tu peux facilement les mettre en cluster, mais meme en mettre une infinite est loin de faire une puissante infinie.

Oui, le clustering, ça fonctionne jusqu'à un certain point. Pour le build de code natif, le scaling est sub-linéaire. Si j'essaie de convaincre mon chef de projet de faire des builds distribués plus complexes pour gagner quelques minutes sur un build qui prend moins de 20' sur un vieux Xeon, je sais ce qu'il va me dire, et il aura raison
J'ai déjà augmenté le parallélisme et allégé le build (réduction des headers, etc.), de telle sorte que sur un Core i7 Ivy Bridge mobile avec HT activé et un HDD classique, cache froid (# echo 3 > /proc/sys/vm/drop_caches) un make -j6 d'une des deux parties principales dépasse 500% CPU en moyenne sur plusieurs minutes. On doit pouvoir aller légèrement plus loin sur le code et le système de build, mais c'est plus efficace et plus rentable d'utiliser des machines plus récentes avec plus de coeurs, d'introduire des SSDs, et j'en passe.

Et ca ne change pas que certains bout de code, suivant les archis (ARM ou autre) peux marcher avec de bonne perfs sur une archi, et avoir des perfs abominable sur une autre...

Ca peut arriver.

C’est plutôt courant en fait, j’ai eu le problème récemment, du code tout à fait inovent, suivant comment il est compilé il est 3x plus lent, et a fréquence équivalente il est largement plus lent sur arm que sur pc

A propos de clustering de petites machines: une distribution légère, mais cependant certifiée, de Kubernetes ("K8s"), baptisée "K3s", a été officiellement annoncée hier. Elle vise notamment les machines de la classe RPi 3, où il est difficile de tourner un K8s habituel (en plus des applications que justement, la machine est censée tourner) parce que c'est trop gourmand en RAM.



->

Un jeu d'aventures textuel sous forme de système de fichiers (la vidéo donne une idée de comment ça marche) :

Lol pas mal

Ca me rappelle AdventureOS, l'aspect graphique en moins.

J'hésite entre génial et débile.

Denial

Uther (./7480) :
J'hésite entre génial et débile.

Inutile… donc indispensable ?

Excellent

Plus sérieux : MS change son fusil d'épaule ; à l'avenir, le support des applis Linux sous Windows n'utilisera plus une espèce de WINE dans l'autre sens, mais un "vrai" noyau Linux tournant dans une VM légère :

Uh?

Ca ca être terrible en terme de perds, et même encore pire en terme de contrôle...

La solutions qu’il avaient était très bien, c’est quoi cette histoire ??!!!!

Non justement, ils changent d'approche parce que la solution actuelle a des gros problèmes de perfs (jusqu'à 20x plus lent qu'un "vrai" Linux à hardware identique ; non, je sais pas pourquoi c'est le cas). Et on arrive à faire de la virtualisation avec un impact modéré sur les perfs.

Oui et tu peu oublier toutes les passerelles entre le monde Windows et Linux avec la solution Vm.

Le FS sera (peut être) plus rapide, et plein d’autre choses seront plus lente et la consommation mémoire sera bien plus importante et surtout permanente.

Ouais je sais pas trop quoi penser, mais j'attends de voir s'ils implémentent la VM intelligemment… ça peut être intéressant si c'est le cas.

./7487> Bah les perfs sont correctes. C'est vrai qu'un rm -rf genre est lent, mais pour la plupart des trucs, rien de bien notable.

Godzil (./7488) :
Oui et tu peu oublier toutes les passerelles entre le monde Windows et Linux avec la solution Vm.

Boah, pas forcément, il y a tout un tas de possibilités de faire interagir une VM avec son hôte de façon propre, donc si c'est bien pensé ça peut être transparent pour l'utilisateur.
Par contre, je trouve que ça va un peu à l'encontre de ce qu'ils ont annoncé avec Windows Terminal pour avoir un environnement unifié CMD/PowerShell/WSL.

Heu, non en fait non pas vraiment, c’est absolument pas comparable. WSL tel qu’il fonctionne actuellement, tout process Linux est en fait un process NT avec une couche de saveur un peut différente d’un process Win32 classique, mais tous les outils permettent de les voir, tuer et interagir. Ce n’est pas le cas avec une VM

(Je sais lespremiere version de WSL cloisonnait les process Linux, mais ce n’est plus le cas)

Sans compter la lourdeur d’une VM, alors à moins que Microsoft n’utilise pas une VM mais fasse des modify dans le kernel pour en remplacer le scheduler et memory manager, et bon courage c’est probablement une tâche bien plus complexe que WSL tel qu’il est actuellement, tu n’auras aucun de ces trucs de manière simple. Les IPC devront passer par une forme de réseau, idem pour lancer un process Windows, le FS sera soit une partition dédié soit un fichier (énorme) sur ton disque dur, et ton noyau Linux prendra de la mémoire physique en permanence, ça ne sera pas juste le process que tu lances..

assez d'accord avec godzil, c'est de la merde ce changement, on fait aussi bien avec virtual box... l'intéret de wsl c'était l'intégration avec windows...

Godzil (./7491) :
le FS sera soit une partition dédié soit un fichier (énorme) sur ton disque dur

Pas forcément, pour le coup, il y a des couches d'abstraction qui permettent ça assez facilement (et heureusement, sinon on ne pourrait pas faire de partage hôte/invité avec VirtualBox, par exemple).

Godzil (./7491) :
et ton noyau Linux prendra de la mémoire physique en permanence

Ça dépend aussi comment c'est géré à ce niveau, tu peux très bien avoir le kernel qui est géré comme d'autres niveaux d'abstraction (win16 en son temps, typiquement).
Après, il faut voir comment ça se passe au final, et quel est le niveau de porosité VM-OS.

Non nil, deja l'enorme fichier n'a rien a voir avec ce que tu dit, et on ne peux pas faire autrement, sinon c'est pas un FS natif et on retrouve les meme problemes (en pire) qu'avec le WSL actuel.


Et non pour le kernel, c'est tout ou rien, si c'est une VM tu ne peux pas charger/decharger le kernel a ton bon vouloir, ni pire lancer un kernel pour chaque app que tu lance, ca serait sacrément moche et monstrueux (et empecherais completement les RPC entre apps non issues du meme kernel)


Non les VM ne permettent pas de RPC entre l'hote et les apps, sinon ce n'est plus une VM a proprement parler. Les seules RPC que tu peux esperer sont via reseau.

Bref, WSL2 == Virtualisation du kernel == tres loin de ce que Docker prone sous Linux, et ce que WSL propose, Aussi tres loin de ce que WINE propose. Si WINE est plus proheminent que ReactOS ce n'est pas pour rien.

Apres tout, on pourrais sous linux faire une VM "light" qui fait tourner ReactOS pour faire tourner les app Windows hein!

Alors pourquoi les gens preferent WINE?

Godzil (./7494) :
Alors pourquoi les gens preferent WINE?

Moi je préfère une VM Windows XP que Wine, en fait, justement parce que WINE vient avec tout un tas de problèmes non pas d'intégrations avec Linux, mais dans les échanges inter-applications Windows (tout ce qui est OLE, une partie de ce qui est échangé en interne [typiquement, faire du MIDI entre deux applications sous WINE est de l'ordre de l'impossible, donc faire fonctionner une banque de son sur UVI Workstation depuis un séquenceur ne fonctionne pas, ni depuis une autre application Windows, ni depuis une application Linux... pour arriver à quelque chose de potable, il faut lancer UVIW dans une VM et faire du routage MIDI entre l'application Linux et la VM - et aucun souci évidemment dans l'environnement Windows]).
Bref tout n'est pas magiquement magique et chaque solution vient avec ses avantages ; reste à voir comment c'est intégré au final...

Tu utilise un Windows virtualisé pour faire de l'audio? #puke#

Tu aime vraiment te faire mal mon pauvre Nil!

Ah ben si tu savais où il se le met en plus, son Windows, tu crois pas si bien dire !

faut bien comprendre en plus que son installation de XP, c’est facile 500 mégas bites !!!!!!!

Ha non Folco, pas toi!

Chez Nil l'été, le démon de MIDI arrive a 14h parce que la RTC de linux est en UTC.

Tsss

Godzil (./7496) :
Tu utilise un Windows virtualisé pour faire de l'audio? #puke#

J'ai essayé de me passer de Windows pour faire de l'audio et faire du tout Linux (c'était, à peu de choses près, ma seule contrainte lourde à un passage tout Linux). Je n'ai pas réussi ; j'ai testé un temps la solution intermédiaire de faire ce mélange Linux+VM légère Windows, qui fonctionne plutôt bien, mais j'ai fini par revenir à du tout Windows à la maison (et du tout Linux au boulot, sauf pour une seule application, parce qu'impossible de lire facilement une carte Mifare Desfire avec Linux, alors que j'ai trouvé un outil qui me permet de le faire sans prise de tête sous Windows).