Progs en C - Page 4

GoldenCrystal :
Comme si une nouvelle version allait faire gagner plusieurs Ko

Sur un projet de plusieurs dizaines de KO, c'est tout à fait possible!

(enfin, si c'était le cas ==> gcc est mal programmé)

Non, il y a de nouvelles optimisations qui ont été rajoutées, et surtout les optimisations existantes ont été améliorées, tout simplement.

Si. Le gain d'optimisation de GCC 3.3 est vraiment sensible. je pense que avec GCC 3.3 TIGCC très proche de GTC en matière d'optimisation place

si tu veux y'a mon snake mais c'est pas forcement tres interressant (17005 octets non compressé avec TIGCC v0.94 SP4).les sources sont sur ma page

En quoi est-ce sale ce quej 'ai fait pour les Pack Archive ?

Si. Le gain d'optimisation de GCC 3.3 est vraiment sensible. je pense que avec GCC 3.3 TIGCC très proche de GTC en matière d'optimisation place

Bon Thibaut m'a filé les sources d'Einstein pour que je compile avec GCC 3.3.

Résultat des courses (j'en ai profité pour que GTC affiche aussi la RAM requise pdt l'exécution) :

	--- Size statistics for Einstein ---

GCC version 3.3, -Os, -fomit-frame-pointer
GTC pre-version, -Os

*** Unpacked version
  TIGCC !ppg	32601
  GTC !exe	30385

  -> size gain : +7.3%


*** Packed version
 - RAM requirement
  TIGCC ppg	34306	(32601+1705)
  GTC exe	28766

  -> RAM gain  : +19.3%

 - Packed size
  TIGCC ppg	19749	(18044+1705)
  GTC exe	16979

  -> size gain : +16.3%

Voilà

Mais:
* tu as sans doûte utilisé l'ancien linker, qui ne peut pas optimiser jsr+rts en jmp. Le nouveau linker peut faire ça.
* je vais travailler encore sur l'optimisation de GCC pendant la série de bêtas de TIGCC 0.95. (Il y a un patch pour éviter les grosses tables de sauts qui vient d'être accepté pour GCC 3.4 que je vais probablement mettre aussi dans notre patchset pour GCC 3.3; et il y a encore le problème des bset/bclr/btst à règler.)

Pollux : GCC 3.3 a donc réduit Einstein de 1,2 ko. Pas mal

Kevin > Il y a un patch pour éviter les grosses tables de sauts
J'espère qu'il ne sera pas appliqué en -O2 et -O3.

Pourquoi éviter les grosses tables de saut ?
Que mettre à la place qui prendrait moins de place ?

Des branchements qui parcourent l'arbre des possibilités par dichotomie, je suppose.
Ca prend moins de place quand les valeurs possibles sont dispersées.

Kevin>kel nouveau linker

Euh désolé j'avais complètement oublié le mode regparm! Voilà le comparatif en mode regparm (pas eu le tps de faire le bench en non compressé, de toutes façons on s'en fout vu la vitesse de décompression de GTC) :

	--- Size statistics for Einstein ---

GCC version 3.3, -Os, -fomit-frame-pointer, -mregparm
GTC pre-version, -Os

- RAM requirement
  TIGCC ppg	33554	(31849+1705)
  GTC exe	29188

  -> RAM gain  : +15.0%

- Packed size
  TIGCC ppg	19487	(17782+1705)
  GTC exe	17045

  -> size gain : +14.3%

La différence est un peu plus faible, surtout au niveau RAM.

Thibaut :
Kevin > Il y a un patch pour éviter les grosses tables de sauts J'espère qu'il ne sera pas appliqué en -O2 et -O3.

Évidemment que non! Ni les mainteneurs de GCC, ni moi, ne sommes suffisamment stupides pour faire ça! C'est une optimisation en taille uniquement, donc en -Os seulement.

Sasume :
Pourquoi éviter les grosses tables de saut ? Que mettre à la place qui prendrait moins de place ?

if / else if répétés. C'est nettement plus compact que les tables de saut fortement redondantes. Quand la table de saut n'est pas fortement redondante, une table de saut continuera à être utilisée.

Pollux, as-tu essayé -fno-if-conversion? (Ce n'est pas forcément une amélioration, c'est à essayer.)

