Methode et beauté du code

Geo Trouvpatou · **Inscription:** Dim 23/Déc/2007 18:10 **Messages:** 471

Et ça donne quoi avec un exemple test?
Parce que ta procédure ne me cause absolument pas.
:?:

Bye.

cha0s · **Inscription:** Sam 05/Mar/2005 16:09 **Messages:** 681

http://fr.wikipedia.org/wiki/RDTSC

Geo Trouvpatou · **Inscription:** Dim 23/Déc/2007 18:10 **Messages:** 471

Ben c'est la 1ère chose que j'ai fait, mais cela ne m'avance pas plus.

cha0s · **Inscription:** Sam 05/Mar/2005 16:09 **Messages:** 681

en gros on compte les cycles du processeur depuis que l'ordinateur est allumé, c'est plus précis que ElapsedMilliseconds().

Geo Trouvpatou · **Inscription:** Dim 23/Déc/2007 18:10 **Messages:** 471

A vrai dire, c'est surtout que je n'avais pas compris comment utiliser ta fonction.
Donc j'ai fais ça :

Code:

Procedure.q ElapsedCycles()
    !rdtsc
    ProcedureReturn
EndProcedure

DisableDebugger ; ********************************************** 1

Delay(1) ; ***************************************************** 2
temp = ElapsedCycles()
For n = 1 To 100000000
    
    trucATester + 1
    
Next n
Norm = ElapsedCycles() - temp
MessageRequester("Norm1", Str(Norm) + " - " + Str(trucATester)) 


Delay(1) ; ***************************************************** 3
temp = ElapsedCycles()
For n = 1 To 100000000
    
    trucATester + 1
    
Next n
Opti = ElapsedCycles() - temp
MessageRequester("Opti1", Str(Opti) + " - " + Str(trucATester)) 

Delay(1) ; ***************************************************** Final
diff = Norm - Opti 
MessageRequester("Diff", Str(diff)) 

Mais au final on à un chiffre pas très parlant.
Utilisant exactement le même code dans les 2 situations, je m'attendais donc à quelque chose de proche de zéro, mais non.

A un moment, je m'étais dit que cela pouvait venir du processeur qui montait en température à cause du 1er calcul et du coup qui fatiguait pour le second.
Donc j'ai mis une interruption de 10sec entre les 2 calculs, mais cela n'a pas amélioré la chose.

Dommage :cry:

Donc je ne sais pas si l'on pourra vraiment avoir un bon benchmark.

djes

Et pourquoi on ne pourrait pas avoir un bon benchmark?

PAPIPP · **Inscription:** Sam 23/Fév/2008 17:58 **Messages:** 204

Bonjour à tous
Il existe pour chaque machine un rapport constant entre le nb de cycles
et le temps elapse .Ce rapport est de 3192095 + ou - 1 pour ma machine
Voici le prg qui le calcul

Code:

Macro q_t_
  "
EndMacro
Macro frmn(n)
  q_t_#n# = q_t_ + Str(n) + " "
EndMacro

Macro frms(S)
  q_t_#S# = q_t_ + S + " "
EndMacro

Macro frmf(F)
  q_t_#F# = q_t_ + StrF(f) + " "
EndMacro

Macro frmd(D)
  q_t_#D# = q_t_ + StrD(D) + " "
EndMacro

Macro frmQ(Q)
  q_t_#Q# = q_t_ + StrQ(Q) + " "
EndMacro

Macro frmH(H)
  q_t_#H# = q_t_ + Hex(H) + " "
EndMacro

Macro frmHq(Hq)
  q_t_#Hq# = q_t_ + HexQ(Hq) + " "
EndMacro

Macro frmU(U)
  q_t_#U# = q_t_ + Str(U) + " "
EndMacro

