Utilisateurs RiscOS francophones - Page 2

Ah oui, 20k cycles pour 20 millions, c'est 1 pour mille, donc c'est vraiment minime en effet. Merci bien.

Ximoon (./23) :
Et quid de leur réactivité, justement ?

Ça dépend, il y a plein de manières de faire. Il s'agit généralement de systèmes embarqués.
On peut soit fonctionner sur interruption, ce qui permet de garantir la réactivité, justement, soit fonctionner sur du polling, ce qui permet de la séquencer, voire d'en rendre l'évolution déterministe.

Quoi qu'il en soit, le simple fait qu'il existe des systèmes sans scheduler est suffisant à montrer qu'on ne peut pas mesurer la réactivité du système simplement en analysant le scheduler, sinon ça voudrait dire que la notion de réactivité est indéfinie pour les systèmes qui n'en ont pas.

Non, ça veut simplement dire que la réactivité dépend du mécanisme qui gère les priorités des tâches, qui est bien essentiellement le scheduler dans les systèmes qui en ont un, et autre chose dans les systèmes qui n'en ont pas.

zerosquare

Oui, mais ce n'est pas ce qui était dit dans le post que je citais. D'où ma remarque.
Encore que même comme ça c'est toujours qu'une vérité partielle, dans le sens où par réactivité il y a également la réactivité aux événement matériels, qui ne dépendent pas que du scheduler, mais également d'autres critères, tels que la rééentrance de certaines sections du noyau et/ou des drivers.

Zerosquare (./31) :
Il me semble que les timeslices de Windows et Linux sont aux alentours de 10 ms

windows oui, linux très souvent.

Folco (./29) :
C'est marrant, comme j'ai l'impression que ce sont toujours des millisecondes qui sont donnés aux processus, le temps de scheduling est du coup important en comparaison. De plus, il faut modifier le proc, au niveau des registres et du pipeline (à moins que certaines instructions modernes permettent de faire un backup/restore très rapide de l'état du CPU j'imagine ?), je pense aussi qu'il doit y avoir des changements dans la MMU, les ports etc... Bon bref, je constate que ça marche très bien, mais je sais pas du tout comment

oui, on donne des ms au process, mais le scheduler s'exécute en quelques microsecondes, les vitesses d'exécution d'instructions individuelles sont encore plus faibles.

A sauvegarder, il y a les registres normaux, les FPU, et le pointeur vers la table des pages, qui est juste un registre de plus (cr3 sur x86, c2 du coprocesseur 15 sur ARM)
Il y a un tout petit peu de temps perdu par le vidage des caches, que ce soit instruction ou table de pages, justement.
http://fr.wikipedia.org/wiki/Translation_Lookaside_Buffer
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0198e/Babjcchb.html

Folco> tu peux toujours aller jeter un coup d'oeil au scheduler d'Opale si tu veux

Ah oui c'est vrai, ce "noyau multi-threadé en 68k"

Folco (./26) :
Pour info, quel est le pourcentage de temps CPU bouffé par un scheduler, en moyenne, sur une machine PC "de base", avec un seul coeur etc...

Godzil (./27) :
oula ridiculement bas

Ça dépend quand-même du scheduler. Je me rappelle qu'à un moment, le noyau Linux est passé à un scheduler en O(1) (je ne sais plus quelle complexité le scheduler avait avant) et que ça a accéléré pas mal le système quand il y avait beaucoup de processus.

Oula le O(1) de linux c'est du passé!

Ca va faire plus de 10ans qu'il est passé a la trappe lui

Et maintenant, c'est pire ou mieux ?

Faut faire exprès pour avoir un temps de traitement en O(1) ?

ça veut dire temps constant quel que soit le nb de processus, donc ça veut dire qu'on ne parcourt pas de liste.
C'est possible si on se démerde pour que le prochain processus a activer soit toujours le premier au début de la liste.

on peut faire pareil pour gérer une grande série de timers qui doivent péter à des moments différents; On les classe par ordre croissant de date d'expiration, ça prend plus de temps à la création, mais l'interrupt n'a qu'à s'occuper du premier timer de la liste.

Zerosquare (./33) :
Non, ça veut simplement dire que la réactivité dépend du mécanisme qui gère les priorités des tâches, qui est bien essentiellement le scheduler dans les systèmes qui en ont un, et autre chose dans les systèmes qui n'en ont pas.

