Je vais faire un effort mais... - Page 2

GT Turbo
:

tu attends la config machine ou il tournera bien.

Pensée pur d'une personne de la generation PC, on s'embete plus a voir la vitesse du code, on change de carte mere !!

Imagine juste un truc Fadest, un programme qui tourne assez vite sur un PC, ecrite en C, sa reecriture en assembleur permettrait de tourné minimun deux fois plus vite, imagine le gain de temps. Azrael qui pour sa these a du faire tourné des machines pendant un mois pour avoir un resultat, tu crois pas que cela l'aurait arrangé d'avoir un resultat en 15 jours ?

Et si tu optimises un peu, imagine le gain, a l'époque on dvp pas tout en asm, pour des raisons assez simples, sur un 68000 pas de virgule donc certains calculs bonjour !!

Azrael avait meme commencé a dvp des routines flottantes, on voulait dvp un raytracer, un programme de generation d'images de synthese. Mais maintenant le pb ne se pose plus. En recherche medical (Adn, etc..) y mettes plusieurs années pour décodé certaines sequences, divise leur le temps par 2, la medecine tirerait meme avantage de programmé en asm, et cela sans attendre qu'une machine plus puissante doive sortir.

Et en plus un dernier truc, dvp des jeux et des démos c'est un peu plus hard qu'un prog professionnel, un prog professionnel utilise des librairies, fonctions systems existantes, cela raccourci encore le dvp en asm.

C'est plus une peur de pas y arrivé qu'autre chose de pas dvp en Asm !!

GT Turbo (Oui je sais je suis un lourdeau mais bon je suis comme ca !)

P.S. Que bas niveau soit pejoratif ou pas, je te rassures cela ne changera rien !!

pour une routine de calcul qui demande un an de coding en C pour 4 ans à tourner après, si on veut la même chose en asm "pur" (cad sans aucune lib puisque c'est ce que tu reproches -indirectement- au C) il faudra 4 ans de coding pour un prog qui mettra deux ans à tourner...

Le résultat est pire.

Et encore les assembleurs que tu utilises (ceux pour 68k) ne sont pas de "vrais" assembleurs... normalement en "vrai" assembleur, tu ne peut pas faire de post incrémentation, d'indirections... comme le permet le langage que tu utilises.

En résumé, ce que tu peux faire en C, tu peux le faire en ASM, ce que tu peux faire en ASM, tu peux le faire en C, ensuite, c'est juste une question de savoir. Et les "non-optimisations" que tu as pu trouver en désassemblant du binaire codé en C sont peut-êtres dues à un switch du compilateur... (ou au manque d'expérience du codeur, ça arrive aussi)

vince :
pour une routine de calcul qui demande un an de coding en C pour 4 ans à tourner après, si on veut la même chose en asm "pur" (cad sans aucune lib puisque c'est ce que tu reproches -indirectement- au C) il faudra 4 ans de coding pour un prog qui mettra deux ans à tourner...

Le résultat est pire.

Et encore les assembleurs que tu utilises (ceux pour 68k) ne sont pas de "vrais" assembleurs... normalement en "vrai" assembleur, tu ne peut pas faire de post incrémentation, d'indirections... comme le permet le langage que tu utilises.

En résumé, ce que tu peux faire en C, tu peux le faire en ASM, ce que tu peux faire en ASM, tu peux le faire en C, ensuite, c'est juste une question de savoir. Et les "non-optimisations" que tu as pu trouver en désassemblant du binaire codé en C sont peut-êtres dues à un switch du compilateur... (ou au manque d'expérience du codeur, ça arrive aussi)

Pas d'accord avec toi Vince, il ne faut pas oublié certaines choses. Pour le C il faut des librairies mais 90% d'une librairie c'est quoi ? A par des appels systèmes qui sont de toute façon dans la machine, cela fait un peu doublon, c'est pour cela que les progs C sont plus gros que les Asm, meme les prog Gfa compilés sont plus petit !!

Un exemple pas trop vieux, j'ai adapté notre routine fractale Gfa en Asm, cela m'a demandé 25 minutes et le gain de temps est tout simplement hallucinant et le résultat est visible a l'oeil nu. Routine que je viens de repassé en pure C justement et je t'avoues que la différence au niveau de l'éxécution est plus de 4 a 5 fois plus rapide.

