Simplification de programme

[invite23ed8df1]

Salut j'aurai besoin de votre aide pour la simplification d'un de mes programmes :
11) Ecrivez une fonction moyenneListe(L) qui calcule et retourne la moyenne des éléments de L :

def moyenneListe(L):
       s=0
       for i in L:
           s=s+i
       return s/len(L)

2. Ecrivez une fonction nbNotesAuDessus(L) qui calcule et retourne le nombre de notes superieurs ou égale a la moyenne des éméments de L:

(j'ai recopier la fonction moyenneListe(L), puis

def nbAuDessus(L):
    nb=0
    for k in L :
             if k(sup)=moyenneListe(L):
                     nb=nb+1
    return nb

3. Ecrivez une fonction existeNoteMoyenne(L) qui retourne True is il E un element de L egale a la moyenne des éléments de L, sinon False:

def existeNoteMoyenne(L):
    s=0
    for i in L:
            s=s+i
    for k in L:
           m=s/len(L)
           if k==m:
                 return True
    return False

je me demande si pour la 2 il est possible de simplifier sur le modele de la 3, ou alors si pour la 3 je dois proceder comme la 2
-----

[pm42]

Salut,

Il faut utiliser des balises CODE. Sinon, c'est difficilement lisible.

Sinon, la 2 est bien à part que ca vaudrait la peine de mettre le calcule de la moyenne dans une variable avant ta boucle. Sinon, tu la recalcule à chaque fois.
La 3 devrait être comme la 2 : on écrit des petites fonctions qu'on réutilise plutôt que de tout mélanger.

[invite73192618]

Je n'ai pas compris le 2, mais c'est dans tous les cas c'est sympa que tu ai mis ton code.Perso mes suggestions seraient de reconnaitre qu'il y a une fonction commune, et d'utiliser les compréhensions de liste

def cumsum(L):
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])

def moyenne(L):
    return cumsum(L)/len(L)

def nbNotesAuDessus(L):
    moy = moyenne(L)                                     # cf conseil pm42
    return cumsum([1 for i in L if i > moy])

def existeNoteMoyenne(L):
    moy = moyenne(L)
    return 0<cumsum([1 for i in L if i == moy])

[pm42]

utiliser les compréhensions de liste

En effet. Je me suis posé la question de proposer une écriture plus concise mais vu le code, je me suis dit qu'on était au niveau débutant qui commence juste à maitriser les boucles simples.

[A voir en vidéo sur Futura]

[PHIGE]

Bonjour,

Pour la 1, il faut vérifier que la liste n'est pas vide (et prévoir une valeur le cas échéant) sinon il y a une division par 0.

Pour la 2, il faut sortir le calcul de la moyenne de la boucle par exemple :

def nbAuDessus(L):
    nb=0
    moy=moyenneListe(L)
    for k in L :
             if k(sup)=moy:
                     nb=nb+1
     return nb

Ceci pour éviter de recalculer "Len" fois la moyenne.

Pour la 3 même commentaire pour "m=s/len(L)" qui doit être calculé une seule fois avant la boucle et il serait mieux d'appeler la fonction qui calcule la moyenne comme dans l'exemple 2.

Salutations

[PA5CAL]

Bonjour

def cumsum(L):
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])

D'une manière générale, les fonctions récursives sont des aberrations, car leurs appels répétés consomment inutilement du temps d'exécution et risquent de saturer rapidement la mémoire.

Dans le cas présent, un simple test de la fonction cumsum sur mon Mac plante avec une liste de plus de 998 nombres sous Python 2 et de plus de 997 nombres sous Python 3 :

Sous Python 2 :

Traceback (most recent call last):
  File ".../test.py", line 13, in <module>
    s = moyenne(L)
  File ".../test.py", line 7, in moyenne
    return cumsum(L)/len(L)
  File ".../test.py", line 4, in cumsum
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])
...
  File ".../test.py", line 4, in cumsum
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])
RuntimeError: maximum recursion depth exceeded

Sous Python 3 :

Traceback (most recent call last):
  File ".../test.py", line 13, in <module>
    s = moyenne(L)
  File ".../test.py", line 7, in moyenne
    return cumsum(L)/len(L)
  File ".../test.py", line 4, in cumsum
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])
  File ".../test.py", line 4, in cumsum
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])
  File ".../test.py", line 4, in cumsum
    return L[0] if len(L) == 1 else L[0] + cumsum(L[1:])
  [Previous line repeated 994 more times]