Macro _lng_()
  "ligne=" + Str(#PB_Compiler_Line) + " "
EndMacro
; *********************
Macro dbgn(n)
  Debug q_t_#n# = q_t_ + Str(n)
EndMacro

Macro dbgs(S)
  Debug q_t_#S# = q_t_ + S
EndMacro

Macro dbgf(F)
  Debug q_t_#F# = q_t_ + StrF(f)
EndMacro

Macro dbgd(D)
  Debug q_t_#D# = q_t_ + StrD(D)
EndMacro

Macro dbgQ(Q)
  Debug q_t_#Q# = q_t_ + StrQ(Q)
EndMacro

Macro dbgH(H)
  Debug q_t_#H# = q_t_ + Hex(H)
EndMacro

Macro dbgHq(Hq)
  Debug q_t_#Hq# = q_t_ + HexQ(Hq)
EndMacro

Macro dbgU(U)
  Debug q_t_#U# = q_t_ + HexQ(U)
EndMacro

Procedure.q ElapsedCycles()
  !rdtsc
  ProcedureReturn
EndProcedure
For i=100 To 10000 Step 1000
t_dc1.q = Elapsedcycles()
t_d1 = ElapsedMilliseconds()
Debug "***"+frmn(t_dc1)+" "+frmn(t_d1)+" "+ frmn(t_dc1/t_d1)
Debug _lng_()
Delay(i)
t_dc2.q = Elapsedcycles()
t_d2 = ElapsedMilliseconds()
d_dc.q=t_dc2-t_dc1
d_d.q=t_d2-t_d1
r_dc=d_dc/d_d
Debug frmn(i)+"  "+frmn(d_dc)+" "+frmn(t_dc2-t_dc1)+" "+frmn(d_d)+" "+frmn(t_d2-t_d1)+" "+frmn(r_dc)
Next 

La fonction Elapsedcycles() est bien plus précise que le temps elapse

Voici mes résultats

Code:

***t_dc1 = 113048850447864  t_d1 = 35415250  t_dc1/t_d1 = 3192095 
ligne=83 
i = 100   d_dc = 321035800  t_dc2-t_dc1 = 321035800  d_d = 93  t_d2-t_d1 = 93  r_dc = 3451997 
***t_dc1 = 113049171559488  t_d1 = 35415343  t_dc1/t_d1 = 3192095 
ligne=83 
i = 1100   d_dc = 3513195088  t_dc2-t_dc1 = 3513195088  d_d = 1110  t_d2-t_d1 = 1110  r_dc = 3165040 
***t_dc1 = 113052684891184  t_d1 = 35416453  t_dc1/t_d1 = 3192095 
ligne=83 
i = 2100   d_dc = 6705160008  t_dc2-t_dc1 = 6705160008  d_d = 2093  t_d2-t_d1 = 2093  r_dc = 3203612 
***t_dc1 = 113059390142576  t_d1 = 35418546  t_dc1/t_d1 = 3192095 
ligne=83 
i = 3100   d_dc = 9897462128  t_dc2-t_dc1 = 9897462128  d_d = 3110  t_d2-t_d1 = 3110  r_dc = 3182463 
***t_dc1 = 113069287701808  t_d1 = 35421656  t_dc1/t_d1 = 3192094 
ligne=83 
i = 4100   d_dc = 13089453664  t_dc2-t_dc1 = 13089453664  d_d = 4094  t_d2-t_d1 = 4094  r_dc = 3197228 
***t_dc1 = 113082377249248  t_d1 = 35425750  t_dc1/t_d1 = 3192095 
ligne=83 
i = 5100   d_dc = 16281664328  t_dc2-t_dc1 = 16281664328  d_d = 5109  t_d2-t_d1 = 5109  r_dc = 3186859 
***t_dc1 = 113098659005952  t_d1 = 35430859  t_dc1/t_d1 = 3192094 
ligne=83 
i = 6100   d_dc = 19473795888  t_dc2-t_dc1 = 19473795888  d_d = 6094  t_d2-t_d1 = 6094  r_dc = 3195568 
***t_dc1 = 113118132894200  t_d1 = 35436953  t_dc1/t_d1 = 3192095 
ligne=83 
i = 7100   d_dc = 22665933880  t_dc2-t_dc1 = 22665933880  d_d = 7093  t_d2-t_d1 = 7093  r_dc = 3195535 
***t_dc1 = 113140798918872  t_d1 = 35444046  t_dc1/t_d1 = 3192096 
ligne=83 
i = 8100   d_dc = 25858065008  t_dc2-t_dc1 = 25858065008  d_d = 8110  t_d2-t_d1 = 8110  r_dc = 3188417 
***t_dc1 = 113166657071832  t_d1 = 35452156  t_dc1/t_d1 = 3192095 
ligne=83 
i = 9100   d_dc = 29050205080  t_dc2-t_dc1 = 29050205080  d_d = 9094  t_d2-t_d1 = 9094  r_dc = 3194436 

A+

surfer_ix

Le Soldat Inconnu a écrit:

pour les routines, j'ai une base de données de fonction, et je fais du copier coller des fonction dont j'ai besoin :roll:

Arrrrgh.
C'est bien la pire hérésie de programmation propre que j'aie pu lire.
Autrement dit si tu trouve un problème dans une de tes fonctions, tu dois reporter à la main la correction dans tous tes programmes...

Excuse moi je ne veux pas paraitre méchant, mais c'est vraiment l'opposé du gain de temps.

Autre chose importante : il faut essayer de faire des commentaire qui se rapprochent le plus possible du style JavaDoc. Pourquoi ? Parce que tout le monde s'en sert, et partout (Java, Php, C++, C#) et en faisant ainsi, le jour où vous voulez lire de la doc d'un programme fait par quelqu'un d'autre ce sera bien plus facile, croyez moi

SPH · **Inscription:** Mer 09/Nov/2005 9:53 **Messages:** 2662

Citation:

***t_dc1 = 47421636415021 t_d1 = 21474718 t_dc1/t_d1 = 2208254
ligne=80
i = 100 d_dc = 221950894 t_dc2-t_dc1 = 221950894 d_d = 110 t_d2-t_d1 = 110 r_dc = 2017735
***t_dc1 = 47421858424908 t_d1 = 21474828 t_dc1/t_d1 = 2208253
ligne=80
i = 1100 d_dc = 2430114566 t_dc2-t_dc1 = 2430114566 d_d = 1093 t_d2-t_d1 = 1093 r_dc = 2223343
***t_dc1 = 47424288596828 t_d1 = 21475921 t_dc1/t_d1 = 2208254
ligne=80
i = 2100 d_dc = 4638585237 t_dc2-t_dc1 = 4638585237 d_d = 2110 t_d2-t_d1 = 2110 r_dc = 2198381
***t_dc1 = 47428927238220 t_d1 = 21478031 t_dc1/t_d1 = 2208253
ligne=80
i = 3100 d_dc = 6846894571 t_dc2-t_dc1 = 6846894571 d_d = 3094 t_d2-t_d1 = 3094 r_dc = 2212958
***t_dc1 = 47435774203554 t_d1 = 21481125 t_dc1/t_d1 = 2208253
ligne=80
i = 4100 d_dc = 9055406690 t_dc2-t_dc1 = 9055406690 d_d = 4093 t_d2-t_d1 = 4093 r_dc = 2212413
***t_dc1 = 47444829668907 t_d1 = 21485218 t_dc1/t_d1 = 2208254
ligne=80
i = 5100 d_dc = 11263259579 t_dc2-t_dc1 = 11263259579 d_d = 5110 t_d2-t_d1 = 5110 r_dc = 2204160
***t_dc1 = 47456092982584 t_d1 = 21490328 t_dc1/t_d1 = 2208253
ligne=80
i = 6100 d_dc = 13471647134 t_dc2-t_dc1 = 13471647134 d_d = 6093 t_d2-t_d1 = 6093 r_dc = 2211003
***t_dc1 = 47469564693023 t_d1 = 21496421 t_dc1/t_d1 = 2208254
ligne=80
i = 7100 d_dc = 15680048406 t_dc2-t_dc1 = 15680048406 d_d = 7110 t_d2-t_d1 = 7110 r_dc = 2205351
***t_dc1 = 47485244818726 t_d1 = 21503531 t_dc1/t_d1 = 2208253
ligne=80
i = 8100 d_dc = 17888221923 t_dc2-t_dc1 = 17888221923 d_d = 8094 t_d2-t_d1 = 8094 r_dc = 2210059
***t_dc1 = 47503133094527 t_d1 = 21511625 t_dc1/t_d1 = 2208254
ligne=80
i = 9100 d_dc = 20096502822 t_dc2-t_dc1 = 20096502822 d_d = 9109 t_d2-t_d1 = 9109 r_dc = 2206224

Moi, j'adoooore reduire les routines et les rendre les plus rapides possibles. J'adore faire ca !!!! Je vais dire un truc débile mais c'est comme faire un sport de combat avec le processeur ! :wink:

pbprint · **Inscription:** Lun 19/Juil/2010 17:03 **Messages:** 6

@PapiPP

Citation:

Il existe pour chaque machine un rapport constant entre le nb de cycles
et le temps elapse .Ce rapport est de 3192095 + ou - 1 pour ma machine...

C'est pour cette raison (entre autres), qu'il est préférable de mettre toujours les procédures au début et non pas à la fin. N'oubliez pas que l'accès à une procédure se fait (par la machine)
de cette manière:

1) Se positionner au début du code
2) Recherche du nom de procédure appelée (parcours ligne par ligne..)
3) Exécution de la procédure
4) Retour immédiat après l'instruction appelante (ici l'accès est direct car l'adresse de cette instruction est sauvegardée jusqu'à ce que l'exécution de la procédure soit terminée)

