Discussion :

[petitcoucou31]

bonjour a tous.

Une demande un peu spéciale et je ne sais pas si je suis sur le bon forum.
Je devrais (peut-être) ré-écrire des bouts de code qui existent aujourd'hui en delphi7 (presque du pascal) vers du langage Python.

Avant de me lancer dans cela, je me pose les questions suivantes :

• Un code Delphi compilé pour Linux a-t il les mêmes performances que le même code compilé pour Win32 ?
• Si des gens ont pu comparer deux algo quasi identiques dans ces deux langages (Delphi7 et Python) et quel serait le ratio de vitesses.

Mon 1er avis étant : l'un est compilé (Delphi) donc plus rapide que l'autre qui est interprété (python), mais cela n'est peut être pas si simple.
Surtout qu'au final cela tournera sous Linux.

Dans l'attente de réponses..

A bientôt.

[Paul TOTH]

oui un bon code Delphi sera plus rapide qu'un mauvais code Python...mais la première question serait: est-ce que la performance est un critère décisif ?

par exemple, pour les développements web j'utilise souvent PHP, pas parce que c'est mieux que Delphi, mais parce que je peux facilement déployer un serveur PHP sur du mutualisé OVH ... alors que pour héberger un service Delphi il me faut un serveur dédié Windows ou Linux qu'il faut alors gérer en plus de l'application.

[SergioMaster]

Bonjour,

Sujet d'actualité car deux webinaires ont été proposés.
Le premier, passé, est déjà en rediffusion

rien qu'à la banane de Jim McKeeth au cours de la démonstration, il est facile de tirer de premières conclusions
Cela écrit, le prochain volet montrera peut-être autre chose . Ne connaissant pas Python et surtout les bibliothèques proposées je ne prendrai pas parti.

par contre :

Un code Delphi compilé pour Linux a-t il les mêmes performances que le même code compilé pour Win32 ?

Oui, tout ce que j'ai pu faire comme applications (Windows/Ubuntu) fonctionnent apparement de manière identique.
NB. Un programme D7 peut très bien "tourner" sous linux pour peu d'installer WINE

Maintenant, dans la première vidéo, un exemple de Python créant une "application Delphi" est montrée, de quoi rester songeur ....

[petitcoucou31]

bonjour,

Paul,

Est-ce que la performance est un critère décisif ?

OUI,
En fait ces codes Delphi, qu'il faut ré-écrire en python, sont des fonctions de "bas niveaux". Ces fonctions permettent un dialogue bidirectionnel entre le logiciel (haut niveau) et le matériel (FPGA, CAD CDA,...) au travers d'un bus sur 8 bits. Un grand nombre d’échanges bidirectionnels est nécessaires pour effectuer une tache de base.
Même si une perte de vitesse ne perturbe pas le fonctionnement du système, à cause de ce grand nombre d'échanges bidirectionnels la vitesse de ces échanges est primordiale pour ne pas ralentir la durée des processus complets.
Cette durée est directement liée au temps d’exécution du code et bien sur à la vitesse de la CPU. Et la vitesse des CPU est aussi liée à leur coût..
D’où ma recherche sur perte potentielle de vitesse !

Pour info : J'irai faire des mesures pour connaitre la vitesse réelle et actuelle entre deux écritures sur le matériel, sur un CPU de performance moyenne.

SergioMaster
La tache n'est pas de développer des scripts Python avec/pour Delphi, mais remplacer complément Delphi par python. ET aussi passer sur des CPU équipées de Linus à la place de Windows.

Selon ton expérience, tu as pas vus de différence entre la compil d'un même code Delphi sous Win32 et Linux, mais peut être la vitesse pour toi n’était pas significative.

Si je trouve assez d'avantages pour Delphi, peut-être pourra-t-on conserver Delphi en le compilant sous Linus (pour Linux j'ai pas le choix).

[Paul TOTH]

