Temps d'exécution d'un sous-programme appelé par SUB/GOSUB

Code:: rem ============================================================================
rem Comparaison des temps d exécution d un sous-programme appelé par
rem GOSUB et par SUB
rem ============================================================================
rem GOSUB peut doubler, voir tripler la vitesse d exécution du code.
rem Explication:
rem L appel d une procédure SUB relève d un processus relativement coûteux.
rem Panoramic doit conserver le contexte du code appelant (valeurs des variables,
rem point d exécution en cours, etc.), transférer les éventuels arguments vers
rem la pile, puis localiser le point d entrée de la procédure dans la mémoire avant
rem de l appeler.
rem Un sous-programme (appelé par son LABEL) n a pas de telles exigences en matière
rem de temps système, car il ne requiert aucune pile de variables.
rem ============================================================================
label calcul
dim x,y,t1,t2,t_sub,t_gosub
font_bold 0
' Appel par SUB
t1 = NUMBER_TICKS
for x = 1 to 10000
   calcul()
next x
t2 = NUMBER_TICKS
t_sub = (t2-t1)/1000
print " Durée pour SUB -------------> " + str$(t_sub)
rem ============================================================================
' Appel par GOSUB
t1 = NUMBER_TICKS
for x = 1 to 10000
   gosub calcul
next x
t2 = NUMBER_TICKS
t_gosub = (t2-t1)/1000
print " Durée pour GOSUB --------> " + str$(t_gosub)
rem ============================================================================
print : print "Rapport : t_sub / t_gosub = " + str$(t_sub / t_gosub)
print "L'appel par GOSUB est plus rapide"

end
rem ============================================================================
Calcul:
   y = sqr(x) + 3*sin(3*pi/4)
return
rem ============================================================================
SUB Calcul()
   y = sqr(x) + 3*sin(3*pi/4)
END_SUB
rem ============================================================================

Sujet: Très bon à savoir Jeu 10 Nov 2016 - 17:26

Très bon à savoir

Cordialement

Sujet: Et GOTO dans tout ça ? Lun 14 Nov 2016 - 8:48

J'ai pas réussi avec GOTO ?!?

Code:: rem =====
rem Comparaison des temps d exécution d'un sous-programme appelé par
rem GOSUB, SUB et GOTO
rem =====
label calcul1,calcul2
dim x,y,t1,t2,t_sub,t_gosub,t_goto
font_bold 0
' Appel par SUB
t1 = NUMBER_TICKS
for x = 1 to 10000
calcul()
next x
t2 = NUMBER_TICKS
t_sub = (t2-t1)/1000
print " Durée pour SUB -------------> " + str$(t_sub)
rem =====
' Appel par GOSUB
t1 = NUMBER_TICKS
for x = 1 to 10000
gosub calcul1
next x
t2 = NUMBER_TICKS
t_gosub = (t2-t1)/1000
print " Durée pour GOSUB --------> " + str$(t_gosub)
rem =====
' Appel par GOTO
t1 = NUMBER_TICKS
goto calcul2
t2 = NUMBER_TICKS
t_goto = (t2-t1)/1000
print " Durée pour GOTO --------> " + str$(t_goto)
rem =====
' print : print "Rapport : t_sub / t_gosub = " + str$(t_sub / t_gosub)
' print "L'appel par GOSUB est plus rapide"
end
rem =====
Calcul1:
y = sqr(x) + 3*sin(3*pi/4)
return
rem =====
SUB Calcul()
y = sqr(x) + 3*sin(3*pi/4)
END_SUB
rem =====
Calcul2:
for x = 1 to 10000
y = sqr(x) + 3*sin(3*pi/4)
next x
return

Nostalgie :
https://www.youtube.com/watch?v=170E9Maoocw

Salut tout le monde

Ouf_ca_passe a écrit:: J'ai pas réussi avec GOTO ?!?

Le contraire m’aurait surpris !
Sache que :
1) L’appel à une procédure SUB se fait en invoquant la SUB par son nom.
Le programme se branche sur la 1ere instruction de la SUB et exécute le code jusqu’à l’instruction END_SUB.
Cette dernière déclenche un branchement du programme vers l’instruction qui suit l’instruction d’appel.
(Tu me suis toujours ?)
Il y a donc sauvegarde de l’environnement du travail lors de l’appel puis restitution de cet environnement.
2) L’appel à un sous-programme localisé par un identificateur de LABEL se fait par l’instruction GOSUB (GO TO SUBROUTINE).
Le programme se branche et exécute les instructions entre le LABEL et le RETURN.
Cette dernière instruction (RETURN) indique au programme qu'il doit se brancher à l’instruction juste après celle de l’appel. C'est donc une instruction de retour.
3) Le GOTO est un branchement vers une partie du programme SANS RETOUR !.
La fin du bloc d’instructions NE DOIT PAS contenir l’instruction RETURN. Ça n’a pas de sens.

En résumé :
SUB doit contenir END_SUB (éventuellement EXIT_SUB) qui est une instruction de retour vers l’appelant.
Le s/p débutant par l’identificateur d’un LABEL et appelé par GOSUB doit contenir RETURN qui est une instruction de retour.
L’appel par GOTO est un branchement sans retour.