Donc mieux vaut perdre un peu de temps a dvp un prog en Asm pour qu'il tourne du feu de dieu a l'éxécution ou prendre moins de temps a le codé et boire des cafés durant sont exécution ?

Un calcul qui te demanderai un mois d'éxécution, te demanderai plus que 15 jours, perso moi j'ai fait mon choix.

Le pb vient aussi du fait que tu tournes sur une machine beaucoup plus rapide que moi, donc tu ne vois pas trop le soucis, mais quand tu tournes sur des machines a 8,16 Mhs la différence Asm et C est dure a croire !!

Le 68000 est un vrai asm, je penses que tu fais une référence par rapport au processeur de la Lynx qui est un 8 bit. J'ai eu dernièrement l'occasion de faire mes premiers pas dans les 8 bits en reprogrammant le processeur clavier de mon Ste (6301 Hitachi) et effectivement les modes d'adressages sont plutot pauvre comparé a un 68xxx. Mais le 68xxx est un vrai processeur avec un vrai asm. On va posé la question a ceux qui font de l'asm sur PC, quels sont les modes d'adressage dispo sur un PC, je suis sur que certaine modes d'adressage que tu penses 'faux' du 68000 se retrouve sur les processeurs PC !!


GT En train de discuté avec Vince, c'est Cool !!

P.S. : Désolé pour les fautes !!

GT Turbo
:

vince :
pour une routine de calcul qui demande un an de coding en C pour 4 ans à tourner après, si on veut la même chose en asm "pur" (cad sans aucune lib puisque c'est ce que tu reproches -indirectement- au C) il faudra 4 ans de coding pour un prog qui mettra deux ans à tourner...

Le résultat est pire.

Et encore les assembleurs que tu utilises (ceux pour 68k) ne sont pas de "vrais" assembleurs... normalement en "vrai" assembleur, tu ne peut pas faire de post incrémentation, d'indirections... comme le permet le langage que tu utilises.

En résumé, ce que tu peux faire en C, tu peux le faire en ASM, ce que tu peux faire en ASM, tu peux le faire en C, ensuite, c'est juste une question de savoir. Et les "non-optimisations" que tu as pu trouver en désassemblant du binaire codé en C sont peut-êtres dues à un switch du compilateur... (ou au manque d'expérience du codeur, ça arrive aussi)

Pas d'accord avec toi Vince, il ne faut pas oublié certaines choses. Pour le C il faut des librairies mais 90% d'une librairie c'est quoi ? A par des appels systèmes qui sont de toute façon dans la machine, cela fait un peu doublon, c'est pour cela que les progs C sont plus gros que les Asm, meme les prog Gfa compilés sont plus petit !!

C'est une obsession chez toi... TU N'ES PAS obligé d'avoir recours à des librairies quand tu codes en C

Un exemple pas trop vieux, j'ai adapté notre routine fractale Gfa en Asm, cela m'a demandé 25 minutes et le gain de temps est tout simplement hallucinant et le résultat est visible a l'oeil nu. Routine que je viens de repassé en pure C justement et je t'avoues que la différence au niveau de l'éxécution est plus de 4 a 5 fois plus rapide.

GFA Basic ? je connais mal, mais ce ne serait pas de l'interprété des fois ? Pour le C précise le langage et le compilo, l'éditeur, j'en ai rien à foutre. Tu as un très bon niveau en ASM, qui te dit que tes perfs en C sont suffisantes pour pouvoir se permettre une comparaison ?

Donc mieux vaut perdre un peu de temps a dvp un prog en Asm pour qu'il tourne du feu de dieu a l'éxécution ou prendre moins de temps a le codé et boire des cafés durant sont exécution ?

Justement, sur de très gros projets en équipe, quand tu dvp en asm, c'est pas un peu de temps que tu «perds» (j'aurait utiliser le verbe passer mais bon) Vaut mieux prendre moins de temps à le coder et passer son temps à coder autre chose pendant l'exécution

Un calcul qui te demanderai un mois d'éxécution, te demanderai plus que 15 jours, perso moi j'ai fait mon choix.

Pas forcément le quart. La plupart du temps quand te rapproche du facteur 2 entre C et ASM, tu peux faire péter le champagne. C'est pas parcque TOI dans certains cas particuliers bien précis, il t'es arrivé de dépasser ce facteur 2 que c'est tout le temps possible. Et puis au risque de me répéter, recommences le test avec le même temps de développement et deux développeurs qui ont le même niveau... Là tu comprendras l'avantage du C par rapport à un langage bas niveau...

