Xbase++ 1.90 und Dual Core / X2 oder HT - Erfahrungen ?

[brandelh]

Hallo,

immer wieder ließt man Meldungen in der Alaska News Group, dass Anwender Probleme mit Xbase++ Anwendungen und mehreren Prozessoren haben. Mit 1.90 sollte da ja was verbessert werden ?

Ich ging eigentlich davon aus, dass ein Programm, das in mehrere Threads aufgeteilt wird, von jedem neuen Prozessorkern mehr profitieren müsste (vorausgesetzt, die Aufgabe kann den Prozessor überhaupt fordern).

Wer hat Erfahrungen auf diesem Gebiet ?

Ich meine TOM hat mal geschrieben, dass seine Anwendungen auf Mehrprozessor Servern laufen, aber auch gleichzeitig auf mehreren CPUs ? Man kann ja eine Anwendung davon abhalten mehrere CPUs zu nutzen und es kann natürlich auch sein, dass die Plattensuche so lange dauert, dass selbst eine CPU sich langweilt.

[Tom]

Hallo, Hubert.

Es gab schon in der 1.8 (möglicherweise sogar in der 1.7) die Funktionen _sysGetCPU() und _sysSetCPU() (Lib Xpprt1). Mit deren Hilfe konnte (und kann) man die Anzahl der CPUs (auch "unechte", also für HT-Prozessoren) ermitteln und die CPU setzen, auf der die App laufen sollte. Mit der 1.7 hatte Alaska nämlich abgeschaltet, daß das Betriebssytem die CPU wählen durfte; Xbase-Applikationen laufen also standardmäßig auf CPU 1 und nur dort. Wir haben für unsere Multiprozessor-Kunden dann ein System geschaffen, mit dem die Applikation die Anzahl der eigenen gestarteten Instanzen zählt und sich gleichmäßig auf die Prozessoren verteilt.

Mit der 1.9 wird eine Lib ASMP10 ausgeliefert, die folgende Funktionen enthält:

_MPGetLeastUsed()
_MPSetCPU()
_MPNumProcessors()
_MPGetWorkLoad()

Diese Funktionen greifen auf die PDH.DLL (Performance Data Helper) zu, die man aber nicht einbinden muß; das macht die ASMP10. Um zum Beispiel die echte Prozessorlast zu ermitteln, erzeugt die PDH.DLL "virtuelle" Registry-Einträge, die jeweils die aktuelle Last enthalten.

Wir haben dann alles umgestellt, um die Applikation je nach Last auf dem Prozessor laufen zu lassen, der am wenigsten zu tun hat. Ging auch auf ein, zwei Rechnern, aber bei den meisten fror die Applikation einfach ein, mal von denen abgesehen, die aufgrund der OS-Version überhaupt keine PDH.DLL hatten (die man ab Windows NT bei Microsoft laden kann). Also haben wir den ganzen Schmonzes wieder rausgeschmissen (bzw. per Aufrufparameter abgeschaltet), Fehlermeldungen an Alaska verfaßt und auf das alte System zurückgestellt.

Xbase-Apps laufen immer nur auf einem Prozessor, aber Steffen hat in New Hamsphire gesagt, daß der Compiler eigentlich vorzüglich dafür geeignet wäre, parallel auf mehreren CPUs zu laufen. Dafür wären auch nur geringfügige Änderungen nötig. Wann die kommen, weiß der Geier.

Ich habe auf meiner Entwicklungsmaschine HT abgeschaltet, damit der Compiler und meine App schneller arbeiten.

[Tom]

Ergänzung: Das Setzen der CPU betrifft immer alle Threads. Es ist mit beiden Techniken nicht möglich, die CPU für einen einzelnen Thread zu wählen.

[mr@nline.de]

Hallo,
also ich stelle die CPU auch manuell per Aufrufparameter ein.
Zum Beispiel habe ich einen Anwender der einen Terminalserver einsetzt, dort habe ich die Benutzer jeweils zur Hälfte auf CPU-1 unde CPU-2 verteilt. Das bringt deutliche Vorteile.
Irgendwo hier in der Newsgroup liegt ein Artikel von Steffen der beschreibt wie man die Anwendung automatisch auf mehrere CPU's verteilen kann.
hier ein Ausschnitt