RecursionError: maximum recursion depth exceeded in comparison

Inutile de dire qu'on ne peut pas traiter des listes contenant quelques millions d'éléments de cette manière.

[pm42]

D'une manière générale, les fonctions récursives sont des aberrations, car leurs appels répétés consomment inutilement du temps d'exécution et risquent de saturer rapidement la mémoire.

Une référence à l'appui de ces affirmations ?

Parce que c'est totalement faux. Elles ont au contraire l'avantage d'être plus faciles à écrire et lire, de se prêter très bien à pas mal de styles de programmation, etc.
De plus, les compilateurs savent les optimiser dans les cas adéquats.
De plus, les architectures modernes sont précisément conçues pour qu'un appel de fonction ne coûte pas cher. Il suffit d'avoir débuggé n'importe quel programme de moins de 20 ans (voire plus) pour voir la profondeur des piles d'appels ce qui n'empêche pas la rapidité.

On peut également remarquer que pas mal de langages utilisent massivement la récursivité : c'est le cas de Erlang, d'Haskell, de Lisp bien sur et de tous les langages typés programmation fonctionnelle.

[Tryss2]

Certains langages se prêtent bien à la récursivité, d'autres non. Python fait partie de la seconde catégorie.

Donc non, écrire ce genre de fonction récursives en python est aussi aberrant que de faire des boucles itératives en Haskell

[PA5CAL]

Une référence à l'appui de ces affirmations ?

Parce que c'est totalement faux. Elles ont au contraire l'avantage d'être plus faciles à écrire et lire, de se prêter très bien à pas mal de styles de programmation, etc.
De plus, les compilateurs savent les optimiser dans les cas adéquats.
De plus, les architectures modernes sont précisément conçues pour qu'un appel de fonction ne coûte pas cher. Il suffit d'avoir débuggé n'importe quel programme de moins de 20 ans (voire plus) pour voir la profondeur des piles d'appels ce qui n'empêche pas la rapidité.

On peut également remarquer que pas mal de langages utilisent massivement la récursivité : c'est le cas de Erlang, d'Haskell, de Lisp bien sur et de tous les langages typés programmation fonctionnelle.

Réaliser un programme qui marche et qui atteint les performances attendues est plus important que de faire un programme facile à écrire et à lire.

Et il me semble que l'exemple de la fonction cumsum rapporté ci-dessus dément catégoriquement le fait que les outils de développement et les architectures modernes puissent toujours traiter ce cas de figure. Et si j'ai pris la peine de faire le test, c'est justement parce qu'il résulte de mon expérience que ce problème est courant, en Python, mais également en C/C++, en Pascal, en Fortran, etc. .


Savoir combien les appels prennent de temps et consomment sur la pile au moment du développement importe peu lorsqu'on ignore quels seront, dans le futur, la quantité de mémoire effectivement disponible (fonction de l'occupation du système) et le nombre d'appels réalisés (fonction du volume de données traitées).

En ce qui me concerne, c'est après avoir constaté les dégâts inopinément causés par ce genre d'astuce de programmation que j'ai été poussé à les interdire a priori, et en particulier à les éliminer des développements des sous-traitants, sauf dans les cas particuliers où les comportements pouvaient être garantis, preuves à l'appui.

Professionnellement, j'ai eu à déplorer des plantages et des ralentissements insupportables pour cette seule raison à de nombreuses reprises, notamment avec des logiciels développés par des personnes issues du milieu universitaire, qui semblent être coutumiers de cette astuce (je me rappelle d'ailleurs l'avoir déjà évoqué ici, dans une ancienne discussion).

Par exemple, des routines qui s'exécutaient normalement en une fraction de seconde se sont mis par moment à occuper la machine (PC Windows) durant plusieurs minutes, et quelquefois durant plusieurs heures, du fait d'une mémoire disponible insuffisante qui forçait le système à swapper de façon incessante.

C'est du plus mauvais effet quand cela survient une fois les logiciels mis en exploitation chez les clients, causant parfois des centaines de milliers d'euros de pertes. Tout ça pour un programme soi-disant plus lisible...

[pm42]

Tu te contentes de raconter ton expérience comme si elle était généralisable...
Aucune référence, rien de concret. Et tu mélanges tout, parlant du swap comme s'il était lié alors que la récursivité ne peut pas le provoquer (la stack est trop limitée en taille pour cela).

