boucle while

[polo974]

Pas en général. Si tu fais while(), tu vas avoir un message d'erreur.

La boucle for est ultra-générale en C avec les 3 composantes, initialisation, action à chaque passage dans la boucle et critère d'arrêt qui sont facultatives. Et si rien n'indique à la boucle quand s'arrêter, elle continue et c'est au code de gérer via un break, return, longjmp, exit...

Ce qui est amusant, c'est qu'à l'époque, cela donnait de la puissance expressive au programmeur qui pouvait optimiser son code aux petits oignons mais qu'aujourd'hui, c'est plutôt le contraire : cela complique le travail du compilateur plus qu'autre chose.

C'est vrai que je n'utilise pas trop le while, le for étant plus court à écrire et plus puissant... (il faut bien que je me justifie...)

Je me demande combien de personnes utilisent le setjump/longjump (autrement qu'à l'insu de leur plein gré)...
Perso, je l'avais utilisé pour écrire des coroutines et sauter de bouts de pile en bout de pile... Du temps ou je faisais du sport en informatique...
-----

[pm42]

C'est vrai que je n'utilise pas trop le while, le for étant plus court à écrire et plus puissant... (il faut bien que je me justifie...)

Bienvenu au club?

Je me demande combien de personnes utilisent le setjump/longjump (autrement qu'à l'insu de leur plein gré)...
Perso, je l'avais utilisé pour écrire des coroutines et sauter de bouts de pile en bout de pile... Du temps ou je faisais du sport en informatique...

Bonne question et comme toi, je ne l'ai pas utilisé depuis longtemps.
Je pense qu'il sert dans certains bout de code système, ou pour traiter des exceptions trop compliquées autrement.

Dans le même genre, goto est pas mal utilisé dans le noyau Linux.

[jiherve]

bonsoir
revenez à l'assembleur et vous comprendrez tout!
JR

[pm42]

revenez à l'assembleur et vous comprendrez tout!

Qu'est ce qui te fait penser qu'on n'en a pas fait et qu'on ne comprend pas ce que font setjmp/longjmp ?

[jiherve]

Bonjour,
ne te sens pas visé .
Cela confirme que l'on peut plaisanter de tout mais pas avec tout le monde!
JR

[pm42]

ne te sens pas visé .
Cela confirme que l'on peut plaisanter de tout mais pas avec tout le monde!

Je ne me sentais pas spécialement visé mais tu as clairement interprété ma réponse très différemment de l'esprit dans lequel elle était écrite ce qui prouve que la communication n'est pas facile et encore moins en ligne.

[albanxiii]

revenez à l'assembleur et vous comprendrez tout!

Le rustre

[pm42]

Le rustre

Excellent

[jiherve]

bonjour
rouillé mais pas tant que çà car il y a de la matière!
JR

[Garion]

bonsoir
revenez à l'assembleur et vous comprendrez tout!
JR

C'est quand même redoutable l'assembleur quand on a des besoins critiques de rapidité.
J'ai encore des bouts de code en assembleur SSE4 dans mon soft de simulation énergétique de bâtiment incroyablement plus rapide que des librairies comme Lapack pour des cas particuliers (factorisation de Choleky avec des matrices creuses dans mon cas).

[jiherve]

