Et bien, suffit de comparer un truc entre deux extremes pour voir un peu la difference. Par exemple, tu prends une appli qui utilise une webview avec JQuery pour afficher les dits boutons. Je te mets au defis de reussir a faire tenir ca dans moins de 150Mo. Alors forcement, des que l'application affiche un peu plus ca va vite et puis tu n'es pas tout seul sur les 1Go de RAM de ton telephone. En comparaison la meme application aurait utilise moins de 3Mo avec les EFL. Et encore, je pense etre un peu large dans mes estimations.
Au final, c'est la difference entre du C natif et bien controle vs du JS simple mais sans controle possible de ce qui se place. Perso, je prefererais avoir des applications de 3Mo comme ca en multitache, elle ne passerait pas leur temps a redemarrer entre autre chose…
Ah, et pour ce qui est des perfs de Java vs C, je suis assez impressionne des resultats d'Android qui n'est que 30% plus consommateurs de ressources batterie que les EFL en C. Il est probable qu'avec un controle fin de la memoire, il n'y aurait pas autant de difference, mais ca n'empeche que c'est pas mal comme prouesse quand meme (Bon apres si on a une autonomie de 10h, ca represente quand 3h de batterie de perdu en Java…).
GCC n'a plus changé d'ABI depuis qu'ils utilisent ce standard.
Si je me souviens bien aux alentours de 2007, ils ont casse par inadvertance l'ABI. Mais je crois que c'etait uniquement un truc dans la STL. Mais sinon l'ABI du C++11 de GCC n'est pas encore considere comme stable et toutes les applications qui l'utilisent seront a recompiler avec le prochain GCC. C'est un exercice tres difficile de maintenir l'ABI d'une lib C++ stable plus de quelques annees. Pour le coup, le projet Qt est tres impressionnant pour avoir reussi a tenir 7 ans entre deux cassages d'ABI, si je ne me trompe pas.
Principalement parce qu'ils sont plus complexe et inliner un decompresseur LZ4 ou LZO pour acceder a une ligne de pixels dans un glyph, ca va un peu impacter tes caches instructions et donc ta bande passante memoire. Maintenant le challenge, c'est de coder un decompresseur RLE avec des shaders :-)
Apres je ne crois pas qu'il y ait l'equivalent des instructions AES de disponible pour faire de la compression/decompression a la volee. Clairement, si c'etait disponible on utiliserait un mecanisme disponible en hard pour tenter de gagner encore en bande passante (meme si au final, on a le meme debit, on aurait moins d'instruction et donc plus de bande passante pour pousser des pixels a l'ecran).
Oui, mais sur quel CPU ? Sur A8, je n'en doute pas, sur A9, c'est moins évident.
Le A8 n'est pas multiprocesseur :-) Donc on parle bien des generations apres le A8.
Vous triez déjà les champs des structures de données par ordre décroissant de taille pour éviter le padding ?
Ca, ca fait des annees que l'on fait ca ! C'est un peu la base. On en est a faire de la deduplication de structure entre objet pour limiter la consomation memoire. Une espece de copy on write de certaine partie d'une structure en C avec un garbage collector qui utilise une table de hash pour trouver qui ressemble a qui et merger tout le monde on-idle.
Vous pouvez aussi mettre en place du tiling, c'est à dire de changer l'ordre des opérations pour que les données utiles restent dans le cache le plus longtemps possible (travailler par texture et non par coordonnés d'écran par exemple, etc…).
On fait deja ca, meme en OpenGL, pour reordonneer les operations et rester en cache (ou limiter les switch de context en OpenGL).
Sinon, je croyais qu'un des avantages des images vectorielles étaient justement la faible empreinte mémoire, remplacé par du temps cpu.
Le probleme etant que le temps de generation devient bien trop important et que la somme de code necessaire pour generer une image est aussi problematique. Il faut trouver un equilibre entre le niveau de compression, la somme de code que cela necessite pour faire la decompression, la bande passante memoire utilise et la puissance CPU necessaire pour cela.
Le RLE se code assez facilement en inline pour la decompression. Globalement, c'est "juste" une expansion d'une valeur. En ajoutant une table de saut en entete pour faciliter le saut a une ligne precise, tu te retrouves avec un code un peu complexe, mais pas impossible a maintenir et sans impact important sur la masse de code traverse. Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard…
J'ai vu apparaitre ca dans le hard qu'on a eu, il y a environ 1 an et demi. Et c'est different de mettre la clock a zero. Le temps pour rallumer un CPU est "assez" important vu qu'on pert le cache de premier niveau.
De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. Le principale probleme, c'est que compare a toute la tripote de MMX, SSE et compagnie du x86, NEON est assez pauvre et manque souvent de fonctionalites qui le rendent moins utile. Mais le point important, c'est qu'un blit d'un glyph en 8bits optimise en assembleur vectorise est plus lent que du code qui fait du blit d'un glyph compresse en RLE code en C (optimise aussi, mais pas autant).
Cela veut dire que l'on est clairement memory bound sur ce genre d'operation. En fait, ce n'est pas la premiere optimisation qui en reduisant notre consomation memoire resulte en une amelioration de nos performances. Nous avons fait de la deduplication de chaine de characteres et de structure C en memoire pour diminuer notre consomation memoire, mais, au final, nous avons gagne plus de 10% de performance de rendu. On en est a ce demander si ca ne vaut pas le cout de compresse en RLE certaine de nos resources graphiques. Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser.
Pour le detail, sur les Exynos et les derniers Qualcomm, pour ne citer que ceux que je connais, on fait du hot plug de CPU. On les coupe litteralement completement si ils ne sont pas necessaire. C'est d'ailleur assez problematique comme systeme, car tu ne peux plus detecter combien de core tu as et repartir intelligement tes taches. Globalement, le manque de communication entre noyau et espace utilisateur est encore plus criant.
A priori non, car la tension varie en fonction de l'horloge.
Quand a la strategie du race to idle, il faut qu'il n'y ait rien qui ne se mette en travers du CPU. Hors il est tres tres difficile d'avoir une tache qui n'est pas memorie bound. Resultat si tu peux, et c'est le cas sur pas mal de tache, diviser le boulot entre 4 coeurs qui tourneront a frequence plus faible qu'un unique coeur qui tournera a frequence maximum, tu gagnes en batterie. Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. Le probleme, c'est qu'a ce moment la, c'est la memoire qui ne suit plus et tu te retrouves a prendre au tant de temps qu'avant, sauf que tu as 4 coeurs qui tournent dans le vide une bonne partie du temps. Le principal probleme vient de la bande passante memoire qu'un unique coeur peut saturer assez facilement sur quasiment toutes les operations.
Pour la blague, on fait de la compression RLE des glyphs pour gagner sur la bande passante memoire. On gagne 30% de performances sur le rendu du texte et un peu plus de 10% en terme de gain sur la batterie. On fait faire plus au processeur, mais il attend alors moins longtemps avant d'aller roupiller. Sans compter qu'en accedant moins au sous-systeme memoire, on diminue aussi la consomation, car chaque niveau a un cout d'acces energetique superieur. Ah, et c'est chiffre sont sans optimisation de type vectorisation pour l'instant. Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur…
Cela releve aujourd'hui de l'histoire, mais il y a plus de 15 ans le projet Enlightenment faisait parti du projet GNOME en tant que Window Manager. Il y eu alors a l'epoque un clash entre Carsten Haitzler, createur de Enlightenment, et Miguel de Icaza, createur de GNOME. Le clash a porte sur le fait que Miguel et la majorite des developpeurs de Redhat voulait copier Windows 95 pour en faire une version Linux (technology incluse, malheureusement) alors que le projet Enlightenment voulait faire quelques choses de different et neuf…
La conclusion de cette discussion fut que Carsten quitta Redhat, Enlightenment ne fut plus utilise par GNOME et que Enlightenment devient un pet project pendant une decennie. Pour preuve de mes propos, il te suffira de faire un peu de recherche et regarder des trucs comme systray, corba, mono, … Je ne sais pas si il y a eu tant d'informations que cela sur le sujet dans les mailing-list et si on peut encore les trouver sur le net, mais il suffit de demander aux personnes impliquer dans ces projets a l'epoque pour qu'ils se rappellent.
Vu qu'on fait varier la frequence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation.
La conso dynamique était devenu inférieur à la conso statique.
Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important. Maintenant la plus part de ces terminaux mobiles sont la pour etre utilise et le but est donc de maximiser le temps d'utilisation. Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour. Par contre pour la conso dynamique, tu peux gratter un ordre de grandeur entre deux logiciels qui donnent le meme resultat visuel et ca, ce n'est absolument pas negligeable. Une optimisation qui te donne un gain de 10% de batterie quand tu as deja 10h d'autonomie en utilisation, ce n'est pas negligeable. Et Android n'est pas un foudre de guerre de ce cote la (Pas de scene graph et pas de gestion fine de la memoire).
Apres il y a d'autres trucs fun qui ont un impact sur la consomation. Par exemple avec les ecrans AMOLED, il vaut mieux un theme sombre pour minimiser l'utilisation de la batterie. Certains ecrans integres une memoire directement au niveau du pixel, ce qui permet d'eteindre completement la puce qui fait le scanout et d'avoir encore une consomation plus basse meme quand on affiche quelques choses.
Le touchscreen est aussi un truc qui coute de la batterie. C'est pour ca que Qualcomm pour sa montre est capable de n'activer qu'une partie de celui-ci. Mais cela demande au soft de remonter quel sont les zones ou il veut recevoir des events et d'adapter l'UI en fonction.
Certaines applications ont besoin d'information de geolocalisation, mais n'ont pas forcement besoin d'une grande precision, avoir un daemon et une API qui permet d'eviter d'allumer le GPS quand une application veut juste savoir a peu pres ou tu es et encore une optimisation qui paye.
C'est avec toutes ces optimisations qu'on arrive, ou pas, a tenir une journee sur sa batterie en utilisant son telephone. Par contre, si tu arretes de l'utiliser, il tiendra la semaine sur sa batterie…
Peut être une partie du problème viens que GNOME cherche à suivre MacOSX ou Android. Or ces OS ne suivent pas la tradition UNIX (X-Window) du copier coller par bouton du milieu, follow mouse, menu local…
C'est finalement ca la grande difference entre KDE et GNOME. GNOME a ete cree pour copier Windows. Il n'y a jamais eu de volonte d'innover de leur cote. Aujourd'hui c'est clairement MacOS X l'inspiration. KDE par contre a toujours eu une approche pragmatique pour permettre d'inclure le maximum de fonctionnalite et une approche beaucoup plus bazard que cathedrale, donc mecaniquement moins cette volonte de copie.
C'est une évidence que la complexité de tes shader impacte les performances. Tout comme les optimisation qui suppriment les invariant des coeur de boucle et les dupliquent. Avec les shaders, il faut le faire a la main étant donné la barrière entre les deux compilateurs. C'est d'ailleurs un des grands inconvénients de ce modèles de rendu, surtout quand on sait qu'il faut limiter les changements de shaders pour maximiser les performances.
Il est admis que la consomation d'energie suit une loi en puissance de 3 de la frequence. Donc si tu as 25 a 1/3 de la frequence, tu passes a 25 * 25 * 25 a pleine frequence. Pas 100, mais 15625. Ca change un peu le calcul de depart a pleine frequence :-)
La consomation dynamique n'est pas a negliger quand tu as un CPU qui peut passer de 0 a 2Ghz avec de 1 a 4 coeurs (voir avec des variations sur les coeurs disponible). Il y a clairement une consomation statique, mais bon, sur le materiel dont on parle, c'est la partie dynamique qui est le plus genant (Sans compter l'ecran et la radio).
D'ou ma description de l'utilisation du parallelisme. Reussir a faire la meme tache en tournant sur 4 coeurs a 1/3 de la frequence pour le meme resultat. Ca ne prend pas moins de temps ou plus de temps, ca utilise par contre moins d'energie. En gros, en faisant tourner le 4 eme core (qui est problement necessaire pour payer l'overhead du multithread), tu arrives a obtenir le meme resultat en temps d'execution. Mais du fait que tu tournes a 1/3 de la frequence, tu reussis a consommer moins d'energie.
Mais comme je l'ai deja dis dans un autre thread, le probleme, c'est la cooperation entre le kernel et l'user space. Il n'y a pas moyen d'informer le kernel qu'on a 4 taches CPU intensif et que la maintenant, il faut reveiller tout le monde. Le kernel d'un point de vue scheduling joue au devinette et ca devient tres complique pour lui. Plusieurs coeurs heterogenes qui peuvent tourner a des frequences variables avec des taches a dispatche dont on ne connait pas les besoins futures, mais juste le comportement passe. Meme Mme Irma se trouve dans une meilleur situation lorsqu'elle predit l'avenir !
J'esperes que tu n'as pas fait le raccourci terminaux mobiles, telephone :-) Mais la gamme NX300 de Samsung utilise effectivement des technologies d'Enlightenment (Dans le respect de la license Samsung fournit sur son site web le code source de ces appareils photos et tu peux y trouver les EFL).
C'est juste mon metier. Je passe mes journees a optimiser la consommation cpu, memoire et batterie de toute la stack graphique du projet Enlightenment pour des terminaux mobiles. J'ai une bonne vision de quels sont les points chauds dans un programme et quels en sera l'impact au final sur l'ensemble du systeme.
Mais si tu ne me crois pas, tu peux faire l'experience chez toi avec simplement PowerTop et Firefox ouvert sur un site web (par exemple un webmail). Puis tu coupes Firefox et tu lances claws-mail par exemple sur le meme imap. Tu verras la difference de consomation d'energie pour la meme tache (Et en plus c'est basique, pas la peine de commencer a titiller le bousin en lui faisant ouvrir un mail). Tu auras perdu une heure d'autonomie avec Firefox… Dans le meme genre, d'experience, si tu installes Enlightenment, tu peux t'amuser a utiliser le backend software et GL en comparant le resultat toujours avec PowerTop. Tu decouvriras de maniere amusante que pour un meme resultat visuel, l'utilisation de OpenGL te prendras 1h de batterie de plus (Forcement tu utilises une puce supplementaire et le modele de rendu GPU necessite un rendu fullscreen). Pas la peine d'acheter du materiel chere pour apprendre par soi meme les bases des problematiques d'optimisation pour le mobile.
De ce que je vois sur mon Geeksphone, les performances sont tout à fait honorables. Maintenant, un geeksphone, c'est quand même, au niveau matériel, du bas de gamme (140 euros et encore).
Tu te rends compte de ce que tu racontes ? Avec le hardware qui est dans ces telephones, je te fais tourner Enlightenment en mode desktop et en dual screen. Il y a plus de puissance dans ce telephone a 140 euros que dans un netbook de deux ans d'age ! Et non, les performances ne sont meme pas honorable. Compare avec le meme materiel sous Android et tu verras la difference te sauter aux yeux ! Et pourtant Android n'est pas ce qu'il se fait de mieux et on leur propre challenge a resoudre. Si tu as une petite idee de comment fonctionne la stack d'Android, d'une navigateur et d'un toolkit avec un scene graph, tu auras compris par toi meme, que les challenges des un ne sont meme pas les problemes des autres.
Qu'en sais-tu ? Tu as mesuré ?
Pour le coup, tu n'as pas besoin de mesurer pour savoir si tu tournes au dela de 55FPS ou pas. Je vois directement le frame drop a l'oeil nu. Et a vu de nez, ca tombe souvent a 30 FPS. Mais bon, c'est mon metier de regarder un ecran de telephone et de savoir quand on a un frame drop, donc j'ai l'habitude de savoir a quoi ca ressemble une interface a 60FPS et une qui ne l'es pas. Pour la plus part des gens, ca sera percu comme un probleme de qualite avant d'etre percu comme un probleme de performance (pour la plus part des gens il faut tomber en dessous de 30FPS pour qu'ils y voient un probleme de performance).
L'OS ne fait pas tout, il faut aussi un matériel qui soit à la hauteur. Et puis tu n'as pas besoin de 60FPS pour toutes les applications.
Comme dit plus haut le hardware que tu as dans un telephone a 140 euros et largement suffisant pour faire du 60FPS dans quasiment toutes les applications courantes (prend le meme telephone sous Android et tu verras quasiment aucun frame drop). D'accord le design n'est pas le meme, mais bon, leur complexite est globalement la meme et pas enorme vu qu'il n'y a pas trop d'overlay et d'animation. Et non, changer de CPU/GPU n'est pas la solution a leur probleme, car c'est juste deporter le probleme. Ils auront moins de batterie que la concurrence a l'usage. D'abord, il faut a hardware equivalent aller aussi vite, ensuite, tu optimises pour etre a consomation equivalent. Seulement apres tout ca, tu peux passer a un hardware plus important, car la consomation d'energie elle, elle n'est pas ameliore tant que ca en changeant de CPU/GPU (voir c'est meme l'inverse) et ta batterie ne grossit pas non plus aussi vite que les CPU/GPU… Donc non, pour les smartphones un telephone haut de gamme ne resoud pas tous tes problemes de logiciel !
Prend un Android sur un smartphone à 140 euros, il va beaucoup plus ramer que sur un galaxy s3.
Pour la blague, j'etais a Hong Kong recement, et ils vendent plein de Galaxy S3/S4 a 140 euros (Oui, ceux sont des faux). Je te promet qu'ils sont fluide et il faut un oeil un peu exerce pour voir les problemes et la difference (principalement la resolution est nettement inferieur pour les faux). En france, je pense qu'un Wiko Iggy correspond a peu de chose pres a ce que fait un Geekphone (Je n'ai jamais eu de Wiko, n'habitant pas en France, donc c'est un guess). Et non, ca ne reste pas a prouver, Firefox a a rattraper la concurrence.
Je te remercie de parler de Enlightenment :-) Oui, ca marche tres bien sur telephone et oui, on a fait des efforts d'optimisation pour cette raison. Maintenant on n'a pas l'eco-systeme de KDE ou GNOME et c'est un probleme qu'il n'est pas simple de resoudre.
Si tu baisses la fréquence, tu augmentes le temps pour une tache,
Uniquement si tu as un seul coeur et que ta tache n'est pas divisible sur plusieurs coeurs !
J'ai même lu une étude, ou il baissait la fréquence cpu ou celle du bus mémoire en fonction de la charge qui était cpu bound ou memory bound, il gagnait 10% de consommation.
Etude mono-coeur probablement. Mais bon, il faut voir que le noyau et les applications ne communiquent aussi pas assez sur le sujet pour prendre une bonne decision. Si tu as des threads qui vont etre CPU bound, faut reveiller toutes tes cores le plus vite possible (Pas de warmup comme avec l'ordonnanceur classique de linux). Puis tu reajustes la frequence a la baisse en fonction de ton package de temperature et de l'utilisation reelle du CPU.
Par contre, si tu as des threads IO bound, tu te reveilles tranquille avec un warmup. Meme avec la frequence la plus basse, tu vas avoir de tres bonne perfs (energie et temps pour le resultat) et tu augmentes progressivement jusqu'a ce que cela ne serve a rien. C'est la logique qui est globalement utilise par le noyau actuellement.
Si tu as des threads memory bound, tu reveille un coeur a pleine frequence et tu ajustes progressivement si necessaire pour avoir le resultat qui maximise la bande passante et l'usage d'un coeur.
Bon, ca c'est simple… Maintenant tu mixes des threads de toutes les categories dans le meme systeme et pour etre plus sympa tu ne dis pas qui fait quoi au kernel ! Bien entendu le resultat est globalement mauvais. C'est un des changements que j'aimerais bien voir arriver a un moment dans le kernel, la possibilite de dire si un thread est CPU, IO ou memory bound. Avec ca le scheduler pourrait prendre des decisions plus efficace pour eviter d'avoir des frame drop et une surconsomation d'energie. Par contre, c'est des problematiques bas niveau et il faut que toute la chaine coopere.
Cela demande aussi de diviser tes taches intelligement en plusieurs thread pour que kernel puisse prendre la bonne decision de scheduling (globalement equilibre les taches entre les processeurs et ajuster la frequence a la volee).
Sinon les processeurs que j'utilise sont parfaitement capable d'ajuster la frequence de toute la puce, sous systeme memoire inclue. Ca fait d'ailleur partie des points de mesure en premiere approximation de la consomation d'energie de deux logiciels qui font la meme chose. D'ailleurs ils ont des fonctions sympa, comme la possibilite de couper l'alimentation complete d'un banc de memoire pour sauver de l'energie. Ca veut dire qu'il faut bouger tout le monde pour ne pas perdre les donnees, mais c'est payant si ton soft est optimise pour ne pas utiliser trop de memoire et avoir des grandes periodes de veille
La strategie etant d'attendre un peu, de signaler aux applications qu'on va partir en veille profonde donc qu'elles doivent vider leur cache et compresser leurs objets ou juste se succider. Puis on peut commencer a bouger les pages d'un banc a l'autre, probablement que l'utilisation de zswap peut aider dans ce scenario. Enfin on peut peut etre couper un banc memoire complet et partir en suspend. Sachant que en suspend, la memoire est le second point de consomation (derriere la radio), c'est une optimisation assez sympa, surtout sur les telephones qui passe leur temps en suspend dans la poche.
Que l'API système soit du C, du Java ou du JS qu'est ce que ça change fonctionnellement ?
Si l'API systeme est du C, tu as une meilleur portabilite tes applications existantes. Ca peut aider quand tu bootstrap un ecosysteme de pas partir de zero.
Ce n'est pas parce que FirefoxOS n'a rien d'excitant que son architecture technique est pire qu'une autre (ou alors il va falloir que tu explique un peu plus).
Au hazard, ecosysteme limite (la portabilite de solution existante est limite), performance problematique et peu de chance que ca s'ameliore. Les performances sur un telephone sont critiques. Dans un premier temps, il te faut atteindre les 60FPS constant (pas encore la pour FFOS), ensuite il faut diminuer ta consommation de memoire (pour faire du multitache, parce que bon avoir un seul tab/application actif, c'est plus trop acceptable de nos jours) et enfin il faut diminuer la consommation de batterie (parce que bon, c'est bien si tu peux encore l'utiliser quelques heures ton telephone :-) ). Je met les optimisations dans cette ordre, car c'est veritablement dans cette ordre que l'on peut resoudre le probleme. Et dans tout ca, partir avec de l'HTML/JS, c'est partir avec un gros handicap.
Donc tu te retrouves avec un OS plus limite et moins performant. Tu peux tenter de le vendre dans le bas de gamme ou les clients sont moins regardant, mais Android est deja plus performant et avec un ecosysteme plus complet… Autant dire que courir une course en partant apres tout le monde et en utilisant des bequilles, c'est clairement pas un avantage !
Malheureusement les drivers ne sont pas encore tres utilisable pour faire un telephone. Freedreno ne permet que de piloter l'ecran externe du Nexus 4, la derniere fois que j'ai regarder. La derniere fois que j'ai regarder, il n'y avait pas encore de solution simple pour avoir un GNU/Linux en dual boot avec Android (histoire de ne pas avoir une brique inutilisable). Pour les machines a base de Vivante, Mali, tu peux oublier, on n'en est pas encore la du tout. Donc pour developper une distribution libre pour telephone, tu as encore "un peu" de boulot, juste sur le bas niveau.
Contrairement a ce que tu penses, je ne crois pas que le modem soit un "vrai" probleme. C'est finalement pas different des blobs pour carte reseau et autres sur PC. L'API publique est defini et utilisable. Ils sont extensivement teste et peu modifier au cour du temps pour faire leur tache, donc assez stable et parfaitement utilisable depuis le systeme host. Pas de quoi empecher la realisation d'une distribution libre.
Effectivement, c'est un probleme de securite si le modem a un acces DMA a la memoire systeme, ce qui est le cas avec quasiment tous les modems LTE et probablement aussi 3G. Mais bon une attaque qui consisterait a introduire du code dans le modem pour t'espionner, requiert que tu sois une cible importante, car il faut :
- un firmware pour ta version de telephone patcher pour dumper sur le reseau mobile sans trop d'instabilite
- un acces physique pour changer le blob et le rendre permanent
- ou une faille remote et utiliser une antenne mobile pour injecter le code (ce qui requiert une surveillance de proximite de la cible)
- enfin un monitoring de proximite pour reussir a dumper la memoire de ton telephone (car faire un dump sur un reseau d'operateur, ca va pas trop marcher)
- bien entendu, le dump va necessiter d'analyser la memoire de maniere specifique, en ayant un systeme exotique, tu viens juste de rendre cette analyse extremement couteuse et il faudra donc une tres tres bonne raison pour mettre en place une telle attaque…
Rien d'impossible et probablement que la NSA en a les moyens, mais ca n'est pas une attaque de surveillance de masse et necessite que tu sois une cible de tres grande valeur pour que ca en vaille le cout…
D'ou mon point de vue qui est de dire que ce n'est pas un probleme (sans compter que de faire certifier ton nouveau firmware libre pour modem, ca sera drole).
Il sera plus important pour arriver a avoir une distribution libre de reussir les etapes suivante :
- dual boot distribution classique/android
- reverse engineering du protocal du compositeur de Android pour pouvoir faire un serveur Wayland/Surface flinger et avoir une migration d'un telephone qui marche a un telephone libre plus probable.
- merge du patch volatile memory dans le kernel (avec 1GB sans swap et avec du multi app dont du web, ca part vite, faut pouvoir redonner efficacement de la memoire au systeme).
- porter les toolkit/serveur Wayland sur Android (ca veut dire commencer par faire marcher tous les desktop sur Wayland)
- ecrire/modifier des applications en se focalisant sur l'optimisation CPU/Memoire/Batterie.
- avoir un noyau a jour avec tous les peripheriques de supporter (le nexus 4 semble bien parti)
- ajouter le concept de intent dans la stack Linux libre
Ca fait pas mal de boulot et si on a un truc utilisable dans 2 ans et capable de remplacer un Android, je serais content…
Tous les ordinateurs auront donc au moins une carte SIM intégrée avec le support 4G et du coup la fibre optique se généralisera pour tenter de concurrencer la 4G. Nostradamus a parlé.
Hum, euh, hum, c'est bizarre, je dois vivre dans le futur. Ici tout le monde a la fibre et la 4G. Tu peux trouver du wifi gratuit a peu pres partout, meme les bus on une borne Wifi (Et aussi des TV avec de la pub entre deux arrets). Par contre, on fait plutot du tethering, vu qu'on a 5Go de limite mensuel sur nos forfaits 4G. Une fois les update automatique d'Android desactive, il y a de la marge pour consommer de la bande passante sur une seule SIM.
Ah, oui, je ne suis pas en France, ni dans le futur, mais juste en Coree !
Sinon j'ai du mal a voir comment pourront etre utiliser ce genre de CPU sur une utilisation de courante par tout le monde. La plus grosse contrainte sur la majeur partie des taches que l'on fait tous les jours, a part pour la cryptographie et la decompression video, c'est la bande passante memoire. Et meme si tu utilises de la compression a la volee, tu ne vas pas gagner tant que ca, sans compter que ca complexifie ton code pas mal. Pour du rendu 2D, la plus part des taches (a part le blend avec du smooth scaling) sont capable de saturer un unique core et la 3D est plus facilement gere par un GPU. On experimente actuellement la decompression RLE de glyph pour ameliorer les performances du rendu texte en software, et ca marche, mais un coeur unique est encore suffisant pour saturer la bande passante memoire. Et ca, c'est avec des infrastructure qui se parallelise bien.
Paralleliser le rendu et la manipulation d'une page web, sans augmenter les besoins de bande passante memoire, c'est un joli challenge. Je me demande comment Servo/Rust va s'en sortir de ce cote la. Mais pour le reste, si tu arrives a utiliser en parallele efficacement plus de 4 cores, je dis chapeau bas. Apres il y a probablement une possibilite, si tu arrives a faire tourner 4 coeurs a moins d'un tiers de la frequence d'un seul pour le meme resultat, peut etre que tu consommeras moins d'energie (du fait que la consomation est une loi en puissance cubique de la frequence). Mais pour l'instant aucun toolkit n'est capable de mettre en avant une tel infrastructure et on ne sait pas encore si au final, le cout de la parallelisation en logiciel (lock, queue, allocation memoire …) ne va pas augmenter la consomation d'energie quand on commence a utiliser plein de coeur. Et puis aussi, combien de coeur peut reussir a utiliser une application ? 2 sans souci, 4 probablement, 8 ce sera deja un challenge… alors 256 ! Donc ce n'est probablement pas une solution pour tout le monde.
Qualcom et arm ont a peu près la même part de marché et aucun ne voit l'intérêt du libre. Et vu leur croissance,ils ne sont pas près d'écouter ! Seul l'arrivée d'un outsider pourrait les faires réagir, mais Intel après ça conférence du ces ne semble pas être intéresser par le domaine du mobile…
Si tu as 20 millions d'euros, je te le fais. Il faudra aussi trouver 30000 clients deboursant environs 700€ pour un nouveau téléphone par an…
Le problème c'est que la majorité des investisseurs ne comprennent pas l'intérêt du logiciel libre et encore moins les problèmes de sécurité du logiciel propriétaire. Ensuite même avec un tel budget, tu n'auras pas de drivers avec qui que ce soit qui fait un chipset arm…
Bienvenue au debut des annees 90 ! L'histoire se repette cela en est presque triste…
Il n'existe pas encore de projet libre comme KDE ou GNOME pour faire un OS mobile libre. Ce qui s'en rapproche le plus, c'est probablement Cyanogen mode qui est a Android ce que Gnome etait a Windows a l'epoque. Mais on est loin d'avoir un eco systeme aussi complet que sur le desktop. La principale raison, c'est que Android nous pousse a tout reinventer pour diverse raison.
La premiere, c'est que comme environnement de developpement natif, Android, c'est la poisse si tu veux reutiliser ce que tu as deja fait. Il te faut ajouter un Android.mk dans tes sources et le maintenir. Et il faut faire ca pour toutes tes dependances.
Une fois que tu as passe la barriere de ce premier probleme, tu vas te rendre compte que l'approche de KDE et GNOME qui a ete tres pragmatique et n'a pas du tout pousse a l'optimisation va rendre absolument inutilisable leur techno pour longtemps sur le mobile. Il va falloir reinventer un environnement complet pour y arriver, ou pas loin. C'est ce que fait KDE avec Plasma pour tablette.
Enfin quand ca marchera a peu pres, le principal probleme restera l'etat des drivers qui sont globalement catastrophiques sur ARM et Android. Ils sont globalement teste et optimise pour un seul scenario et mettre une autre plateforme que celle attendu par dessus, c'est comme construire sur un chateau de carte. Sans compter que chaque driver a son propre set d'API proprietaire et que cela ne derange pas les constructeurs de completement modifier leur stack juste pour un driver. Par contre dans le libre, se tapper la maintenance de n backend differents et de plus en plus nombreux, ca n'est pas jouable.
Il va nous falloir des annees pour regler ces problemes et quand ce sera fait, et bien le marche sera aussi domine par Android que le desktop par Microsoft. Il est deja certain que Android/Arm a gagne et que personne n'arrivera a revenir dans la course du mobile. On a remplace le couple Microsoft/Intel par Google/Arm. Je ne suis pas convaincu qu'on est forcement gagne au change en fait !
[^] # Re: Bindings
Posté par cedric . En réponse à la dépêche Gtk to Qt - A strange journey. Évalué à 10.
Et bien, suffit de comparer un truc entre deux extremes pour voir un peu la difference. Par exemple, tu prends une appli qui utilise une webview avec JQuery pour afficher les dits boutons. Je te mets au defis de reussir a faire tenir ca dans moins de 150Mo. Alors forcement, des que l'application affiche un peu plus ca va vite et puis tu n'es pas tout seul sur les 1Go de RAM de ton telephone. En comparaison la meme application aurait utilise moins de 3Mo avec les EFL. Et encore, je pense etre un peu large dans mes estimations.
Au final, c'est la difference entre du C natif et bien controle vs du JS simple mais sans controle possible de ce qui se place. Perso, je prefererais avoir des applications de 3Mo comme ca en multitache, elle ne passerait pas leur temps a redemarrer entre autre chose…
Ah, et pour ce qui est des perfs de Java vs C, je suis assez impressionne des resultats d'Android qui n'est que 30% plus consommateurs de ressources batterie que les EFL en C. Il est probable qu'avec un controle fin de la memoire, il n'y aurait pas autant de difference, mais ca n'empeche que c'est pas mal comme prouesse quand meme (Bon apres si on a une autonomie de 10h, ca represente quand 3h de batterie de perdu en Java…).
[^] # Re: mélange de langage ?
Posté par cedric . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 6.
Si je me souviens bien aux alentours de 2007, ils ont casse par inadvertance l'ABI. Mais je crois que c'etait uniquement un truc dans la STL. Mais sinon l'ABI du C++11 de GCC n'est pas encore considere comme stable et toutes les applications qui l'utilisent seront a recompiler avec le prochain GCC. C'est un exercice tres difficile de maintenir l'ABI d'une lib C++ stable plus de quelques annees. Pour le coup, le projet Qt est tres impressionnant pour avoir reussi a tenir 7 ans entre deux cassages d'ABI, si je ne me trompe pas.
[^] # 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.
Principalement parce qu'ils sont plus complexe et inliner un decompresseur LZ4 ou LZO pour acceder a une ligne de pixels dans un glyph, ca va un peu impacter tes caches instructions et donc ta bande passante memoire. Maintenant le challenge, c'est de coder un decompresseur RLE avec des shaders :-)
Apres je ne crois pas qu'il y ait l'equivalent des instructions AES de disponible pour faire de la compression/decompression a la volee. Clairement, si c'etait disponible on utiliserait un mecanisme disponible en hard pour tenter de gagner encore en bande passante (meme si au final, on a le meme debit, on aurait moins d'instruction et donc plus de bande passante pour pousser des pixels a l'ecran).
[^] # 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.
Le A8 n'est pas multiprocesseur :-) Donc on parle bien des generations apres le A8.
Ca, ca fait des annees que l'on fait ca ! C'est un peu la base. On en est a faire de la deduplication de structure entre objet pour limiter la consomation memoire. Une espece de copy on write de certaine partie d'une structure en C avec un garbage collector qui utilise une table de hash pour trouver qui ressemble a qui et merger tout le monde on-idle.
On fait deja ca, meme en OpenGL, pour reordonneer les operations et rester en cache (ou limiter les switch de context en OpenGL).
Le probleme etant que le temps de generation devient bien trop important et que la somme de code necessaire pour generer une image est aussi problematique. Il faut trouver un equilibre entre le niveau de compression, la somme de code que cela necessite pour faire la decompression, la bande passante memoire utilise et la puissance CPU necessaire pour cela.
Le RLE se code assez facilement en inline pour la decompression. Globalement, c'est "juste" une expansion d'une valeur. En ajoutant une table de saut en entete pour faciliter le saut a une ligne precise, tu te retrouves avec un code un peu complexe, mais pas impossible a maintenir et sans impact important sur la masse de code traverse. Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard…
[^] # 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.
J'ai vu apparaitre ca dans le hard qu'on a eu, il y a environ 1 an et demi. Et c'est different de mettre la clock a zero. Le temps pour rallumer un CPU est "assez" important vu qu'on pert le cache de premier niveau.
[^] # 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.
De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. Le principale probleme, c'est que compare a toute la tripote de MMX, SSE et compagnie du x86, NEON est assez pauvre et manque souvent de fonctionalites qui le rendent moins utile. Mais le point important, c'est qu'un blit d'un glyph en 8bits optimise en assembleur vectorise est plus lent que du code qui fait du blit d'un glyph compresse en RLE code en C (optimise aussi, mais pas autant).
Cela veut dire que l'on est clairement memory bound sur ce genre d'operation. En fait, ce n'est pas la premiere optimisation qui en reduisant notre consomation memoire resulte en une amelioration de nos performances. Nous avons fait de la deduplication de chaine de characteres et de structure C en memoire pour diminuer notre consomation memoire, mais, au final, nous avons gagne plus de 10% de performance de rendu. On en est a ce demander si ca ne vaut pas le cout de compresse en RLE certaine de nos resources graphiques. Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser.
[^] # 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.
Pour le detail, sur les Exynos et les derniers Qualcomm, pour ne citer que ceux que je connais, on fait du hot plug de CPU. On les coupe litteralement completement si ils ne sont pas necessaire. C'est d'ailleur assez problematique comme systeme, car tu ne peux plus detecter combien de core tu as et repartir intelligement tes taches. Globalement, le manque de communication entre noyau et espace utilisateur est encore plus criant.
[^] # 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é à 4.
A priori non, car la tension varie en fonction de l'horloge.
Quand a la strategie du race to idle, il faut qu'il n'y ait rien qui ne se mette en travers du CPU. Hors il est tres tres difficile d'avoir une tache qui n'est pas memorie bound. Resultat si tu peux, et c'est le cas sur pas mal de tache, diviser le boulot entre 4 coeurs qui tourneront a frequence plus faible qu'un unique coeur qui tournera a frequence maximum, tu gagnes en batterie. Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. Le probleme, c'est qu'a ce moment la, c'est la memoire qui ne suit plus et tu te retrouves a prendre au tant de temps qu'avant, sauf que tu as 4 coeurs qui tournent dans le vide une bonne partie du temps. Le principal probleme vient de la bande passante memoire qu'un unique coeur peut saturer assez facilement sur quasiment toutes les operations.
Pour la blague, on fait de la compression RLE des glyphs pour gagner sur la bande passante memoire. On gagne 30% de performances sur le rendu du texte et un peu plus de 10% en terme de gain sur la batterie. On fait faire plus au processeur, mais il attend alors moins longtemps avant d'aller roupiller. Sans compter qu'en accedant moins au sous-systeme memoire, on diminue aussi la consomation, car chaque niveau a un cout d'acces energetique superieur. Ah, et c'est chiffre sont sans optimisation de type vectorisation pour l'instant. Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur…
[^] # Re: Local knowledge
Posté par cedric . En réponse au journal Gtk to Qt - A strange journey. Évalué à 10.
Cela releve aujourd'hui de l'histoire, mais il y a plus de 15 ans le projet Enlightenment faisait parti du projet GNOME en tant que Window Manager. Il y eu alors a l'epoque un clash entre Carsten Haitzler, createur de Enlightenment, et Miguel de Icaza, createur de GNOME. Le clash a porte sur le fait que Miguel et la majorite des developpeurs de Redhat voulait copier Windows 95 pour en faire une version Linux (technology incluse, malheureusement) alors que le projet Enlightenment voulait faire quelques choses de different et neuf…
La conclusion de cette discussion fut que Carsten quitta Redhat, Enlightenment ne fut plus utilise par GNOME et que Enlightenment devient un pet project pendant une decennie. Pour preuve de mes propos, il te suffira de faire un peu de recherche et regarder des trucs comme systray, corba, mono, … Je ne sais pas si il y a eu tant d'informations que cela sur le sujet dans les mailing-list et si on peut encore les trouver sur le net, mais il suffit de demander aux personnes impliquer dans ces projets a l'epoque pour qu'ils se rappellent.
[^] # 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.
Vu qu'on fait varier la frequence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation.
Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important. Maintenant la plus part de ces terminaux mobiles sont la pour etre utilise et le but est donc de maximiser le temps d'utilisation. Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour. Par contre pour la conso dynamique, tu peux gratter un ordre de grandeur entre deux logiciels qui donnent le meme resultat visuel et ca, ce n'est absolument pas negligeable. Une optimisation qui te donne un gain de 10% de batterie quand tu as deja 10h d'autonomie en utilisation, ce n'est pas negligeable. Et Android n'est pas un foudre de guerre de ce cote la (Pas de scene graph et pas de gestion fine de la memoire).
Apres il y a d'autres trucs fun qui ont un impact sur la consomation. Par exemple avec les ecrans AMOLED, il vaut mieux un theme sombre pour minimiser l'utilisation de la batterie. Certains ecrans integres une memoire directement au niveau du pixel, ce qui permet d'eteindre completement la puce qui fait le scanout et d'avoir encore une consomation plus basse meme quand on affiche quelques choses.
Le touchscreen est aussi un truc qui coute de la batterie. C'est pour ca que Qualcomm pour sa montre est capable de n'activer qu'une partie de celui-ci. Mais cela demande au soft de remonter quel sont les zones ou il veut recevoir des events et d'adapter l'UI en fonction.
Certaines applications ont besoin d'information de geolocalisation, mais n'ont pas forcement besoin d'une grande precision, avoir un daemon et une API qui permet d'eviter d'allumer le GPS quand une application veut juste savoir a peu pres ou tu es et encore une optimisation qui paye.
C'est avec toutes ces optimisations qu'on arrive, ou pas, a tenir une journee sur sa batterie en utilisant son telephone. Par contre, si tu arretes de l'utiliser, il tiendra la semaine sur sa batterie…
[^] # Re: Local knowledge
Posté par cedric . En réponse au journal Gtk to Qt - A strange journey. Évalué à -3.
C'est finalement ca la grande difference entre KDE et GNOME. GNOME a ete cree pour copier Windows. Il n'y a jamais eu de volonte d'innover de leur cote. Aujourd'hui c'est clairement MacOS X l'inspiration. KDE par contre a toujours eu une approche pragmatique pour permettre d'inclure le maximum de fonctionnalite et une approche beaucoup plus bazard que cathedrale, donc mecaniquement moins cette volonte de copie.
[^] # Re: Et les cartes graphiques ?
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.
C'est une évidence que la complexité de tes shader impacte les performances. Tout comme les optimisation qui suppriment les invariant des coeur de boucle et les dupliquent. Avec les shaders, il faut le faire a la main étant donné la barrière entre les deux compilateurs. C'est d'ailleurs un des grands inconvénients de ce modèles de rendu, surtout quand on sait qu'il faut limiter les changements de shaders pour maximiser les performances.
[^] # 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.
Il est admis que la consomation d'energie suit une loi en puissance de 3 de la frequence. Donc si tu as 25 a 1/3 de la frequence, tu passes a 25 * 25 * 25 a pleine frequence. Pas 100, mais 15625. Ca change un peu le calcul de depart a pleine frequence :-)
La consomation dynamique n'est pas a negliger quand tu as un CPU qui peut passer de 0 a 2Ghz avec de 1 a 4 coeurs (voir avec des variations sur les coeurs disponible). Il y a clairement une consomation statique, mais bon, sur le materiel dont on parle, c'est la partie dynamique qui est le plus genant (Sans compter l'ecran et la radio).
[^] # 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.
D'ou ma description de l'utilisation du parallelisme. Reussir a faire la meme tache en tournant sur 4 coeurs a 1/3 de la frequence pour le meme resultat. Ca ne prend pas moins de temps ou plus de temps, ca utilise par contre moins d'energie. En gros, en faisant tourner le 4 eme core (qui est problement necessaire pour payer l'overhead du multithread), tu arrives a obtenir le meme resultat en temps d'execution. Mais du fait que tu tournes a 1/3 de la frequence, tu reussis a consommer moins d'energie.
Mais comme je l'ai deja dis dans un autre thread, le probleme, c'est la cooperation entre le kernel et l'user space. Il n'y a pas moyen d'informer le kernel qu'on a 4 taches CPU intensif et que la maintenant, il faut reveiller tout le monde. Le kernel d'un point de vue scheduling joue au devinette et ca devient tres complique pour lui. Plusieurs coeurs heterogenes qui peuvent tourner a des frequences variables avec des taches a dispatche dont on ne connait pas les besoins futures, mais juste le comportement passe. Meme Mme Irma se trouve dans une meilleur situation lorsqu'elle predit l'avenir !
[^] # Re: Oui
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3.
J'esperes que tu n'as pas fait le raccourci terminaux mobiles, telephone :-) Mais la gamme NX300 de Samsung utilise effectivement des technologies d'Enlightenment (Dans le respect de la license Samsung fournit sur son site web le code source de ces appareils photos et tu peux y trouver les EFL).
[^] # Re: Oui
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 6.
C'est juste mon metier. Je passe mes journees a optimiser la consommation cpu, memoire et batterie de toute la stack graphique du projet Enlightenment pour des terminaux mobiles. J'ai une bonne vision de quels sont les points chauds dans un programme et quels en sera l'impact au final sur l'ensemble du systeme.
Mais si tu ne me crois pas, tu peux faire l'experience chez toi avec simplement PowerTop et Firefox ouvert sur un site web (par exemple un webmail). Puis tu coupes Firefox et tu lances claws-mail par exemple sur le meme imap. Tu verras la difference de consomation d'energie pour la meme tache (Et en plus c'est basique, pas la peine de commencer a titiller le bousin en lui faisant ouvrir un mail). Tu auras perdu une heure d'autonomie avec Firefox… Dans le meme genre, d'experience, si tu installes Enlightenment, tu peux t'amuser a utiliser le backend software et GL en comparant le resultat toujours avec PowerTop. Tu decouvriras de maniere amusante que pour un meme resultat visuel, l'utilisation de OpenGL te prendras 1h de batterie de plus (Forcement tu utilises une puce supplementaire et le modele de rendu GPU necessite un rendu fullscreen). Pas la peine d'acheter du materiel chere pour apprendre par soi meme les bases des problematiques d'optimisation pour le mobile.
Tu te rends compte de ce que tu racontes ? Avec le hardware qui est dans ces telephones, je te fais tourner Enlightenment en mode desktop et en dual screen. Il y a plus de puissance dans ce telephone a 140 euros que dans un netbook de deux ans d'age ! Et non, les performances ne sont meme pas honorable. Compare avec le meme materiel sous Android et tu verras la difference te sauter aux yeux ! Et pourtant Android n'est pas ce qu'il se fait de mieux et on leur propre challenge a resoudre. Si tu as une petite idee de comment fonctionne la stack d'Android, d'une navigateur et d'un toolkit avec un scene graph, tu auras compris par toi meme, que les challenges des un ne sont meme pas les problemes des autres.
Pour le coup, tu n'as pas besoin de mesurer pour savoir si tu tournes au dela de 55FPS ou pas. Je vois directement le frame drop a l'oeil nu. Et a vu de nez, ca tombe souvent a 30 FPS. Mais bon, c'est mon metier de regarder un ecran de telephone et de savoir quand on a un frame drop, donc j'ai l'habitude de savoir a quoi ca ressemble une interface a 60FPS et une qui ne l'es pas. Pour la plus part des gens, ca sera percu comme un probleme de qualite avant d'etre percu comme un probleme de performance (pour la plus part des gens il faut tomber en dessous de 30FPS pour qu'ils y voient un probleme de performance).
Comme dit plus haut le hardware que tu as dans un telephone a 140 euros et largement suffisant pour faire du 60FPS dans quasiment toutes les applications courantes (prend le meme telephone sous Android et tu verras quasiment aucun frame drop). D'accord le design n'est pas le meme, mais bon, leur complexite est globalement la meme et pas enorme vu qu'il n'y a pas trop d'overlay et d'animation. Et non, changer de CPU/GPU n'est pas la solution a leur probleme, car c'est juste deporter le probleme. Ils auront moins de batterie que la concurrence a l'usage. D'abord, il faut a hardware equivalent aller aussi vite, ensuite, tu optimises pour etre a consomation equivalent. Seulement apres tout ca, tu peux passer a un hardware plus important, car la consomation d'energie elle, elle n'est pas ameliore tant que ca en changeant de CPU/GPU (voir c'est meme l'inverse) et ta batterie ne grossit pas non plus aussi vite que les CPU/GPU… Donc non, pour les smartphones un telephone haut de gamme ne resoud pas tous tes problemes de logiciel !
Pour la blague, j'etais a Hong Kong recement, et ils vendent plein de Galaxy S3/S4 a 140 euros (Oui, ceux sont des faux). Je te promet qu'ils sont fluide et il faut un oeil un peu exerce pour voir les problemes et la difference (principalement la resolution est nettement inferieur pour les faux). En france, je pense qu'un Wiko Iggy correspond a peu de chose pres a ce que fait un Geekphone (Je n'ai jamais eu de Wiko, n'habitant pas en France, donc c'est un guess). Et non, ca ne reste pas a prouver, Firefox a a rattraper la concurrence.
Je sens que ma batterie va apprecier :-)
[^] # Re: L'histoire se repette !
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Je te remercie de parler de Enlightenment :-) Oui, ca marche tres bien sur telephone et oui, on a fait des efforts d'optimisation pour cette raison. Maintenant on n'a pas l'eco-systeme de KDE ou GNOME et c'est un probleme qu'il n'est pas simple de resoudre.
[^] # 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é à 5.
Uniquement si tu as un seul coeur et que ta tache n'est pas divisible sur plusieurs coeurs !
Etude mono-coeur probablement. Mais bon, il faut voir que le noyau et les applications ne communiquent aussi pas assez sur le sujet pour prendre une bonne decision. Si tu as des threads qui vont etre CPU bound, faut reveiller toutes tes cores le plus vite possible (Pas de warmup comme avec l'ordonnanceur classique de linux). Puis tu reajustes la frequence a la baisse en fonction de ton package de temperature et de l'utilisation reelle du CPU.
Par contre, si tu as des threads IO bound, tu te reveilles tranquille avec un warmup. Meme avec la frequence la plus basse, tu vas avoir de tres bonne perfs (energie et temps pour le resultat) et tu augmentes progressivement jusqu'a ce que cela ne serve a rien. C'est la logique qui est globalement utilise par le noyau actuellement.
Si tu as des threads memory bound, tu reveille un coeur a pleine frequence et tu ajustes progressivement si necessaire pour avoir le resultat qui maximise la bande passante et l'usage d'un coeur.
Bon, ca c'est simple… Maintenant tu mixes des threads de toutes les categories dans le meme systeme et pour etre plus sympa tu ne dis pas qui fait quoi au kernel ! Bien entendu le resultat est globalement mauvais. C'est un des changements que j'aimerais bien voir arriver a un moment dans le kernel, la possibilite de dire si un thread est CPU, IO ou memory bound. Avec ca le scheduler pourrait prendre des decisions plus efficace pour eviter d'avoir des frame drop et une surconsomation d'energie. Par contre, c'est des problematiques bas niveau et il faut que toute la chaine coopere.
Cela demande aussi de diviser tes taches intelligement en plusieurs thread pour que kernel puisse prendre la bonne decision de scheduling (globalement equilibre les taches entre les processeurs et ajuster la frequence a la volee).
Sinon les processeurs que j'utilise sont parfaitement capable d'ajuster la frequence de toute la puce, sous systeme memoire inclue. Ca fait d'ailleur partie des points de mesure en premiere approximation de la consomation d'energie de deux logiciels qui font la meme chose. D'ailleurs ils ont des fonctions sympa, comme la possibilite de couper l'alimentation complete d'un banc de memoire pour sauver de l'energie. Ca veut dire qu'il faut bouger tout le monde pour ne pas perdre les donnees, mais c'est payant si ton soft est optimise pour ne pas utiliser trop de memoire et avoir des grandes periodes de veille
La strategie etant d'attendre un peu, de signaler aux applications qu'on va partir en veille profonde donc qu'elles doivent vider leur cache et compresser leurs objets ou juste se succider. Puis on peut commencer a bouger les pages d'un banc a l'autre, probablement que l'utilisation de zswap peut aider dans ce scenario. Enfin on peut peut etre couper un banc memoire complet et partir en suspend. Sachant que en suspend, la memoire est le second point de consomation (derriere la radio), c'est une optimisation assez sympa, surtout sur les telephones qui passe leur temps en suspend dans la poche.
[^] # Re: Oui
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3.
Si l'API systeme est du C, tu as une meilleur portabilite tes applications existantes. Ca peut aider quand tu bootstrap un ecosysteme de pas partir de zero.
Au hazard, ecosysteme limite (la portabilite de solution existante est limite), performance problematique et peu de chance que ca s'ameliore. Les performances sur un telephone sont critiques. Dans un premier temps, il te faut atteindre les 60FPS constant (pas encore la pour FFOS), ensuite il faut diminuer ta consommation de memoire (pour faire du multitache, parce que bon avoir un seul tab/application actif, c'est plus trop acceptable de nos jours) et enfin il faut diminuer la consommation de batterie (parce que bon, c'est bien si tu peux encore l'utiliser quelques heures ton telephone :-) ). Je met les optimisations dans cette ordre, car c'est veritablement dans cette ordre que l'on peut resoudre le probleme. Et dans tout ca, partir avec de l'HTML/JS, c'est partir avec un gros handicap.
Donc tu te retrouves avec un OS plus limite et moins performant. Tu peux tenter de le vendre dans le bas de gamme ou les clients sont moins regardant, mais Android est deja plus performant et avec un ecosysteme plus complet… Autant dire que courir une course en partant apres tout le monde et en utilisant des bequilles, c'est clairement pas un avantage !
[^] # Re: L'histoire se repette !
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 4.
Malheureusement les drivers ne sont pas encore tres utilisable pour faire un telephone. Freedreno ne permet que de piloter l'ecran externe du Nexus 4, la derniere fois que j'ai regarder. La derniere fois que j'ai regarder, il n'y avait pas encore de solution simple pour avoir un GNU/Linux en dual boot avec Android (histoire de ne pas avoir une brique inutilisable). Pour les machines a base de Vivante, Mali, tu peux oublier, on n'en est pas encore la du tout. Donc pour developper une distribution libre pour telephone, tu as encore "un peu" de boulot, juste sur le bas niveau.
Contrairement a ce que tu penses, je ne crois pas que le modem soit un "vrai" probleme. C'est finalement pas different des blobs pour carte reseau et autres sur PC. L'API publique est defini et utilisable. Ils sont extensivement teste et peu modifier au cour du temps pour faire leur tache, donc assez stable et parfaitement utilisable depuis le systeme host. Pas de quoi empecher la realisation d'une distribution libre.
Effectivement, c'est un probleme de securite si le modem a un acces DMA a la memoire systeme, ce qui est le cas avec quasiment tous les modems LTE et probablement aussi 3G. Mais bon une attaque qui consisterait a introduire du code dans le modem pour t'espionner, requiert que tu sois une cible importante, car il faut :
- un firmware pour ta version de telephone patcher pour dumper sur le reseau mobile sans trop d'instabilite
- un acces physique pour changer le blob et le rendre permanent
- ou une faille remote et utiliser une antenne mobile pour injecter le code (ce qui requiert une surveillance de proximite de la cible)
- enfin un monitoring de proximite pour reussir a dumper la memoire de ton telephone (car faire un dump sur un reseau d'operateur, ca va pas trop marcher)
- bien entendu, le dump va necessiter d'analyser la memoire de maniere specifique, en ayant un systeme exotique, tu viens juste de rendre cette analyse extremement couteuse et il faudra donc une tres tres bonne raison pour mettre en place une telle attaque…
Rien d'impossible et probablement que la NSA en a les moyens, mais ca n'est pas une attaque de surveillance de masse et necessite que tu sois une cible de tres grande valeur pour que ca en vaille le cout…
D'ou mon point de vue qui est de dire que ce n'est pas un probleme (sans compter que de faire certifier ton nouveau firmware libre pour modem, ca sera drole).
Il sera plus important pour arriver a avoir une distribution libre de reussir les etapes suivante :
- dual boot distribution classique/android
- reverse engineering du protocal du compositeur de Android pour pouvoir faire un serveur Wayland/Surface flinger et avoir une migration d'un telephone qui marche a un telephone libre plus probable.
- merge du patch volatile memory dans le kernel (avec 1GB sans swap et avec du multi app dont du web, ca part vite, faut pouvoir redonner efficacement de la memoire au systeme).
- porter les toolkit/serveur Wayland sur Android (ca veut dire commencer par faire marcher tous les desktop sur Wayland)
- ecrire/modifier des applications en se focalisant sur l'optimisation CPU/Memoire/Batterie.
- avoir un noyau a jour avec tous les peripheriques de supporter (le nexus 4 semble bien parti)
- ajouter le concept de intent dans la stack Linux libre
Ca fait pas mal de boulot et si on a un truc utilisable dans 2 ans et capable de remplacer un Android, je serais content…
[^] # Re: L'histoire se repette !
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Cool, je compte sur toi ! :-)
# 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é à 6.
Hum, euh, hum, c'est bizarre, je dois vivre dans le futur. Ici tout le monde a la fibre et la 4G. Tu peux trouver du wifi gratuit a peu pres partout, meme les bus on une borne Wifi (Et aussi des TV avec de la pub entre deux arrets). Par contre, on fait plutot du tethering, vu qu'on a 5Go de limite mensuel sur nos forfaits 4G. Une fois les update automatique d'Android desactive, il y a de la marge pour consommer de la bande passante sur une seule SIM.
Ah, oui, je ne suis pas en France, ni dans le futur, mais juste en Coree !
Sinon j'ai du mal a voir comment pourront etre utiliser ce genre de CPU sur une utilisation de courante par tout le monde. La plus grosse contrainte sur la majeur partie des taches que l'on fait tous les jours, a part pour la cryptographie et la decompression video, c'est la bande passante memoire. Et meme si tu utilises de la compression a la volee, tu ne vas pas gagner tant que ca, sans compter que ca complexifie ton code pas mal. Pour du rendu 2D, la plus part des taches (a part le blend avec du smooth scaling) sont capable de saturer un unique core et la 3D est plus facilement gere par un GPU. On experimente actuellement la decompression RLE de glyph pour ameliorer les performances du rendu texte en software, et ca marche, mais un coeur unique est encore suffisant pour saturer la bande passante memoire. Et ca, c'est avec des infrastructure qui se parallelise bien.
Paralleliser le rendu et la manipulation d'une page web, sans augmenter les besoins de bande passante memoire, c'est un joli challenge. Je me demande comment Servo/Rust va s'en sortir de ce cote la. Mais pour le reste, si tu arrives a utiliser en parallele efficacement plus de 4 cores, je dis chapeau bas. Apres il y a probablement une possibilite, si tu arrives a faire tourner 4 coeurs a moins d'un tiers de la frequence d'un seul pour le meme resultat, peut etre que tu consommeras moins d'energie (du fait que la consomation est une loi en puissance cubique de la frequence). Mais pour l'instant aucun toolkit n'est capable de mettre en avant une tel infrastructure et on ne sait pas encore si au final, le cout de la parallelisation en logiciel (lock, queue, allocation memoire …) ne va pas augmenter la consomation d'energie quand on commence a utiliser plein de coeur. Et puis aussi, combien de coeur peut reussir a utiliser une application ? 2 sans souci, 4 probablement, 8 ce sera deja un challenge… alors 256 ! Donc ce n'est probablement pas une solution pour tout le monde.
[^] # Re: L'histoire se repette !
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Qualcom et arm ont a peu près la même part de marché et aucun ne voit l'intérêt du libre. Et vu leur croissance,ils ne sont pas près d'écouter ! Seul l'arrivée d'un outsider pourrait les faires réagir, mais Intel après ça conférence du ces ne semble pas être intéresser par le domaine du mobile…
[^] # Re: L'histoire se repette !
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3.
Si tu as 20 millions d'euros, je te le fais. Il faudra aussi trouver 30000 clients deboursant environs 700€ pour un nouveau téléphone par an…
Le problème c'est que la majorité des investisseurs ne comprennent pas l'intérêt du logiciel libre et encore moins les problèmes de sécurité du logiciel propriétaire. Ensuite même avec un tel budget, tu n'auras pas de drivers avec qui que ce soit qui fait un chipset arm…
# L'histoire se repette !
Posté par cedric . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 10.
Bienvenue au debut des annees 90 ! L'histoire se repette cela en est presque triste…
Il n'existe pas encore de projet libre comme KDE ou GNOME pour faire un OS mobile libre. Ce qui s'en rapproche le plus, c'est probablement Cyanogen mode qui est a Android ce que Gnome etait a Windows a l'epoque. Mais on est loin d'avoir un eco systeme aussi complet que sur le desktop. La principale raison, c'est que Android nous pousse a tout reinventer pour diverse raison.
La premiere, c'est que comme environnement de developpement natif, Android, c'est la poisse si tu veux reutiliser ce que tu as deja fait. Il te faut ajouter un Android.mk dans tes sources et le maintenir. Et il faut faire ca pour toutes tes dependances.
Une fois que tu as passe la barriere de ce premier probleme, tu vas te rendre compte que l'approche de KDE et GNOME qui a ete tres pragmatique et n'a pas du tout pousse a l'optimisation va rendre absolument inutilisable leur techno pour longtemps sur le mobile. Il va falloir reinventer un environnement complet pour y arriver, ou pas loin. C'est ce que fait KDE avec Plasma pour tablette.
Enfin quand ca marchera a peu pres, le principal probleme restera l'etat des drivers qui sont globalement catastrophiques sur ARM et Android. Ils sont globalement teste et optimise pour un seul scenario et mettre une autre plateforme que celle attendu par dessus, c'est comme construire sur un chateau de carte. Sans compter que chaque driver a son propre set d'API proprietaire et que cela ne derange pas les constructeurs de completement modifier leur stack juste pour un driver. Par contre dans le libre, se tapper la maintenance de n backend differents et de plus en plus nombreux, ca n'est pas jouable.
Il va nous falloir des annees pour regler ces problemes et quand ce sera fait, et bien le marche sera aussi domine par Android que le desktop par Microsoft. Il est deja certain que Android/Arm a gagne et que personne n'arrivera a revenir dans la course du mobile. On a remplace le couple Microsoft/Intel par Google/Arm. Je ne suis pas convaincu qu'on est forcement gagne au change en fait !