Je te laisse à tes certitudes obsolètes depuis des décennies. A titre indicatif, il y a un exemple célèbre de soft embarqué en téléphonie qui non seulement devait avoir les perfs attendues dans ce genre de domaine et qui a atteint un taux de disponibilité de 99.9999999%.

Curieusement, il était écrit dans un langage basé massivement sur la récursivité (déjà cité plus haut).

[invite73192618]

Certains langages se prêtent bien à la récursivité, d'autres non. Python fait partie de la seconde catégorie.

Pourrais-tu expliquer ton raisonnement? Par exemple, si tu es devant un nouveau langage X, comment jugeras-tu si ce nouveau langage se prête bien à la récursivité ou non?

Réaliser un programme qui marche et qui atteint les performances attendues est plus important que de faire un programme facile à écrire et à lire.

N'est-ce pas un point de vue surprenant dans le cadre d'une discussion sur python, dont la facilité d'écriture et de lecture est un des attraits principaux? Si on cherche des performances en python, on va le faire en utilisant une bibliothèque en sous-main, par exemple:

import numpy, time
def mycumsum(L):
    return numpy.cumsum(L)[-1]

L = [i for i in range(1000000)]
t1=time.time()
print(mycumsum(L))
t2=time.time()
print(str(round(1000*(t2-t1))) + ' ms')

...qui répond en une centaine de ms sur un vieux taco. Mais je ne pense pas que cette forme soit le but de l'exercice d'initiation qui est le sujet du fil.

En ce qui me concerne, c'est après avoir constaté les dégâts inopinément causés par ce genre d'astuce de programmation que j'ai été poussé à les interdire a priori, et en particulier à les éliminer des développements des sous-traitants, sauf dans les cas particuliers où les comportements pouvaient être garantis, preuves à l'appui.

Le comportement récursif n'est-il pas garanti en python, justement à cause/grace à la limite de profondeur que tu as touchée? Autrement dit, est-ce que tu as un exemple applicable à python ou c'est une règle que tu t'es construite au contact de langages plus anciens?

[PA5CAL]

Et puisque tu le prends sur ce ton, moi je te laisse à tes illusions basées sur ton manque d'expérience. (Non, mais !)

Il te suffirait de te donner la peine de procéder à des essais avec quelques outils que tu as sous la main pour t'apercevoir de la réalité des faits.


Le fait que la stack soit trop limitée est justement la raison pour laquelle il ne faut pas utiliser de fonction récursive sans pouvoir garantir préalablement tout à la fois la disponibilité et la consommation maximale des ressources dans tous les cas de figure envisageables.

Quant aux ralentissements dans les cas que j'ai évoqués, ils étaient bien été la conséquence du swap provoqué par la récursivité des fonctions de traitement (qui ne consommaient pas de la mémoire que sur la pile), ces problèmes ayant instantanément disparu grâce à la simple re-linéarisation de ces fonctions. J'ai juste précisé les cas où le problème ne s'était pas soldé par un plantage pur et simple.


À titre d'autre exemple, je prends ce que j'ai sous la main au moment où j'écris ces lignes (tablette sous Windows 10 / GCC 6.2), je fais un test de fonction récursive, et j'obtiens :

[Fustigator]

Réaliser un programme qui marche et qui atteint les performances attendues est plus important que de faire un programme facile à écrire et à lire.

Déjà qui marche et qui atteint les performances attendues sont deux sujets totalement différents; comparer des poires et des oranges n'a aucun intérêt.

Ensuite, si on se concentre sur l'aspect "performances attendues", c'est plus que discutable car le "facile à lire" a de facto un impact important sur la maintenance. Comme dans tous les projets d'une certaine taille cette dernière est en générale déléguée sous forme de TMA (c'est à dire que ce sera maintenu par une équipe n'ayant pas écrit une seule ligne du projet initial), troquer un gain marginal de perf contre une augmentation des coûts de TMA est un choix que presque personne ne fait "IRL".

Bien sur, sur un module de taille réduite et/ou au périmètre fonctionnel clairement circonscrit à un aspect technique, le choix inverse est parfaitement défendable (une couche réseau au sens large, une librairie de calcul, etc ....); mais poser cela en temps que règle général est absurde.

[invite73192618]

PS: (ce n'est pas spécialement en lien avec le dernier message) SVP tout le monde faisons un effort de civilité, cela peut être intéressant de connaitre les expériences de programmation des uns et des autres même si à la fin on devait rester en désaccord sur certains des conseils que ces expériences amènent.

[PA5CAL]

N'est-ce pas un point de vue surprenant dans le cadre d'une discussion sur python, dont la facilité d'écriture et de lecture est un des attraits principaux? Si on cherche des performances en python, on va le faire en utilisant une bibliothèque en sous-main

Ma remarque ne concernait pas que Python, et s'il est vrai qu'on utilise d'autres langages quand on souhaite atteindre de hautes performances, une programmation adaptée en Python permet tout de même de proposer aux utilisateurs des performances qui restent acceptables : sans qu'on ait vraiment besoin d'aller vite, il vaut mieux qu'une commande donne une réponse en deux secondes plutôt qu'en une heure, surtout si elle est souvent utilisée, ou encore qu'elle n'accapare toutes les ressources au détriment des autres fonctions, notamment sur les petits systèmes (smartphones, cartes à µC).

Le comportement récursif n'est-il pas garanti en python, justement à cause/grace à la limite de profondeur que tu as touchée? Autrement dit, est-ce que tu as un exemple applicable à python ou c'est une règle que tu t'es construite au contact de langages plus anciens?

J'ai pu vérifier le problème dans différents langages, avec différents compilateurs (ou interpréteurs) jusque dans des versions très récentes. Mais dans le fond, cela tient bien plus aux principes sous-jacents qu'au langage.

À la base, l'appel et l'exécution d'une fonction consomme de la mémoire. Donc si la programmation ne permet pas de fixer la limite de cette consommation et si le compilateur ne parvient pas à optimiser suffisamment le code (soit parce qu'il n'est pas assez perspicace, soit parce que la réduction nécessaire des opérations programmées réclamerait d'en modifier les concepts), alors il existe une limite à partir de laquelle la mémoire disponible ne suffit plus, et un risque que cette limite soit un jour dépassée.

Mon expérience m'a juste permis de confirmer qu'en règle générale, lorsqu'on n'a pas expressément mis les moyens pour contrôler le comportement d'une fonction récursive, on ne peut pas avoir la garantie de son innocuité. Penser que les compilateurs et les systèmes modernes arrangent forcément cette question à notre place est une erreur, puisque les faits prouvent que souvent ils n'y parviennent pas tout seuls.

La question peut d'ailleurs être étendue plus généralement au contrôle des ressources utilisées par les programmes. J'ai pu constater que de nombreux développeurs ne s'inquiétaient pas de savoir si le niveau d'appel maximum des fonctions était compatibles avec la taille de la pile, ni si le volume maximal des données traitées tenait dans la mémoire disponible, ni si l'intégration de leur programme dans un système final présentant une charge spécifiée était possible. Il est à la mode de programmer en pensant que les ressources disponibles sont infinies, ce qui parfois joue des tours.

[Tryss2]

Pourrais-tu expliquer ton raisonnement? Par exemple, si tu es devant un nouveau langage X, comment jugeras-tu si ce nouveau langage se prête bien à la récursivité ou non?

Lire la doc du langage pour savoir comment est traité la récursivité.

[PA5CAL]

Déjà qui marche et qui atteint les performances attendues sont deux sujets totalement différents; comparer des poires et des oranges n'a aucun intérêt.

Le bon fonctionnement et le respect des performances attendues vont de paire.

Un programme lisible qui marche mais qui n'atteint pas les performances attendues est juste bon pour la poubelle. Les performances minimales font souvent partie du cahier des charges. Mais même dans les cas où elles ne sont pas spécifiées, elles existent encore de façon qualitatives, de trop mauvaises performances pouvant rendre un programme inutilisable en pratique, ou commercialement inacceptable.

Ensuite, si on se concentre sur l'aspect "performances attendues", c'est plus que discutable car le "facile à lire" a de facto un impact important sur la maintenance. Comme dans tous les projets d'une certaine taille cette dernière est en générale déléguée sous forme de TMA (c'est à dire que ce sera maintenu par une équipe n'ayant pas écrit une seule ligne du projet initial), troquer un gain marginal de perf contre une augmentation des coûts de TMA est un choix que presque personne ne fait "IRL".