Personnellement je n’utilise GOTO que pour montrer comment elle fonctionne et jamais dans mes codes car elle est (selon moi) la négation de la programmation structurée.
Quand on structure son code convenablement on n’a pas besoin de GOTO.

Pour SUB et GOSUB le système gère lui-même le retour.
Par contre pour GOTO, le programmeur doit gérer lui-même les branchements / débranchements pour finir avec un beau treillis inextricable qu'il est TOUJOURS (ou presque) possible d'éviter.

J'ai modifié ton code pour utiliser GOTO

Code:: rem =====
rem Comparaison des temps d exécution d'un sous-programme appelé par
rem GOSUB, SUB et GOTO
rem =====
label calcul1,calcul2,retour
dim x,y,t1,t2,t_sub,t_gosub,t_goto
font_bold 0
' Appel par SUB
t1 = NUMBER_TICKS
for x = 1 to 10000
   calcul()
next x
t2 = NUMBER_TICKS
t_sub = (t2-t1)/1000
print " Durée pour SUB -------------> " + str$(t_sub)
rem =====
' Appel par GOSUB
t1 = NUMBER_TICKS
for x = 1 to 10000
   gosub calcul1
next x
t2 = NUMBER_TICKS
t_gosub = (t2-t1)/1000
print " Durée pour GOSUB --------> " + str$(t_gosub)
rem =====
' Appel par GOTO

t1 = NUMBER_TICKS
   goto calcul2
retour:
t2 = NUMBER_TICKS
t_goto = (t2-t1)/1000
print " Durée pour GOTO --------> " + str$(t_goto)
rem =====
' print : print "Rapport : t_sub / t_gosub = " + str$(t_sub / t_gosub)
' print "L'appel par GOSUB est plus rapide"
end
rem =====
Calcul1:
  y = sqr(x) + 3*sin(3*pi/4)
return
rem =====
SUB Calcul()
  y = sqr(x) + 3*sin(3*pi/4)
END_SUB
rem =====
Calcul2:
  for x = 1 to 10000
   y = sqr(x) + 3*sin(3*pi/4)
  next x
  goto retour

Mon conseil : évite tant que faire se peut d'utiliser l'instruction GOTO dans tes codes!

J'ai testé ton code Papydall,

Effectivement on a au moins 40% d'écart de durée d'exécution.
C'est à retenir pour certains cas de traitement.

A+

Préférer GOSUB à SUB lorsqu’on est en présence d’un long traitement qui demande beaucoup de temps machine.
Pour un GOSUB le système ne retient que le point de retour (l’instruction après l’appel) lorsqu’il rencontre RETURN.
Par contre, l’appel à SUB oblige le système à retenir le point de retour, mais aussi à gérer les éventuels arguments de la SUB, l’utilisation de la pile, la sauvegarde de l’environnement (variables globales et locales) et ça demande un temps précieux.

Ça entre dans la phase d’optimisation du code pour les gros projets !

Salut Papydall !

Voila une réflexion très intéressante. Merci pour le résultat de ces recherches.

Moi qui remplace systématiquement tous les sous-programme xxxxxx:/RETURN par les SUB xxx()/END_SUB quand cela est possible, me donne matière à réflexion pour mes prochaines réalisations !

Comme tu le dit si bien lors de l'usage dans de gros programmes où les sous-programmes sont parfois imbriqués les uns dans les autres, le résultat peut être surprenant si l'on gagne 40% de temps comme le dit notre amis Jean Claude

Du coup je me pose la question pour GPP sur les modification à apporter ?!
Encore du déménagement dans l'air en prévision... Wink

Bonsoir,
Sur ce sujet, restons prudent pour éviter une mauvaise interprétation.
Comme vous l'avez suggéré tous les deux, il ne s'agit pas de supprimer l'usage des SUB(s), surtout pour celle quii sont appelées sans passage de paramètres.
Mais, comme dit Papydall:

Citation :: Préférer GOSUB à SUB lorsqu’on est en présence d’un long traitement qui demande beaucoup de temps machine.

Pour un gros traitement, là c'est justifié, mais pour les petits traitements, les SUB(s) restent bien pratique.
De plus la vitesse des processeurs actuels permettent quelques petits écarts...

L'usage des SUB(s) trouve son intérêt, surtout, dans le passage de paramètres pour un traitement et/ou avec un retour de valeur(s).

A+

Tu as bien compris mon idée, Jean Claude.
En fait, pourquoi faire des programmes ?
Réponse : C’est pour trouver une solution à un problème que l’on se pose.
Donc, en première analyse, c’est écrire un code qui marche, sans se soucier ni de la performance ni de l’optimisation.
Si le programme fait ce qu’il est sensé faire, c’est déjà un exploit.
On peut en rester là pour un projet modeste.

Mais si on entre dans une application costaude (comme pour GPP de Minibug ou Maxi-scool de Pedro Alvarez, etc.) toute microseconde gagnée dans un traitement (multipliée par N très grand) aura son importance.

» Un programme plante sous l'IDE, mais marche sous l'éditeur
» PROCÉDURE et SOUS-PROGRAMME
» Sous-programme(résolu)
» [R] DIM_LOCAL et sous-programme
» ce fut mon 2ème programme en panoramic! (mauvais programme)