Dobro · **Inscription:** Lun 26/Avr/2004 0:40 **Messages:** 13085

pbprint a écrit:

@PapiPP

Citation:

Il existe pour chaque machine un rapport constant entre le nb de cycles
et le temps elapse .Ce rapport est de 3192095 + ou - 1 pour ma machine...

C'est pour cette raison (entre autres), qu'il est préférable de mettre toujours les procédures au début et non pas à la fin. N'oubliez pas que l'accès à une procédure se fait (par la machine)
de cette manière:

1) Se positionner au début du code
2) Recherche du nom de procédure appelée (parcours ligne par ligne..)
3) Exécution de la procédure
4) Retour immédiat après l'instruction appelante (ici l'accès est direct car l'adresse de cette instruction est sauvegardée jusqu'à ce que l'exécution de la procédure soit terminée)

ce que tu dis serait valable pour un langage interpreté (et encore.. mon pureGolo gere tres bien les 2 cas de figures)

mais Purebasic est un compilateur, une fois compillé
l'emplacement des procedures de ton listing n'a aucune importance !

faudra voir a pas trop raconter de niaiseries quand meme

pour rappel :

Citation:

l'éditeur de liens permet d'ajuster les adresses des différentes procédures.

Prenons un exemple concret : imaginons un programme C qui fasse appel à une fonction toto() :

