Logicielsmoto.com
Nous sommes le 12 Oct 2024, 11:14

Voir les messages sans réponses | Voir les sujets actifs


Index du forum » Technique » Programmation

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  Page 39 sur 41
  [ 601 messages ]  Aller à la page Précédente  1 ... 36, 37, 38, 39, 40, 41  Suivante
  Imprimer le sujet Sujet précédent | Sujet suivant 
Auteur Message
Bentoc
MessagePosté: 21 Nov 2022, 16:22 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
Je n’ai pas encore intégré tes deux dernières optims … c’est sur la todo list :tourne:
Merci :bien:
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 23 Nov 2022, 23:02 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
ça y est :
- dernières optims commit
- mise à jour de toutes les démos avec la nouvelle routine RunObjects
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 26 Nov 2022, 22:54 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
tiens ... j'ai remarqué un oubli d'optimisation dans mon générateur de sprite compilé :

Code:
adr_fnt_3x7N_50_DN0
   LEAU 120,U

   LDA #$00
   STA 120,U
   STA -120,U
   LDA 80,U
   ANDA #$0F
   ORA #$00
   STA 80,U
   LDA 40,U
   ANDA #$0F
   ORA #$00
   STA 40,U
   LDA ,U
   ANDA #$F0
   ORA #$00
   STA ,U

   LDU <glb_screen_location_1
   LEAU 140,U

   LDA 100,U
   ANDA #$0F
   ORA #$00
   STA 100,U
   LDA -60,U
   ANDA #$0F
   ORA #$00
   STA -60,U
   LDA -100,U
   ANDA #$0F
   ORA #$00
   STA -100,U
   RTS


quand on a un pixel plein index couleur 0 et un pixel transparent, on fait un ORA #$00 totalement inutile.
Haut
 Profil  
Répondre en citant le message  
Samuel Devulder
MessagePosté: 27 Nov 2022, 00:39 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1809
Localisation: Brest
J'ai aussi remarqué dans le code qu'on fait souvent des ANDA #$00 pour nettoyer la partie haute de D.

Alors ok c'est 2 cycles, c'est rien, mais c'est surtout 2 fois plus d'octets que CLRA. Au final ces petits octets s'accumulent et ajoutent une bank RAM qui pourrait servir plus tard. Idem avec LDA #0, qu'il vaut mieux remplacer par CLRA généralement parlant.

Le seul cas ou ANDA #0/LDA #0 se justifie c'est lorsqu'on veut préserver la retenue (CLRA l'éfface).

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
Yoann Riou
MessagePosté: 28 Nov 2022, 15:33 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 492
Bentoc a écrit:
tiens ... j'ai remarqué un oubli d'optimisation dans mon générateur de sprite compilé :

quand on a un pixel plein index couleur 0 et un pixel transparent, on fait un ORA #$00 totalement inutile.


De meme qu'un ANDA #$FF si t'en as
Haut
 Profil  
Répondre en citant le message  
Samuel Devulder
MessagePosté: 03 Déc 2022, 12:24 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1809
Localisation: Brest
Samuel Devulder a écrit:
Sur 32s d'execution, il n'y a qu'une seule lecture dans la zone $4000-$5FFF, en $4774 suite à un LDA D,Y en $3C70. Ca ressemble plus à un débordement de tableau qu'un truc volontaire: https://www.cjoint.com/doc/22_10/LJEv5a ... .html#3C70


Je pense que c'est un bug de l'outil d'analyse car je viens de fixer un soucis faisant apparaitre des lectures à des adresses fantômes.
https://github.com/Samuel-DEVULDER/DCMo ... e816fR2091

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 03 Déc 2022, 12:44 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
ah super, merci pour l'info.
J'avais fait quelques tests mais n'avais pas réussi a reproduire le problème.
Haut
 Profil  
Répondre en citant le message  
Samuel Devulder
MessagePosté: 07 Déc 2022, 21:42 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1809
Localisation: Brest
Groumph, je fais un test d'installation du source sur une nouvelle machine (linunx pour simplifier) et je repars de 0.

Déjà après le checkout j'ai 75 fichiers modifiés par GIT à cause des \r\n qui trainent. Bon ca ca va je sais gérer, mais je suis surpris par le nombre de fichiers en CRLF. Je pensais que tout avait été nettoyé.

Ensuite je compile mais je tombe sur cette erreur:
Code:
$ java -jar ../../java-generator/target/game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar ./s2-EHZ-halfline2-linux.properties
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Load Game configuration: ./s2-EHZ-halfline2-linux.properties ...
Build error.
java.lang.Exception: Impossible de charger le fichier de configuration: ./objects/main-character/sonic/Sonic.properties
        at fr.bento8.to8.build.Object.<init>(Object.java:55) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.GameMode.<init>(GameMode.java:118) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.Game.<init>(Game.java:176) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.BuildDisk.loadGameConfiguration(BuildDisk.java:201) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.BuildDisk.main(BuildDisk.java:127) [game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
Caused by: java.io.FileNotFoundException: ./objects/main-character/sonic/Sonic.properties (No such file or directory)
        at java.io.FileInputStream.open0(Native Method) ~[?:?]
        at java.io.FileInputStream.open(FileInputStream.java:219) ~[?:?]
        at java.io.FileInputStream.<init>(FileInputStream.java:157) ~[?:?]
        at java.io.FileInputStream.<init>(FileInputStream.java:112) ~[?:?]
        at fr.bento8.to8.build.Object.<init>(Object.java:52) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]

Et effectivement, sur mon disk, le fichier ./objects/main-character/sonic/Sonic.properties est écrit ./objects/main-character/sonic/sonic.properties avec un s minuscule. Comment ca se fait que je ne découvre cela que maintenant ? Les compiles précédentes sur l'autre machines n'avaient pas ce soucis.

Une fois cela corrigé, je me dis qu'enfin c'est bon, mais hélas:
Code:
                        ./generated-code/Bridge/Img_bridge_log_0_ND1.lst lwasm.exe DRAW cycles: 501 computed cycles: 501
                        ./generated-code/Bridge/Img_bridge_log_0_ND1.lst lwasm.exe DRAW size: 316 computed size: 316
Generate Tilesets ...
        EHZ tileset: Tls_EHZ
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at fr.bento8.to8.image.SpriteSheet.prepareImages(SpriteSheet.java:469)
        at fr.bento8.to8.image.SpriteSheet.<init>(SpriteSheet.java:431)
        at fr.bento8.to8.build.BuildDisk.generateTilesets(BuildDisk.java:579)
        at fr.bento8.to8.build.BuildDisk.generateTilesets(BuildDisk.java:552)
        at fr.bento8.to8.build.BuildDisk.main(BuildDisk.java:137)
Fin, arg oui cette machine n'a que 8Go de ram alors que la précédente en avait 32. Je ne pensais pas qu'il fallait autant de ram. Est-ce que j'aurais fais un truc de travers ?

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 07 Déc 2022, 22:39 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
Salut Sam,

Désolé pour ces déboires.

je viens de commit la correction du S majuscule. Etant sous Windows je ne vois malheureusement pas ces erreurs.
Pour les CR LF je vais regarder ... mais il faut que je trouve une solution pour contrôler de manière automatique car j'ai l'impression que le problème va revenir régulièrement.

En ce qui concerne la RAM c'est la première fois que je vois le problème.
J'ai regardé le profil de consommation :
On est à 150Mo au début, dès qu'on commence le tileset EHZ c'est là que ça monte fort : 1400Mo
On termine le build à 2200Mo avec des pics vers 2400Mo

est-ce que tu utilises une JVM 32 bits ? As tu possibilité de lancer une JVM 64 bits ?
Il me semble que c'est 2Go la limite pour une JVM 32 bits (sauf cas particuliers de certains Kernels linux)

Un coup de profiler ne ferait pas de mal sur le code du builder mais comme je vais le réécrire en grande partie ...
Haut
 Profil  
Répondre en citant le message  
Samuel Devulder
MessagePosté: 07 Déc 2022, 23:00 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1809
Localisation: Brest
C'est une JVM64bits. Pour tout dire je suis sous WSL2 (avant: WSL1) avec 8gb de limite de RAM. J'ai du mal à comprendre pourquoi java manque de mémoire sous ces conditions. Il me semble qu'il y a moyen de dumper la mémoire sur disk quand cela se produit, et l'analyser avec MAT. Je vais voir ca dès que je peux. Si ca se trouve c'est un bug dans le jdk (11.0.17 de mémoire) ou WSL2.

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 07 Déc 2022, 23:06 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
tu peux mettre : -verbose:gc -XX:+PrintGCDetails
pour tracer ce qui se passe.