Code: Alles auswählen

  II.) Allow your application to run on different CPUs at the same point in
time. In other words
  allow the operating system scheduler to automatically distribute your
threads over all (Un-Bound)
  or a specific set of processors (Multi-Bound). Changing this setting needs
a resource file with
  a version resource such as shown below:

  use this ARC file to define the version resource
  compile with arc and link the .res-file to the .exe
     VERSION
         "CompanyName"      = "Stock Analysts Inc."
         "ProductName"      = "SA-Quick "
         "ProductVersion"   = " 5.0"
         "FileVersion"      = " 5.001.893"
         "FileDescription"  = "Analyze stock markets"
         "InternalName"     = "SAQ5"

         "LegalCopyright"   = "Copyright  Stock Analysts Inc. 2001"
         "OriginalFilename" = "SAQ.DLL"
         "ProcAffinity"     = "3"
 end of res file

 See the "ProcAffinity" entry. In this case it is assigned to 3 which means
Bit 0 and Bit 1
 are set. This allows the Xbase++ Process to run its threads freely on CPU 0
and CPU 1.
 If we are running a exe which has linked in that specific Version-Resource
"ProcAffinity"
 on a 2 Processor system the Xbase++ EXE runs Un-Bound, if we are running
that
 EXE on 4 Processor system it runs Multi-Bound - only two processors #0 and
#1 are
 allowed.

 You can also mix the two strategies, for example you can enable the Xbase++
EXE
 by default to run on all CPUs ProcAffinity = "65535" and the lateron use
_MPSetCPU()
 to restrict the process to a single or multiple CPUs.

 For the technical freaks out there: If the Xbase++ process is allowed to
run Un-Bound
 or Multi-Bound the internal locking alogrithms are different bec.
operations against
 memory are no more atomic with a simple test-set-semaphore such as it is
the case
 with fast-semaphores. However all of these complexities are hidden by the
runtime
 and automatically managed by the Xbase++ core.

Ich hab das Ganze probiert und muss sagen, von Geschwindigkeit kann man nicht mehr reden, furchtbar langsam.

Gruss
Manfred

[brandelh]

Ergänzung: Das Setzen der CPU betrifft immer alle Threads.
Es ist mit beiden Techniken nicht möglich, die CPU für einen einzelnen Thread zu wählen.

Also ich bin jetzt mal so richtig naßforsch ...

Warum zum Teufel soll ICH entscheiden welcher Thread meiner Anwendung (und ich meine hier Thread !) auf welcher CPU läuft. Dafür gibt es schließlich das Betriebssystem und eine Anwendung hat gefälligst dieses nicht zu behindern, sondern der Compiler muss das abdecken wenn er sich als 'Multithreaded...' titulieren will.

Wenn ich mich aber recht erinnere hat doch vor einigen Wochen eine INTEL usw. Konferenz stattgefunden, die das Problem der Mehr-CPU-Unterstützung behandelt hat (für C++ glaube ich), also sind die anderen auch nicht besser dran

Kann man sagen, dass Xbase++ Anwendungen auf alten (single) CPUs besser laufen als auf den neuen 'Doppelherzen'; ich fürchte ja

Nachtrag:

wie weiter unten ausgeführt wird, laufen diese nicht schlechter !

[mr@nline.de]

Hallo Hubert,
wenn ich die Dokumentation richtig gelesen habe (Beitrag von Steffen Pirsig in der NewsGroup) scheint das Problem darin zu bestehen, dass ja jede CPU ihren eigenen Speicherbereich für Code und Daten besitzt. Wenn nun innerhalb eines Programms thread1 (CPU1) und thread2 (CPU2) gegenseitig auf Variablen und Objecte zugreifen wollen funktioniert das nicht , bzw. mit enorm hohen Aufwand für die Speicherverwaltung.....
Man korrigiere mich wenn das falsch ist.

Gruss
Manfred

[brandelh]

Hi Manfred,

