Discussion :

[Transgarp]

Tout est dans le titre.

Pour un programme test donné, je l'ai fait tourner sur plusieurs ordinateurs allant du IBM-PC8088 4Mhz au Bi-Xeon 3.2Ghz FSB800

Ce programme est installé sur une disquette 3.5" et démarre l'ordi à tester en mode plein DOS, alors ne vous préoccuppez pas du OS, si j'ai Win3.0 ou Vista.

J'ai noté une progression proportionnelle de la vitesse d'exécution entre le IBM PC8088 au P3-1000Mhz, mais rien au dessus.

Pire, la vitesse reste presque la même que le P3 que j'utilise P4 ou Bi-Xeon multi-core

Il y a surement quelque chose que je n'ai pas compris, éclairez moi

[diden138]

ben l'a j'avoue que je reste perplexe.
que fais ton programme exactement j'ai pas compris ?
Cordialement @+

[Transgarp]

Ce programme est simplement un QuickSort d'une matrice de chaine de caractère en ordre descendant que le programme exécute en donnant le nombre de secondes une fois que le QuickSort a terminé.

Les temps selon mes anciens ordis:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
IBM   PC8088-4    4836.00 sec
IBM   XT286-6     1209.00 sec
AMD   386DX-40    171.02 sec
INTEL 486DX-50    91.27 sec
AMD   486DX2-80   64.69 sec
AMD   486DX4-100  54.05 sec
INTEL P1-120      25.03 sec
INTEL P2-350      12.23 sec
INTEL P3-550      9.97 sec
INTEL P3-800      6.78 sec
AMD   Athlon-800  5.46 sec
INTEL P3DUAL-1000 5.20 sec

Et aucun de mes nouveaux ordis ( P4, Xeon, etc...) n'arrivent à exécuter ce programme compilé BP7 en bas de 5.00 secondes en mode plein DOS

[diden138]

tu peux poser ton prog ici pour qu'on le test c'est bizarre ça mais j'avoue que ça m'intéresse
Cordialement @+

[Transgarp]

Mouais, je ne sais pas trop.

A chaque fois que je pose du code ici, on me chicane pour le manque de documentation et mon code pas informatically correct

De toute facon, ce programme a besoin de mes trois principaux Unit personnel commun à la majorité de mes programmes, GRP_FONC.PAS, GRP_GRAP.PAS, GRP_PROC.PAS

En plus de ces six fichiers .MAK pour rendre indépendant les drivers graphique, ATT.MAK, CGA.MAK, EGAVGA.MAK, HERC.MAK, IBM8514.MAK, PC3270.MAK

Finalement la matrice source n'est pas descendante, mais Ascendant 1 et petit a la fin.

Le Unit GRP_GRAP est en majorité du code assembleur.

L'exécutable System Information Gariepy http://transgarp.dyndns.org/bp7/SIG.EXE

Ca fonctionne direct de votre navigateur Internet

J'ai placé le tout à cette adresse http://transgarp.dyndns.org/bp7/

Le lien est ouvert en exploration de répertoire et l'exécutable SIG.EXE prêt à utiliser sur tous les ordis de la planète.

[diden138]

bonsoir,
avec ma config 4sec9
Cordialement @+

[Transgarp]

Ah bon, 4sec9,

Et pourtant ton P4 ressemble au miens

Néanmoins j'arrive à 5.2 sec avec un P3-1Ghz

Vu que ton P4 possède tout comme le miens un processeur 3.2Ghz on serait porté à penser que ca roule 3 fois plus vite qu'un P3-1Ghz, mais en réalité ce n'est que 30% plus rapide.

Là-dessus je m'interroge.

[droggo]

Wai,

Ah bon, 4sec9,

Et pourtant ton P4 ressemble au miens

Néanmoins j'arrive à 5.2 sec avec un P3-1Ghz

Vu que ton P4 possède tout comme le miens un processeur 3.2Ghz on serait porté à penser que ca roule 3 fois plus vite qu'un P3-1Ghz, mais en réalité ce n'est que 30% plus rapide.

Là-dessus je m'interroge.

Tout à fait possible, les P4 ayant marqué une nette régression sur la qualité du CPU, côté vitesse : de nombreuses instructions de base prennent plus de cycles horloges que sur les P3 et processeurs antérieurs.

Je me suis toujours demandé pourquoi Intel avait sorti ce processeur avec un coeur de calcul provenant clairement d'une génération ancienne. Peut-être par facilité pour permettre le développement de processeurs affichant des fréquences élevées, ce qui était presque le seul critère pris en compte par les clients.

Bref, le P4 est catastrophique (à titre d'exemple, pour une application gourmande en calcul, mais n'utilisant pas la FPU, le calcul sur un Athlon XP 2600+, de fréquence réelle à peine supérieure à 1900 MHz,est environ 2 fois plus rapide que sur un P4 3000 MHz).

[Transgarp]

Dans le cas du bi-Xeon 3.2Ghz Nocona, aucun gain pour mes applications Pascal comparé à mon P4 3.2Ghz mono core, dual thread

J'en suis à penser à retourner sur mon vieil P3-1Ghz mono core, mono thread pour mes exécutables Pascal, qui dépasse en performance tout ce que j'ai en P4 et bi-Xeon

Par contre, le bi-Xeon est 10 fois plus rapide que le P3 pour compresser un fichier natif .avi en divx

[M.Dlb]

As-tu tracé une courbe de ces valeurs ? Pour moi c'est "scalable", à vu de nez. Pas de surprise

[Transgarp]