As tu configuré un disque de swap ? (swapon, ...)
Haut
 Profil  
Répondre en citant le message  
Samuel Devulder
MessagePosté: 07 Déc 2022, 23:39 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1809
Localisation: Brest
oui il y a un petit swap de 2G.. Un truc que je suspecte est que les ByteBuffrers java ne sont pas alloués dans le HEAP java, mais à coté via un bon malloc() de base sous linux (source). Résultat: quand yen a trop d'alloués/désalloués ca fragmente la mémoire un max. Bon, ca n'est qu'une hypothèse.

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 08 Déc 2022, 08:29 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
Mea culpa j'ai bien fait une erreur dans le code.
... une erreur qui fait que j'alloue dans le cas d'un tileset, une quantité astronomique de mémoire.

dans SpriteSheet.java / prepareImages :

Code:
      int paddedImage = 80*height;
      pixels = new byte[subImageNb][2][paddedImage];
      data = new byte[subImageNb][2][paddedImage];


=> 2 allocations de [479][2][80*7664] => deux tableaux de 587 Mo continus !

a été corrigé par :

Code:
      int paddedImage = 80*(height/subImageNb);
      pixels = new byte[subImageNb][2][paddedImage];
      data = new byte[subImageNb][2][paddedImage];


=> 2 allocations de [479][2][80*16] => deux tableaux de 1,2 Mo

Outre le problème de la quantité requise, c'est bien la nature "continue" de la mémoire demandée qui a provoqué le out of memory.

Correction commit sur le repo.
Haut
 Profil  
Répondre en citant le message  
PulkoMandy
MessagePosté: 08 Déc 2022, 09:15 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 455
Localisation: France
Citation:
Pour les CR LF je vais regarder ... mais il faut que je trouve une solution pour contrôler de manière automatique car j'ai l'impression que le problème va revenir régulièrement.


Cela peut se faire dans la configuration de Git avec l'option "autocrlf"

https://git-scm.com/book/fr/v2/Personna ... ion-de-Git

On peut l'utiliser des deux côtés: sur la machine Windows qui crée les fichiers, ou sur la machine Linux qui essaie de les utiliser.
Haut
 Profil  
Répondre en citant le message  
Bentoc
MessagePosté: 08 Déc 2022, 12:28 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 437
Localisation: Var
super merci pour l'info !

Du coup de mon coté (windows) j'ai joué la commande : $ git config --global core.autocrlf true

Citation:
Git peut gérer ce cas en convertissant automatiquement les fins de ligne CRLF en LF lorsque vous validez, et inversement lorsqu’il extrait des fichiers sur votre système. Vous pouvez activer cette fonctionnalité au moyen du paramètre core.autocrlf. Si vous avez une machine Windows, positionnez-le à true. Git convertira les fins de ligne de LF en CRLF lorsque vous extrairez votre code :

$ git config --global core.autocrlf true
Si vous utilisez un système Linux ou macOS qui utilise les fins de ligne LF, vous ne souhaitez sûrement pas que Git les convertisse automatiquement lorsque vous extrayez des fichiers. Cependant, si un fichier contenant des CRLF est accidentellement introduit en gestion de versions, vous souhaitez que Git le corrige. Vous pouvez indiquer à Git de convertir CRLF en LF lors de la validation mais pas dans l’autre sens en fixant core.autocrlf à input :

$ git config --global core.autocrlf input
Ce réglage devrait donner des fins de ligne en CRLF lors d’extraction sous Windows mais en LF sous macOS et Linux et dans le dépôt.


J'ai refait la liste des fichiers avec crlf sur l'index :
git ls-files --eol | grep i/crlf

et j'ai push/commit les fichiers en question ...
Normalement il n'y a plus de fichiers en crlf sauf les binaires evidement.
Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  Page 39 sur 41
  [ 601 messages ]  Aller à la page Précédente  1 ... 36, 37, 38, 39, 40, 41  Suivante

Index du forum » Technique » Programmation

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 12 invités

Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com