Le pb vient aussi du fait que tu tournes sur une machine beaucoup plus rapide que moi, donc tu ne vois pas trop le soucis, mais quand tu tournes sur des machines a 8,16 Mhs la différence Asm et C est dure a croire !!

Rappel : je code aussi sur des procos 8bits...

Le 68000 est un vrai asm, je penses que tu fais une référence par rapport au processeur de la Lynx qui est un 8 bit.

non, l'assembleur du 68000 tel que tu le connais fait des optimisations AVANT la conversion en langage machine, de ce fait, il n'est pas 100% bas niveau et par définition n'est pas un asm pur

J'ai eu dernièrement l'occasion de faire mes premiers pas dans les 8 bits en reprogrammant le processeur clavier de mon Ste (6301 Hitachi) et effectivement les modes d'adressages sont plutot pauvre comparé a un 68xxx.

C'est pas qu'ils sont pauvres, c'est qu'ils ne sont prémachés, c'est tout.

Mais le 68xxx est un vrai processeur avec un vrai asm.

Non, une post incrémentation(par exemeple) n'est pas interprétable en langage machine, l'asm n'est donc pas la conversion en opérandes et mnémoniques du langage machine... et que dire des macros ? tu crois qu'elles sont gérées nativement par le proco ? laisse moi te détromper...

On va posé la question a ceux qui font de l'asm sur PC, quels sont les modes d'adressage dispo sur un PC, je suis sur que certaine modes d'adressage que tu penses 'faux' du 68000 se retrouve sur les processeurs PC !!

Un monsieur a tué sa femme à coups de couteau, pour savoir si oui ou non c'est horrible on va demander son avis à hannibale Nan mais t'en a d'autres des comme ça ? De plus, il me semble que dans la doc de A68K, tu trouves l'explication de ce que je donne plus haut...

GT En train de discuté avec Vince, c'est Cool !!

P.S. : Désolé pour les fautes !!

vince en train de discuter avec GT, c'est limite lisible son texte, word lui permettrait de diviser par deux le nombre de fautes...

C'est une obsession chez toi... TU N'ES PAS obligé d'avoir recours à des librairies quand tu codes en C

D'un coté tu a raison, les librairies ne sont qu'un morceau de code C. Mais dans certain cas tu est obligé de les utilisé, exemple un calcul en flottant (On parle la d'une machine avec copro arithmetic (Le 68000 seul est incapable)) tu fais comment pour utilisé le copro ?

GFA Basic ? je connais mal, mais ce ne serait pas de l'interprété des fois ? Pour le C précise le langage et le compilo, l'éditeur, j'en ai rien à foutre. Tu as un très bon niveau en ASM, qui te dit que tes perfs en C sont suffisantes pour pouvoir se permettre une comparaison ?

Le Gfa est effectivement interprété mais la je parles des .PRG résultants (Soit d'une compilation, soit d'un assemblage).

J'ai un peu de mal ca comprendre ta question, 'Pour le C précise le langage', le C n'est pas un langage ? La je commences a paniqué !!

Justement, sur de très gros projets en équipe, quand tu dvp en asm, c'est pas un peu de temps que tu «perds» (j'aurait utiliser le verbe passer mais bon) Vaut mieux prendre moins de temps à le coder et passer son temps à coder autre chose pendant l'exécution

Possèdant un O.S. monotache, si j'attends durant sont execution, je pourrais rien codé d'autre !!!

Un calcul qui te demanderai un mois d'éxécution, te demanderai plus que 15 jours, perso moi j'ai fait mon choix.

Pas forcément le quart. La plupart du temps quand te rapproche du facteur 2 entre C et ASM, tu peux faire péter le champagne.

Alors je vais le faire peter souvent !!


[cite ]C'est pas parce que TOI dans certains cas particuliers bien précis, il t'es arrivé de dépasser ce facteur 2 que c'est tout le temps possible. Et puis au risque de me répéter, recommences le test avec le même temps de développement et deux développeurs qui ont le même niveau... Là tu comprendras l'avantage du C par rapport à un langage bas niveau...[/cite]

Un exemple pour t'expliqué la chose, sur un 68030 (Falcon) le cache de celui ci ne fait que 256 octets, en asm tu peux savoir exactement la taille de n'importe qu'elle partie du code, donc tu peux t'arrangé pour le faire rentré dedans , en C tu fais comment pour mesuré ?