#include

int main()
{
printf("\n Appel de toto");
toto();

exit(0);
}

La compilation de ce programme se passera sans problème : le programme transcrit chaque instruction en langage assembleur. En rencontrant la ligne toto();, le programme notera simplement l'appel à la fonction toto. Le résultat obtenu est un fichier objet.

Lors de l'édition des liens, le programme cherchera alors l'emplacement de la fonction toto dans un des fichiers objet passés en paramètre. Il recherchera également la fonction printf et la fonction exit. Dans le programme exécutable final, il indiquera l'adresse de ces fonctions pour que celles-ci puissent être appelées.

Cls

Dobro a écrit:

faudra voir a pas trop raconter de niaiseries quand meme

+1 A la rigueur on peut considérer que ça diminue le temps de compilation... M'enfin à 2 - 3 millièmes près, faut pas pousser...

Myshl · **Inscription:** Lun 15/Oct/2007 16:44 **Messages:** 7

Ouf !
On a échappé à la "normalisation"...

Même un produit comme Ada, qui est normalisé ISO, IEC, AFNOR et tutti quanti, n'impose pas de discipline aux programmeurs, seulement les règles dictées par les compilateurs. On trouve bien des recommandations, au CNES par exemple, mais la liberté est laissée aux programmeurs et autres bidouilleurs de s'organiser à leur aise, y compris la liberté de sa viander, rien que pour le plaisir de trouver pourquoi..

PureBasic est un lang(u)age etc... Sympa autant qu'efficient. C'aurait été dommage de le formoliser, de le fossiliser. PB comme le démontrent les forums est un joyeux foutoir, un éternel bébé en pleine croissance, entouré d'affection, qui suscite intérêt et étonnement. Ce n'est donc pas le moment, et que ça ne le devienne jamais, de le "normaliser". Ou sinon, faudra refaire le logo en kaki...

Je sors d'une aventure extra-conjugale avec RealBasic, et j'ai encore tenté de débroussailler Ada. Je me sens revenir à grands pas vers PureBasic, parce que c'est jeune, parce que la communauté est sympa en plus d'être active, et parce que je me sens libre.

Les gosses d'abord.
PB... Pure bébé est très attachant, alors ne l'habillons pas d'un uniforme.
Et continuons longtemps de lui acheter ses couches.

Keskonsmar...

Myshl

Dobro · **Inscription:** Lun 26/Avr/2004 0:40 **Messages:** 13085

il ne s'agit pas ici de mettre un uniforme , ou de normaliser quoique ce soit

juste de donner quelques bonnes habitude qui évites les soucis bien souvent !

je suis partisant de garder le Goto par exemple alors que bien des membres
du forum voudraient le faire disparaitre

lorsque j'ai commencé ce topic , je n'imaginais pas qu'il attirerai autant de participations

meme si certains préconisent des trucs que j'aime pas (les procédures en debut de code par exemple)

il s'agit ici d'une discussion informel sur l'architecture d'un code ; et non pas d'une volonté d'obligé qui que ce soit

SPH · **Inscription:** Mer 09/Nov/2005 9:53 **Messages:** 2662

Dobro a écrit:

je suis partisant de garder le Goto par exemple alors que bien des membres
du forum voudraient le faire disparaitre

Je suis aussi partisan du GOTO. Tiens, je me demande si on pourrait coder n'importe quelle routine sans goto. En tout cas, en ASM, il est OBLIGATOIRE !!!!!

PureBasic

Methode et beauté du code

Qui est en ligne