| Amiga Impact

  · Accueil
  · Actualités
   · Proposer une info
  · Agenda
   · Proposer une date
  · Articles
  · Forum
  · Petites Annonces
  · Chat IRC
  · À propos du site



 | Connexion

Identifiant :

Mot de passe :

 Mémoriser

  · Inscription
  · Mot de passe oublié



 | En ligne

Illustration du profil de Aurélien Loron Illustration du profil de rodi Illustration du profil de Bwah Bwah Illustration du profil de infinity1200 Illustration du profil de EdVirus




 | Nous suivre

Flux RSSGoogle+TwitterFacebook





Actualités


   Nouveau système d’allocation mémoire pour OS4
   | 13 décembre 2005 | Logiciels,

logiciels

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




Les commentaires appartiennent à leurs auteurs.
Nous ne sommes pas responsables de leur contenu.


Auteur Conversation
elwood Posté le 13 décembre 2005



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 Posté le 14 décembre 2005



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



CLS2086 Posté le 14 décembre 2005



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



logo Posté le 14 décembre 2005



Ah, l’éternel débat entre confort-sécurité Vs performance !

Si tu vas trop loin avec les premiers, tu as quelque chose d’aussi optimisé que Windows ;-).
Avec le second, poussé trop loin, tu es en ligne de commande jusqu’en l’an 3000…



krabob Posté le 14 décembre 2005



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)



logo Posté le 14 décembre 2005



avec un bon algo, tu as toujours le beurre et l’argent du beurre

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

N’empêche que ce débat est éternel :
Assembleur Vs C
Protection mémoire Vs Pas de protection mémoire
Ligne de commande Vs Tout souris (la souris a gagné)
etc…

Là quand même vous êtes un gros tas de loosers question code. Mes amis, croyez en un demomaker

MDR
Tu devrais quand même demander à Kiero un peu de modestie pour noël, parce qu’être un bon demomaker comme toi C pas mal, mais être un bon demomaker modeste, C la classe internationale ! 😉



krabob Posté le 14 décembre 2005



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 Posté le 14 décembre 2005



@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 Posté le 14 décembre 2005



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é.



logo Posté le 14 décembre 2005



@Krabob

Tu piges keudal 😉 !
Où ai-je mentionné que la programmation C du compromis ???
Je parle d’une fonctionnalité (d’un Os par exemple) qui apporte du confort ou de la sécurité.

Je suis complètement de ton avis pour dire qu’il y a toujours une bonne manière et une (des) mauvaises manières pour coder quelque chose, mais ça n’a rien à voir avec mes propos.

Pour résumer, je voulais juste dire qu’un système stable, par exemple, C souvent au prix de quelques cycles supplémentaires dépensés pour faire la « police » à propos de la manière dont s’exécutent les programmes.

Autre exemple : un antivirus + un firewall C de la sécurité, mais au prix d’une baisse de performances de la machine hôte…

Voilà ce que je désigne par compromis. L’idéal étant pour moi de trouver le juste équilibre.
Maintenant, si cette nouvelle fonctionnalité Os4 permet à la fois de stabiliser le système, et en plus d’en augmenter les perfs, alors très bien… Vous aurez le beurre et son argent !



logo Posté le 14 décembre 2005



@Crisot

Alors je suppose que tu refuses toute programmation C ou avec tout autre langage de haut niveau, ou d’utiliser une bibliothèque OpenGL par exemple.

Bah oui, parce que pour tout ça, on ne peut appliquer ta règle d’or. Ce n’est que du compromis.



crisot Posté le 14 décembre 2005



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 🙂



logo Posté le 14 décembre 2005



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

Ce ne serait pas un compromis ça, entre temps d’optimisation nécessaire pour améliorer la gestion mémoire (d’utilité faible) et quantité de mémoire disponible ?

Oh le vilain, il a fait un compromis ! 😉

En fait, je ne pensais pas à ça directement, mais coder C donc bien aussi faire des compromis entre :
performance
efficacité d’une optimisation
facilité de mise à jour
portabilité
temps de développement
(envie d’aller faire un calin;-))
etc..



crisot Posté le 14 décembre 2005



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é.



logo Posté le 14 décembre 2005



Je dirais même que si tu trouves le bon compromis, l’amélioration de la stabilité peut te permettre d’améliorer la vitesse.

Ouais, éviter de rebooter toutes les 5 minutes, ça fait gagner du temps !



crisot Posté le 14 décembre 2005



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….



SoundSquare Posté le 14 décembre 2005



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 Posté le 15 décembre 2005



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 Posté le 15 décembre 2005



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.



Gofromiel Posté le 16 décembre 2005



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 😉








Haut de page 

Copyright © 2004-2017 Amiga Impact. Tous droits réservés. Les marques citées sont déposées par leurs propriétaires respectifs.
Conditions d'Utilisation, Politique de Confidentialité et Information sur les cookies.


Fil RSS WordPressNicolas Gressard, Conseil et développement informatique

Do NOT follow this link or you will be banned from the site!