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

[RenaudM]

Je me souviens avoir vu il n'y a pas si longtemps un comparatif de performance, et Python était environ 80 fois plus lent que Delphi...
Bon, c'était sur des exemples précis, pas sûr que ça soit une généralité.

[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

[pprem]

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

Même sans avoir à embaucher quelqu'un, s'ils font du C++, ils doivent pouvoir prendre un jour ou deux pour apprendre la syntaxe du Pascal et travailler sous Delphi, c'est quand même pas le langage le plus compliqué du monde.

Pour le reste, effet de mode ou pas, il y a une tendance forte à utiliser pour tout un tas de choses pour lesquelles il n'a pas été fait. En France, le choix de l'éducation nationale de l'utiliser est incompréhensible.

Au moins ce genre de librairies et de webinaires montrent que Delphi, même si c'est propriétaire, reste ouvert vers l'extérieur comme il l'a toujours été et permet d'interagir avec d'autres environnements. Ca avait déjà été fait pour utiliser Delphi en interface avec des formulaires web en JS et il y en a d'autres sur GitHub et d'autres dépôts de sources.

[SergioMaster]

En France, le choix de l'éducation nationale de l'utiliser est incompréhensible.

pas totalement mais c'est un autre débat, je ne dirais que WEB et pas de compilateur justement d'un autre côté pourquoi Python (ces lignes par indentation ça m'a quelque peu effrayé) et pas plutôt PHP une culture des expressions régulières de la part des décideurs ?

[Paul TOTH]

Même sans avoir à embaucher quelqu'un, s'ils font du C++, ils doivent pouvoir prendre un jour ou deux pour apprendre la syntaxe du Pascal et travailler sous Delphi, c'est quand même pas le langage le plus compliqué du monde.

je suis un fan inconditionnel de Delphi (ou plus généralement du Pascal), mais si j'étais responsable des développements du boîte ou je n'ai pas de développeur Delphi, je ne prendrais pas en charge un projet Delphi...soit je soustraite sa maintenance (pourquoi pas), soit je change de langage. Ce que j'ai dit sur l'apprentissage de Python et vrai aussi pour Delphi, passer du C++ à Delphi c'est plein de pièges ne serait-ce que sur la gestion mémoire, la nature des classes objets, les dépendances des unités...rien d'insurmontable, mais encore faut-il que l'investissement en vaille la peine....pour un seul produit, sauf s'il est génial et incontournable, ça ne me parait pas en valoir le coup.

[Montor]

Dès que je vois les underscore du Python je m'en fuis ça me rappelle les macro du C

[Paul TOTH]

Dès que je vois les underscore du Python je m'en fuis ça me rappelle les macro du C

je sais pas ce que c'est, mais ce genre de chose c'est souvent une question d'habitude.

par exemple, ça fait longtemps que j'utilise Javascsript mais au cours du temps je suis passé d'une programmation procédurale, au prototypage, puis les class, et je viens d'adopter les fonctions flèches qui au départ me semblait une hérésie.

il y a pas bien longtemps je n'aurais jamais écrit

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class MyTable {  
// ...
  toText() {
    var text = [];
    this.rows.forEach(row => {
      row.forEach(cell => {
        text.push(cell.value);
      }
    });
    return text.join(';');
  }
}

en fait il faut du temps pour se faire à un langage et en appréhender tous les aspects...le Pascal, je l'ai découvert avec Turbo Pascal 3, donc j'ai eu tout le temps nécessaire à intégrer les nouveautés au fur et à mesure