Si quelqu'un est prèt a joué le jeu, je fournis le source C de la routine de fractale, il optimise il fait ce qu'il veut, je fais pareil sur la routine Asm, et après on sort les chronos.

Rappel : je code aussi sur des procos 8bits...Non, l'assembleur du 68000 tel que tu le connais fait des optimisations AVANT la conversion en langage machine, de ce fait, il n'est pas 100% bas niveau et par définition n'est pas un asm pur

Je t'arretes tout de suite, Devpac (L'assembleur que j'utilise le plus, une version 2.xx) ne fait aucune optimisation, comment je le sais ? Quand tu utilise un débuggeur, le source que tu avais sous l'éditeur est exactement le meme que celui que tu a sous le débuggeur, sinon je t'avoues que plus aucun codeur ne pourrait codé d'overscan, la moindre optimisation modifie le nombre de cycles et nous sommes synchro au nop près (4 cycles). Et j'ai encore fait des essais pour du code généré, j'assemblais mon code a la main (Feuille + Motorola doc) et je l'assemblais sous Devpac, 100% pareil !!

C'est pas qu'ils sont pauvres, c'est qu'ils ne sont prémachés, c'est tout.

Un processeur 8 bits est pauvre autant en mode d'adressage qu'en registre, quand tu te bas avec 2 registres alors que j'ai l'habitude d'en avoir 16, chapeau au codeur 8 bit !!

Non, une post incrémentation(par exemeple) n'est pas interprétable en langage machine, l'asm n'est donc pas la conversion en opérandes et mnémoniques du langage machine... et que dire des macros ? tu crois qu'elles sont gérées nativement par le proco ? laisse moi te détromper...

Tu me fais peur, tu veux dire que la doc Motorola est pleine d'erreur ? La post incrémentation est comme un dépilage mais sur un autre registre que la pile.

Pour se remettre en situation, on ne parle que du coté soft ?

vince en train de discuter avec GT, c'est limite lisible son texte, word lui permettrait de diviser par deux le nombre de fautes...

Il existe sur Atari ?

MS Word non mais MS Write oui il a existé

GTT : as tu simplement essayé de lancer un profiler sur ton code C ?

J'avais une routine en C de calcul d'ensemble de Lyapunov (un peu comme des fractales, mais pas les classiques de mandelbrot). Je l'ai passé dans un profiler qualconque (par le Pure qui était commercial). Bah ouais, mon prog passait 99,9% de son temps dans les appels GEM (ah oui, j'étais en fenêtre pour l'affichage) et VDI (compatibilité oblige). Bref, pas facile de voir ou optimiser...
En asm, ça aurait été pareil, c'est les GEM et la VDI qui auraient tout bouffés...

Pour en revenir aux compilateurs C, outre le fait qu'il existe plusieurs normes (K&R et ANSI essentiellement) suivant les périodes (comme tous les langages normés), il existe plusieurs compilateurs, dont certains optimisent plus ou moins le code. Ils vont par exemple voir si telle ou telle variable peut être mise en registre ou non et autres subtilités, à tel point que dans la plupart des cas, le code asm généré est meilleur que si la même personne l'écrit directement en asm.
Avant que tu ne hurles ton cas sur tous les toits : évidemment, il est possible de faire mieux, ce que je veux dire, c'est que faire mieux ne sera pas donné à tout le monde.
Pure C date de plus de 10 ans, il n'est pas vraiment à la pointe de ce qui fait dans le domaine de la compilation.

PS : ton truc hyper optimisé en assembleur, qui est capable d'y retouché 5 ans après à part toi ?
Ce genre de pratique (encore mieux, sans commentaires dans le source), ça s'appelle généralement une assurance anti-licenciement dans le vrai monde (celui ou un patron te paye pour faire un programme), mais corollaire : tu restes bloqué au niveau du grouillot qui sait

Il me semblait avoir déjà signalé aux uns et aux autres de ne pas perdre leur temps à discuter C avec GTT.
Pour ceux qui ne l'aurait pas encore remarqué, il me (re)demande de façon cyclique de lui trouver un editeur-compilateur C sur le net pour (re)faire des tests et ensuite il poste sur le Yaro que c'est trop nul.
Ca dure trois jours entre Troll et et flame de bon aloi.
Et puis, deux mois plus tard, ça recommence...

Jusqu'au jour où il ouvrira les yeux...

RaZ :
Il me semblait avoir déjà signalé aux uns et aux autres de ne pas perdre leur temps à discuter avec GTT.

Kuk, va faire un Calvin snowmen dehors si j'y suis... (et prend des photos).

Fade est: ça s'appelle généralement une assurance anti-licenciement dans le vrai monde (celui ou un patron te paye pour faire un programme), mais corollaire : tu restes bloqué au niveau du grouillot qui sait
Exact fadest, C'est exactement ce qui se passe dans ma boite !

J'ai même pas envie de répondre, sache juste que tu me deçois GT.

Comment peut-on être aussi médisant sur un language qu'on ne connait même pas?

Sinon, sache que c'est le codeur qui code et non le language, ce qui fait qu'un code peut-etre trés lent en ASM et trés rapide en C.. et vis-versa...


A+
Zorro

Fadest :
Ce genre de pratique (encore mieux, sans commentaires dans le source), ça s'appelle généralement une assurance anti-licenciement dans le vrai monde (celui ou un patron te paye pour faire un programme), mais corollaire : tu restes bloqué au niveau du grouillot qui sait

Tiens tiens, c'est vraiment récurrent ça Ici aussi, dans ma boite, mes collègues fonctionnent comme ça. Moi aussi j'ai gardé l'esprit 'grouillot' de quand j'étais prestataire de service, code propre et commenté :/

Et bon, je fais des trucs en C/C++ que je ne pourrais pas faire en ASM, tout simplement parce que je devrais plancher des semaines pour travailler sur la structure du code, alors qu'en C, et surtout en C++ en ce qui concerne des héritages, le compilo le fait pour moi. Et les compilos de nos jours, ils sont vraiments très bon

Kochise

Zorro270 :
J'ai même pas envie de répondre, sache juste que tu me deçois GT.

Comment peut-on être aussi médisant sur un language qu'on ne connait même pas?

Sinon, sache que c'est le codeur qui code et non le language, ce qui fait qu'un code peut-etre trés lent en ASM et trés rapide en C.. et vis-versa...


A+
Zorro

D'accord ave toi Zorro, mais j'ai vraiment un pb, j'ai essayé plusieurs fois et la syntaxe, la norme sont assez spéciales, faut avoir un certain esprit cartésien pour apprécié ce langage, je sais par exemple qu'Azrael code très bien en C, toutes les personnes qui travaille avec ce langage ont soit un sacré niveau mathématique soit une certaine logique, et je n'ai ni l'un ni l'autre !! Voila mon pb !! Cela ne vient pas du C meme, cela vient de moi et je le sais. Sinon pourquoi autant de personnes l'utiliseraient ?


GT Pas logique du tout !!

Hep GT, tu indente just avec { et } alors que sous le GFA c'est fait automatiquement (les WHILE, le IF, etc...) et tu fous un ; après chaque instruction ! C'est quand même pas en dehors de tes compétences Le reste; c'est presque comme du GFA, tu évites juste de préciser PROCEDURE et FN pour les (sous)fonction !

Y'a pas de compétence particulière à avoir. Je viens moi même du GFA et j'y arrive très bien en C/C++ ! Mais je reconnais que c'est un peu le bordel sur Atari. Essaye sur PC avec Dev-c++, c'est plus facile, et le débuggeur est bien...

Soit un peu plus rigoureux mon p'tit GT, fais pas ta forte tête !

Kochise

Kochise :

Y'a pas de compétence particulière à avoir. Je viens moi même du GFA et j'y arrive très bien en C/C++ ! Mais je reconnais que c'est un peu le bordel sur Atari. Essaye sur PC avec Dev-c++, c'est plus facile, et le débuggeur est bien...

Soit un peu plus rigoureux mon p'tit GT, fais pas ta forte tête !

Kochise

Je te rassure Kochise, je ne fais pas ma forte tête, cela serait débile de ma part, je vais effectivement faire comme tu as dis dans ta première partie !! On va convertir le code Gfa en C a la main grace a la méthode Kochise !!

Par contre désolé, je suis prèt a faire un effort pour du C, mais pas sur un PC !!

Atari fanatisme oblige !!

Merci a toi Kochise !!

GT Heureux on m'a donné des chouettes conseils !!

Relis mon tutorial C : topics/45255-format-des-fichiers-gfa

Kochise

Celui de Squale92 ( http://www.ti-fr.com/?act=66&art=3 ) est excellent aussi...