Évidemment que non! Ni les mainteneurs de GCC, ni moi, ne sommes suffisamment stupides pour faire ça! C'est une optimisation en taille uniquement, donc en -Os seulement.

Je commence à me dire qu'il faudrait vraiment un format intermédiaire entre -Os et -O2... Sinon -Os va devenir vraiment lent (à quand les FLine automatiquement activés en -Os qd le prog est assez gros pour contenir un émulateur? ), et -O2 vraiment gros...

Enfin moi je dis ça c votre pb

Pollux, as-tu essayé -fno-if-conversion? (Ce n'est pas forcément une amélioration, c'est à essayer.)

Thibaut l'avait déjà activé, donc je me suis dit que ct indispensable. Ca fait quoi?

(en tout cas dans l'exemple de thibaut ça doit forcément améliorer pour qu'il l'ait activé)

Je l'ai activé parceque Kevin me l'a demandé l'autre jour. Mais il ne marche pas avec ma version de TIGCC.
Donc à l'origine il n'y est pas. Vire-le, pour voir si Einstein grossit ou pas

Ah oui mais c long de recompiler
Bon vais voir si j'ai du temps à perdre

Pollux
: Je commence à me dire qu'il faudrait vraiment un format intermédiaire entre -Os et -O2...

Programmant très peu, et surtout en asm, je n'ai jamais manipulé les switches de GCC, mais le -O1, s'il existe, que fait-il? Il ne fait pas justement un format intermédiaire?

Pollux
:

Pollux, as-tu essayé -fno-if-conversion? (Ce n'est pas forcément une amélioration, c'est à essayer.)

Thibaut l'avait déjà activé, donc je me suis dit que ct indispensable. Ca fait quoi?

Il est censé désactiver la transformation de bCC en sCC, ce qui est généralement une bonne idée en -Os. Mais malheureusement, la if-conversion fait aussi d'autres choses qui sont utiles en -Os. À long terme, je vais (si les développeurs de FSF GCC ne le font pas eux-mêmes ) devoir modifier la passe de if-conversion elle-même pour qu'elle fasse seulement les choses utiles pour diminuer la taille quand on est en -Os et qu'elle laisse tomber les sCC.

Link
:

Pollux
: Je commence à me dire qu'il faudrait vraiment un format intermédiaire entre -Os et -O2...

Programmant très peu, et surtout en asm, je n'ai jamais manipulé les switches de GCC, mais le -O1, s'il existe, que fait-il? Il ne fait pas justement un format intermédiaire?

Pas vraiment. La définition est: optimisation en vitesse, mais moins poussée que -O2. Il y a un seul niveau d'optimisation en taille, et c'est -Os. Tout le reste optimise (plus ou moins bien) en vitesse.

Thibaut
: Des branchements qui parcourent l'arbre des possibilités par dichotomie, je suppose.

Oui, c'est ce qu'il donne. Et c'est affreux! Ça prend 2 branchements par test!
Moi, je veux un parcours linéaire tout bête avec 1 branchement par test!
Il va falloir que je patche ça...

Ce qu'il donne:

	cmp.w #28,%d0
	jbeq .L1318
	jbgt .L1328
	cmp.w #23,%d0
	jbeq .L1314
	jbgt .L1329
	cmp.w #21,%d0
	jbeq .L1312
	cmp.w #22,%d0
	jbeq .L1313
	jbra .L1310
	.even
.L1329:
	cmp.w #26,%d0
	jbeq .L1316
	jbgt .L1317
	cmp.w #25,%d0
	jbeq .L1315
	jbra .L1310
	.even
.L1328:
	cmp.w #95,%d0
	jbeq .L1322
	jbgt .L1330
	cmp.w #92,%d0
	jbeq .L1320
	jbgt .L1331
	cmp.w #91,%d0
	jbeq .L1319
	jbra .L1310
	.even
.L1331:
	cmp.w #93,%d0
	jbeq .L1321
	jbra .L1310
	.even
.L1330:
	cmp.w #97,%d0
	jbeq .L1324
	jblt .L1323
	cmp.w #98,%d0
	jbeq .L1325
	jbra .L1310

Ce que je veux, moi:

	cmp.w #21,%d0
	jbeq .L1312
	cmp.w #22,%d0
	jbeq .L1313
	cmp.w #23,%d0
	jbeq .L1314
	cmp.w #25,%d0
	jbeq .L1315
	cmp.w #26,%d0
	jbeq .L1316
	cmp.w #28,%d0
	jbeq .L1318
	cmp.w #91,%d0
	jbeq .L1319
	cmp.w #92,%d0
	jbeq .L1320
	cmp.w #93,%d0
	jbeq .L1321
	cmp.w #95,%d0
	jbeq .L1322
	cmp.w #97,%d0
	jbeq .L1324
	cmp.w #98,%d0
	jbeq .L1325
	jbra .L1310

Ces crétins de programmeurs GNU n'ont pas l'air de savoir ce que optimisation en taille veut dire!

PS: Sans le patch, j'avais:

	add.w #-21,%d0
	cmp.w #77,%d0
	jbhi .L1310
	and.l #0xFFFF,%d0
	add.l %d0,%d0
	.set .LI1326,.+2
	move.w .L1326-.LI1326.b(%pc,%d0.l),%d0
	jmp %pc@(2,%d0:w)
	.even
.L1326:
	.word .L1312-.L1326
	.word .L1313-.L1326
	.word .L1314-.L1326
	.word .L1310-.L1326
	.word .L1315-.L1326
	.word .L1316-.L1326
	.word .L1317-.L1326
	.word .L1318-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1310-.L1326
	.word .L1319-.L1326
	.word .L1320-.L1326
	.word .L1321-.L1326
	.word .L1310-.L1326
	.word .L1322-.L1326
	.word .L1323-.L1326
	.word .L1324-.L1326
	.word .L1325-.L1326

ce qui est encore pire.

Mieux, tu peux essayer de couper le switch en deux régions... Dans ton cas par exemple, ça serait très efficace.

Certes, mais le problème des comparaisons répétées faites en dichotomie alors que je les veux faites linéairement en -Os est quand-même à règler.

J'ai trouvé une solution (2 petits patches d'une ligne chacun) pour avoir exactement le code que je veux. Cf. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=86.topic pour plus de détails.

Et pour arrêter le off-topic ici: Si vous préférez répondre sur yAronet plutôt que sur le forum de la TICT, faites-le dans le topic approprié s'il vous plaît.

Pollux
: Voilà, GTC approche de la release, au moins pour la version PC...

Il est sorti ou pas, finalement ?

À ma connaissance, non.
Nous (Sebastian et moi), on tient nos promesses (même avec le FTP de ticalc.org hors-service...). Pollux, lui...

lui il n'a pas donné de date de sortie et ne sort pas des trucs buggés après avoir fait un tout étalage de pub

Euh Vark, j'espère que c'est du 2nd degré...
Pollux a dit que la beta sortirait dans la semaine... (c'était il y a un mois)
Et puis je pense que quand GTC sortira, il y aura quand même encore des bugs, et de toute façon, on ne peut pas reprocher à la TIGCC team de sortir un TIGCC 0.95 buggé alors qu'on les a prié de le sortir.

ah nan moi g rien demandé

Vark
: lui il n'a pas donné de date de sortie

Si, il a donné plusieurs dates de sortie, toutes passées depuis des mois.

et ne sort pas des trucs buggés

On a fait de notre mieux pour sortir quelque chose sans bogues. Mais une bêta est une bêta. Et il n'y a pas de bogues vraiment graves dans la bêta 1 (sauf celui de A68k, qui a été corrigé le jour même).

après avoir fait un tout étalage de pub

Si ce n'est pas "un tout étalage de pub", tu l'appelles comment, ce qu'il fait depuis des années?

Kevin Kofler
:

Vark
: lui il n'a pas donné de date de sortie

Si, il a donné plusieurs dates de sortie, toutes passées depuis des mois.

oué mais ça compte pas, on y est tellement habitués

et ne sort pas des trucs buggés

On a fait de notre mieux pour sortir quelque chose sans bogues. Mais une bêta est une bêta. Et il n'y a pas de bogues vraiment graves dans la bêta 1 (sauf celui de A68k, qui a été corrigé le jour même).

oué mais d'après ce que j'ai lu y'a pas mal de fonctionnalités en moins aussi

après avoir fait un tout étalage de pub

Si ce n'est pas "un tout étalage de pub", tu l'appelles comment, ce qu'il fait depuis des années?

par rapport à ce que tu fais toi pour tigcc et les prog de la tict ce n'est vraiment rien du tout