Bien sur, sur un module de taille réduite et/ou au périmètre fonctionnel clairement circonscrit à un aspect technique, le choix inverse est parfaitement défendable (une couche réseau au sens large, une librairie de calcul, etc ....); mais poser cela en temps que règle général est absurde.

Le codage et la maintenance sont du ressort des professionnels qui produisent le logiciel. Le bon fonctionnement et les performances concernent leurs clients, qui n'ont pas à savoir comment ils y parviennent.

D'une part, la question de la sécurité de l'exécution passant bien avant la lisibilité du code, il paraît inconcevable de recourir à des pratiques de programmation potentiellement dangereuses. Les exemples simples donnés ci-dessus en Python et en C devraient convaincre de la réalité de cet état de fait.

D'autre part, il est facile de réaliser de gros programmes lisibles sans faire appel à aucune fonction récursive.

[pm42]

À titre d'autre exemple, je prends ce que j'ai sous la main au moment où j'écris ces lignes (tablette sous Windows 10 / GCC 6.2), je fais un test de fonction récursive, et j'obtiens :

Le même code fonctionne sans problème avec des valeurs très grandes (millions...) en C compilé avec gcc ou converti en Scala et sans aucun doute dans d'autres langages.
Le plus rigolo est de compiler avec -O juste pour voir.

Mais bon, le code source ressemble au discours général : on se croirait dans les années 70 à 80 au mieux... Ceci explique cela.

[invite73192618]

En passant j'ai trouvé une solution qui devrait faire l'unanimité

def cumsum(L):
    return sum(L)

def moyenne(L):
    return sum(L)/len(L)

def nbNotesAuDessus(L):
    moy = moyenne(L)                                     # cf conseil pm42
    return sum([1 for i in L if i > moy])

def existeNoteMoyenne(L):
    moy = moyenne(L)
    return 0<sum([1 for i in L if i == moy])

[Spazi]

Le même code fonctionne sans problème avec des valeurs très grandes (millions...) en C compilé avec gcc ou converti en Scala et sans aucun doute dans d'autres langages.
Le plus rigolo est de compiler avec -O juste pour voir.

Mais bon, le code source ressemble au discours général : on se croirait dans les années 70 à 80 au mieux... Ceci explique cela.

En compilant avec -O, vous permettez au compilo de convertir votre fonction recursive en boucle.

Pas vraiment un bon exemple de récursivité utile.

[pm42]

En compilant avec -O, vous permettez au compilo de convertir votre fonction recursive en boucle.

Oui d'où la remarque sur "c'est rigolo".
Parce que c'est un exemple de récursivité terminale, massivement optimisable et justement intéressante pour cela.
Mais qu'il a été donné comme exemple de "la récursivité ne marche pas et regardez, mon programme plante"...

Pas vraiment un bon exemple de récursivité utile.

Au contraire, la récursivité terminale est l'une des plus utiles justement : on a alors le meilleur des 2, la concision et la simplicité d'expression tout en ayant un code compilé aussi efficace qu'une boucle.
C'est pour cela que certains langages se passent globalement de boucles et n'utilisent que la récursivité. C'est aussi pour cela que certains permettent de forcer l'écriture en récursivité terminale (@tailrec en scala) ou de gérer la technique du trampoline (javascript, groovy, clojure).

https://eddmann.com/posts/recursive-...in-javascript/
https://eddmann.com/posts/recursive-...ne-in-clojure/
http://mrhaki.blogspot.com/2011/04/g...h-closure.html

[pm42]

Juste une petite précision : dans le cas du code en C donné au dessus, gcc va carrément un cran plus loin que de remplacer la récursivité par une boucle.
Il se contente de renvoyer end.

Voici le code x86 généré :

	pushq	%rbp
	movq	%rsp, %rbp
	movl	%esi, %eax
	popq	%rbp
	retq

[PA5CAL]

Le même code fonctionne sans problème avec des valeurs très grandes (millions...) en C compilé avec gcc ou converti en Scala et sans aucun doute dans d'autres langages.
Le plus rigolo est de compiler avec -O juste pour voir.

Qu'à cela de tienne. Bien évidemment, le compilo est assez intelligent pour réduire le cas ultra-simple ci-dessus, mais un le compliquant très légèrement, on continue de faire face au même problème en optimisant :



Quand bien même on utiliserait un compilateur plus perspicace, on pourrait certainement trouver des cas de figure qui le mettrait en défaut : la profondeur des optimisations présente toujours une limite qui peut être dépassée par une plus grande complexité du programme.