bonsoir
et oui si l'on taquine le processeur à ses limites il faut souvent coder en assembleur(pas toujours si le compilo est très bon et que la tache s'y prête ) , mais d’après certains c'est démodé sauf que leurs langages de haut niveau ne tiennent, n'existent que parce que les "has been" se sont farci la lecture des data sheet (je sais c'est souvent dur à comprendre) et ont pris le temps de coder en bas niveau et ainsi cacher les difficultés à l'utilisateur lambda.
JR

[pm42]

C'est quand même redoutable l'assembleur quand on a des besoins critiques de rapidité.

En moyenne plus trop de nos jours et notamment sur les processeurs RISC : les compilos sont meilleurs que les humains.

J'ai encore des bouts de code en assembleur SSE4 dans mon soft de simulation énergétique de bâtiment incroyablement plus rapide que des librairies comme Lapack pour des cas particuliers (factorisation de Choleky avec des matrices creuses dans mon cas).

La question est de savoir si ton code pour traiter des cas particuliers n'aurait pas été quasi aussi rapide si écrit en Fortran, C ou même Rust.

[Garion]

En moyenne plus trop de nos jours et notamment sur les processeurs RISC : les compilos sont meilleurs que les humains.

Je ne suis pas concerné, mon code doit tourner en x64 (et je doute quand même que dans des cas particulier, le compilo fasse mieux que l'humain).

La question est de savoir si ton code pour traiter des cas particuliers n'aurait pas été quasi aussi rapide si écrit en Fortran, C ou même Rust.

Concernant Fortran ou C, j'en doute, l'original était en Delphi compilé x64, la différence entre ces langages et Delphi est relativement faible. J'ai obtenu en gain X4 dans ma version assembleur (monothread) par rapport à Delphi (dont le compilateur gère nativement le SSE), et un gain supérieur à 100 par rapport à Lapack sur des grosses matrices creuses (mais j'ai trouvé un astuce de reconditionnement des matrices qui me permet de bénéficier à fond de mon code dans le cas de matrices creuses).
Pour Rust, je ne peux pas me prononcer.
La théorie, c'est bien joli, mais je suis prisonnier d'un code de calcul d'un million de lignes calcul en Pascal, il faut bien que je fasse avec, et si ça doit passer par de l'assembleur inline pour accélérer la chose, ben, je le fais et j'ai des résultats, et pas besoin de changer tout mon code pour pouvoir utiliser une DLL compilé dans un autre langage (si je dois changer mon format de donnée pour m'adapter à la DLL, ça détruirait la performance).

[polo974]

Lapack n'est pas fait pour tricoter des matrices creuses...

sinon, ça fait un certain temps que je n'avais pas visité: https://benchmarksgame-team.pages.de...andelbrot.html

