Board index » cppbuilder » Intel Hyper-threading technology problem?

Intel Hyper-threading technology problem?

2004-06-15 12:56:36 AM
When I upgraded my computer to a P4 3.0GHz with hyper-threading technology I
can no longer run my project in BCB 6, I cant even open a form witn a number
of 3d party componnets on it in BCB ide, BCB hangs. When I turn of
hyper-threading technology in bios all works OK.
Anyone hear of problem with BCB or 3d party components and hyper-threading
Best Regards,
Christer Strandh

Re:Intel Hyper-threading technology problem?

"Christer Strandh Aragon" < XXXX@XXXXX.COM >wrote in message news:40cdd84e$ XXXX@XXXXX.COM ...
I experienced a similiar problem with our sql / multimedia server.
The server can be compiled with different compilers and when
i started the server, which has been compiled with BCB 6.0,
sometimes the server simply blocked for 10 seconds or more.
I separated the problem and wrote a simple test program which
is only allocating and freeing memory from inside different threads.
(Allocating and freeing small memory blocks at that high rate
is a performance killer for each compiler and application - but
very good to reproduce the hyperthreading problem)
The test program blocks right after it has been started, if multiple
threads with different priority are entering the same critical section
(as for example the ones used by the heap manager).
When i didnīt change the priority the problem occured too,
and the application didnīt block completely, but the application
did run up to 100 times slower than the one compiled with
the other compiler (VC).
The difference between compilers is, that BCB uses itīs own
heap manager, while the other one is using the windows heap manager
to allocate memory blocks.
The VC runtime library can be forced to use the old implementation
on Win2K and XP - an own heap manager like BCB6 - for
small memory blocks.
But the BCB6 compiled application had still a very poor performance,
while the VC application, now using a comparable heap allocation as
BCB6, still had no problems.
Windows uses critical sections with spin counts to lock operations,
which are comparably fast to execute.
So i wrapped an critical section initialized with
InitializeCriticalSectionAndSpinCount around the heap allocation
and freeing functions in my test program.
The VC application did run without any significant performance decrease,
but the BCB6 application was boosted and did run now in a comparable
equal speed as the VC application.
When i used a critical section without spin counting the VC application
behaved like the BCB6 one and blocked.
I recompiled the runtime library of BCB6 and changed the initialization
of the critical sections in the heap manager code to critical sections
with a spin count of 5000.
After i recompiled our server with that runtime library the locks have
been gone.
From this follows that:
High performance multiprocessor programming isnīt that simple,
even if the processors are only virtual ones.
I donīt know if the locks in your program are caused by the
same reason, i described above, but if so then you have the
following options:
1) Use SetProcessAffinityMask to force the application
to only run on a single cpu
2) Disable hyperthreading (an option i wouldnīt like because
Windows is much more responsive when an application
isnīt cooperative and consuming much cpu cycles)
3) Recompile the BCB6 heap manager
4) Hook the InitializeCriticalSection calls and call
InitializeCriticalSectionAndSpinCount instead.
I donīt think this to be a good option,
since you will change all CriticalSections and
perhaps you will experience a performance
loss from threads spinning around and
consuming needlessly all cpu cycles on
long lasting locked operations.
5) Use a global spin counted critical section for
your all allocations / deallocations -
No good option either.....
x) Perhaps anybody knows another option(s) or
other potential pitfalls ?
Hope this helps a bit,

Re:Intel Hyper-threading technology problem?

I had some experience with TThread in BCB, did not compared with VC yet. I
spent couple weeks to figured out the position where the problem were, but
do not know why.
System : BCB6
Windows: ME, 2000Pro and XP
Application: The peak time is 8 background threads ran at the sametime, use
TMultiReadExclusiveWrite (TMREW) to protect the variables.
Problem: System frozen on threads with no apparent errors, Debug tools shows
all the threads are stoped at random point.
After couple weeks trying, Here are what I concluded from the fact (but I
really do not know the reason)
1. Never let TThread call it's own suspend() method, actually I totally
abandoned to use suspend() method, anytime I use suspend(), the problem came
again and again. Use TEvent->Waitfor() insdead;
2. Each variable shared by multi-thread need one TMREW to protected. I was
lazy to use one TMREW to protect couple varaibles and got trouble with it.
3. All the TThreads in my application are deleted manually. (Set
FreeOnTerminate to false)
After I done those steps, All the applications are rarelly frozen anymore
during development time.