es scheint wohl so zu sein, dass der Overhead für das Umschalten
bei den Anwendungen die üblicherweise mit Xbase++ programmiert werden mehr Zeit braucht, als 2 Kerne wieder einfahren können.

Wer schreibt schon eine Video-Bearbeitung mit Xbase++.

Dann sollte es aber zumindest so sein, dass die komplette EXE auf dem jeweils gerade freien Prozessor gestartet wird und alle Threads dort gehalten werden.

Kann man das eventuell einstellen ?

Schließlich wird kein Endanwender verstehen, dass ein Programm auf einem 2xCPU Rechner langsamer läuft als auf einem 1xCPU Rechner.
Und wenn alle Programme auf den 1. Prozessor befohlen werden, was macht dann der 2. Prozessor außer einrosten

[mr@nline.de]

Hi Hubert,
also wenn du nichst weiter machst als das Programm zu starten,
läuft das xBase++ Programm auf def CPU-1 und zwar nicht langsamer
als wenn nur eine CPU vorhanden ist. Es wird auch keine automatische
Umschaltung vom Betriebssystem vorgenommen. Du hast aber auch keinen Geschwindigkeitsvorteil ! Das ist aber so bei 99% aller vorhandenen Anwendungsprogramme.
Mit den Dualcore-Rechnern und den Programmen ist es ungefähr so wie mit den super tollen HDTV kompatiblen Fernsehbildschirmen für die es momentan ja auch kaum Sender gibt die ein entsprechendes Signal liefern, also fast immer ohne praktischen Nutzen für den Anwender.

Gruß
Manfred

[Tom]

Hallo, Hubert.

Siehe erste Antwort auf Deine Frage. Wenn Du auf einem Multiprozessor-Server alle Instanzen standardmäßig auf CPU 1 laden läßt, geht der Kerl irgendwann in die Knie. Die (programmgesteuerte) Aufteilung der CPUs bringt da immense Vorteile. Die im zitierten Posting von Steffen dargestellte Methode zwingt hingegen das Programm so oder so in die Knie, auch auf Nicht-MP-Systemen. Unpraktikabel.

[brandelh]

Hi,

wie wir von Stefen erfahren haben ist die manuelle Zuweisung der CPU z.B. per Zufallszahl oder einfach immer den nächste ... die praktischte und zur Zeit beste Lösung. Ein Beispiel liegt schon seit mehreren Xbase++ Versionen der Prof.Sub in ?:\XPPW32\SOURCE\samples\solution\smp.

Die von TIL dargestellte Methode erlaubt es dem Betriebssystem die Threads frei auf den CPUs zu verteilen, was aber nur dann Vorteile bringen könnte, wenn die Threads wirklich völlig unabhängig voneinander wären. Ansonsten müssen die CPUs sich gegenseitig immer ausbremsen und Ergebnisse austauschen. Ob eine Aufgabe sinnvoll aufgeteilt werden kann, kann weder der Kompiler noch das BS im Voraus wissen, daher führt diese automatische Aufteilung zu schlechteren Ergebnissen. Die meisten anderen 'normalen' Programme haben nur einen Thread und damit eventuell hiermit Vorteile, dass diese zumindest nicht langsamer laufen.

Ob es bei Datenbankprogrammen überhaupt Anwendungen gibt, die durch die einzelne CPU in der Leistung begrenzt werden ist dann schon wieder eine andere Frage, denn beim Drucken, suchen, indizieren speichern etc. werden ja immer auch Daten von der Festplatte benötigt - alles viel langsamer als die CPU.

Real betrachtet, gibt es wirklich nur sehr wenige Programme die einen 2. Prozessor zur Geschwindigkeitssteigerung nutzen können, das sind Profiprogramme von CAD oder Videoschnitt die in hohen Preisregionen liegen.

Ich habe also gelernt, dass ich bei meinem nächsten Rechner ruhig eine 2x CPU ordern kann und dann auch mit den beiden experimentieren kann

[AUGE_OHR]

hi,

... ich denke mir gerade : spricht eigendlich etwas dagegen "grundsätzlich"
Xbase++ Applicationen, bei DualCore oder HT, auf CPU > 1 laufen zu
lassen ? Man könnte doch theroretisch auch den "Main" Thread auf der
CPU > 1 laufen lassen ... ?