petite précision, sous Linux c'est un compilateur 64bits qui génère un code différent de Win32...il faudrait comparer avec Win64 en fait.
notamment car le compilateur Win32 reste compatible avec de vieux CPU alors que Win64 part de processeurs forcément plus récent avec des jeux d'instructions forcément présents (notamment sur les flottants)

je ne connais pas Python et ses capacités, mais pour du lowlevel je resterais sur Delphi qui peut au besoin faire de l'assembleur, voir je basculerais sur du C si je dois m'appuyer sur des bibliothèques spécifiques...bien qu'il soit toujours possible de passer par une DLL (.so sous Linux)....qui sera exploitable sans doute aussi sous Python.

mais pourquoi Python ? tu connais ? tu en as entendu parler en bien ? car s'approprier un nouveau langage n'est pas toujours une mince affaire. Ce n'est pas tellement la syntaxe qui est un obstacle, mais la maitrise du framework, la connaissance des librairies, les bonnes pratiques en matière justement de performance...tout cela prend bcp de temps à acquérir.

[petitcoucou31]

re,

La raison de ce changement, c'est que le produit (qui utilise les "DLL" à traduire) dont on parle, est repris par une société tierce qui dans sa 20éne de développeurs logiciel ont aucune compétence en Delphi, sinon que c'est du pascal, qu'ont apprenaient à l’école .

Histoire homogénéité dans leur développement (C,C++,Python...), ils souhaitent migrer les DLL dont je parle vers des logiciels dont ils ont la maitrise. Cela permet aussi une compatibilité avec les produits propres. A terme surement intéressante et aussi plus maintenable.
Peut-être que l'embauche d'une personne qui en plus de la connaissance de leurs environnements de développement qu'ils utilisent aurait aussi une compétence en Delphi serai le mieux.

L'option "C" a la place de Python peut aussi être envisagé.

Pourquoi python :

• D'après la société en question, il existe beaucoup de bibliothèque adaptées à Linux pour utiliser les com des cartes CPU, ce qui serait plus pérenne. Leur propre bas niveau est déjà codé en Python ou en C.
• Moi, je ne le maitrise (juste un peu par curiosité), mais la société en question, je pense que oui,
• En entendre parler en bien... comme tous les logiciels il y a un phénomène de mode, il semble actuellement en poupe.
  J'ai vu un comparatif sur le site qui ne le classe pas très bien. mais dans les conditions de ce test.
  https://programmation.developpez.com...es-plus-verts/

Bonne soirée

[SergioMaster]

Bonjour,

La tache n'est pas de développer des scripts Python avec/pour Delphi, mais remplacer complément Delphi par python

j'avais bien compris. Si tu as regardé la vidéo le premier exemple répond en gros à la question "vitesse"

dans un premier temps seul le script Python est utilisé pour le calcul des 1000 (ou 10000 ?) premiers nombres premiers temps 4s
puis il y a différents appels via Python de la fonction identique en Pascal, y a pas photo 10 fois moins minimum.
Qu'il ait fallu des composants spécifique pour interfacer Python et Delphi OK mais c'était le but du webinaire, ce qu'il manquait :une page web appelant le code Python comme comparatif ?

Selon ton expérience, tu as pas vus de différence entre la compil d'un même code Delphi sous Win32 et Linux, mais peut être la vitesse pour toi n’était pas significative.

Certes mes comparatifs ont été fait avec des programmes de gestion (donc beaucoup d'inter-action avec l'utilisateur) donc des questions de micro-secondes ne se posent pas (de secondes pour l'ontention des données si) . Néanmoins je reste persuadé qu'un langage interprété reste plus lent qu'un programme compilé.

Si, effectivement, il n'y a pas de compétence C, de Delphi à C++ (bref RAD Studio et donc le même IDE) ce n'est qu'un petit pas (même si j'ai fait l'inverse)
S'il s'agit de bibliothèques (généralement C) deux arguments Delphi, mais aussi C++ peut y accéder, que fait Python sinon la même chose ? d'ailleurs en quel langage a été écrit l'interprétreur Python ?

il y a un phénomène de mode,

C'est clair mais aussi dû à l'enseignement