Manifest und Affinity ? Xbase++/2

[AUGE_OHR]

hi,

gab es nicht mal einen Thread betr. XP Manifest Eintrag und CPU "Affinity" ?

unter Vista/win7 kann ich mit /affinity xxx die CPU "auswählen"
http://www.howtogeek.com/howto/windows- ... ows-vista/

in c:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg steht

* 1 = Nur Erste CPU, 2 = 2. CPU, 4 = 3. CPU, 16 = 8. CPU
* 3 = 1. + 2. CPU

funktioniert 3 bei euch ?

[AUGE_OHR]

hi,

keine Reaktion habe ich die Frage falsch gestellt ?

Frage : warum läuft ein Xbase++ Programm nur auf "einer" CPU ?

Ich kann doch im Taskmanger die "Zugehörigkeit" ändern

ZU_CPU.JPG (8.76 KiB) 4937 mal betrachtet

ein Xbase++ Programm läuft "default" nur auf CPU0

NUR_CPU0.JPG (16.17 KiB) 4937 mal betrachtet

übrigens : wenn man eine "laufende" Xbase++ Application im Taskmanager "so umschaltet" dann "hängt" die Xbase++ Application mit 0% CPU.
Auch ein "zurück schalten" nützt dann nichts mehr

"jedes" andere Programm inklusive CMD.EXE läuft aber mit "beiden" CPUs

CMD_CPU.JPG (21.57 KiB) 4937 mal betrachtet

Xbase++/2 ... eine "alte" Erblast

[Koverhage]

Jimmy,

soweit ich das noch im Kopf habe, hat Steffen gesagt, man kann zwar die CPU auswählen, aber
grundsätzlich laufen Xbase++ Programme nur auf einer CPU.

[AUGE_OHR]

soweit ich das noch im Kopf habe, hat Steffen gesagt, man kann zwar die CPU auswählen, aber grundsätzlich laufen Xbase++ Programme nur auf einer CPU.

das hab ich schon verstanden aber die Frage ist doch "wieso" ?
Ich ging davon aus das es sich auf "externes" SMP bezieht, also wenn man "manuell" die CPU "wählt".

Im "normal" Fall sollte ja das OS() dafür sorgen das die "Last" auf die CPUs verteilt wird.
dabei sind dann immer "alle" CPUs "angekreuzt.

bei Xbase++ ist aber immer nur eine CPU angekreuzt und wenn man die 2nd "aktiviert" hängt die ganze Xbase++ Application.

da ja sogar CMD.EXE auf "allen" CPUs läuft, also auch Cl*pper, frage ich mich warum Xbase++ das nicht kann ???

ist es wie ich vermute eine Erblast ... Xbase++/2

[brandelh]

Hi Jimmy,

das wurde schon in mindestens 3 Threads durchgekaut

Xbase++ kann auf mehreren Prozessoren laufen, wenn man das zuläßt.
Allerdings geht dann die Geschwindigkeit in den Keller, wenn einzelne Threads auf verschiedene CPUs aufgeteilt werden.
Xbase++ hat immer mindestens 2 oder waren es 3 Threads.
Um das Problem zu umgehen, werden Xbase++ Programme über einen Schalter auf die erste CPU bzw. Kern gebunden.
Das kann man über einen Zufallsgenerator ändern, aber es muss immer ein Kern sein.

[Tom]

das wurde schon in mindestens 3 Threads durchgekaut

Mindestens.

Wenn ich mich recht an Steffens Ausführungen zum Thema erinnere, hat die 1.70 noch das Betriebssystem den Prozessor wählen lassen, ab 1.8/1.9 wurde dann festgelegt, dass Xbase++-Anwendungen immer auf Prozessor 0 oder 1 (je nach Zählung) laufen. Innerhalb der Applikation ist die Umschaltung möglich; jeder von uns, der Kunden mit Terminal-Servern hat, wird das sinnvollerweise tun. Wir haben hierfür verschiedene Systematiken ausprobiert und sind letztlich bei der - auch empfohlenen - halbzufälligen Auswahl gelandet, wobei unter TS protokolliert wird, wie viele Instanzen der App laufen, so dass hier "verteilt" werden kann. Wenn kein Terminal Server benutzt wird, wählt unsere App den Prozessor nach dem Zufallsprinzip. Eine Verteilung auf mehrere Prozessoren ist nicht möglich und auch nicht wirklich sinnvoll. Ich kann aber bestätigen, dass unsere App ebenfalls einfriert, wenn man über den Task-Manager und "Zugehörigkeit festlegen" einen oder mehrere andere Prozessoren wählt. Über die API-Funktionen innerhalb der App geht es aber problemlos. Was (meistens) nicht funktioniert, ist der Zugriff auf die Lastverteilung über die virtuellen Registry-Einträge. Hier schmieren wir fast regelmäßig ab, deshalb haben wir darauf verzichtet, diese Technik einzusetzen.

