Discussion :

[Transgarp]

Dans mon dernier sujet, sur la vitesse d'exécution d'une application Pascal, je me suis rendu compte que la charge du ou des cpu = (100% / nombre de thread ou core total de la carte mère )

Alors un exécutable Pascal poussera au maximum la charge totale du ou des cpu à :
- 100% sur un P3 mono-core, mono-thread
- 50% sur un P4 mono-core, dual-thread
- 25% sur bi-Xeon mono-core, dual-thread
- 12.5% sur bi-Xeon quad-core

Et impossible de pousser à plus de 25% la charge totale des cpu sous une application Pascal sur le bi-Xeon dual-thread

Par contre j'ai fait le test d'exécuter 4 applications Pascal sous le bi-Xeon dual-thread et ainsi atteindre 100% de la charge totale des cpu

J'ai fait rouler, mon programme de comparaison des formes de tri SORT_PTR.EXE sous 4 noms de programmes SORT1.EXE, SORT2.EXE, SORT3.EXE, SORT4.EXE qui eux même envoyaient le résultat sur des noms différents de fichiers SORT1.DOC, SORT2.DOC, SORT3.DOC, SORT4.DOC

Comme résultat du ExchangeSort qui donnait environ 6 secondes sur le programme SORT1.EXE s'exécutant seul et toujours 6 secondes sur les 4 programmes SORT s'exécutant en même temps.

Alors si on ne gagne rien en gain de vitesse sur une application tournant sur des P4 multi-core comparé à un P4 mono-core pour la même vitesse de CPU, on y gagne beaucoup plus du fait qu'on peu faire tourner autant d'applications qu'il y a de core ou de thread et ainsi faire travailler l'ordi à 100% de sa charge totale.

Là je regarde la possibilité de programmation parallèle entre plusieurs applications Pascal tournant en même temps

[Mat.M]

Quelle version de TP ? Si c'est sous Dos .exe cible ms-dos tu ne pourras jamais dépasser les limites,à moins d'utiliser un dos Extender mais là dessus j'ai des doutes
Pour exploiter le multithreading, il faut obligatoirement passer par les threads systèmes de Windows et que le compilateur qui génére le code soit optimisé pour.
Si tu veux des performances qui utilisent pleinement les performances des nouveaux types de CPU il faut prendre les bibliothèques de code d'Intel genre VTune mais pas disponibles pour TP


RE: un programme conçu pour ms-dos va être exécuter dans une boite virtuelle ms-dos donc tu ne pourras pas dépasser les limites c'est peine perdu tu risques de perdre ton temps inutilement ou alors tu prends Delphi...

Je refais un copier coller
Tu peux avoir des différences entre un P3 et P4 de performances mais jamais tu ne pourras exploiter l'hyperthreading, multicore avec un programme conçu pour tourner sous ms-dos

[Mat.M]

Alors si on ne gagne rien en gain de vitesse sur une application tournant sur des P4 multi-core comparé à un P4 mono-core pour la même vitesse de CPU, on y gagne beaucoup plus du fait qu'on peu faire tourner autant d'applications qu'il y a de core ou de thread et ainsi faire travailler l'ordi à 100% de sa charge totale.

Là je regarde la possibilité de programmation parallèle entre plusieurs applications Pascal tournant en même temps

Mais tu l'écris toi-même tu ne gagneras rien !
Un programme écrit avec Turbo Pascal est prévu pour ms-dos monotache et mode réel. ( à moins d'avoir la version Turbo Pascal pour Windows qui a existé )
Connais-tu la différence entre mode réel et mode protégé du x86 ?
TP c'est pour le mode réel préhistorique..
Et puis si tu veux faire tourner plusieurs exe comment vas-tu faire pour faire communiquer les processus entre eux ?

[Transgarp]

Je roule BP7 version license sous XP-Pro; le dernier logiciel que j'ai acheté de Borland en 1992.

Finalement, le seul lien que je vois présentement entre 2 programmes Pascal roulant en même temps; est d'utiliser des données envoyées à des fichiers communs. Et là dessus il faut faire attention que le programme2 écrit dans le fichier data quand le programme1 ne l'a pas ouvert ou vice-versa, sinon il y a risque de corruption des données.

Quand je roulais avec Win9x en descendant, je n'osais jamais rouler plusieurs exécutables Pascal en même temps. De toute facon, ces vieux OS ne prenaient pas en compte le fait que je roulais bi-cpu, dual-thread. Maintenant je peu le faire sans problème en autant que ce soit des programmes différents n'utilisant pas des fichiers data communs.

J'ai fais plusieurs tests hier de 4 exécutables Pascal différents roulant en même temps et aucune corruption de donnée ou baisse de performance.

Bien sur il y a baisse de performance si j'ajoute un 5e exécutable Pascal, car je n'ai que 4 thread avec le Xeon Nocona

Il se produit la même perte de performance si j'ajoute une 3e compression DivX, quand il y en a déjà 2 qui roule.

Finalement je peu compresser un DivX en même temps que 2 exécutables Pascal, sans perte de performance.

L'idée dans tout ca, est d'utiliser au maximum les ressources des ordis multi-cpu, multi-core, multi-thread.

@Mat.M
J'ai roulé 4 exécutables Pascal en mode DPMI et chacun utilise 16M de mémoire sans problème

[Mat.M]

Finalement je peu compresser un DivX en même temps que 2 exécutables Pascal, sans perte de performance.

L'idée dans tout ca, est d'utiliser au maximum les ressources des ordis multi-cpu, multi-core, multi-thread.

Pour des petits projets et des petits programmes cela peut se concevoir... tu ne pourras jamais atteindre les performances avec ubn exe spécialement compilé pour Windows.
Et puis c'est pas safe la méthode que tu utilises l'écriture simultanée de fichiers..
Le premier job en tant qu'analyste programmeur que j'ai eu c'était dans une petite boite ( = compagnie au QC ) près de Paris ; le projet était fait avec QBasic et pareil la technique utilisée était l'échange de données par des fichiers et c'était un bazar monstre.

@Mat.M
J'ai roulé 4 exécutables Pascal en mode DPMI et chacun utilise 16M de mémoire sans problème

Oui mais le DPMI c'est un peu dépassé...tu ne peux pas faire de multithreading à ma connaissance je me trompe ? tu ne peux pas utiliser les particularités de la Win32, threads, sémaphores, events , pipes...

Je suggère de revoir le message d'Alcatiz:
http://www.developpez.net/forums/sho...49&postcount=8

[Transgarp]

Je viens de repenser au problème de la programmation // sous BP7.

Oui il y a une merveilleuse possibilité, premièrement revoir mes travaux de programmation // que j'ai fais à l'Université et surtout utiliser des fichiers drapeaux pour avertir les programmes concernés quand il est le temps de lire ou d'écrire.

Si je ne peu passer par la porte d'en avant, ca sera la porte d'en arrière ou par le sous sol

Mouais, je suis un peu très d'accord, ici au Québec on est un peu tête de mule

[Transgarp]

Tu as raison Mat.M pour le multi-thread, rien à faire avec des dinosaures comme BP7, ca n'existait même pas dans la tête des ingénieurs de l'époque ou possiblement en théorie.

Par contre il y a peux-être possibilité avec la technique des fichiers drapeaux.

Le problème des lecteurs / ecrivains est un classique dans les cours universitaires d'informatique et j'avais eu à le réaliser en C en 1991

Ouais, je viens de voir mon programme C, la variable semaphore est permise, pas en BP7