Nouveau système d’allocation mémoire pour OS4

Un nouvel article est disponible sur OS4.Hyperion-Entertainment.biz. Il décrit le nouveau système d’allocation de la mémoire d’AmigaOS 4.0.

Il parle de la méthode des « alloueurs de slabs » et de la « mise en cache des objets » qui réduit de beaucoup la fragmentation externe de la mémoire tout en gardant la fragmentation interne au plus bas. Ceci a pour effet de garantir une allocation de la mémoire à vitesse constante.

Site internet : Site officiel AmigaOS 4.0

20 Commentaires

Passer au formulaire de commentaire

    • elwood sur 13 décembre 2005 à 23h38
      Auteur

    Si quelqu’un a une traduction pour « slab », je prends. 🙂

    NB: je viens de voir que ça veut dire « galette ». Ils sont forts ces informaticiens anglais. 🙂

    • Lynx sur 14 décembre 2005 à 8h15

    C’est à cause de la bière belge 😀

    • CLS2086 sur 14 décembre 2005 à 14h19

    Reste à voir les cycles CPU supplémentaires que cela va engendrer pour faire les déplacements, et surtout lorsque le « slab » sera plein

    • krabob sur 14 décembre 2005 à 15h37

    Là quand même vous êtes un gros tas de loosers question code. Mes amis, croyez en un demomaker:
    avec un bon algo, tu as toujours le beurre et l’argent du beurre: c’est a dire la performance ET le confort. Si on vous prétend qu’il faut « choisir » on vous ment.
    (en l’occurence, le site explique trés bien cet état de fait.)

    Reste à voir les cycles CPU supplémentaires que cela va engendrer pour faire les déplacements, et surtout lorsque le « slab » sera plein

    t’as pas du tout lire… il n’y a pas de déplacement !!! et quand le slab est plein on en prend un autre !!! les slabs ne sont crée qu’occasionnellement !! il n’y a énormément moins de recherche par liste, et plus par index: gain énormé de performance lors d’un uptime long.
    Il y a toujours des « trous », mais * statistiquement * beaucoup moins qu’avec la « vieille méthode ».

    Ce que j’avais pas compris au départ et qui est interessant, c’est l’aspect probabilité: les slabs se créée d’aprés des tailles d’allocs déjà demandé, et
    statistiquement ça doit fonctionner a mort !!!

    Il est certain aussi que ceci est d’autant plus optimal avec des mémoires genre 128,256,512 mb qu’avec les 2Mb d’un a1200 tout vanille. 😳

    Puis si il fallait tout expliquer, cette méthode de gestion peut permettre de mieux gérer d’autres aspet du systeme (comme noté sur le site)

    • krabob sur 14 décembre 2005 à 17h52

    Disons que tu as le meilleur compromis

    non et non, la programmation n’est pas une question de compromis, cent fois non non et non !!!

    par exemple, tu prends des algorithme de tri (pour faire classique), et ben un tri a bulle va te prendre statistiquement exponentiellement plus de puissante selon que tu as plus d’élément à trier.
    Certains algorithmes comme le radix vont te prendre
    une puissance « absolument proportionnelle » au nombre d’élément à trier. On va me dire: oui mais le radix demande une table mémoire supplémentaire. Eh ben avec un bon radix bien fait,( comme celui de karate, inspiré de scorpion/silicon) tu as 512 octets de table.
    -> c’est incroyablement plus rapide
    -> ça prends moins de puissance
    -> ça fait plus.

    Tu en as marre de ce systéme qui ne gére pas la pile et tu veux tracer des arbres récursivement ?
    Utilises ça

    En informatique, on peut toujours faire PLUS avec MOINS. essai de compreeeendre: PLUS AVEC MOINS.

    Kiero modeste ??? Brfffppfff pfbrr Aahahahahhaaaahh Tout ce qu’il sait dire dans la vie c’est « we rulez! yaa ! madwizaard is the best! yaa ! BASS! » avec une bouteille de vodka a moitié vide dans chaque main. (mais je suis d’accord les mawi sont fort en vodka)

    Kiero dans une posture difficile
    Kiero a la fete du slip

    • CLS2086 sur 14 décembre 2005 à 20h40

    @Krabob : je ne critique pas cette méthode inventé dans les labos de chez SUN au niveau sécurité, c’est leur spécialité.
    Quand je parle de déplacement, c’est que parfois tu as besoin de gros espaces en ram, donc avec cette méthode « sécuritaire » tu vas remplir des blocs non contigu (si j’ai bien pigé) te permettant de gagner plein de place, mais :
    1 – pas de « burst » en E/S de la ram donc baisse énorme du débit, nan ?
    2 – au final le gain de place peut être bouffé par la table des allocations si les fragmentations sont énormes….
    3 – si un prog à la porky big tape bien fort dans le hard et corromp un bloc contigu, what’s up doc ? possible ou non ?

    /ps : nan je ne mettrai pas le lien de Krabob en short … 😀

    • crisot sur 14 décembre 2005 à 22h07

    Disons que tu as le meilleur compromis (avec un programmeur de talent) et C l’idée de ma réponse.

    Non, il n’y a pas de compromis. Un truc bien programmé vas:

    – la vitesse maximale
    – à la consommation de mémoire minimale
    – au « confort » maximal.

    Le fait de baisser/monter l’un de ces facteur ne doit pas modifier un autre facteur dans l’autre sens. Sinon, c’est mal programmé.

    • crisot sur 14 décembre 2005 à 22h30

    Je me suis mis au C y’a a peu prèt un an et ce language est catastrophique! Mon C est gavé d’ASM dans la mesure du possible.

    Je n’utilise pas OpenGL, juste Warp3D pour le rendu polygon.

    EDIT: A ceci prèt que maintenant je néglige la consommation mémoire. Au prix du mega, rien à péter 🙂

    • crisot sur 14 décembre 2005 à 22h53

    Disons que personnellement ouai le « compromis » si tu en veux un je le fais sur le temps de developpement.

    Mais à la base ce que Krabob voulait dire, c’est que si on le veux et qu’on s’en donne les moyens, il y a possibilité d’etre optimal sur tout sans pour autant que cela soit un compromis sur autre chose (je parle uniquement à l’echelle du soft, pas de la vie sociale du developpeur). Et la vitesse n’a jamais été incompatible avec la stabilité.

    • crisot sur 14 décembre 2005 à 23h04

    Ca dépend si le reboot prend plus de 8 secondes 🙂

    Cela dit j’aime bien ton argument car à l’époque y’a quelques années c’était ce que je disais aux gens qui bavaient sur Windows qui métait 2 minutes à booter alors qu’un 4000 blindé prenait que 40 secondes.

    Sauf que le 4000 y’avait des jours où fallait le rebooter 10 fois 😉 Enfin bon on a quitté le sujet depuis un moment…. Moi j’essaye d’analyser la 2e page de l’article mais ça ne m’inspire qu’à moitier pour le moment….

  1. merde alors… suis-je bien ou mal codé ? mon ADN est il optimisé ou ne suis-je qu’un compromis ??? 😮

    Dieu aurait codé l’espèce humaine sans optimiser son code pour sauvegarder sa vie sociale ?

    • krabob sur 15 décembre 2005 à 10h27

    Quand je parle de déplacement, c’est que parfois tu as besoin de gros espaces en ram, donc avec cette méthode « sécuritaire » tu vas remplir des blocs non contigu (si j’ai bien pigé) te permettant de gagner plein de place, mais :

    vive les discussion interessante. On va effectivement remplir des blocs non-contigus, mais, avec la methode « classique » tu ne remplissais des blocs contigus QUE LORS DE LA PREMIERE ALLOC: dés que tu commences a libérer des blocs au « milieu », tu fragmentes ton tas de telle maniére que « ressouder les blocs libres » devient impossible. Donc tu gagnes de la place « statistiquement ».

    1 – pas de « burst » en E/S de la ram donc baisse énorme du débit, nan ?

    pourquoi ? non, le cache se fou des trou !!
    c’est d’autant plus vrai que les slags doivent forcer des alignement….(j’ai une idée trés claire des cacheligne en L1, mais en L2 moins… a vérifier: la taille d’un CL L2… et confer dcbz: pourquoi ne pas dcbzédifier toutes ligne de cache fraichement allouer->megaburst.)

    au final le gain de place peut être bouffé par la table des allocations si les fragmentations sont énormes….

    Mais non c’est tout le contraire !
    avec la methode classique, tu as une structure de cellule qui gére et connait ton alloc, avec des info dessus, meme si tu a fait « malloc(1) » . Avec les parts de gateau, tu as une cellule qui gére une part, avec des bool qui disent qui est utilisé->gain de place énooorme en fait et non perte !!

    Et en fait, les plus malins auront compris que la mémoire ne se fragmente plus ou infiniment moins (si des free() manquent) au cours du temps: un slab se désalloue si il est vide.

    si un prog à la porky big tape bien fort dans le hard et corromp un bloc contigu, what’s up doc ? possible ou non ?

    ??? meme probléme qu’avec l’ancienne methode !!! mais les structure qui gére la mémoire sont sencé etre protégé dans un bon systeme. De plus a cause de (2) il y a moins de chance que ça arrive. 🙄

    -> Que des avantages
    -> aucun inconvénient.

    Notez que quand j’ai vu l’info hier ma réaction a été:
    « ben heureusement qu’ils doivent faire des effort sur les allocs, c’est la moindre des choses. » La problématique de l’évolution du (des?) systemes amiga devrait se situer bien plus haut que ça… Au boulot hypérion ! une vrai ressource tracking par dessus ça et là oui ça prendra son sens. (plus de libération manquante= plus de fragmentation RAM)

    • krabob sur 15 décembre 2005 à 15h00

    merde alors… suis-je bien ou mal codé ? mon ADN est il optimisé ou ne suis-je qu’un compromis ???

    Pas de panique je répond.
    Nous sommes tous mal codé. Le programmeur, c’est le darwinisme. Nous sommes plus ou moins « adapté à notre milieu ». C’est une erreur de croire que la nature selectionne l’intelligence. La plupart du temps elle selctionne la bétise. Le fait que certain humain soit intelligent (genre 1 sur 400) est du au hazard. La plupart de ces gens sont les clochards les plus sales, d’autres sont demomaker ou alcoliques.

    Dieu aurait codé l’espèce humaine sans optimiser son code pour sauvegarder sa vie sociale ?

    ce gros mongolo de dieu n’existe pas. Seul le pére noël est la seule élucubration digne d’interet.

  2. Au risque de me faire taper sur les doigts (je m’en fiche j’en ai plein), c’est quoi la différence entre les « stabs » et les « pools ».

    Et encore pire (aïe): pour le système mémoire de Feelin j’utilise une chtite table de hashage qui gère les « puddles » et qui trouve les chtites allocations en un éclair. Les stabs utilisent toujours des listes est-ce que c’est pas juste un mieux en performance mais c’est pas merveilleux non plus.

    Perso en lisant l’article je me suis dis qu’ils comparaient leur système mémoire avec le VIEUX AllocMem()/FreeMem() mais PAS DU TOUT avec le système des « pools » introduit avec l’OS 3.0… ça me laisse perplexe… surtout quand on sait à quel point la foule est impressionnable… enfin ske j’en dis 😉

Les commentaires sont désactivés.

Amiga Impact