Mais Tu n'utilises pas LibreOffice sur une tablette de toute façon : les ressources sont plus limitées, donc il faut des performances plus pointues quitte à faire des compromis sur la richesse des fonctionnalités (je ne parle pas de pertinence, hein, mais de richesse).
Pour ce qui est du probleme de performance de LibreOffice, ce n'est pas lie du tout a la richesse des fonctionnalites, mais principalement voir meme uniquement a l'architecture archaique de leur code. Ils ont pas mal de chose en cours pour ameliorer les choses et si quelqu'un les sponsorise en 6 mois, tu auras une suite utilisable sur telephone en terme de performance avec le meme niveau de fonctionnalite (D'ailleur avec leur support OpenCL, tu devrais outperformer la concurrence sur le tableur).
Par contre le vrai probleme, c'est qu'il faut effectivement faire une interface specifique pour tablette et une autre pour telephone. C'est dans cette optique qu'ils passent a XML pour definir leurs interfaces pour avoir plus de souplesse dans ca definition.
En gros le grand nettoyage a des objectifs bien clair sur ou ils vont…
Alors en general, l'acceleration materiel se limite au support d'un plan hardware specifique, overlay (ce qui permet d'eviter la mise a jour de l'ecran). Ce qui va avec cet overlay, c'est le support de la convertion hw de YUV->RGB. Pas vraiment de quoi casser trois pattes a un canard. Les fonctionnalites plus avance comme presenter par la va api et consort sont rarement configure et se limite a quelques codec (mpeg2 et h264 en general). Ce qui fait que statistiquement, ce n'est pas quelques choses sur lequel il faut compter.
Tu ne donnes aucune information concernant ce que tu tests… de plus, tu mélanges composite et rendu 2d. Ça n'a aucun rapport ! Donc je me répète, mais faire du rendu composite via le cpu est la plus part du temps plus performant en terme de consommation. Si tu parles de passer par x et non par un compositeur cpu, clairement x n'est plus compétitif et c'est pourquoi on se dirige vers wayland.
Maintenant, une liste des choses ou un gpu n'est pas bon. Mettre a jour une partie de l'écran,genre le curseur qui clignote. Ou la mise a jour du contenu d'une fenêtre qui n'a pas été rendu sur le gpu (genre un film). Ça suffira comme exemple. Et ce serait bien que tu sois plus précis dans tes termes…
De quelle concurrence tu parles ?!? Je n'en connais aucune avec un début de performance 2d descente !
Si tu as fais un peu d'opengl et de 2d, et que tu as essaye d'optimiser tout ça… tu auras découvert que ceux ci ne sont pas adapté du tout pour cette tâche et qu'on les contorscionne excessivement pour arriver a quelque chose !
Ah sinon,sur un autre Linux, Android, ils ont effectivement le même "problème" , le mode sauver de la batterie force le passage en rendu cpu… et je parie que sur iphone, ils font de même. Faudrais que je passe un peu de temps un jour a détailler pourquoi le cpu est plus efficace …
Va falloir venir avec un veritable argument la. Parce que pour le coup, il est assez facile de rentrer dans le code, j'en veux pour preuve le nombre de contribution.
sa volonté de vouloir tout remplacer d'un coup
La volonte de systemd, c'est de repondre a un probleme. Le fait est qu'il est plus facile de faire tout proprement en integrant toute la chaine que de diviser le tout en 25 projets differents qui n'auront pas autant de traction et en dispersant les forces. Integrer ca aide clairement a faire bouger les choses, un seul projet dans lequel ameliorer les choses, impactant toutes les distributions moderne de linux, pas de probleme de synchronisation de version, …
l'avis de RedHat
Ah ah ah, non, pas l'avis de Redhat, l'avis des developpeurs actifs sur Linux. C'est ceux qui codent qui font la direction, Redhat a certe un certain nombre de dev, mais ils n'ont pas le pouvoir d'imposer leur solution. De meme pour Ubuntu. Il y a une raison pour que Systemd progresse bien plus vite et couvre bien plus de cas d'usage que Upstart…
Je peux reprendre exactement les même critères et les appliquer aux petrole, gaz, charbon et photovoltaique… l'énergie propre n'existe pas, quand au coût,il ne reflète jamais que l'effort humain estimé a l'instant t.
Peux-tu etres plus precis, parce que les cout caches des energies, c'est un peu le cas de toute. Il n'y a pas de source d'energie qu'on achete a un prix non subventionne.
Xrender, c'est de la p….. de m…. ! Et je suis serieux sur ce sujet, on aurait du l'abandonner il y a des annees deja ! Ca utilise une acceleration 2D fournit par le driver de X utilise. Techniquement depuis que ca existe, il n'y a jamais eu un seul driver qui l'implemente avec des performances correct (J'entend par la qui soit juste a la hauteur des performances du rendu en software sur CPU).
En fait ca a toujours ete un ordre de grandeur plus lent que le rendu software dans les EFL, c'est pour ca qu'on en a abandonne le support. Sans compter que les deformations arbitraire ne sont pas possible et donc limite grandement ses possibilites. Ce fut une perte de temps. Il y aurait mieux valu travailler plus sur OpenGL pour en ameliorer ses performances et son adequation avec le rendu 2D. Au moins, c'est une erreur qui ne se reproduira pas avec Wayland !
Je bosses sur les EFL, toolkit graphique, on fonctionne avec un systeme pour l'instant avec uniquement 2 threads la majorite du temps (main loop et thread de rendu). Le fait est qu'il y a un certain nombre de probleme observable avec le "scheduler" actuel.
Ainsi lorsque l'utilisateur n'a pas interagit avec la machine pendant quelques secondes et se met a faire une action importante (cas normal de je lis ce qui est a l'ecran avant de passer a un autre ecran), on se retrouve a avoir un enorme frame drop du fait que tous les coeurs sont globalement au repos, et qu'ils sont incapable d'accelerer instantanement tous en meme temps. Si on force a la frequence maximum et tous les coeurs allumes, il n'y a pas de souci. Or le toolkit sait quand il va rendre une frame, il sait dire a ce moment la qu'il va etre dans un premier temps CPU bound sur la traverse du scene graph et le calcul de ce qui doit etre dessine avant d'avoir un mix de CPU et memory bound en fonction des operations de rendu qu'il va faire (en GL, ca sera majoritairement du memory bound et on a un interet a avoir les deux threads schedule sur deux coeurs differents pour qu'ils puissent beneficier de tout le L1 possible).
Et bien entendu quand le CPU est enfin completement reveille, il est trop tard. L'animation est fini et tout ce qu'il a appris du passe est juste plus d'actualite ! On se retrouve donc dans une situation ou tous les coeurs sont enfin allume et la frequence au maximum, mais on n'a plus rien a faire. Echec total du scheduler et utilisateur ayant l'impression d'avoir un hardware incapable de gerer son application.
D'ou l'interet de permettre a l'user space de dire au kernel ce qu'il se passe. On sait ce qui va se passer, on sait combien de temps notre animation va durer. De plus, si on avait une telle infrastructure, ca vaudrait le cout d'augmenter le nombre de thread en les specialisant encore plus. On pourrait tirer clairement mieux parti du hardware si le kernel et l'user space communique un peu plus. Il ne faut pas oublier qu'un toolkit moderne fournit toutes les primitives d'acces aux systemes graphiques et IO ainsi qu'une certaine abstraction des threads. Il est donc possible que dans la majorite des cas, le fait de juste integrer ces hints dans le toolkit soit suffisant pour avoir un benefice notable.
L'alternative moins elegante est celle d'Android. Elle consiste a toujours refuser le dialogue avec l'user space et a faire un scheduling ou on boost le CPU au moment d'une phase interactive. Je ne trouve pas cette solution elegante, car le systeme va faire une pointe de consomation d'energie qui n'est probablement pas necessaire (et plus on aura de coeurs, plus cette pointe risque d'etre surdimensionne).
KWin n'a pas a ma connaissance de compositing software :-) Je parlerais bien d'un mode dans lequel KWin fairait tout de meme les effets de compositing, mais en software au lieu de GPU.
Ainsi tu as tous les benefices du rendu en compositing pour sauvegarder la batterie, comme limiter le nombre d'update a un framerate maximal. Mais tu ne payes pas les exces de OpenGL qui force le redraw complet de l'ecran (typique quand tu n'as qu'un curseur qui clignote a l'ecran).
Et ce dont parle bien Martin dans cet article, c'est de desactiver le compositing completement et de s'appuyer sur X. Et ca je peux te dire, qu'il a raison. Tu n'as pas envie de laisser faire X de nos jours pour gerer le rendu a l'ecran (C'est une des raisons pour lesquels on se dirige vers Wayland).
Bon apres, il y a des trucs qui seraient assez sympa et qu'on ne fait pas dans Enlightenment, c'est de faire un switch de profile quand on passe sur batterie pour automatiquement changer le nombre de FPS et passer en rendu software. Pour l'instant, ca, c'est a faire a la main.
Ton gestionnaire de fenetre et sa configuration ont aussi un impact important. De meme que les logiciels que tu utilisent. Ainsi si tu utilises Enlightenment, je te conseille d'utiliser le backend software, il permet de gagner sur mon PC 1h d'autonomie par rapport au backend OpenGL. La raison est assez simple. Quand tu fais de l'OpenGL, tu demarres un CPU supplementaire qui va consommer de l'energie. Hors le rendu OpenGL n'est pas aussi optimal que le rendu software, car on est oblige de mettre a jour tout l'ecran au lieu de juste ce qui a change. Ainsi quand tu as un curseur qui clignote a l'ecran, tu consommes toute la puissance de ta carte graphique a faire le rafraichissement de 90% de l'ecran qui ne sert a rien.
Je n'ai jamais pris le temps de faire un benchmark et une comparaison avec toutes les configurations possible de tous les desktop (J'ai pas envie de les installer sur mon PC pour commencer). Mais ce que je viens de dire doit etre vrai pour tous les composite managers.
Sinon apres il y a aussi d'autres trucs, genre si tu as une puce d'acceleration video qui ne marche que sous Windows, celle-ci est pris en compte dans les tests de batterie et diminue la consomation. Ce qui n'est probablement pas le cas sous Linux. De plus, je ne sais pas si ils prennent en compte dans leur mesure l'utilisation permanente de site web comme GMail ou Facebook qui sont des vrais pompes a batterie (De maniere general, un navigateur web c'est pas une bonne idee de l'utiliser si on veut de la batterie).
Oh et pour info, avec toutes les bonnes options et la bonne configuration logiciel, j'ai une heure de batterie supplementaire que ce qui est annonce par le constructeur sous Windows…
Desole de faire un gros tas de toutes les decisions de scheduling en mettant dedans aussi la prise de decision sur les ressources a rendre disponible pour les applications (puisque c'est globalement l'idee derriere allumer/eteindre et regler la frequence des differents coeurs). Mais bon, d'un point de vue user-space, c'est la meme problematique :-)
Aujourd'hui, le noyau est aveugle. Il n'a aucune idee de ce qu'une tache va potentiellement faire dans le futur. Des IO ? Des acces memoire ? Une utilisation intensive du CPU ? Cela a directement un impact sur les performances, la reactivite et la consomation batterie. Il y a deja des cooperations entre l'user space et le noyau, c'est juste une de plus. Bien entendu le kernel ne vas pas baser ses decisions uniquement sur ces hints sans ajuster un peu a posteriori ses decisions, mais si le systeme coopere, c'est nettement plus malin. Si un toolkit fait du rendu graphique, il va pouvoir assez facilement indiquer quel thread va etre CPU ou memory bound dans le futur. Ce que le kernel ne pourra jamais savoir ou que lorsque ce sera trop tard.
Ce n'est pas du cooperatif au sens de je relache le CPU quand j'ai fini de faire mes betises, mais du cooperatif au sens des hints qu'on met sur une page lors d'un mmap. L'idee est d'aider le noyau a prendre la bonne decision. Ca ne sert a rien d'allumer 4 coeurs pour 4 taches IO bound, par contre si elles sont CPU bound, ca serait une tres bonne idee de le faire tout de suite, et pas quand elles seront presque fini…
Je vois au moins deux choses qu'ils manquent aujourd'hui au noyau Linux et sur lesquels personnes ne travaillent a ma connaissance.
La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire. Typiquement le comportement actuel est de ne jamais marquer une page memoire comme etant libere dans une application, mais de se baser sur le fait que si une page n'est plus utilise, on peut la swapper. Resultat on copie globalement des pages inutiles dans la swap… et cela impact les performances. Il serait nettement plus malin de pouvoir marquer des pages memoires comme sans importance pour l'user space de maniere a ce que le kernel puisse les jeter. Pour cela, il y a un patch actuellement en developpement, mais pas encore upstream. Meme si cela ameliorerait la situation, il resterait le cas ou tout le systeme commence a etre short niveau memoire. A ce moment la, les applications pourraient, de maniere cooperative, vider leur cache si elles ne sont pas active. Enfin en derniere recour, elle pourrait decider de s'arreter completement avant que l'OOM ne decide de les tuer, plutot que de faire un arret a l'arrache. Pour ces deux derniers cas, il n'y a pas a ma connaissance de travaux upstream sur le sujet (Android a une implementation partielle de ce genre d'idee).
Le deuxieme endroit qui necessite des ameliorations, c'est le scheduling. Le noyau est completement aveugle a ce qui va se passer dans l'espace utilisateur. Il joue au devinette en esperant que ce qui s'est passe dans le passe va se repeter a court terme. C'est un peu domage, car les applications, elles savent ce qu'elles vont faire. Or dans un systeme moderne, le scheduling est devenu tres complique. Frequence et nombre de coeur actif variable. Characteristique des coeurs differentes. Difference de bande passante memoire, IO et CPU tres grande. Ce qui rend le boulot d'un scheduler assez impossible. Android a un scheduler un peu different maintenant, au lieu d'ajuster au fur et a mesure la charge, facon TCP, il fait un gros burst des qu'on lui en demande un petit peu et redescend progressivement (en frequence et coeur). Cela permet d'avoir une reactivite plus grande aux actions de l'utilisateurs. Mais cela n'est pas forcement optimal d'un point de vue energie. A quoi cela peut-il servir de demarrer un nouveau coeur, si on a une tache qui va etre bloque par les IO.
La solution est "assez" simple, il faut que l'espace utilisateur donne l'information au kernel. Si le kernel peut savoir qu'il a des taches IO bound, memory bound ou CPU bound, il a alors une information nettement plus pertinente sur le futur et peux demarrer de maniere efficace avec la bonne frequence les coeurs qui sont necessaire avec une meilleur probabilite de reussite. Cela necessite de modifier la libc pour exposer un nouvel attribut sur les threads et aussi les process. Ensuite la majorite des operations sont maintenant fait par des toolkits comme Qt, les EFL voir meme la SDL et cela limite donc les endroit a modifier pour prendre avantage d'une telle solution.
Voila, juste une petite liste d'idee de chose qui pourrait etre ameliore niveau user space et aurait un impact direct sur l'utilisation de tous les jours de ton PC. Avoir une machine plus reactive meme quand elle est charge et qui tire meilleur partie de sa batterie et de ses processeurs, ca serait pas mal comme amelioration, non ?
Tester la résistance de la couche simulation réseau d'un hyperviseur c'est bien, mais c'est la couche OpenBSD native que tu veux tester. Dans le genre de tests que tu préconises il est impossible de savoir si c'est OpenBSD qui est en défaut ou si c'est l'émulation.
Ok, mais dans ce cas, si les seuls machines qui ont besoin d'etre allume 24h/24 sont pour ce genre de tests, pourquoi pas prendre des trucs genre ARM voir un ATOM qui consommeront une fraction de l'energie qu'il semble consommer.
-Peut-on effacer un compte et les données associées?
Idem, pour moi c'est faisable (peut être difficilement), mais une fonctionnalité à mettre dans la beta.
Plutot que de chercher a effacer a un compte, pourquoi perpetuellement repliquer toutes ces donnees ? C'est twitter. Ce n'est pas une solution de stockage. Personne n'est interresse par les twitt d'il y a plus de 15 jours. Donc pourquoi ne pas implementer directement dans le systeme un droit a l'oublie et arreter de repliquer les informations trop vieille. Effacer un compte devient alors automatique.
Ca serait cool si cela pouvait tirer parti de Terminology, l'emulateur de terminal du projet Enlightenment. Il y a probablement moyen de faire quelque chose de tres sympa en tirant benefice des deux projets. Par exemple utiliser directement des images pour les differente signaletique. Mais il y a probablement la possibilite de faire plus.
Faudra regarder dans le detail, mais il y a un detail a ne pas oublier, c'est qu'on a besoin de pouvoir faire un acces aleatoire aux pixels (pour pouvoir supporter le clipping). Il faut donc faire attention a ne pas etre force de lire tout une ligne pour trouver le pixel qui nous interresse. De plus il faut pouvoir chainer la mecanique de saut pour trouver le pixel qui nous arrange, a celui ou on blit en mixant le code avec le reste de la logique de decompression. Ca pose certaine contrainte. Mais je regarderais si il n'y a pas moyen de moyenner quelques choses avec Lz4, meme si ma semble tres tres complique au vu de l'ensemble des contraintes.
Le probleme du vectoriel, c'est qu'on se retrouve avec des formules de courbe assez complexe a execute niveau CPU dans tous les cas. Je ne pense pas qu'il soit possible d'avoir un format vectoriel qui est des performances proches de ce que font de simple blit. Il faudrait que la difference entre bande passante memoire et performance CPU soit encore plus grande qu'actuellement pour que cela soit vraiment plus interressant (En esperant arriver a faire tenir le tout dans pas trop de code pour eviter de perdre de l'autre cote dans les temps d'acces au code).
Pour l'instant, tous les systemes de rendu vectoriel que je connais sont un ordre de grandeur plus lent que ceux qu'on a. Pour etre interressant, il faudrait trouver un qui soit deja dans le meme ordre de grandeur puis voir si on peut l'optimiser pour le rendre competitif. Je n'en connais pas qui corresponde a cette objectif…
Malheureusement sur le hard auquel on a acces, on ne peut pas mesurer la consomation independante de chaque sous systeme (Systom On Chip avec memoire Package On Package). Par contre, on a acces aux spec precises de consomation en fonction de la frequence du CPU, memoire, GPU et de la bande passante utilise pour chaque niveau de la hierarchie memoire (qui sont toute mesurable en temps reel), on peut faire une estimation au doigt leve de ou part la consomation d'energie. Ensuite en ajustant un algo dans un sens ou dans un autre, on peut verifier si notre theorie est bonne et ameliorer les choses.
On avance un peu dans le noir, surtout avec les experimentations sur la compression, car globalement la regle est moins on en fait, moins on consomme. Sauf que lorsqu'on compresse la memoire, on fait tourner plus le CPU, mais on fait moins de transfert memoire et on attend aussi moins sur le sous systeme memoire. Avant d'experimente, on n'etait pas sur de gagner au final. Mais il semble que le plus simple c'est de d'abord optimiser pour les performances, puis la memoire, et apres d'ajuster pour la consomation batterie si necessaire. Cela semble pour l'instant toujours porter ses fruits comme strategie.
Il n'y a pas que la vitesse brute et visible par l'utilisateur. Il y aussi la possibilite de laisser tourner d'autre application en tache de fond et d'avoir une duree d'utilisation sur batterie qui reste "invisible" a l'utilisateur. Tant que tu ne codes qu'une petite application que l'utilisateur ne va pas utiliser pendant des heures, ca ne pose pas de probleme.
Mais GMail, Facebook, Twitter ou G+, ceux sont les premieres choses que je coupe quand je passe sur batterie. Ca tue litteralement la batterie de mon PC (je n'ai pas d'iPad, mais les consequence seront les meme). L'HTML5, c'est un joli hack pour deployer une petite application rapidement sur plein de terminaux, mais ce n'est pas forcement la solution pour tous les cas…
Un mixe de benchmark et d'application écrites pour les deux plateformes. ensuite tu utilise le même hardware, tu enlèves la batterie et tu fais tourner ça sur une alimentation qui te donne une trace numérique. Quand je dis le même hardware, je parle bien d'un même device en dual boot, car entre deux devices il peut y avoir de légère différence de consommation pour plein de petit détail.
[^] # Re: Mouahis
Posté par cedric . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 3.
Pour ce qui est du probleme de performance de LibreOffice, ce n'est pas lie du tout a la richesse des fonctionnalites, mais principalement voir meme uniquement a l'architecture archaique de leur code. Ils ont pas mal de chose en cours pour ameliorer les choses et si quelqu'un les sponsorise en 6 mois, tu auras une suite utilisable sur telephone en terme de performance avec le meme niveau de fonctionnalite (D'ailleur avec leur support OpenCL, tu devrais outperformer la concurrence sur le tableur).
Par contre le vrai probleme, c'est qu'il faut effectivement faire une interface specifique pour tablette et une autre pour telephone. C'est dans cette optique qu'ils passent a XML pour definir leurs interfaces pour avoir plus de souplesse dans ca definition.
En gros le grand nettoyage a des objectifs bien clair sur ou ils vont…
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 4.
Alors en general, l'acceleration materiel se limite au support d'un plan hardware specifique, overlay (ce qui permet d'eviter la mise a jour de l'ecran). Ce qui va avec cet overlay, c'est le support de la convertion hw de YUV->RGB. Pas vraiment de quoi casser trois pattes a un canard. Les fonctionnalites plus avance comme presenter par la va api et consort sont rarement configure et se limite a quelques codec (mpeg2 et h264 en general). Ce qui fait que statistiquement, ce n'est pas quelques choses sur lequel il faut compter.
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 3.
Tu ne donnes aucune information concernant ce que tu tests… de plus, tu mélanges composite et rendu 2d. Ça n'a aucun rapport ! Donc je me répète, mais faire du rendu composite via le cpu est la plus part du temps plus performant en terme de consommation. Si tu parles de passer par x et non par un compositeur cpu, clairement x n'est plus compétitif et c'est pourquoi on se dirige vers wayland.
Maintenant, une liste des choses ou un gpu n'est pas bon. Mettre a jour une partie de l'écran,genre le curseur qui clignote. Ou la mise a jour du contenu d'une fenêtre qui n'a pas été rendu sur le gpu (genre un film). Ça suffira comme exemple. Et ce serait bien que tu sois plus précis dans tes termes…
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 4.
De quelle concurrence tu parles ?!? Je n'en connais aucune avec un début de performance 2d descente !
Si tu as fais un peu d'opengl et de 2d, et que tu as essaye d'optimiser tout ça… tu auras découvert que ceux ci ne sont pas adapté du tout pour cette tâche et qu'on les contorscionne excessivement pour arriver a quelque chose !
Ah sinon,sur un autre Linux, Android, ils ont effectivement le même "problème" , le mode sauver de la batterie force le passage en rendu cpu… et je parie que sur iphone, ils font de même. Faudrais que je passe un peu de temps un jour a détailler pourquoi le cpu est plus efficace …
[^] # Re: Mini précision, variable d'environnement
Posté par cedric . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 5.
Va falloir venir avec un veritable argument la. Parce que pour le coup, il est assez facile de rentrer dans le code, j'en veux pour preuve le nombre de contribution.
La volonte de systemd, c'est de repondre a un probleme. Le fait est qu'il est plus facile de faire tout proprement en integrant toute la chaine que de diviser le tout en 25 projets differents qui n'auront pas autant de traction et en dispersant les forces. Integrer ca aide clairement a faire bouger les choses, un seul projet dans lequel ameliorer les choses, impactant toutes les distributions moderne de linux, pas de probleme de synchronisation de version, …
Ah ah ah, non, pas l'avis de Redhat, l'avis des developpeurs actifs sur Linux. C'est ceux qui codent qui font la direction, Redhat a certe un certain nombre de dev, mais ils n'ont pas le pouvoir d'imposer leur solution. De meme pour Ubuntu. Il y a une raison pour que Systemd progresse bien plus vite et couvre bien plus de cas d'usage que Upstart…
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 8.
Je peux reprendre exactement les même critères et les appliquer aux petrole, gaz, charbon et photovoltaique… l'énergie propre n'existe pas, quand au coût,il ne reflète jamais que l'effort humain estimé a l'instant t.
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 10.
Suffit de faire une bête boucle infini dans plusieurs thread pour obtenir le même résultat.
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 2.
Peux-tu etres plus precis, parce que les cout caches des energies, c'est un peu le cas de toute. Il n'y a pas de source d'energie qu'on achete a un prix non subventionne.
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 5.
Xrender, c'est de la p….. de m…. ! Et je suis serieux sur ce sujet, on aurait du l'abandonner il y a des annees deja ! Ca utilise une acceleration 2D fournit par le driver de X utilise. Techniquement depuis que ca existe, il n'y a jamais eu un seul driver qui l'implemente avec des performances correct (J'entend par la qui soit juste a la hauteur des performances du rendu en software sur CPU).
En fait ca a toujours ete un ordre de grandeur plus lent que le rendu software dans les EFL, c'est pour ca qu'on en a abandonne le support. Sans compter que les deformations arbitraire ne sont pas possible et donc limite grandement ses possibilites. Ce fut une perte de temps. Il y aurait mieux valu travailler plus sur OpenGL pour en ameliorer ses performances et son adequation avec le rendu 2D. Au moins, c'est une erreur qui ne se reproduira pas avec Wayland !
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 10.
Je bosses sur les EFL, toolkit graphique, on fonctionne avec un systeme pour l'instant avec uniquement 2 threads la majorite du temps (main loop et thread de rendu). Le fait est qu'il y a un certain nombre de probleme observable avec le "scheduler" actuel.
Ainsi lorsque l'utilisateur n'a pas interagit avec la machine pendant quelques secondes et se met a faire une action importante (cas normal de je lis ce qui est a l'ecran avant de passer a un autre ecran), on se retrouve a avoir un enorme frame drop du fait que tous les coeurs sont globalement au repos, et qu'ils sont incapable d'accelerer instantanement tous en meme temps. Si on force a la frequence maximum et tous les coeurs allumes, il n'y a pas de souci. Or le toolkit sait quand il va rendre une frame, il sait dire a ce moment la qu'il va etre dans un premier temps CPU bound sur la traverse du scene graph et le calcul de ce qui doit etre dessine avant d'avoir un mix de CPU et memory bound en fonction des operations de rendu qu'il va faire (en GL, ca sera majoritairement du memory bound et on a un interet a avoir les deux threads schedule sur deux coeurs differents pour qu'ils puissent beneficier de tout le L1 possible).
Et bien entendu quand le CPU est enfin completement reveille, il est trop tard. L'animation est fini et tout ce qu'il a appris du passe est juste plus d'actualite ! On se retrouve donc dans une situation ou tous les coeurs sont enfin allume et la frequence au maximum, mais on n'a plus rien a faire. Echec total du scheduler et utilisateur ayant l'impression d'avoir un hardware incapable de gerer son application.
D'ou l'interet de permettre a l'user space de dire au kernel ce qu'il se passe. On sait ce qui va se passer, on sait combien de temps notre animation va durer. De plus, si on avait une telle infrastructure, ca vaudrait le cout d'augmenter le nombre de thread en les specialisant encore plus. On pourrait tirer clairement mieux parti du hardware si le kernel et l'user space communique un peu plus. Il ne faut pas oublier qu'un toolkit moderne fournit toutes les primitives d'acces aux systemes graphiques et IO ainsi qu'une certaine abstraction des threads. Il est donc possible que dans la majorite des cas, le fait de juste integrer ces hints dans le toolkit soit suffisant pour avoir un benefice notable.
L'alternative moins elegante est celle d'Android. Elle consiste a toujours refuser le dialogue avec l'user space et a faire un scheduling ou on boost le CPU au moment d'une phase interactive. Je ne trouve pas cette solution elegante, car le systeme va faire une pointe de consomation d'energie qui n'est probablement pas necessaire (et plus on aura de coeurs, plus cette pointe risque d'etre surdimensionne).
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 4.
KWin n'a pas a ma connaissance de compositing software :-) Je parlerais bien d'un mode dans lequel KWin fairait tout de meme les effets de compositing, mais en software au lieu de GPU.
Ainsi tu as tous les benefices du rendu en compositing pour sauvegarder la batterie, comme limiter le nombre d'update a un framerate maximal. Mais tu ne payes pas les exces de OpenGL qui force le redraw complet de l'ecran (typique quand tu n'as qu'un curseur qui clignote a l'ecran).
Et ce dont parle bien Martin dans cet article, c'est de desactiver le compositing completement et de s'appuyer sur X. Et ca je peux te dire, qu'il a raison. Tu n'as pas envie de laisser faire X de nos jours pour gerer le rendu a l'ecran (C'est une des raisons pour lesquels on se dirige vers Wayland).
Bon apres, il y a des trucs qui seraient assez sympa et qu'on ne fait pas dans Enlightenment, c'est de faire un switch de profile quand on passe sur batterie pour automatiquement changer le nombre de FPS et passer en rendu software. Pour l'instant, ca, c'est a faire a la main.
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 8.
Ton gestionnaire de fenetre et sa configuration ont aussi un impact important. De meme que les logiciels que tu utilisent. Ainsi si tu utilises Enlightenment, je te conseille d'utiliser le backend software, il permet de gagner sur mon PC 1h d'autonomie par rapport au backend OpenGL. La raison est assez simple. Quand tu fais de l'OpenGL, tu demarres un CPU supplementaire qui va consommer de l'energie. Hors le rendu OpenGL n'est pas aussi optimal que le rendu software, car on est oblige de mettre a jour tout l'ecran au lieu de juste ce qui a change. Ainsi quand tu as un curseur qui clignote a l'ecran, tu consommes toute la puissance de ta carte graphique a faire le rafraichissement de 90% de l'ecran qui ne sert a rien.
Je n'ai jamais pris le temps de faire un benchmark et une comparaison avec toutes les configurations possible de tous les desktop (J'ai pas envie de les installer sur mon PC pour commencer). Mais ce que je viens de dire doit etre vrai pour tous les composite managers.
Sinon apres il y a aussi d'autres trucs, genre si tu as une puce d'acceleration video qui ne marche que sous Windows, celle-ci est pris en compte dans les tests de batterie et diminue la consomation. Ce qui n'est probablement pas le cas sous Linux. De plus, je ne sais pas si ils prennent en compte dans leur mesure l'utilisation permanente de site web comme GMail ou Facebook qui sont des vrais pompes a batterie (De maniere general, un navigateur web c'est pas une bonne idee de l'utiliser si on veut de la batterie).
Oh et pour info, avec toutes les bonnes options et la bonne configuration logiciel, j'ai une heure de batterie supplementaire que ce qui est annonce par le constructeur sous Windows…
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 7.
Desole de faire un gros tas de toutes les decisions de scheduling en mettant dedans aussi la prise de decision sur les ressources a rendre disponible pour les applications (puisque c'est globalement l'idee derriere allumer/eteindre et regler la frequence des differents coeurs). Mais bon, d'un point de vue user-space, c'est la meme problematique :-)
Aujourd'hui, le noyau est aveugle. Il n'a aucune idee de ce qu'une tache va potentiellement faire dans le futur. Des IO ? Des acces memoire ? Une utilisation intensive du CPU ? Cela a directement un impact sur les performances, la reactivite et la consomation batterie. Il y a deja des cooperations entre l'user space et le noyau, c'est juste une de plus. Bien entendu le kernel ne vas pas baser ses decisions uniquement sur ces hints sans ajuster un peu a posteriori ses decisions, mais si le systeme coopere, c'est nettement plus malin. Si un toolkit fait du rendu graphique, il va pouvoir assez facilement indiquer quel thread va etre CPU ou memory bound dans le futur. Ce que le kernel ne pourra jamais savoir ou que lorsque ce sera trop tard.
Ce n'est pas du cooperatif au sens de je relache le CPU quand j'ai fini de faire mes betises, mais du cooperatif au sens des hints qu'on met sur une page lors d'un mmap. L'idee est d'aider le noyau a prendre la bonne decision. Ca ne sert a rien d'allumer 4 coeurs pour 4 taches IO bound, par contre si elles sont CPU bound, ca serait une tres bonne idee de le faire tout de suite, et pas quand elles seront presque fini…
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 10.
Je vois au moins deux choses qu'ils manquent aujourd'hui au noyau Linux et sur lesquels personnes ne travaillent a ma connaissance.
La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire. Typiquement le comportement actuel est de ne jamais marquer une page memoire comme etant libere dans une application, mais de se baser sur le fait que si une page n'est plus utilise, on peut la swapper. Resultat on copie globalement des pages inutiles dans la swap… et cela impact les performances. Il serait nettement plus malin de pouvoir marquer des pages memoires comme sans importance pour l'user space de maniere a ce que le kernel puisse les jeter. Pour cela, il y a un patch actuellement en developpement, mais pas encore upstream. Meme si cela ameliorerait la situation, il resterait le cas ou tout le systeme commence a etre short niveau memoire. A ce moment la, les applications pourraient, de maniere cooperative, vider leur cache si elles ne sont pas active. Enfin en derniere recour, elle pourrait decider de s'arreter completement avant que l'OOM ne decide de les tuer, plutot que de faire un arret a l'arrache. Pour ces deux derniers cas, il n'y a pas a ma connaissance de travaux upstream sur le sujet (Android a une implementation partielle de ce genre d'idee).
Le deuxieme endroit qui necessite des ameliorations, c'est le scheduling. Le noyau est completement aveugle a ce qui va se passer dans l'espace utilisateur. Il joue au devinette en esperant que ce qui s'est passe dans le passe va se repeter a court terme. C'est un peu domage, car les applications, elles savent ce qu'elles vont faire. Or dans un systeme moderne, le scheduling est devenu tres complique. Frequence et nombre de coeur actif variable. Characteristique des coeurs differentes. Difference de bande passante memoire, IO et CPU tres grande. Ce qui rend le boulot d'un scheduler assez impossible. Android a un scheduler un peu different maintenant, au lieu d'ajuster au fur et a mesure la charge, facon TCP, il fait un gros burst des qu'on lui en demande un petit peu et redescend progressivement (en frequence et coeur). Cela permet d'avoir une reactivite plus grande aux actions de l'utilisateurs. Mais cela n'est pas forcement optimal d'un point de vue energie. A quoi cela peut-il servir de demarrer un nouveau coeur, si on a une tache qui va etre bloque par les IO.
La solution est "assez" simple, il faut que l'espace utilisateur donne l'information au kernel. Si le kernel peut savoir qu'il a des taches IO bound, memory bound ou CPU bound, il a alors une information nettement plus pertinente sur le futur et peux demarrer de maniere efficace avec la bonne frequence les coeurs qui sont necessaire avec une meilleur probabilite de reussite. Cela necessite de modifier la libc pour exposer un nouvel attribut sur les threads et aussi les process. Ensuite la majorite des operations sont maintenant fait par des toolkits comme Qt, les EFL voir meme la SDL et cela limite donc les endroit a modifier pour prendre avantage d'une telle solution.
Voila, juste une petite liste d'idee de chose qui pourrait etre ameliore niveau user space et aurait un impact direct sur l'utilisation de tous les jours de ton PC. Avoir une machine plus reactive meme quand elle est charge et qui tire meilleur partie de sa batterie et de ses processeurs, ca serait pas mal comme amelioration, non ?
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 2.
Desktop is dead ?
[^] # Re: Oui
Posté par cedric . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 1.
Ok, mais dans ce cas, si les seuls machines qui ont besoin d'etre allume 24h/24 sont pour ce genre de tests, pourquoi pas prendre des trucs genre ARM voir un ATOM qui consommeront une fraction de l'energie qu'il semble consommer.
[^] # Re: Petit compte-rendu du papier blanc
Posté par cedric . En réponse au journal twister un microblog opensource P2P. Évalué à 4.
Plutot que de chercher a effacer a un compte, pourquoi perpetuellement repliquer toutes ces donnees ? C'est twitter. Ce n'est pas une solution de stockage. Personne n'est interresse par les twitt d'il y a plus de 15 jours. Donc pourquoi ne pas implementer directement dans le systeme un droit a l'oublie et arreter de repliquer les informations trop vieille. Effacer un compte devient alors automatique.
[^] # Re: Mouais
Posté par cedric . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Hum, parcontre en temps de generation (pour la compression et la decompression), ca doit etre plutot couteux, non ?
Ca doit probablement se rapprocher des techniques de Glyphy pour le rendu des font directement cote GPU.
# Terminology
Posté par cedric . En réponse à la dépêche Liquidprompt version 1.8. Évalué à 4.
Ca serait cool si cela pouvait tirer parti de Terminology, l'emulateur de terminal du projet Enlightenment. Il y a probablement moyen de faire quelque chose de tres sympa en tirant benefice des deux projets. Par exemple utiliser directement des images pour les differente signaletique. Mais il y a probablement la possibilite de faire plus.
Pour plus d'information sur Terminology: https://enlightenment.org/p.php?p=about/terminology&l=en . Et pour la liste des escapes supplementaires disponible, c'est dans le README a cette addresse ( https://git.enlightenment.org/apps/terminology.git/tree/README ). Cette liste n'est d'ailleur pas finit et il est tout a fait possible de faire des demandes de nouvelle fonctionnalite via phab.enlightenment.org.
[^] # Re: Mouais
Posté par cedric . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Faudra regarder dans le detail, mais il y a un detail a ne pas oublier, c'est qu'on a besoin de pouvoir faire un acces aleatoire aux pixels (pour pouvoir supporter le clipping). Il faut donc faire attention a ne pas etre force de lire tout une ligne pour trouver le pixel qui nous interresse. De plus il faut pouvoir chainer la mecanique de saut pour trouver le pixel qui nous arrange, a celui ou on blit en mixant le code avec le reste de la logique de decompression. Ca pose certaine contrainte. Mais je regarderais si il n'y a pas moyen de moyenner quelques choses avec Lz4, meme si ma semble tres tres complique au vu de l'ensemble des contraintes.
[^] # Re: Mouais
Posté par cedric . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Non, on parle de glyph pour l'instant uniquement, donc niveau de gris.
[^] # Re: Mouais
Posté par cedric . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
Le probleme du vectoriel, c'est qu'on se retrouve avec des formules de courbe assez complexe a execute niveau CPU dans tous les cas. Je ne pense pas qu'il soit possible d'avoir un format vectoriel qui est des performances proches de ce que font de simple blit. Il faudrait que la difference entre bande passante memoire et performance CPU soit encore plus grande qu'actuellement pour que cela soit vraiment plus interressant (En esperant arriver a faire tenir le tout dans pas trop de code pour eviter de perdre de l'autre cote dans les temps d'acces au code).
Pour l'instant, tous les systemes de rendu vectoriel que je connais sont un ordre de grandeur plus lent que ceux qu'on a. Pour etre interressant, il faudrait trouver un qui soit deja dans le meme ordre de grandeur puis voir si on peut l'optimiser pour le rendre competitif. Je n'en connais pas qui corresponde a cette objectif…
[^] # Re: Bindings
Posté par cedric . En réponse à la dépêche Gtk to Qt - A strange journey. Évalué à 7.
Malheureusement sur le hard auquel on a acces, on ne peut pas mesurer la consomation independante de chaque sous systeme (Systom On Chip avec memoire Package On Package). Par contre, on a acces aux spec precises de consomation en fonction de la frequence du CPU, memoire, GPU et de la bande passante utilise pour chaque niveau de la hierarchie memoire (qui sont toute mesurable en temps reel), on peut faire une estimation au doigt leve de ou part la consomation d'energie. Ensuite en ajustant un algo dans un sens ou dans un autre, on peut verifier si notre theorie est bonne et ameliorer les choses.
On avance un peu dans le noir, surtout avec les experimentations sur la compression, car globalement la regle est moins on en fait, moins on consomme. Sauf que lorsqu'on compresse la memoire, on fait tourner plus le CPU, mais on fait moins de transfert memoire et on attend aussi moins sur le sous systeme memoire. Avant d'experimente, on n'etait pas sur de gagner au final. Mais il semble que le plus simple c'est de d'abord optimiser pour les performances, puis la memoire, et apres d'ajuster pour la consomation batterie si necessaire. Cela semble pour l'instant toujours porter ses fruits comme strategie.
[^] # Re: Bindings
Posté par cedric . En réponse à la dépêche Gtk to Qt - A strange journey. Évalué à 6.
Il n'y a pas que la vitesse brute et visible par l'utilisateur. Il y aussi la possibilite de laisser tourner d'autre application en tache de fond et d'avoir une duree d'utilisation sur batterie qui reste "invisible" a l'utilisateur. Tant que tu ne codes qu'une petite application que l'utilisateur ne va pas utiliser pendant des heures, ca ne pose pas de probleme.
Mais GMail, Facebook, Twitter ou G+, ceux sont les premieres choses que je coupe quand je passe sur batterie. Ca tue litteralement la batterie de mon PC (je n'ai pas d'iPad, mais les consequence seront les meme). L'HTML5, c'est un joli hack pour deployer une petite application rapidement sur plein de terminaux, mais ce n'est pas forcement la solution pour tous les cas…
[^] # Re: Bindings
Posté par cedric . En réponse à la dépêche Gtk to Qt - A strange journey. Évalué à 4.
Un mixe de benchmark et d'application écrites pour les deux plateformes. ensuite tu utilise le même hardware, tu enlèves la batterie et tu fais tourner ça sur une alimentation qui te donne une trace numérique. Quand je dis le même hardware, je parle bien d'un même device en dual boot, car entre deux devices il peut y avoir de légère différence de consommation pour plein de petit détail.