Une courbe non, mais en exécutant SIG.EXE on voit le graphique de tout mes vieux ordis.

Ah moins que je vous convertisse le programme pour obtenir une courbe.

Je peu ajouter aussi, qu'aucun des ordis multi-cpu, multi-core ou multi-thread pousse au delà de 25% de la charge des CPU.

[diden138]

aujourd'hui j'ai essayé votre programme sur mon pc (la config est cité dans ma signature) j'ai eu une amélioration du temps d'exécution (320) donc chez moi aucun problème.

le P4 est catastrophique (à titre d'exemple, pour une application gourmande en calcul, mais n'utilisant pas la FPU, le calcul sur un Athlon XP 2600+, de fréquence réelle à peine supérieure à 1900 MHz,est environ 2 fois plus rapide que sur un P4 3000 MHz).

j'en doute ...
Cordialement @+

[Transgarp]

Autre point à mentionner.

La charge totale des CPU ne dépasse jamais ( 100% / nombre de thread ou de core de l'ordi )

Je viens de tester sur mon P4 mono-core, dual-thread et le CPU pousse maximum 50% sous un exécutable Pascal

Sur mes bi-Xeon dual-cpu, dual-thread, qui totalise 4 thread les CPU pousse un maximum de 25%

En extrapolant, sur un bi-Xeon quad-core qui totalise 8 thread, la charge des CPU ne dépasserait pas 12.5%

Sur mes vieux ordis mono-cpu, mono-thread; la charge du CPU atteint tout le temps 100% sous un programme Pascal.

[droggo]

Fie,

j'en doute ...

Tu as le droit, c'est pourtant réel.

Et c'est simple à vérifier : va chez Intel prendre les docs des différents processeurs, et vérifie le nombre de cycles horloges pour chaque instruction.

[droggo]

Hie,

Autre point à mentionner.

La charge totale des CPU ne dépasse jamais ( 100% / nombre de thread ou de core de l'ordi )

Je viens de tester sur mon P4 mono-core, dual-thread et le CPU pousse maximum 50% sous un exécutable Pascal

Sur mes bi-Xeon dual-cpu, dual-thread, qui totalise 4 thread les CPU pousse un maximum de 25%

En extrapolant, sur un bi-Xeon quad-core qui totalise 8 thread, la charge des CPU ne dépasserait pas 12.5%

Sur mes vieux ordis mono-cpu, mono-thread; la charge du CPU atteint tout le temps 100% sous un programme Pascal.

Sous MSDOS, il faut oublier les multi-core, qui ne sont pas du tout pris en compte (il ne faut pas oublier que cet OS date déjà pas mal, et à l'époque, personne n'envisageait d'avoir plusieurs coeurs sur une seule puce).

[Transgarp]

Je sais bien que ca fait mal à ceux qui préfère Intel à AMD, donc j'en fais partie, mais en général pour la même vitesse de processeur une application compilée Pascal tournera toujours plus vite sur AMD.

J'ai eu ces 2 ordis 800Mhz, l'un Intel et l'autre AMD

Code :

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

1
2
3
 
INTEL P3-800      6.78 sec
AMD   Athlon-800  5.46 sec

Je m'amuse à penser à cette analogie du monde de la moto, dans le cas d'un exécutable Pascal, vaut mieux un gros monocylindre qu'un multicylindre pour la même grosseur de piston de 3.2Ghz

[diden138]

chez moi dans mon PC P4 intel 3.2 GHZ ton prog s'exécute en 3.29sec si tu veux une capture je t'en ferais une.
je doute de ce qui dit droggo parce que la compression d'un fichier (qui est essentiellement du calcul) prend plus de temps sur un P3 que sur un P4 voila et c'est tout à fait normal sinon j'aurais garder mon ancien PC.
Cordialement @+

[Transgarp]

Diden138 tu m'intrigue vu que je n'ai obtenu que 6 sec en mode Full DOS (démarrage du DOS sur disquette) sur mon P4 Intel 3.2Ghz FSB800

Le meilleur temps que j'ai obtenu est de 5.2 sec sur mon P3 Dual-CPU 1Ghz aussi en mode DOS

Tu démarre SIG.EXE sous quel OS ?

Le patch du CRT Unit peux t il en être la cause ?

J'utilise BP7PATCH.ZIP de Fred VonBerg

[diden138]

voila la capture ici
Cordialement @

[droggo]

Fie,

chez moi dans mon PC P4 intel 3.2 GHZ ton prog s'exécute en 3.29sec si tu veux une capture je t'en ferais une.
je doute de ce qui dit droggo parce que la compression d'un fichier (qui est essentiellement du calcul) prend plus de temps sur un P3 que sur un P4 voila et c'est tout à fait normal sinon j'aurais garder mon ancien PC.
Cordialement @+

Là, ça dépend du logiciel utilisé, entre autres, s'il sait utiliser les SSE de la génération maximale intégrée au processeur, et le temps dépend également d'autres facteurs (par exemple : fréquence mémoire, vitesse des disques, éventuelle occupation du CPU par d'autres programmes...).

Et comme déjà dit, va chez Intel et AMD, prends les docs, et vérifie le nombre de cycle horloges pour les instructions.

Mon programme est une application qui utilise une librairie de calcul multi-précision, écrite pour l'essentiel en assembleur, fortement optimisée (pas totalement cependant, car il est très difficile de le faire avec les processeurs modernes, avec tous les paramètres à prendre en compte).
Pour ceux qui connaissent, cette librairie donne très sensiblement les mêmes temps de calcul que la librairie bien connue GMP.