[AUGE_OHR]

das wurde schon in mindestens 3 Threads durchgekaut

Mindestens.

NEIN, NEIN, NEIN

ich spreche über Vista/Win7 "build-in Affinity Switch" was vom OS() kommt.
Ihr sprecht von SMP welches die Application verwendet.

Den "switch" gibt es erst seit Vista / Win7, bei XP muss man "manuell" umschalten.
über den "switch" können wir also noch gar nicht gesprochen haben

bei den "älteren" Version lief Xbase++ noch auf mehreren CPU ( v1.5 ) aber die SL1 v1.9.355
verwende "nur" noch auf 1 CPU.
wenn man eine "weite" CPU zuschaltet "hängt" alles was vorher ( v1.5) nicht so war.

auch läuft das Demo c:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg nicht mehr(?) mit der Option 3

>ab 1.8/1.9 wurde dann festgelegt, dass Xbase++-Anwendungen immer auf Prozessor 0 oder 1

Auch "glaube" ich nicht an die Erklärung von Alaska, denn dann müsste auch harbour oder Cl*pper das Problem haben.
Das was uns Steffen das erzählt kommt wohl aus der OS/2 Vergangenheit und hat NICHTS mit Vista / Win7 und CPU "Affinity" zu tun.
Wer Lust hat kann sich ja mal bei Google schlau machen wie "moderne" OS() nun mit 4 oder 6 oder mehr CPUs "umgehen" und welche "Tricks" es für die "manuelle" Lastverteilung es gibt.

[AUGE_OHR]

noch eine Beispiel http://www.robpol86.com/index.php/ImageCFG
wenn ihr es startet wird eine Meldung für die XBase++ Application ausgegeben "Subsystem Version of 4.0"
wir sind aber inzwischen bei "Subsystem Version of 6.1" !!!

[brandelh]

Hallo Jimmy,

warum hackst du immer auf der OS/2 Vergangenheit herum ?
OS/2 selbst und auch viele Anwendungen konnten mit Multiprozessor Maschienen umgehen !
Allerdings waren diese sehr selten, und die meisten Programme nutzten nur einen Thread (dann gibt es keine Probleme).

Xbase++ für Windows muss intern deutliche Unterschiede machen, da WinNT ff. eben nicht OS/2 3.x war.
Es liegt daran, dass die Xbase++ Threads für GUI etc. untereinander nicht unabhängig sind.
Das gilt immer noch, auch wenn Win7 und Vista eventuell mittlerweile zusätzliche Module bereitstellen.
An den neuen Modulen scheint sich aktuell der alte Code aufzuhängen,
aber die MANUELLE Verteilung funktioniert sicher immer noch.

[AUGE_OHR]

OS/2 selbst und auch viele Anwendungen konnten mit Multiprozessor Maschienen umgehen !

YUP ... ich wollte mich auch nicht über OS/2 selbst "beschweren" ... vielmehr fand ich das /2 "passend" für den Titel

Xbase++ für Windows muss intern deutliche Unterschiede machen, da WinNT ff. eben nicht OS/2 3.x war.

klar musste von OS/2, für das Xbase++ ursprünglich abstammte, auf Windows "umgesetzt" werden.
Die Frage dabei : ist der "Grundstock" immer noch der selbe ? ("Subsystem Version of 4.0")

Es liegt daran, dass die Xbase++ Threads für GUI etc. untereinander nicht unabhängig sind.

aber einige von den Sachen ( GuiThread ) sind erst seit der SL1 "drin"

Das gilt immer noch, auch wenn Win7 und Vista eventuell mittlerweile zusätzliche Module bereitstellen.

Nope das ganze kann man unter XP ja auch mit dem Taskmanager selbst provozieren.

An den neuen Modulen scheint sich aktuell der alte Code aufzuhängen,
aber die MANUELLE Verteilung funktioniert sicher immer noch.

bei vorherigen Xbase++ Version war ich der Meinung das die "3" beim Demo noch funktionierte.
ich müsste mal überprüfen ab "wann" ( v347 ? ) sich Xbase++ so verhält.

Es ist ja bekannt das die SL1 "umbauten" erfordert hat ... wurde dabei die SL1 auf 1x CPU "begrenzt" damit wir auf keinen Fall mehre CPUs benutzten können weil das "Subsystem" es nicht zulässt

[Markus Walter]

Meiner Mainung nach, gibt es den Gui-Thread nicht erst seit der SL1, sondern schon länger (immer?). Und damit hatte Steffen mal das Verhalten (Begrenzung auf einen Kern) erklärt: Wenn eine Xbase-Applikation threadmäßig auf verschiedene Kerne verteilt würde (und somit der Gui-Thread auf einem anderen Kern läuft, als andere Threads), käme es zur extremen Ausführungs-Verlangsamung. In alten Xbase-Versionen hatte Alaska das "zugelassen", dann aber später "verhindert".

So habe ich das zumindest in Erinnerung.