IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

EDI Delphi Discussion :

Première présentation de Delphi XE2


Sujet :

EDI Delphi

  1. #21
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2005
    Messages
    261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 261
    Points : 658
    Points
    658
    Par défaut
    Citation Envoyé par Gilbert Geyer Voir le message
    Re-bonjour,
    ... j'avais bien cité deux *.exe distincts.
    ... l'exe 64 bits appelle l'exe 32 bits avec ShellExecute en lui transmettant les paramètres pour les calculs : jusqu'ici pas de problème (j'ai testé avec deux exe 32 bits) par contre je n'ai pas encore trouvé la manip pour récupérer le résultat du calcul de l'"esclave" par l'appli-"maître" sans passer par le presse-papier.
    Comme la source de l'"esclave" est un *.dpr qui commence par :
    programme VaCalculer(input,output);
    je ne parviens pas à récupérer le "output" pour l'envoyer en retour à l'appli-maître. (je n'ai jamais travaillé en mode console).
    Tu as tous les mécanismes IPC (Inter Process Communication) pour récupérer l'output. Il y a les pipes, les mémoires partagées, les messages...
    Si tu veux te prendre la tête avec les technos M$, tu peux aussi faire un serveur COM 32 bits qui sera utilisé par ton appli 64 bits.
    Il y a aussi des méthodes plus crades genre Read/WriteProcessMemory ou encore passer par un fichier...

    [edit]
    Forcément, il y a une perte de performance importante dans l'échange par rapport à un appel de fonction. Mais il n'y a pas de solution (Connue...) pour exécuter du code 32 bits dans un processus 64 bits.

  2. #22
    Modérateur
    Avatar de tourlourou
    Homme Profil pro
    Biologiste ; Progr(amateur)
    Inscrit en
    mars 2005
    Messages
    3 623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Biologiste ; Progr(amateur)

    Informations forums :
    Inscription : mars 2005
    Messages : 3 623
    Points : 10 381
    Points
    10 381
    Billets dans le blog
    6
    Par défaut
    Bonjour René et Gilbert.

    L'asm n'est pas mort, on dirait !

    Avec des perspectives intéressantes, même si le multi-(toti ?)-plateformes est le Graal...
    Delphi 5 Pro - Delphi 10.3.2 Rio Community Edition - CodeTyphon 6.90 sous Windows 10 ; CT 6.40 sous Ubuntu 18.04 (VM)
    . Ignorer la FAQ Delphi et les Cours et Tutoriels Delphi nuit gravement à notre code !

  3. #23
    Membre éprouvé
    Avatar de CapJack
    Homme Profil pro
    Prof, développeur amateur vaguement éclairé...
    Inscrit en
    mars 2004
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Prof, développeur amateur vaguement éclairé...
    Secteur : Enseignement

    Informations forums :
    Inscription : mars 2004
    Messages : 622
    Points : 984
    Points
    984
    Par défaut
    Citation Envoyé par Gilbert Geyer Voir le message
    par contre je n'ai pas encore trouvé la manip pour récupérer le résultat du calcul de l'"esclave" par l'appli-"maître"
    Utiliser les primitives des protocoles DDE et COM ? Ça marche même entre un exe et une dll, j'ai pas testé entre deux dll. Pas besoin du presse-papier, c'est une zone de mémoire partagée entre deux processus.

    Mots clefs de départ :
    CreateFileMapping();
    OpenFileMapping();
    MapViewOfFile();
    UnmapViewOfFile();

    Tout est sur msdn.

  4. #24
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2005
    Messages
    261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 261
    Points : 658
    Points
    658
    Par défaut
    Le lien vers la source n'est pas bon.
    Le bon lien est le suivant :
    http://www.jcolibri.com/articles/del...elphi_xe2.html

  5. #25
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2006
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2006
    Messages : 53
    Points : 561
    Points
    561
    Par défaut mise à jour de la présentation
    notre présentation Delphi XE2 - Delphi 2012 ("plus technique" que la petite intro ci dessus que j'avais envoyé à Gordon Fowler ce matin)

    http://www.jcolibri.com/articles/del...elphi_xe2.html

    a été mise à jour avec les nouvelles informations sur les Proxy Connectors pour Android, BlackBerry, Windows Phone 7 et Ios. Avec les liens correspondant à ces informations.

    D'autres informations devraient tomber après l'annonce officielle, et je continuerai à mettre à jour l'article. "Stay tuned"

    Merci aussi à "rt5" pour avoir signalé que le lien "source" du début de page vers notre article est incorrect. Je mentionnerais aussi que les références à Pascalissime (où je n'étais d'ailleurs pas le seul à publier) me sont allées droit au coeur.

    John COLIBRI
    jcolibri@jcolibri.com

  6. #26
    Modérateur

    Homme Profil pro
    Ingénieur retraité
    Inscrit en
    octobre 2005
    Messages
    2 396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur retraité

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 396
    Points : 3 260
    Points
    3 260
    Par défaut
    Bonjour,

    A Rekin85 : merci René pour ta réponse. Et comme tu dis :
    Mais attention elles ne tourneront que sur du 64 bits et le nombre de machines concernées est petit en regard de tout ce qui tourne encore sur du 32.
    ... il n'y a pas le feu au lac : les NewGint et NewGCent ont encore du temps devant elles.

    A Rt15 et à CapJack à propos de la récupération de l'output.
    ... Merci beaucoup pour vos pistes de résolution.
    ... Mais je dois vous dire que mon idée est carrément idiote pour la raison suivante : Utiliser un *.exe 64 bits qui lance un *.exe 32 bits truffé d'Asm+Pascal pour lui faire-faire les calculs et renvoyer le résultat à l'exe 64 bits ... à qui il ne reste plus qu'à afficher le résultat du calcul ... donc autant se passer de l'exe 64 bits et faire afficher le résultat directement par l'exe 32 bits. Faut savoir que le cas qui me préoccupe concerne des calculs effectués par les Unités NewGint et NewGcent précitées et qui renvoient des résultats de calcul dont le nombre de digits n'est limité que par la taille d'une string donc limité par la mem-vive disponible ... donc des résultats de calcul avec lesquels l'exe 64 bits ne pourrait évidemment faire rien d'autre que de les afficher.

    A J. Colibri : Mon attention a été attirée par :

    2.4 - Migration 64 bits Delphi: les points à surveiller
    ...
    ... inclusion de blocs assembleur:
    - il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal // ça à été déjà cité par Sjrd mais pas la suite :
    - seules les procédures ayant l'attribut Asm sont possibles
    ... compte tenu de ceci je pense qu'on peut en déduire que sous XE2 il est possible d'avoir dans la même unité des procédures et des fonctions qui depuis l'attribut Asm jusqu'au end final sont totalement en Asm et d'autres qui depuis le premier begin jusqu'au dernier end sont entièrement en Pascal. Oui/Non ?

    Si Oui il n'y a plus raison de s'affoler vu qu'une routine en Asm peut être appelée par une autre en Pascal et inversement.

    A+.
    N'oubliez pas de consulter les FAQ Delphi et les cours et tutoriels Delphi

  7. #27
    Modérateur
    Avatar de tourlourou
    Homme Profil pro
    Biologiste ; Progr(amateur)
    Inscrit en
    mars 2005
    Messages
    3 623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Biologiste ; Progr(amateur)

    Informations forums :
    Inscription : mars 2005
    Messages : 3 623
    Points : 10 381
    Points
    10 381
    Billets dans le blog
    6
    Par défaut
    Il est effectivement probable que seul le mix soit interdit.

    Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...
    Delphi 5 Pro - Delphi 10.3.2 Rio Community Edition - CodeTyphon 6.90 sous Windows 10 ; CT 6.40 sous Ubuntu 18.04 (VM)
    . Ignorer la FAQ Delphi et les Cours et Tutoriels Delphi nuit gravement à notre code !

  8. #28
    Modérateur

    Homme Profil pro
    Ingénieur retraité
    Inscrit en
    octobre 2005
    Messages
    2 396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur retraité

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 396
    Points : 3 260
    Points
    3 260
    Par défaut
    Bonjour Tourlourou,

    Il est effectivement probable que seul le mix soit interdit.
    ... si on prend chaque mot à la lettre cela devrait être le cas.
    ... mais une bonne confirmation serait rassurante.

    Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...
    ... ça c'est vite dit car le problème sera de savoir tricoter du code Asm-64bits
    ... demandes donc à René ce qu'il en pense.

    A+.
    N'oubliez pas de consulter les FAQ Delphi et les cours et tutoriels Delphi

  9. #29
    Membre expérimenté Avatar de guillemouze
    Profil pro
    Inscrit en
    novembre 2004
    Messages
    876
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : novembre 2004
    Messages : 876
    Points : 1 448
    Points
    1 448
    Par défaut
    Citation Envoyé par tourlourou Voir le message
    Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...
    A priori, une procedure inline est equivalente a faire un $include ou a recopier le contenu à l'endroit de l'appel -> donc mix impossible ... mais ce n'est qu'une impression

  10. #30
    Membre habitué

    Homme Profil pro
    Inscrit en
    mars 2009
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations forums :
    Inscription : mars 2009
    Messages : 119
    Points : 198
    Points
    198
    Par défaut
    Bonjour les amis

    ... ça c'est vite dit car le problème sera de savoir tricoter du code Asm-64bits
    ... demandes donc à René ce qu'il en pense.
    Moi je veux bien essayer de le faire car l'extension des registres-processeurs 32 => 64 bits ainsi que la mise à disposition de registres supplémentaires peut s'entrevoir aussi naturellement que lorsqu'il s'est agi du passage 16 => 32 bits... Mais comment le faire avec Delphi si l'EDI ne donne pas les outils pour ?

    (Je précise que je ne dispose actuellement ni d'une machine à proc 64 bits et a forciori ni d'un environnement Delphi XE2... Donc je parle un peu à vide...)

  11. #31
    Modérateur

    Homme Profil pro
    Ingénieur retraité
    Inscrit en
    octobre 2005
    Messages
    2 396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur retraité

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 396
    Points : 3 260
    Points
    3 260
    Par défaut
    Bonjour,

    A Rekin85 :
    ... Mais comment le faire avec Delphi si l'EDI ne donne pas les outils pour ?
    ... là je ne comprends pas bien René, je m'explique :
    ... puisque sur le site de J. Colibri il est écrit :
    - seules les procédures ayant l'attribut Asm sont possibles
    je suppose que l'EDI de XE2 donne un minimum de choses pour accepter ces procédures en Asm. Bien entendu une confirmation vaudrait mieux qu'une supposition.

    De toutes façons comme on n'est pas pressés vaut mieux consolider la connaissance du sujet avant de passer aux actes si l'envie nous en prend.

    A+.
    N'oubliez pas de consulter les FAQ Delphi et les cours et tutoriels Delphi

  12. #32
    Membre habitué

    Homme Profil pro
    Inscrit en
    mars 2009
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations forums :
    Inscription : mars 2009
    Messages : 119
    Points : 198
    Points
    198
    Par défaut
    Salut Gilbert

    Alors on continue à parler dans le vide ou la supposition... Tant qu'on ne disposera pas du gros bébé francisé après avoir jeté nos tacots en 32 bits en déchetterie, on risque de se faire de fausses idées. Voici ce que j'ai lu sur le site de J. Colibri :
    inclusion de blocs assembleur:
    • il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal
      seules les procédures ayant l'attribut Asm sont possibles
    • la pile doit être alignée sur un multiple de 16 octets au début de chaque instruction
    • le stockage temporaire doit utiliser des locales
    • il n'est pas permis de modifier le pointeur de pile RSP
    • il faut utiliser la convention d'appel unique; les 4 premiers paramètres sont dans les registres RCXn RDX (ou XMM0-XMM3)
    Bon, l'important est donc que le bloc ASM...END dans du Pascal est maintenant interdit par le compilateur ? Il n'est permis que de bâtir du pur ASM en procedure ? Cela voudrait dire qu'on peut s'éclater avec de l'ASM sur du registre 64 bits (Wah ! le rêve ! ) quand même ?

    Pour le reste il fallait s'y attendre... Plus dur : convention d'appel unique. Quid du stdCall pour établir les dll ?

    Bon tu vois Gilbert, du positif à l'horizon... mais j'ai aussi relevé cette assertion qui dit bien ce qu'elle veut dire :
    Et en général, il convient peut être de profiter de ce passage pour remplacer certaines "optimisation assembleur" par un refactoring en Pascal qui pourrait bien en finale s'avérer plus efficace
    Bin oui, si Delphi compile en 64 pourquoi se casser le tronc à tricoter de l'ASM ? Note toutefois que nos types GInt et GCent ne seront sans doute jamais inclus dans Delphi et que l'aventure, si elle continue retera dans de l'ASM bien réflèchi...

  13. #33
    Modérateur

    Homme Profil pro
    Ingénieur retraité
    Inscrit en
    octobre 2005
    Messages
    2 396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur retraité

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 396
    Points : 3 260
    Points
    3 260
    Par défaut
    Re-Salut René,

    Cela voudrait dire qu'on peut s'éclater avec de l'ASM sur du registre 64 bits (Wah ! le rêve ! )
    ... bonne nouvelle : je vois que ça te met l'eau à la bouche.

    Et en général, il convient peut être de profiter de ce passage pour remplacer certaines "optimisation assembleur" par un refactoring en Pascal qui pourrait bien en finale s'avérer plus efficace.
    ... tu nous vois re-convertir les Gint et les GCent en Pascal ???

    Note toutefois que nos types GInt et GCent ne seront sans doute jamais inclus dans Delphi
    ... je note ... mais mais même dans mes rêves cela ne m'était jamais venu à l'esprit et de toutes façons comme on peut ajouter les Units sous Delphi c'est une autre façon de les inclure.

    En attendant comme on ne dispose pour l'instant, ni d'XE2 ni de processeur 64 bits, ça nous laisse le temps de cogiter sereinement le sujet.

    A+.
    N'oubliez pas de consulter les FAQ Delphi et les cours et tutoriels Delphi

  14. #34
    Modérateur
    Avatar de tourlourou
    Homme Profil pro
    Biologiste ; Progr(amateur)
    Inscrit en
    mars 2005
    Messages
    3 623
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Biologiste ; Progr(amateur)

    Informations forums :
    Inscription : mars 2005
    Messages : 3 623
    Points : 10 381
    Points
    10 381
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Rekin85
    Note toutefois que nos types GInt et GCent ne seront sans doute jamais inclus dans Delphi
    Cela serait peut être plus facilement réalisable dans Lazarus ?

    Citation Envoyé par guillemouze
    A priori, une procedure inline est equivalente a faire un $include ou a recopier le contenu à l'endroit de l'appel -> donc mix impossible
    Un peu, mais en fait :
    http://laurent-dardenne.developpez.c...ution/Langage/
    Donc impossible en D2005, et sûrement en 64 bits ! Je me suis emballé...

    En attendant, bonjour à tous et bon code !
    Delphi 5 Pro - Delphi 10.3.2 Rio Community Edition - CodeTyphon 6.90 sous Windows 10 ; CT 6.40 sous Ubuntu 18.04 (VM)
    . Ignorer la FAQ Delphi et les Cours et Tutoriels Delphi nuit gravement à notre code !

  15. #35
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2005
    Messages
    261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 261
    Points : 658
    Points
    658
    Par défaut
    Citation Envoyé par Rekin85 Voir le message
    Pour le reste il fallait s'y attendre... Plus dur : convention d'appel unique. Quid du stdCall pour établir les dll ?
    Les conventions d'appel ont été complètement revues avec le passage en x64. Notamment pour profiter des nouveaux registres (En plus de ce qu'on avait déjà qui se sont étendus eax -> rax, ebx -> rbx... on a par exemple r8, r9, r10, r11, r12, r13, r14, r15 en plus en x64). Ces nouveaux registres sont paraît il bien pratique : qui n'a jamais maudit le peu de registres dispos en x86 obligeant très souvent à mettre des variables locales dans la pile.

    Microsoft est parti sur une convention d'appel unique. Visiblement, Embarcadero s'est aligné dessus (J'espère bien ! )

    Mais il semble que sous unix, une autre convention ait été adoptée. Pas de chance, ça va pas aider à la portabilité tout ça.

  16. #36
    Membre confirmé
    Homme Profil pro
    Santé
    Inscrit en
    septembre 2010
    Messages
    290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Santé
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2010
    Messages : 290
    Points : 534
    Points
    534
    Par défaut
    Salut,

    En matière de performances, dans un environnement 32 bits, le type Integer est le plus adapté.
    Dans un environnement 64 bits, je suppose que le type Int64 jouera l'ancien rôle de l'Integer (puisque Integer restera en 32 bits).

    En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
    - Rien ?
    - Passer en Int64 ?
    - Exploiter le fait qu'il y a 2 Integers dans un Int64 ?

    Corollaire :
    Les applications graphiques basées sur des pixels au format pf32bit risquent-elles d'en pâtir ou,
    au contraire, de pouvoir en tirer parti en traitant 2 pixels en même temps par exemple ?

    Question subsidiaire :
    Je viens d'acheter un bouquin pour (enfin!) m'initier à l'ASM (en 32 bits).
    Me conseillez-vous de me lancer ou est-il urgent d'attendre ?

    Merci d'éclairer mon amateurisme.

  17. #37
    Membre émérite
    Avatar de Thierry Laborde
    Homme Profil pro
    N/A
    Inscrit en
    avril 2002
    Messages
    1 387
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : N/A

    Informations forums :
    Inscription : avril 2002
    Messages : 1 387
    Points : 2 518
    Points
    2 518
    Par défaut
    Bonjour à tous,

    je vois que l'arrivée du 64bits passionne.

    Citation Envoyé par Caribensila Voir le message
    En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
    - Rien ?
    - Passer en Int64 ?
    - Exploiter le fait qu'il y a 2 Integers dans un Int64 ?
    Allez quelques infos :

    • Le type integer reste 32 bits
    • Le type int64 reste 64 bits
    • Arrivée d'un nouveau type NativeInt qui sera 32 bits ou 64 Bits selon que l'on compile pour Win32 ou Win64.


    Voili, voila.

  18. #38
    Membre expérimenté Avatar de guillemouze
    Profil pro
    Inscrit en
    novembre 2004
    Messages
    876
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : novembre 2004
    Messages : 876
    Points : 1 448
    Points
    1 448
    Par défaut
    Citation Envoyé par Caribensila Voir le message
    En matière de performances, dans un environnement 32 bits, le type Integer est le plus adapté.
    Dans un environnement 64 bits, je suppose que le type Int64 jouera l'ancien rôle de l'Integer (puisque Integer restera en 32 bits).

    En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
    - Rien ?
    - Passer en Int64 ?
    - Exploiter le fait qu'il y a 2 Integers dans un Int64 ?
    NativeInt qui s'adaptera en fonction de si tu compiles en 32 ou 64.

    Citation Envoyé par Caribensila Voir le message
    Corollaire :
    Les applications graphiques basées sur des pixels au format pf32bit risquent-elles d'en pâtir ou,
    au contraire, de pouvoir en tirer parti en traitant 2 pixels en même temps par exemple ?
    ce n'est que mon pressentiment (qui est loin d’être celui d'un éclairé sur le sujet), mais je penses que ca va pas changer grand chose. On utilisera que 32 des 64 bits dispo pour les opération. Enfin ca dépend des operations; ca sera a priori le meme comportement que un pf16bit dans un exe 32bits.

  19. #39
    Modérateur

    Homme Profil pro
    Ingénieur retraité
    Inscrit en
    octobre 2005
    Messages
    2 396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur retraité

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 396
    Points : 3 260
    Points
    3 260
    Par défaut
    Re-bonjour,

    Guillemouze : On utilisera que 32 des 64 bits dispo pour les opération.
    ... on peut quand-même espérer qu'avec du 64 bits on disposera d'un pf64bit offrant de nouvelles possibilités !!!

    A+.
    N'oubliez pas de consulter les FAQ Delphi et les cours et tutoriels Delphi

  20. #40
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2005
    Messages
    261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 261
    Points : 658
    Points
    658
    Par défaut
    Salut Caribensila !

    Je vais essayer de compléter un peu ces réponses.

    Citation Envoyé par Caribensila Voir le message
    En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
    - Rien ?
    - Passer en Int64 ?
    - Exploiter le fait qu'il y a 2 Integers dans un Int64 ?
    Déjà, ce qu'il faut savoir, c'est que le 64 bits n'apporte généralement pas grand chose si ce n'est rien au niveau des performances. D'un côté certains "travaux" souvent utilisés sur la mémoire (Ajoutées par le compilateur) peuvent être plus rapides tel que CopyMemory/Move, ZeroMemory (Encore que ça dépend beaucoup de l'implémentation)... De l'autre, le code est beaucoup plus gros en mémoire (Les instructions ont des opérandes sur 64 bits qui prenne de la place), et les données aussi ce qui pose problème pour tout ce qui est cache processeur. Il y a plus de transferts des caches vers la RAM ce qui est préjudiciable.

    Par exemple dans le code suivant (Du moins la partie gestion de i et j en mémoire, l'addition...) tourne très probablement à la même vitesse sur un processeur 64 bit, qu'il soit compilé vers une appli 32 ou 64. Et passer par du Int64 pour la compilation vers 64 ne changerait rien non plus aux perfs.

    Code delphi : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    var
      i, j: Integer;
    begin
      i:= Random(200);
      j:= Random(200);
      ShowMessage(IntToStr(i + j));
    end;

    Par contre, utiliser un Int64 est désastreux pour les perfs quand on compile vers du 32 !
    Et c'est là le principal avantage de compiler vers du 64 bits. Le processeur devient capable de travailler efficacement sur des entiers non signés supérieurs à 4294967295.

    Avant, si l'application devait traiter des entiers supérieurs à 4294967295, soit on passait par un Int64 plus lent (Mais aussi limité), soit par une librairie dédiée au calcul sur grands entiers (Tel que gmp ou peut être NewGInt et NewGCent évoquées sur ce thread), encore plus lente.
    Maintenant, on n'aura plus ce problème de lenteur avec les Int64, et on aura moins tendance à utiliser une "lente" librairie pour les grands entiers. 4 milliards et des brouettes, c'est un chiffre plus facile à dépasser que 18446744073709551615.

    Les applications monétaires actuelles en Delphi utilisent probablement le type Currency pour la plupart. C'est en gros un Int64 auquel on met virtuellement une virgule au niveau du 4ème chiffre. Compilé en 32 bit, ce type est strictement équivalent à un un Int64, donc lent. Compilé en 64 bit, le type Currency devient aussi rapide que ne l'était le type Integer.

    Le processeur devient aussi un peu plus à l'aise avec le type Double (flottant 64 bit). Pas dans les calculs, vu que ça reste le boulot de la FPU qui les gérait déjà, mais dans certains déplacements de Double (Mais bon ça doit rester vraiment marginal. Et dans le domaine du jeux vidéo, passer du Single au Double n'est pas forcément intéressant non plus pour les perfs niveau carte graphique).

    Bref, porter une appli 32 bits en 64 bits n'apporte généralement pas grand chose, et souvent, ceux qui le font conservent pas mal d'entiers en 32 bits ! Faut par exemple savoir que sous Visual C++, si on cible x64 le type C int est sur 32 bits (Relativement normal, de même avec pas mal de compilo sous unix), mais le type long est aussi en 32 bits !
    Mais c'est sûr que comme dit plus, réécrire certaines procédures classiques avec du NativeInt doit parfois être pertinent.

    Citation Envoyé par Caribensila Voir le message
    Je viens d'acheter un bouquin pour (enfin!) m'initier à l'ASM (en 32 bits).
    Me conseillez-vous de me lancer ou est-il urgent d'attendre ?
    Franchement, je te conseillerais de te lancer dans le 32 bits, vu que comme dit partout, le x64 est une "extension" du x86 (Donc facile d'apprendre le x64 après le x86). Tu peux même commencer par du 16 bits si tu veux ! C'est d'ailleurs à peine plus facile pour les humains car les opérandes sont moins grandes.

    En tout cas l'IDE de Delphi (Tout du moins les versions 6 et 7) est vraiment bien pour apprendre l'assembleur, peut être le meilleur produit à ce niveau.

Discussions similaires

  1. Prise en main delphi XE2
    Par SISKODS9 dans le forum EDI
    Réponses: 6
    Dernier message: 10/09/2011, 15h35
  2. Présentation de Delphi 2007 au Luxembourg!
    Par synapsis dans le forum Delphi
    Réponses: 2
    Dernier message: 17/04/2007, 17h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo