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: ***
Code: 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
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.
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