Il y a "un certain temps", les codes gagnants avaient pas mal de directives sauce assembleur, mais là, c'est quand même assez clean...
Le rust est presque joli (il faut vraiment que je m'y mette à ce truc avant que ça ne devienne un hobby de retraité...).

[CM63]

sinon, ça fait un certain temps que je n'avais pas visité: https://benchmarksgame-team.pages.de...andelbrot.html

Ca m'étonne qu'avec Python ils n'arrivent qu'à un "time-out" ou un "failed", ils n'ont pas du se creuser, alors que l'antique Fortran arrive à un score honorable.

[pm42]

Je ne suis pas concerné, mon code doit tourner en x64 (et je doute quand même que dans des cas particulier, le compilo fasse mieux que l'humain).

Sur la grande majorité du code si parce qu'il va faire des optimisations pointues sur les boucles, organiser les instructions pour profiter à fond des pipelines (des instructions qui commencent avant que la précédente ne soit finie), faire du recuit simulé ou autre pour utiliser au mieux les registres...
Et comme je disais, encore plus sur les processeurs RISC.

Et sur certains types de code, on va même plus vite avec des machines virtuelles et un JIT parce qu'avant de compiler, il fait des analyses statistiques à l'exécution et il sait donc quelles fonctions inliner, quelles boucles unroller...

J'ai obtenu en gain X4 dans ma version assembleur (monothread) par rapport à Delphi (dont le compilateur gère nativement le SSE)

Sans connaitre le cas particulier, il est impossible de se prononcer.

et un gain supérieur à 100 par rapport à Lapack

Voir la remarque de polo974 : quand on a un facteur 100 par rapport à Lapack, c'est qu'il n'est pas adapté au problème.

La théorie, c'est bien joli

Ce n'est pas de la théorie, c'est le résultat de l'expérience de décennies de programmeurs.

mais je suis prisonnier d'un code de calcul d'un million de lignes calcul en Pascal, il faut bien que je fasse avec, et si ça doit passer par de l'assembleur inline pour accélérer la chose, ben, je le fais et j'ai des résultats, et pas besoin de changer tout mon code pour pouvoir utiliser une DLL compilé dans un autre langage (si je dois changer mon format de donnée pour m'adapter à la DLL, ça détruirait la performance).

Je pense que tu te trompes mais si ta solution te convient, tant mieux.

[MissJenny]

En fait, à part les trucs faux, on décide que tout est vrai ? Même un sujet sans verbe (c'est à dire qui ne soit pas une proposition logique du type x<5)
Tous les langages font-ils ça ???

Le langage S, qui est implémenté entre autres dans R, utilise une logique trivaluée : FALSE, TRUE, NA. NA signifie "Not Available".

Quand il y a un NA dans une expression logique la valeur de l'expression est NA. Par exemple (TRUE || NA) renvoie NA. Du coup il faut une fonction spéciale pour tester qu'une valeur est NA (car l'expression x==NA renvoie toujours NA même si x vaut NA). On a donc une fonction is.na : is.na(x) renvoie TRUE si x vaut NA. Mais sinon il y a la même convention que dans Python : toutes les valeurs numériques sont équivalentes à TRUE sauf 0 qui est équivalent à FALSE.

[polo974]

Ca m'étonne qu'avec Python ils n'arrivent qu'à un "time-out" ou un "failed", ils n'ont pas du se creuser, alors que l'antique Fortran arrive à un score honorable.

Ben oui, si tu regardes la liste en partant du fond...

Remonte un tout petit peu dans la liste, il est (minablement) à presque 3 mn.

[pm42]

L’antique Fortran reste un des langages les plus efficaces et Python est connu pour être lent si on n’utilise pas une des nombreuses librairies écrites en C/C++ ou autre.

[frequi1]

Bonjour,
quand je tape ceci en python ça m'énumère à l'infini tous les entiers, pourtant je pensais que while attendait une valeur booléenne (vrai ou faux), quelqu'un sait-il ? Car "4" n'est ni vrai ni faux...
je pensais que ça ferait erreur,
merci

i = 0
while 4 :
print(i)
i+=1

Ce bout de code ne veux rien dire:
tu voulais certainement coder:

i = 0
while i <= 4:
      print(i)
      i += 1

[polo974]

Ce bout de code ne veux rien dire:
tu voulais certainement coder:

i = 0
while i <= 4:
      print(i)
      i += 1

Si,si, while 4: veut très bien dire ce qu'il dit: tant qu'il y a "quelque chose" au sens pythonesque de la chose...

[ilelogique]

Non Non c'est bien ce que j'ai écrit (oui ça a peu de sens mais peu importe ici) et la réponse m'étonne donc

[CM63]

"4" n'est ni vrai ni faux...

"4" est converti en valeur logique vrai. Lorsqu'on convertit une donnée en valeur logique, on obtient vrai si la donnée n'est pas nulle, faux si elle est nulle. Par exemple le caractère "0" sera converti en valeur logique vrai (car égal à 48), seul char(0) donnerait une valeur logique fausse. Et pour les nombres entiers, seule la valeur 0 donnera une valeur logique fausse, toute autre valeur donnera vrai.

[pm42]

"4" est converti en valeur logique vrai. Lorsqu'on convertit une donnée en valeur logique, on obtient vrai si la donnée n'est pas nulle, faux si elle est nulle. Par exemple le caractère "0" sera converti en valeur logique vrai (car égal à 48), seul char(0) donnerait une valeur logique fausse. Et pour les nombres entiers, seule la valeur 0 donnera une valeur logique fausse, toute autre valeur donnera vrai.

Tout cela a été expliqué dès les 1ers messages du fil. Est ce que tu l'as lu avant de poster ?