gruss by OHR
Jimmy

[AUGE_OHR]

hi,

kann es sein, das wenn ich eine Xbase++ Application, unter DualCore
oder HT auf CPU 2 betreibe und dann per RUNSHELL eine andere
Application starte das diese "externe" Application dann auf CPU 2
läuft auch wenn die Xbase++ Application beendet wurde und auf
die CPU 1 "zurück geschaltet" wurde ?

gruss by OHR
Jimmy

[brandelh]

Hi,

ich denke mir, das hängt davon ab wie man runshell startet.

Syncron - Neuer Prozess ist sicher auf gleichem Prozessor
Asyncron - Prozessor dürfte von BS vergeben werden.

Eine Anwendung die beendet wird, schaltet keinen Prozessor um, sondern wird einfach beendet. Falls aus dieser heraus eine andere gestartet wurde, dürfte das Ende der ersten keine Auswirkungen auf den verwendeten Prozessor haben.

Probieren kann ich es leider nicht, ich habe nur eine single cpu

[AUGE_OHR]

hi

ich denke mir, das hängt davon ab wie man runshell startet.

Syncron - Neuer Prozess ist sicher auf gleichem Prozessor
Asyncron - Prozessor dürfte von BS vergeben werden.

folgender code

Code: Alles auswählen

#include "dll.ch"
#include "common.ch"

PROCEDURE Main(cExe,cPara)
LOCAL nCpu := 2

   DEFAULT cExe  TO "CMD.EXE"
   DEFAULT cPara TO ""

   IF SmpSetCPU(nCpu) = 0
      SmpSetCPU(1)
   ENDIF

   IF PCOUNT() > 0
      cEXE := "/C START "+cEXE	
   ENDIF

   RunShell(cPara,cExe,.T.)

   IF nCpu = SmpGetCPU()
      SmpSetCPU(1)
   ENDIF
RETURN
/*
 * Die benötigten Funktionen sind Teil der Runtime-Library.
 */
FUNCTION SmpGetCPU()
LOCAL i
    i := DllCall("Xpprt1.dll",DLL_CDECL, "_sysGetCPU")
RETURN i

FUNCTION SmpSetCPU(nCpuMask)
LOCAL rc
    rc := DllCall("Xpprt1.dll",DLL_CDECL, "_sysSetCPU", nCpuMask)
RETURN rc

kann man verschieden verwenden aber es kommt auf das selbe raus :
alles, ausser (!!!) Xbase++ Applicationen, laufen dann auf CPU 2 ab !

1.) Fall : aus Window$ per "doppelclick" startet ein CMD "Fenster". Wenn
ich nun z.b. eine Cl*pper Programm (ReIndex) starte geht CPU 2 %
hoch und CPU 1 bleibt "still"
2.) CMD wurde schon gestarte und RUN2.EXE wird mit Parameter auf-
gerufen. Auch dort kann man dann die CPU 2 % sehen.

jede (!) Xbase++ Application läuft aber "immer" auf CPU 1 (wenn man
nichts gemacht hat) ... und hier tritt und eine Frage auf :

bislang hab ich ja nichts mit der *.ARC Datei gemacht wo man laut Steffen
was eintragen kann(muss ?) ... wie ist da also der zusammenhang ?

gruss by OHR
Jimmy

[AUGE_OHR]

hi,

Wer schreibt schon eine Video-Bearbeitung mit Xbase++.

ich ...

Ergänzung: Das Setzen der CPU betrifft immer alle Threads. Es ist mit beiden Techniken nicht möglich, die CPU für einen einzelnen Thread zu wählen

bist du sicher ?
ich bin der Meinung das ich jetzt 2 Threads auf 2 CPUs "verteilen" kann.

Problem : "schnelles vorspulen" das hat meine "alte" CPU bis zum
"Anschlag" gebracht. Das starten eines weiteren Thread war "kaum"
möglich".
Nun hab ich das "schnelles vorspulen" auf CPU 2 gelegt, wo er sich
zwar auch 100% nähert, aber CPU 1 ist "frei" sodas ich noch einen
"intensiven" Thread laufen lassen kann.