D'une manière générale, on ne peut pas attendre du compilateur qu'il soit plus intelligent que le développeur et qu'il fasse à sa place toujours ce que ce dernier souhaite sans le lui avoir demandé expressément. Et je passe sur le fait que pour cette raison, dans le développement professionnel on est souvent contraint de désactiver l'optimisation automatique pour pouvoir garantir la conformité du code source avec les spécifications.

Mais bon, le code source ressemble au discours général : on se croirait dans les années 70 à 80 au mieux... Ceci explique cela.

L'invective ne donne pas raison.

Ton discours que tu penses moderne est simplement faux. Le mien s'est construit et a évolué au gré de ma longue expérience, qui a effectivement commencé dans les années 70/80, mais qui a continué jusqu'à cet instant. D'ailleurs, comme tu peux le constater, il y a quelques minutes seulement, j'ai encore pu trouver des éléments pour étayer ce que j'avance par l'expérience. A contrario, compte tenu des contre-exemples que j'arrive à fournir sans mal, je ne vois pas comment tu pourrais justifier ton point de vue.

[PA5CAL]

Un autre exemple "pour la route", en Javascript, sous la dernière version de Firefox :

[invite73192618]

on ne peut pas attendre du compilateur qu'il soit plus intelligent que le développeur et qu'il fasse à sa place toujours ce que ce dernier souhaite sans le lui avoir demandé expressément.

N'est-ce pas tres exactement ce que Tensorflow fait?

En general, je comprendrais ton point s'il s'agissait de C ou d'assembleur. Mais ce qui concerne python (le sujet du fil) perso oui je m'attend d'un langage de haut niveau qu'il permette de s'abstenir de specifier exactement toutes les etapes une par une. N'est-ce pas la definition meme d'un langage de haut niveau?

[pm42]

N'est-ce pas tres exactement ce que Tensorflow fait?

Et tous les compilos modernes sans même parler des JIT, des méthodes de GC et j'en passe... Toutes choses qui font qu'on peut justement programmer à un niveau d'abstraction de plus en plus haut sans le payer cher.
On l'a d'ailleurs vu plus haut où gcc virait carrément une boucle inutile.

Après, il faut connaitre les limites des outils qu'on utilise mais ça, cela a toujours été vrai. Et il n'y a pas de raison conseiller aux autres de se passer d'une technique juste parce qu'on ne la maitrise pas...

[invite73192618]

Et tous les compilos modernes sans même parler des JIT, des méthodes de GC et j'en passe...

Je ne les connais pas. Est-ce qu'ils s'occupent également de la répartition de la charge en fonction de la nature du matériel (CPU, GPU, ferme de server) et de la structure du calcul?

[jiherve]

Bonjour,
la récursivité utilise intrinsèquement de la mémoire puisque l'on appelle une fonction de façon itérative c'est le principe, il y a donc une limite imprévisible de la mémoire disponible en fonction de ce qui tourne à coté.
Pas de miracle penchez vous sur le hard qui supporte tout cà , ah oui merde il y a du hard!
La récursivité est STRICTEMENT INTERDITE dans des programmes certifiables DO178 DALXX et ce n'est pas un hasard.
https://www.researchgate.net/profile...tical-Code.pdf
JR

[pm42]

Je ne les connais pas. Est-ce qu'ils s'occupent également de la répartition de la charge en fonction de la nature du matériel (CPU, GPU, ferme de server) et de la structure du calcul?

Cela dépend. Pour la répartition CPU/GPU, c'est très particulier et il y a des langages et librairies spécialisées. Mais en dehors de l'IA, on a plutôt tendance à écrire directement pour les GPU.

Par contre, les compilos font des trucs étonnant notamment dans l'ordonnancement des instructions pour profiter à fond de l'architecture des machines : pipe-line, hyper-threading...
C'est une techno qui a été développée aux débuts des processeurs RISC et cela a abouti à une génération de compilateurs qui sont plus efficaces que des humains.

[pm42]

la récursivité utilise intrinsèquement de la mémoire puisque l'on appelle une fonction de façon itérative c'est le principe,

Voir ce qui a été dit plus haut et qui explique pourquoi ce n'est pas forcément vrai.
Ce n'est même pas vrai hors récursivité, les compilos pratiquant l'inlining quand ils le jugent utile.