Bin cet autre chose correspond quand même vachement à la définition d'un scheduler, non ?
Après, l'algo n'est pas forcément centralisé en un seul code, mais ordonnancer, c'est justement donner la méthode pour dire quel processus est exécuté où, et à quel moment. Ton scheduler peut être basé sur des interruptions, sur un code central qui préempte les processus, mais ça reste un scheduler.

Ximoon (./41) :
Et maintenant, c'est pire ou mieux ?

Mieux. On a le Completely Fair Scheduler d'Ingo Molnár de Red Hat, qui a une complexité proche de O(1) (O(log(N)) dans le pire des cas, O(1) amortisé; en titre de comparaison: le scheduler antique qui avait été remplacé par celui en O(1) était en O(N)!) et produit des résultats nettement meilleurs que le vieux O(1) Scheduler (du même auteur). C'est le fait de garantir ces propriétés qui necessite un arbre binaire balancé (bicolore) et donc une complexité logarithmique dans le pire des cas.

Je comprends pas, tu sembles parler d'un scheduler en O(1) nettement meilleur qu'un vieux en O(1) ?

Il y a eu 3 schedulers (enfin, il y en a eu encore plus, mais je parle des 3 les plus récents):
1. un scheduler en O(N) (trop lent!)
2. O(1) Scheduler (Ingo Molnár), qui réussit à être en O(1) strict à travers plusieurs listes chaînées et des heuristiques, mais malheureusement ces heuristiques peuvent entraîner un scheduling "injuste"
3. Completely Fair Scheduler (Ingo Molnár, également), qui garantit un scheduling juste (fair) en O(log(N)) garanti, et normalement les opérations sur les arbres s'amortisent en O(1) (mais ça dépend de la séquence exacte des insertions et suppressions)

flanker (./45) :
Bin cet autre chose correspond quand même vachement à la définition d'un scheduler, non ?

Disons que je n'ai jamais vu ce mot être employé dans le contexte, par exemple, d'un système sans OS avec une gestion des priorités par interruptions (même si je suis d'accord avec toi que le principe est équivalent à celui d'un scheduler).

Folco : n'oublie pas que la complexité est définie à une constante multiplicative près, et n'indique que le comportement quand N tend vers l'infini. Donc tu peux très bien avoir deux algos A et B qui sont tous les deux O(1), mais A plus performant parce qu'il effectue deux fois mois d'opérations pour obtenir le même résultat. De même que si ton N a une borne supérieure, avoir un algo en O(N) qui est meilleur qu'un autre en O(1).

en plus il faut distinguer la complexité au mieux, au pire, et en moyenne.

Dans le cas des schedulers O(1) et CFS, la complexité du CFS est en fait moins bonne en ce qui concerne la complexité du scheduler (ce n'est plus garanti être en O(1), il y a des cas où il faut O(log(N)) pour mettre à jour la structure de données), mais les résultats sont nettement meilleurs, donc globalement c'est le meilleur scheduler.

()

bonjour tous le monde

je suis tous nouveau sur RiscOS et j'aimerais s'avoir comment me connecter a ma freebox avec une cle wifi TP-LINK

sur un raspberry pi 700MHZ 512M de ram merci d'avance de vos réponses

turbore

Pour moi le RaspBerry pi, qu'il soit sous Raspian ou sous Risc OS, c'est un objet pour faire de l'électronique.
Ce que je regrette quand même, c'est l'absence dun IDE standard et gratuit pour développer en C, sous forme d'un paquet comprenant la totalité des applications et bibliothèques nécessaires. Je sais, il existe un DDE payant qui a tout ça et Charm qui utilise un shell dédié!
Si vous êtes organisé pour développer sous Risc Os, j'aimerais savoir ce que vous avez installé!

Si tu veux faire de l'electronique, part plutot sur une BeagleBone c'est fait pour, 100% opensource, et ca a de vrai IOs contrairement a la RaPI.

Ah ? Il me semblait que c'était un SGX qui était utilisé pour l'acceleration graphique sur cette board. Il est où le driver "100% opensource" ?

Oui c'est un SGX, mais tu n'as pas besoin de la partie 3D pour faire de l’électronique, ni d'un blob binaire pour avoir de l'affichage, la puce SGX n'est pas indispensable pour l'affichage, la partie 2D est documenté.