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

Delphi Discussion :

Delphi et multi processeur


Sujet :

Delphi

  1. #1
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut Delphi et multi processeur
    Bonjour,

    je fais tourner une application Delphi - Access sur un ordinateur multi processeurs, et je m'apercois que les processeurs ne sont pas pleinement utilisés (20 % chacun).
    Peut-on, depuis Delphi, gérer ces processeurs pour qu'ils soient utilisé plus efficacement?

    Merci pour vos réponses.

  2. #2
    Membre éclairé Avatar de slimjoe
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    647
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Canada

    Informations forums :
    Inscription : Juin 2005
    Messages : 647
    Points : 789
    Points
    789
    Par défaut
    Salut!

    Je ne comprends pas le problème (je suis plutôt naïf de nature ).

    Si les cpu sont utilisés à 20% chacun, qu'est-ce qui n'est pas optimisé ? Quel serait le scénario optimal selon toi ?

    Je ne suis pas expert en la matière, mais je crois que c'est à l'OS de gérer l'utilisation des cpu dont il a la responsabilité. Je sais que si ton appli est multi thread, c'est plus facile pour lui de décider de faire rouler un des thread dans un cpu particulier par exemple.

    Peut-être qu'en fouillant dans la classe TThread on y trouverait une manière de spécifier le cpu à utiliser mais j'en doute...

    -Slimjoe

  3. #3
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    Le probleme c'est que mon traitement tourne pendant 35 heures. Et qu'on s'est aperçu que les processeurs n'étaient utilisé qu'a 20% chacun. Donc peut etre qu'en étant utilisés à 80% le traitement irait plus vite.

    Cela dit je doute que ce soit possible à réaliser.
    Et peut etre que ce sont les temps d'acces à la base (le traitement consiste en un chargement de données dans une base) qui sont longs.

  4. #4
    Membre éclairé Avatar de slimjoe
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    647
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Canada

    Informations forums :
    Inscription : Juin 2005
    Messages : 647
    Points : 789
    Points
    789
    Par défaut
    Salut!

    Est-ce que c'est ton appli qui ne prend que 20% du cpu ou est-ce que c'est la somme de tous les process qui ne prennent que 20% ? En d'autres mots, est-ce que tu vois un autre process ralentir ton appli ? Si c'est le cas tu pourrais peut-être augmenter la priorité du process de ton appli.

    Mais à mon avis, le problème est dans quelque chose d'autre que le travail cpu comme l'accès aux disques ou aux autre ressources. Exemple : fais une appli qui calcule des factoriels à l'infini. Je te garantis que le cpu va taper dans le fond pendant 35 heures!

    -Slimjoe

  5. #5
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    C'est la somme des processus qui prend 20 %.
    Sur chacun des graphique (dans l'onglet performance du gestionnaire des taches) de performance, je vois que chacun des proc est utilisé a 20 %.

    Donc je me demandais si Delphi pouvait demander au proc d'utiliser un peu plus de CPU pour le traitement.

  6. #6
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Bonjour,

    Quel est le taux de l'occupation CPU sur un système mono-processeur ?

    Je pense comme slimjoe que le peu d'utilisation des CPU est lié plus aux accès disque ou réseau, pendant lesquels la(les) CPU est(sont) en attente, qu'à l'aspect multi-processeur.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  7. #7
    Membre émérite
    Avatar de Merlin
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Mars 2002
    Messages
    524
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Mars 2002
    Messages : 524
    Points : 2 883
    Points
    2 883
    Par défaut
    Pour comparer il faudrait savoir combien de % cpu ton appli prend lorsqu'elle est sur un mono processeur de "puissance équivalente" voire même réputé moins rapide.
    De plus tu parles d'accès SGBD. Quelle base ? Certaines versions (toutes?) de Interbase par exemple étaient réputées dix fois plus lentes sous NT avec un biproc.
    As tu testé aussi la base toute seule en déroulant un script de requêtes ?
    As tu profiler ton appli pour savoir combien temps est passé dans quelles routines ?

    Il reste beaucoup de choses à sonder avant de se prononcer, et sans des tests "carrés" tu risques de rester dans le flou... et nous aussi pour t'aider...

  8. #8
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    Citation Envoyé par Merlin
    Pour comparer il faudrait savoir combien de % cpu ton appli prend lorsqu'elle est sur un mono processeur de "puissance équivalente" voire même réputé moins rapide.
    De plus tu parles d'accès SGBD. Quelle base ? Certaines versions (toutes?) de Interbase par exemple étaient réputées dix fois plus lentes sous NT avec un biproc.
    As tu testé aussi la base toute seule en déroulant un script de requêtes ?
    As tu profiler ton appli pour savoir combien temps est passé dans quelles routines ?

    Il reste beaucoup de choses à sonder avant de se prononcer, et sans des tests "carrés" tu risques de rester dans le flou... et nous aussi pour t'aider...
    Je n'ai pas de mono processeur au travail... donc ca va être compliqué. Je pense que le probleme vient de la base (Access). Car plus les fichiers à importer sont gros, plus le temps augmente (de facon exponentielle) donc je pense qu'il s'agit d'un probleme d'index a parcourir qui sont de plus en plus importants , donc ca prend de plus en plus de temps au fur et a mesure que la taille de la base augmente.

  9. #9
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Bonjour,

    mon traitement tourne pendant 35 heures
    ...
    probleme vient de la base (Access).
    Dans ce cas, il faut envisager de travailler entièrement en mémoire, c'est-à-dire charger la base en mémoire au début, effectuer les traitement sans accès SGBD et, à la fin du traitement, écrire les modif sur la base.
    J'imagine assez bien un gain de temps qui réduirait le temps total de traitement à moins de 2H.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  10. #10
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    S'il y a une panne de courant en plein milieu du traitement on perd tout. C'est l'inconvénient de tout mettre en mémoire.
    Je pense donc à deux solutions:
    - dire au PC d'utiliser plus de ressource CPU pour mon application (meme si je doute qu'on gagne bcp de temps)
    - améliorer les temps d'acces a la base (peut etre un nettoyage des index de ma base Access, comme le Analyze d'Oracle)

  11. #11
    Modérateur
    Avatar de Rayek
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2005
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 5 235
    Points : 8 504
    Points
    8 504
    Par défaut
    A mon avis changer de base de données et passer sur un SGBD plus costaud serait mieux, car si tu as 35h de traitement tu dois avec un nombre important de données et donc une base de données fichier comme Access te ralenti plus qu'autres choses.
    Modérateur Delphi

    Le guide du bon forumeur :
    __________
    Rayek World : Youtube Facebook

  12. #12
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    Citation Envoyé par Malatar
    A mon avis changer de base de données et passer sur un SGBD plus costaud serait mieux, car si tu as 35h de traitement tu dois avec un nombre important de données et donc une base de données fichier comme Access te ralenti plus qu'autres choses.
    Cela serait top simple...
    Les contraintes techniques et politiques ne me le permettent pas.

  13. #13
    Membre éclairé Avatar de slimjoe
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    647
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Canada

    Informations forums :
    Inscription : Juin 2005
    Messages : 647
    Points : 789
    Points
    789
    Par défaut
    Citation Envoyé par tomy29
    Je pense donc à deux solutions:
    - dire au PC d'utiliser plus de ressource CPU pour mon application (meme si je doute qu'on gagne bcp de temps)
    - améliorer les temps d'acces a la base (peut etre un nettoyage des index de ma base Access, comme le Analyze d'Oracle)
    Salut!

    1. Tout d'abord, comme je le disais plus haut, je ne suis pas d'avis qu'il s'agisse d'un problème CPU. Je crois tout simplement que le CPU voudrait bien travailler d'avantage mais qu'il ne le peut pas parce qu'il attend après des données stockées dans la BD. Si l'accès aux données (ou au disque, ou à une ressource réseau, disquette 5¼ , etc.) est lourd, quels que soient les efforts que tu mettras à faire travailler davantage le CPU, ils seront vains. Ton objectif ici est de constamment extraire tes données le la DB avec plus de vitesse. Et ici, je rejoins Malatar dans sa suggestion de SGBD plus performant. (Toutefois si ton objectif est absolument d'utiliser plus de CPU j'ai une autre solution: installe des CPU moins performants! Tu vas voir, ils vont travailler au max! )
    2. Avec Access il t'est possible de compacter la DB. Et je suis aussi pas mal certain qu'en fouillant dans la FAQ tu trouveras aussi du code Delphi qui te permettra de compacter la DB via ton appli.
    3. Dépendemment de ton niveau de stress acceptable quant aux la pertes de données éventuelles, rien ne t'empêche de travailler en mémoire et de sauvegarder tes résultats dans un intervalle régulier (15 minutes par exemple). Au pire, tu perds 15 minutes de travail. La routine de sauvegarde pourrait aussi être codée dans un thread séparé.
    4. Enfin, si le goulot est l'accès aux données, peut-être pourrais-tu envisager de regarder si la modélisation de ta DB est optimisée. Souvent, l'ajout d'un ou deux index et la normalisation/dénormalisation règlent beaucoup de problèmes reliés à la vitesse.


    Bon dev!
    -Slimjoe

  14. #14
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    Citation Envoyé par slimjoe
    Salut!

    1. Tout d'abord, comme je le disais plus haut, je ne suis pas d'avis qu'il s'agisse d'un problème CPU. Je crois tout simplement que le CPU voudrait bien travailler d'avantage mais qu'il ne le peut pas parce qu'il attend après des données stockées dans la BD. Si l'accès aux données (ou au disque, ou à une ressource réseau, disquette 5¼ , etc.) est lourd, quels que soient les efforts que tu mettras à faire travailler davantage le CPU, ils seront vains. Ton objectif ici est de constamment extraire tes données le la DB avec plus de vitesse. Et ici, je rejoins Malatar dans sa suggestion de SGBD plus performant. (Toutefois si ton objectif est absolument d'utiliser plus de CPU j'ai une autre solution: installe des CPU moins performants! Tu vas voir, ils vont travailler au max! )
    2. Avec Access il t'est possible de compacter la DB. Et je suis aussi pas mal certain qu'en fouillant dans la FAQ tu trouveras aussi du code Delphi qui te permettra de compacter la DB via ton appli.
    3. Dépendemment de ton niveau de stress acceptable quant aux la pertes de données éventuelles, rien ne t'empêche de travailler en mémoire et de sauvegarder tes résultats dans un intervalle régulier (15 minutes par exemple). Au pire, tu perds 15 minutes de travail. La routine de sauvegarde pourrait aussi être codée dans un thread séparé.
    4. Enfin, si le goulot est l'accès aux données, peut-être pourrais-tu envisager de regarder si la modélisation de ta DB est optimisée. Souvent, l'ajout d'un ou deux index et la normalisation/dénormalisation règlent beaucoup de problèmes reliés à la vitesse.


    Bon dev!
    Merci pour ta réponse.
    D'accord avec toi sur tout. La seule solution envisageable serait de tout mettre en mémoire et de tout balancer d'un coup car je pense que le probleme vient surtout de l'insertion des enregistrements dans une base déjà surchargée.En tout cas, il faut surement revoir la stratégie d'import qui n'a certe pas dû être pensée pour des imports importants. Je récupère juste le bébé.

    Et puis, surement changer de SGBD, mais que veux-tu ils ont estimé que Access serait suffisant... Faut pourtant pas être une star pour s'apercevoir que non!!!

    Merci pour vos lumières.

  15. #15
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    488
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 488
    Points : 397
    Points
    397
    Par défaut
    Je rejoins l'analyse de slimjoe & cie : Si les processeurs ne tournent qu'à 20% c'est qu'il y a quelque part un goulot d'étranglement qui ne leur permet pas de travailler plus vite. Dans ce cas c'est probablement les accès disques qui sont la source du problème. Puisque tu ne veux pas travailler en mémoire il faudrait tester avec un système disque plus rapide :
    • Disque plus performant
    • Ensemble de disques en RAID5 (améliore grandement le débit)
    • Disque à mémoire flash (améliore grandement les accès)
    • Ensemble de disques à mémoire flash en RAID5 (améliore les accès et le débit)

  16. #16
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    Citation Envoyé par sovitec
    Je rejoins l'analyse de slimjoe & cie : Si les processeurs ne tournent qu'à 20% c'est qu'il y a quelque part un goulot d'étranglement qui ne leur permet pas de travailler plus vite. Dans ce cas c'est probablement les accès disques qui sont la source du problème. Puisque tu ne veux pas travailler en mémoire il faudrait tester avec un système disque plus rapide :
    • Disque plus performant
    • Ensemble de disques en RAID5 (améliore grandement le débit)
    • Disque à mémoire flash (améliore grandement les accès)
    • Ensemble de disques à mémoire flash en RAID5 (améliore les accès et le débit)
    Merci pour ces infos.

    J'ai remarqué que sur un processeur simple, le CPU est utilisé à 100%. Sur un bi-processeur il est utilisé à 50 % (quadri processeur : 25 %). Est il possible de forcer le bi processeur à travailler à 100%. Le temps de traitement varie beaucoup entre un processeur de 1Gz et un processeur de 2Gz, donc je pense que le processeur a également son importance dans la durée du traitement.

  17. #17
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    488
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 488
    Points : 397
    Points
    397
    Par défaut
    Citation Envoyé par tomy29
    Merci pour ces infos.

    J'ai remarqué que sur un processeur simple, le CPU est utilisé à 100%. Sur un bi-processeur il est utilisé à 50 % (quadri processeur : 25 %). Est il possible de forcer le bi processeur à travailler à 100%. Le temps de traitement varie beaucoup entre un processeur de 1Gz et un processeur de 2Gz, donc je pense que le processeur a également son importance dans la durée du traitement.
    Dans une chaine de traitement c'est toujours l'élément le plus lent qui détermine la vitesse globale du système. Je suppose, si j'ai bien compris, que jusqu'au processeur à 2GHz c'est le processeur l'élément faible de la chaine, ensuite (multiproc) c'est un autre élément de la chaine qui prend le role de maillon faible.

  18. #18
    Membre habitué

    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 639
    Points : 167
    Points
    167
    Par défaut
    Citation Envoyé par sovitec
    Dans une chaine de traitement c'est toujours l'élément le plus lent qui détermine la vitesse globale du système. Je suppose, si j'ai bien compris, que jusqu'au processeur à 2GHz c'est le processeur l'élément faible de la chaine, ensuite (multiproc) c'est un autre élément de la chaine qui prend le role de maillon faible.
    En mono processeur, les temps de traitement diminuent a mesure que la puissance du processeur augmente. Je n'ai pas pu allé au dessus de 2 ghz, je suppose que le traitement diminuerait encore plus si j'etais à 3 ghz, 4 ghz...
    Donc je suppose (peut etre naïvement) qu'avec un quadri processeur (chacun 2 ghz) utilisé à 100%, cela accélérerait encore plus mon traitement... non?

    Pour répondre à ta question, je ne peux pas dire qu'en multi proc, ce soit un autre élément qui soit le maillon faible, ca je ne sais pas si le multi proc alloue 25% (pour un quadri) de cpu a mon traitement parce qu'il ne peut pas faire plus, ou si c'est parce qu'il est mal géré.

  19. #19
    Expert confirmé
    Avatar de Sub0
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2002
    Messages
    3 573
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2002
    Messages : 3 573
    Points : 4 219
    Points
    4 219
    Par défaut
    Je ne suis pas un spécialiste en la matière, alors je vais peut-être dire une bétise, mais selon moi, le multiproc (ou multi-core) sert à partager les ressources (multithread) et non pas doubler ou quadrupler la puissance de calcul...
    De retour parmis vous après 10 ans!!

  20. #20
    Modérateur
    Avatar de Rayek
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2005
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 5 235
    Points : 8 504
    Points
    8 504
    Par défaut
    Comme l'on dit certain, si tes processeurs ne sont pas utilisés à 100% c'est qu'il y a un endroit de ton programme qui bloque/ralenti ton traitement.
    Donc le problème peut venir :
    • Des données sources de la mise à jour
    • De la destination des données de mise à jour
    • Du code qui est pas correct, qui pourrait être simplifié et optimisé


    Pour ma part, base de données ACCESS trop grosse = ralentissement
    Et plus elle va grossir et plus ca va encore ralentir, jusqu'à sa limite de taille de 2go.

    Mais j'aimerai quand même savoir ce que tu fais pour que le traitement dure 35h.
    Modérateur Delphi

    Le guide du bon forumeur :
    __________
    Rayek World : Youtube Facebook

Discussions similaires

  1. Réponses: 9
    Dernier message: 27/04/2011, 15h54
  2. Simulateur d'une architecture multi-processeur
    Par moustafa kurdi dans le forum Administration système
    Réponses: 1
    Dernier message: 30/01/2008, 08h37
  3. Réponses: 4
    Dernier message: 04/12/2007, 16h28
  4. Requête bloquée sur un poste multi processeur
    Par cfeltz dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 26/06/2007, 16h14
  5. [SYBASE]multi-processeur
    Par 6rose dans le forum Sybase
    Réponses: 7
    Dernier message: 05/07/2003, 22h01

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