Compression RLE - Page 4

[HS]./90 : Je pense qu'elle disparaîtra dès que Texas Instruments sortira une version avec des capacités similaires à la nSpire, et ce sera peut-être plus tôt qu'on le pense[/HS]
J'apprécierais être informé sur l'avancée de ton projet, Daniel, et notamment quand tu entreras dans la phase d'essai, histoire de voir si du RLE bit à bit est suffisamment rapide sur une calculatrice pour ce que j'aimerais en faire.

Godzil (./65) :
huffman lent ? c'est un des algo de décompression les plus rapides (bcp bcp plus rapide que du LZ77 par exemple, ou tout format basé sur des fenetres & dico)

euh c'est complètement faux... (surtout sur TI où les libs de huffman existantes sont très primitives et parcourent l'arbre bit à bit ; comparé à un LZ qui manipule presque uniquement des octets entiers voire des paquets de plusieurs octets, c'est difficile de faire le poids...)


pour ce qui est de la méthode de RLE pixel par pixel, je déconseille fortement dans la mesure où ça ne donnerait des taux de compression décents que pour des images très particulières ^^ (à moins de recompresser la sortie avec un truc genre huffman)

Pollux (./92) :
surtout sur TI où les libs de huffman existantes sont très primitives et parcourent l'arbre bit à bit

Ah c'est pas con ça ! Je n'y avais jamais pensé ! C'est vrai qu'il y a moyen de considérablement accélérer la décompression en travaillant sur ce point. C'est peut-être un des secrets de la rapidité de ton launcher

Pollux (./92) :

Godzil (./65) :
huffman lent ? c'est un des algo de décompression les plus rapides (bcp bcp plus rapide que du LZ77 par exemple, ou tout format basé sur des fenetres & dico)

euh c'est complètement faux... (surtout sur TI où les libs de huffman existantes sont très primitives et parcourent l'arbre bit à bit ; comparé à un LZ qui manipule presque uniquement des octets entiers voire des paquets de plusieurs octets, c'est difficile de faire le poids...)

C'est pas parcequ'une implémentation est foireuse que c'est lié a l'algo..

ben le fait est que :
1) faire un décompresseur huffman efficace n'est pas forcément évident (il y a pas mal de compromis entre taille des tables de lookup et vitesse ; et puis il faut bien les générer à un moment donné, ces tables), alors que faire un décompresseur LZ efficace c'est très facile, sauf si le format de fichier est très mal conçu
2) même dans l'hypothèse improbable où ton décompresseur huffman serait un peu plus rapide, c'est n'importe quoi de dire que c'est (je cite ./65) "bcp bcp plus rapide que du LZ77 par exemple"
3) enfin huffman n'est pas un "algo", mais une méthode de compression pour laquelle il y a différents algos de compression et de décompression (avec des performances diverses dans des cas divers)

Thibaut (./93) :

Pollux (./92) :
surtout sur TI où les libs de huffman existantes sont très primitives et parcourent l'arbre bit à bit

Ah c'est pas con ça ! Je n'y avais jamais pensé ! C'est vrai qu'il y a moyen de considérablement accélérer la décompression en travaillant sur ce point. C'est peut-être un des secrets de la rapidité de ton launcher