spielt es vielleicht eine Rolle wie man einen Thread startet ?

Code: Alles auswählen

FUNCTION PLAYSNIP(oMainDlg,aoChild,aDLGOWNER,lGotoEnd)
LOCAL oPlaySnip
   IF lPlaySnip
   ELSE
      lPlaySnip := .T.
      oPlaySnip := Thread():new()
      oPlaySnip:start("PLAYPART",oMainDlg,aoChild,aDLGOWNER,lGotoEnd)
   ENDIF
RETURN lPlaySnip

PROCEDURE PLAYPART(oMainDlg,aoChild,aDLGOWNER,lGotoEnd) 
LOCAL nEvent , mp1 , mp2, oXbp
LOCAL nCpu := 2

DEFAULT lGotoEnd TO .F.

   IF SmpSetCPU(nCpu) = 0
      SmpSetCPU(1)
   ENDIF
...
   here Thread code
...
   IF SmpGetCPU() >= nCpu
      SmpSetCPU(1)
   ENDIF
   lPlaySnip := .F.
RETURN

gruss by OHR
Jimmy

[brandelh]

Hi Jimmy,

da gab es schon mehrere Threads zu dem Thema.
Xbase++ Programme müssen normalerweise auf einer CPU laufen, da beim Syncronisieren zwischen den internen Threads zuviel Zeit verloren geht.

Wenn aber der ideale Zustand eintritt, dass 2 Threads nichts miteinander (inkl. Gui) zu tun haben könnten beide auf getrennten Prozessoren unabhängig laufen. Soweit ich Stefen verstanden habe, ist aber das BS und ein Programm nicht in der Lage einen einzelnen Thread gezielt auf einer anderen CPU laufen zu lassen.

Entweder man gibt alles frei - dann wird es langsam - oder man schreibt der EXE eine CPU vor. Deshalb bleiben die XBase++ Anwendungen per default auf CPU1.

[brandelh]

Hallo,

Toms Hardware Guide hat hier einen interessanten Beitrag zu einem Stromspar PC:

http://hardware.thgweb.de/2006/12/27/st ... age26.html

Die direkt verlinkte Seite zeigt einen Benchmark mit iTunes etc. und da schneidet der Single Core 3800+ deutlich besser ab als der dual core X2 3800++ -> der single core hat eine höhere Taktfrequenz.

Einige Tests später bei z.B. DivX ist die X2 3800+ doppel so schnell wie eine normale 3800+.

Besser kann man nicht sehen, wie stark die Performance von der Software abhängt, und das in mehren Punkten

1. Ist die Aufgabe überhaupt geeignet um parallel ausgeführt zu werden ?
2. Ist der Prozessor überhaupt das begrenzende Element ?
3. Ist das Programm in der Lage die beiden CPUs sinnvoll zu nutzen.

[brandelh]

Hi,

ich bin gerade beim Lesen der FireBird Anleitung und finde folgende Aussage:

SUPERSERVER:
...
On multi-processor Windows
machines, performance can even
drop dramatically as the OS switches the
process between CPUs. To prevent this, set
the CpuAffinityMask parameter in the
configuration file firebird.conf.

ich habe auch noch eine deutsche Übersetzung gefunden:

Keine SMP Unterstützung. Auf Multiprozessormaschinen
unter Windows kann sich die Performance sogar erheblich
verschlechtern, weil das Betriebssystem den Serverprozess
zwischen den CPUs umschaltet. Um dies zu verhindern,
setzen Sie den CpuAffinityMask Parameter in der
Konfigurationsdatei firebird.conf.

also haben andere auch das Problem, dass das Verteilen von einzelnen Threads eines Programmes auf mehrere Kerne das Programm je nach Situation deutlich verlangsamen kann.

[AUGE_OHR]

hi,

Mit der 1.9 wird eine Lib ASMP10 ausgeliefert, die folgende Funktionen enthält:
_MPGetLeastUsed()
_MPSetCPU()
_MPNumProcessors()
_MPGetWorkLoad()

hast du evtl. noch eine Code Beispiel zu den Functionen ?

