Moderator: Moderatoren
Code: Alles auswählen
Thread():new():start("stress")
DO WHILE .T.
nCpu := SmpGetCPU()Code: Alles auswählen
IF SmpSetCPU(nCpu) = 0
? "Kann CPU-Maske nicht setzen auf:" + var2char(nCpu)
END
RunShell(var2char(nCpu),'Stress.Exe',.t.,.t.)
ENDDO
JAbrandelh hat geschrieben:sind die aufgerufenen Programme Xbase++ EXE ?
das ist ja nun der Test mit RunShell() ...brandelh hat geschrieben:Ich meine (kann es aber nicht beweisen), dass die aufgerufene EXE selbst entscheidet welche CPUs sie nutzen kann.
Bei asyncroner Ausführung bin ich mir sogar sicher, bei syncroner Ausführung ... na ja
wenn du nichts machst, zwingt die Standardeinstellung die EXE auf CPU 1 !AUGE_OHR hat geschrieben:mir ist klar das, wenn ich in "Stress.EXE" selbst was einbaue, das es dann auf "der" CPU läuft die ich möchte.
hm ... JA ... bei Xbase++ sowieso !brandelh hat geschrieben:wenn du nichts machst, zwingt die Standardeinstellung die EXE auf CPU 1 !
Code: Alles auswählen
Thread():new():start("stress")
DO WHILE .T.
nCpu := SmpGetCPU()
? "Anwendung läuft z.Z. auf CPU(s): " + var2char( nCpu )
INPUT "Neue CPU-Maske: (0 => Ende)" TO nCpu
IF nCpu = 0
EXIT
ENDIF
IF SmpSetCPU(nCpu) = 0
? "Kann CPU-Maske nicht setzen auf:" + var2char( nCpu )
END
RunShell(var2char( nCpu ),'Stress.Exe',.t.,.t.)
ENDDOCode: Alles auswählen
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
DIM I AS DOUBLE
? "5 min voll Streß ... (ESC = Ende)"
i = TIMER + (5 * 60)
WHILE i > TIMER
IF $ESC = INKEY$ THEN EXIT
WEND
END FUNCTIONCode: Alles auswählen
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
DIM I AS DOUBLE
? "5 min voll Streß ... "
i = TIMER + (5 * 60)
WHILE i > TIMER
WEND
END FUNCTION
Oh ... sorryHans Zethofer hat geschrieben:FRACTAL.CH fehlt! =D>
Code: Alles auswählen
#define NUM_FRACTAL 4
#define NUM_POINTS 5000
#define NUM_EDGE 3Code: Alles auswählen
cmd.exe /C start /affinity 8 notepad.exeCode: Alles auswählen
cmd.exe /C start /affinity 8 Stress.exe
es wurde also im Zuge der Evolution gestrichen ...Re: Multicore cpu and smp
public.xbase++.generic
16. Dezember 2008
Steffen F. Pirsig
this is by design since 1.5 or so. In earlier Versions of Xbase++ with SMP architectures we allowed to have each thread running on a different processor.
Danke !brandelh hat geschrieben:ich hab dir hier mal 2 Versionen eines Streßprogrammes mit PowerBasic CC kompiliert.
Code: Alles auswählen
VERSION
"ProcAffinity" = "255"
*** Anmerkung : man zwar "ProcAffinity" = "3" setzte und die Xbase++ EXE startet auch aber wenn man die Maus bewegt ...12. September 2006
public.xbase++.bugreport
Re: 1.9331 - hang after a while - CPU 98%
Just a few comments regards the "98% cpu" problem.
1.) If the CPU goes to 98% ...
2.) According to our current knowledge of the problem we assume ...
// hier geht es los
3.) Regards the Xbase++ multi processor issue popping up in this thread,
please allow me to refer about the past, current and future in the context
of Xbase++ and the underlying hardware.
a.) PAST: Xbase++ as a product supports multi threading (single or multiple
CPUs) since its first day. It was designed and it is still one of our core
competences and knowledge to provide a runtime which hides most if not all of the
related complexities. In other words, the entire runtime (memory mgmt, datatypes and
operations. database access, error handling, user-interface) is designed in a way to
perform synchronization automatically without any deadlock. Plus the language
provides a clear model regards thread isolation in terms of privates/locals/workareas.
Starting with Version 1.0 until Version 1.8 of Xbase++ the runtime has
automatically adapted the way internal locking algorithms are implemented to the
underlying hardware architecture to support Single CPU and Multiple CPU (SMP) platforms.
Because more and more customers then have complained about the performance loss an
average Xbase++ application receives if executed on a SMP maschine we changed the automated
adaption of the Xbase++ runtime to a single CPU only with Xbase++ 1.82. The positive
effect is that a Xbase++ application now can run on different CPUs on a SMP Box,
however a single Xbase++ process is always bound to a single CPU. To understand the
ration behind it should be noted that a SMP architecture has its benefits only if
multiple processes are executed on the same maschine or if a single process performs CPU bound
operations (such as calculations) in different threads. If however a process is memory
bound or I/O bound the problem with SMP architectures is that the system-bus has to be
locked for memory and I/O access which leads to a dramatic performance penality.
Because Xbase++ application are "never" CPU bound but always memory or I/O bound an average
Xbase++ application runs slower on a SMP machine if running on different processors
at the same point in time.
b.) CURRENT: Xbase++ 1.9 is by default bound to a single CPU (the first cpu
if you have multiple ones or if HT is enabled). However this is just the default
setting and ensures that the average Xbase++ application performs at its best. There are no
performance drawbacks due to CPU context switches and additional synchronization overhead
specifially if memory is accessed from different processors. This mode of operation is called
"Single-Bound". The other type of operation is "Un-Bound" and allows the operating system to
schedule any Xbase++ thread on any processor. There is also the possibility to have your
Xbase++ application "Multi-Bound",meaning that the operating system is allowed to
schedule your Xbase++ applications and its thread to a set of processors. In case of
Un-Bound or Multi-Bound execution, threads of a single process can be executed at the same point in
time by a different CPU.
To change the default behaviour of your Xbase++ application the following options
are:
I.) Single-Bound: Changing the CPU on which the Xbase++ process runs at your own will.
You can use _MPSetCPU() to change the CPU on which the Xbase++ process runs. This
feature can be used to implement your own load-balancing regards available processors.
_MPSetCPU() and other multi-processor support functions are available in the cpuload
package which is a part of the Professional Subscription.
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: ***
See the "ProcAffinity" entry. In this case it is assigned to 3 which meansCode: Alles auswählen
// 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
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.
c.) FUTURE: Since 2002 and Xbase++ 1.82 the world has changed. Today the available
Hardware is quiet different than in the early days of multi-processors with its SMP architecture.
There is Hyperthreading, Single-Core and Multiple-Core processors, we have shared or
multiple cache lines and we even have Multi-Core with HT processors. All of these types
of processors behave totally different if it comes to multi processing. Some of them scale only
if the task if CPU bound, others scale if the tasks are CPU and memory bound. The challenge
for Alaska Software is currently to identify the patterns at which the Xbase++ runtime and/or
different application types get most out of the available CPU power. For this Alaska Software
has already invested in a set of identical boxes, only different by their CPU types, our current
research goals are to have a pre-defined set of Multi-Processing-Setups which can be easily
selected and which ensure that the Xbase++ application performs at its best.
SUMMARY: Changing CPUs, changing processor affinity and therefore changing the
behaviour of the Xbase++ runtime to have it bound to a single or multiple CPUs makes
currently only sense for those which have a deep understanding and control of the
Hardware on which their application is running. There are various parameters which
affect single application performance when it comes to the usage of more than one processor.
However if your are currently running Xbase++ applications via Citrix or Terminal-Server
it is definitive a good idea to have your application Un-Bound - this way the operating
system is free to schedule all threads of all Xbase++ instances running over all CPUs available.
With kind regards
Steffen F. Pirsig
Alaska Software
Dass Xbase++ EXE immer nur den 1. Prozessor nutzen ist ein alter Hut.AUGE_OHR hat geschrieben:falls jemand keinen Zugriff auf die Newgroup hat hier die Mail.12. September 2006
public.xbase++.bugreport
hm ... ich würde eher formulieren : DEFAULT, ab v1.8x, benutzt eine Xbase++ EXE die 1st CPU ( es kann aber auch "eine" andere sein )brandelh hat geschrieben:Dass Xbase++ EXE immer nur den 1. Prozessor nutzen ist ein alter Hut.
wieso "switch" wenn mehrere CPUs, wie bei CMD.EXE, freigegeben wurden ?!brandelh hat geschrieben:Auch, dass die Performance beim CPU switchen (also der EXE mehr CPUs freizugeben) in den Keller geht, sollte jeder mal gehört haben.
Code: Alles auswählen
"ProcAffinity" = "255"
Ich meinte, dass die EXE ihre Threads auf mehrere CPUs verteilen kann ... und dann müssen diese gegenseitig syncronisiert werden, was die Anwendung extrem verlangsamt.Auch, dass die Performance beim CPU switchen (also der EXE mehr CPUs freizugeben) in den Keller geht, sollte jeder mal gehört haben.
von "echten" (getrennten) Threads träumen wir höchstensbrandelh hat geschrieben:Ich meinte, dass die EXE ihre Threads auf mehrere CPUs verteilen kann ...
und dann müssen diese gegenseitig syncronisiert werden, was die Anwendung extrem verlangsamt.
mittels ProcAffinity kann ich schon "eine" CPU festlegen ( i-1**2 ) aber es geht nicht > 1 CPUTom hat geschrieben:Es kommt nichts dabei heraus, wenn man mit der ProcAffinity herumspielt, außer, dass die Anwendungen komplett in die Knie gehen.
Ganz egal, mit welcher Xbase++-Version (ab 1.9).
Code: Alles auswählen
cmd.exe /C start /affinity 8 xxx.exe
ja ... ok ... so langsam hab ich wohl alle Möglichkeiten ausprobiert was mit "ProcAffinity" und-oder / AFFINITY und Runshell() möglich ist.brandelh hat geschrieben:Es hier nochmals durchzukauen ist ...
Code: Alles auswählen
RunShell( [/C start "Cl*pper DBU" /AFFINITY 8 "D:\DB2U\DBU.EXE" ],'CMD.EXE',.T.,.T.)