mon décompresseur n'utilise pas d'arbre (le format pucrunch n'est pas basé sur huffman mais sur LZ), mais effectivement il essaye d'éviter de manipuler des bits isolés quand c'est pas indispensable

Thibaut (./77) :
Pourquoi tu n'essaies pas GTC ? Je crois que le décompresseur de Pollux est à la fois petit et rapide, mais tu pourrais vérifier par toi-même (il est dans la version pour PC). Si la licence le permet, ou bien en négociant avec Pollux pour assouplir la licence, vous pourriez peut-être en faire le nouveau système de package officiel de TIGCC.

Le compresseur de Pollux est une version allégée de pucrunch (ttpack/ttunpack). S'il est plus petit (as-tu bien comparé avec le nouveau ttunpack_small en assembleur?), c'est au prix d'une moins bonne compression pour le programme compressé, donc c'est contreproductif au total! Le seul intérêt des allégements de Pollux est de pouvoir compresser on-calc, ce qui est complètement inintéressant pour TIGCC vu qu'on compresse sur PC de toute façon.

Le lanceur de Pollux me paraissait plus rapide et la compression me paraissait plus importante. Pollux je me trompe ?

Zut, je ne suis toujours pas allé télécharger le dernier GTC, sur le site de Pollux...
Je ne suis pas fermé à son ttpack/ttunpack modifié: Thomas avait essayé de faire une version on-calc de ttpack, mais avait abandonné à cause de la consommation mémoire.

Encore une fois, par rapport à ce qu'elle était à une époque, la vitesse de ttunpack "mainline", version normale/rapide (son appellation dépend des personnes ), a été beaucoup augmentée, d'abord par Greg Dietsche pour SuperStart, puis largement (réécriture en ASM, inlining, optimisations partout) par Samuel Stearley. Au milieu, j'avais fait quelques modifs sur le source C, mais je n'aurais évidemment jamais obtenu les mêmes résultats que Sam.
Je dirais que depuis que l'amélioration de la routine ttunpack "mainline" a commencé, la vitesse a triplé ou quadruplé:'au début, on n'était pas à 30 KB/s, alors qu'on est maintenant aux alentours de 80 KB/s.

Cette nouvelle version, très rapide, date de quand ? Ca m'intéresse pour Einstein, qui peut s'exécuter sans kernel si on utilise un lanceur (il fait 40 ko), mais ce n'est pas le top de devoir attendre 2 secondes de chargement à chaque fois qu'on fait [<>]+[6]. La compilation d'Einstein, donc la version de ttstart qu'il utilise, date de novembre 2002.

> Cette nouvelle version, très rapide, date de quand ?
"ttunpack" normal/rapide a été fait en 2004-2005, ttunpack "super_duper_small" (le nom que Sam lui a donné) a été programmé en 2005, son développement ayant commencé après le gros de l'optimisation sur la routine normale/rapide.

> La compilation d'Einstein, donc la version de ttstart qu'il utilise, date de novembre 2002.
#barf# #puke#
Non seulement sa routine de décompression est ultra-vieille, mais de plus, ce ttstart est tout juste compatible V200 (alors 89T qui a tout cassé après, n'en parlons pas )...

Bah oui, c'est le problème des programmes nostub, quand on change de hardware ou quand les bibliothèques sont perfectionnées, il faut recompiler... Un nombre considérable de programmes pour le monde TI 68k est sorti avant l'apparition de la Titanium, et les auteurs ont disparu du monde entre temps. Résultat : les utilisateurs se retrouvent à patcher des programmes, pour ceux qui savent le faire. Pour les autres, il se retrouvent face à des plantages.
En effet, je suis d'accord avec toi, les programmes nostub sont #barf# #puke# ...

Tu fais semblant d'essayer de lancer un vilain troll, là ?

Pour désactiver les interruptions, on utilisait souvent un SR > 0x0300. Donc, programmes AMS native et kernel-based partagent l'incompatibilité initiale avec l'utilisation de la RTC (AI3) sur AMS 2.07+. Aucun avantage du kernel-based sur ce point.
Il est un fait que ce qu'on appelle habituellement "kernel" agit comme une Hardware/Software Abstraction Layer... mais seulement si les programmes sont faits correctement. Ce qui n'était absolument pas le cas, pour certains programmes, au moment de l'arrivée de la HW2 (adresses absolues vers les variables internes du système !!). Portage et recompilation nécessaire pour nombre de programmes, qui existent en version HW1 et en version HW2. Portage et recompilation généralement effectué par des personnes différentes, les auteurs ayant quitté la communauté entretemps. Aucun outil de patch automatique. Les utilisateurs qui se trompent de version se retrouvent face à des plantages.
Même chose pour l'utilisation du ghost space pour changer les données de la zone RAM des vecteurs, protégée par défaut en écriture. Je n'ai pas la liste des appels kernel en tête, donc il se peut qu'il y ait un appel pour rediriger les vecteurs d'interruption... mais encore faudrait-il l'utiliser. Il se peut donc que les programmes kernel-based aient besoin, eux aussi, de recompilation lors du passage à la 89T.

Il y a la théorie, et la pratique...

Le PIC, c'est cool ^^

Lionel Debroux (./100) :
"ttunpack" normal/rapide a été fait en 2004-2005, ttunpack "super_duper_small" (le nom que Sam lui a donné) a été programmé en 2005, son développement ayant commencé après le gros de l'optimisation sur la routine normale/rapide.

J'ai téléchargé le zip TIGCC Tools Suite sur tigcc.ticalc et tous les utilitaires qui sont à l'intérieur datent de mai 2002 (y compris le lanceur ttstart). Je ne comprends pas.

2ème question : J'ai un exécutable nostub non compressé. Je souhaite le compresser et l'associer à un lanceur qui le décompressera & lancera sans avoir à passer le nom du fichier compressé au lanceur. C'est possible ?

Le ZIP de la TIGCC Tools Suite que tu as récupéré est totalement dépassé, mais il n'y a pas eu de release officielle depuis.
En revanche, ttstart a été mis à jour depuis: ttstart 2.00.
Les sources pour le lanceur personnalisé de TIGCC ne sont plus là-dedans parce que nous avons décidé d'arrêter le bordel de #ifdef et de maintenir 2 versions séparées du code, voilà donc les sources de pstarter.o de TIGCC: http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/pstarter/.

J'ai donc pris les sources de pstarter, et j'ai remplacé comme il convient la chaîne à la fin :

ProgramName:
.asciz "einsppg"

J'ai ensuite modifié les options de compilation pour demander l'utilisation de la version rapide :

--defsym ttunpack_fast=1 -l

Mais la compilation échoue :

Je pensais avoir testé la version rapide, mais visiblement pas. J'ai oublié de corriger ce truc en convertissant la source de A68k vers GNU as. Je vais corriger ça dans le CVS. (Franchement, je n'ai pas grand chose à battre de la version rapide parce qu'elle est nettement plus grosse, mais je vais quand-même faire en sorte qu'elle compile.)

Tu n'es pas très raisonnable.
Tu préfères gagner de la place au détriment de la vitesse, mais ce n'est pas la préférence de tout le monde. Alors quand on a la responsabilité d'un projet qui se veut être "le compilateur de référence" et de ses outils associés, on l'assume. Sinon on passe la main à quelqu'un qui saura respecter les besoins de tous.

Essaie avec cette version de pst-ttuf.h.

Thibaut (./108) :
Tu n'es pas très raisonnable.

Et hop, c'est reparti...

Tu préfères gagner de la place au détriment de la vitesse, mais ce n'est pas la préférence de tout le monde.

* Ici, il s'agit d'un outil de décompression, le but de la compression est justement de gagner de la place en sacrifiant un petit intervalle de temps!
* La vitesse en question ici est la vitesse au lancement du programme, ça n'a aucune influence sur la vitesse du programme pendant son l'utilisation et donc l'utilisabilité (ou jouabilité pour un jeu) du programme.
* La différence de vitesse se mesure en fractions de secondes de temps d'exécution (le temps de décompression total est de l'ordre d'une seconde), franchement ça ne se remarque même pas.
* La taille est à compter pour chaque programme, et un lanceur compilé avec ttunpack_fast est plus gros de 346 octets (34% de la taille du lanceur!), ce qui se multiplie très vite en des KO gâchés pour une différence de temps de démarrage insignifiante.
d'où la décision d'utiliser ttunpack_small par défaut et d'où le fait que je ne teste essentiellement que ça. Maintenant, j'ai corrigé ton problème 16 minutes après que tu l'as reporté, donc je ne vois pas trop pourquoi tu te plains.

Je corrige la phrase: les arguments du côté kernel de kernel vs nostub d'il y a 5 ans sont totalement périmés avec le linker de TIGCC >=0.95. Par exemple, on a les BSS en _nostub aussi maintenant.

Kevin Kofler (./110) :
La vitesse en question ici est la vitesse au lancement du programme

Tu n'as pas conscience que certains programmes sont destinés à être lancés rapidement, parceque lancés souvent, ou parcequ'ils ne sont qu'une étape intermédiaire qui permet le lancement d'un autre programme. Bon exemple : les explorateurs.
Alors en temps que responsable tu devrais respecter (et avec un peu de réflexion, comprendre) ce besoin.

Kevin Kofler (./110) :
ce qui se multiplie très vite en des KO gâchés pour une différence de temps de démarrage insignifiante.

Tu reconnais donc l'avantage du kernel, qui ne nécessite pas 1 ko x le nombre de programmes stockés sur la machine.
PS : chipotage : on écrit ko, pas KO

Kevin Kofler (./110) :
Maintenant, j'ai corrigé ton problème 16 minutes après que tu l'as reporté, donc je ne vois pas trop pourquoi tu te plains.

Je te remercie. Mais ce n'est pas mon problème, c'est celui de tous les utilisateurs qui aimeraient accélérer un peu le chargement de leur programme.

cette discussion que vous avez eu 50 fois, tout le monde la connait, et tout le monde connait vos points de vue... vous avez pas un peu l'impression de vous répéter ?

pstarter plante. Address Error.

Oh fun.
Je vais voir ce qui cloche.
En tout cas, tu dois être le premier à essayer de compiler pstarter avec ttunpack_fast depuis le 20 mars 2006 parce que ça ne compilait même pas pendant tout ce temps et personne ne s'en est plaint.

Faut dire que l'archive n'est pas accessible facilement. Faut savoir qu'elle existe, et où, pour la trouver

@Thibaut, Martial (et aussi Kevin, bien qu'il ne me l'ait pas reproché ici): je sais, je ne fais pas assez de releases officielles. Ca aussi, je l'ai déjà écrit à plusieurs reprises ^^