cent20 wrote:- Le lien entre le CPU utilisé et la mémoire totale maximum disponible, ainsi que le % de mémoire accordé au heap et donc la capacité du constructeur à exploiter correctement son hardware.
Le problème est que nous n'avons pas de méthode universelle pour connaître la capacité exacte de la mémoire RAM sur les modèles à matériel fermé.
Donc si on ne peut pas tester sur tous les modèles, le critère ne pourra pas être comptabilisé au classement.
cent20 wrote:- La fragmentation de la mémoire et ses conséquences : l'année dernière, lors de l’exécution des scripts proposé ici pour évaluer la mémoire sur la NumWorks, on trouvait que le premier bloc mémoire faisait 4 ko puis plus tard après une mise à jour 8ko. Quels conséquences concrète cette fragmentation de la mémoire a t'-elle lors de l’exécution d'un script ?
En gros, pour la même quantité disponible une mémoire plus fragmentée t'interdira de gros objets.
Tu pourras tout aussi bien la remplir, mais avec plusieurs objets plus petits.
Après, il y a de l'aléatoire intervenant déjà sur la quantité totale de heap disponible, même si nous avons finalement réussi à contourner le problème de façon assez fiable ici, ce qui n'était pas le cas l'année dernière. On s'améliore chaque année.
Tout ça pour dire que cet aléatoire interviendra aussi dans la fragmentation, et qu'il faudrait donc un protocole pour contourner cela.
Tu peux déjà consulter la fragmentation mémoire avec le script fourni, il suffit d'appeler
mem() au lieu de mem(0).On pourrait s'arrêter au 1er bloc de mémoire contiguë qui a pu être alloué et tenter de le maximiser de façon similaire, mais j'ignore a priori si c'est donc possible/fiable sans le module gc.
: 