[Tom]

Hallo, Jimmy.

Die Funktionen sind sehr simpel. Schau mal in ..\SOURCE\SAMPLES\Solution\CPULoad. _MPGetLeastUsed() z.B. antwortet mit der Nummer (bei 0 beginnend, wenn ich mich recht erinnere) des am wenigsten genutzten Prozessors. _MPSetCPU() wird entsprechend bestückt. Beispiel:

Code: Alles auswählen

nProcessor := _MPGetLeastUsed()
_MPSetCpu(2**(nProcessor-1))

Die Anzahl der Prozessoren wird einfach über _MPNumProcessors() (ohne Parameter) ermittelt.

Diese Funktionen sind aber (noch immer) nicht sehr verlässlich. Entweder, sie arbeiten nicht richtig, weil die entsprechende API-DLL nie aktualisiert wurde (in solchen Fällen liefert LeastUsed immer Prozessor eins zurück), oder die Auslastungsanzeigen sind nicht ganz richtig. Wir verteilen unsere App zufällig auf alle Prozessoren, damit fahren wir sehr gut.

[brandelh]

Hi,

wenn man sich in der Systemsteuerung die CPU Auslastung ansieht, dann ist da meist eine sehr franzige Zackenlinie. Wahrscheinlich macht es (dem Rechner) mehr Arbeit, das zu Überwachen, als einfach davon auszugehen, dass eine Zufallsverteilung der Aufgaben im Schnitt besser funktioniert. Im nächsten Moment kann die eben noch rauchende CPU schon wieder einschlafen

Ich habe den alten Thread nur deshalb aufgewärmt, da die oben zitierten Aussagen ein Beleg
dafür sind, dass Windows das Problem verursacht und unser Compiler darunter leidet, ohne
etwas dafür zu können.

[Tom]

Ich kann Hubert nur zustimmen. Die Auslastung ist ein Snapshot, und wenn ein anderer Benutzer seinen Finger gerade in diesem Moment über der Schaltfläche "Machedieseriesenauswertungdiedenrechnerkomplettlahmlegt" hat, ist der Wert schon eine Sekunde später nutzlos. Erfahrungsgemäß sind zwei Systeme für die Prozessorauswahl handhabbar: Entweder merkt man sich irgendwie (z.B. in einer Tabelle), wie viele Instanzen der Software laufen und verteilt sie gleichmäßig auf alle Prozessoren - oder man macht das zufällig. Die Ergebnisse ähneln sich; in der Praxis sind beide Ansätze gleich gut. Kaufmännische Anwendungen erzeugen sehr, sehr unterschiedliche Prozessorlasten, abhängig davon, was der Benutzer gerade will, und stehen ansonsten die meiste Zeit über schlicht still, weil sie auf Eingaben warten. Eine Prozessorauswahl über die Auslastung macht nur dann wirklich Sinn, wenn Anwendungen verteilt werden sollen, die über ihre gesamte Laufzeit relative konstante Auslastungen erzeugen.

Edit: Theoretisch könnte man natürlich auch in einem Extrathread permanent die Prozessorauslastungen überwachen, und dann bei Auslastungspeaks wechseln. Ich vermute aber, dass das selbst eine so hohe Last generieren würde, dass sich das System selbst ermorden würde. Einen Versuch wäre es allerdings wert.

[AUGE_OHR]

Hi,

Schau mal in ..\SOURCE\SAMPLES\Solution\CPULoad.

hm ... in meiner Version und in SL1 finde ich das Verzeichniss nicht ?

ist es direkt von Xpp oder Asinet etc. ?

[Tom]

Auf dem 2006er-DevCon-Stick befindet sich ein Unterverzeichnis namens "CPULOAD", und wenn man die Professional Subscription aus dem Download durchtickert, müsste das auch dabeisein. Notfalls einfach mal Till, Andreas oder Steffen anpöbeln. Auf die nette.

[Jan]

Hallo Tom,

auf meinem USB-Stick von 2006 ist der aber nicht drauf.

Und mein Verzeichnis der 1.9-Installation ist leer. Klar, hab nicht die Prof.

Jan