Board index » delphi » D2006 Hyperthreading Win32

2006-01-26 04:45:32 PM
delphi50
Hi
I have Delphi 6 are we run into problems with servers using hyperhtreading. I
saw that someone had raised
the same issue with D7. All I want to do is complie into Win32 we use
visual studio and C# for net stuff.
Have borland fixed this isue in D2006 and it that the right version to be
using for only win32 development.
Thanks
Mike
 

Mike writes:
Are there official QualityCentral reports for this?
I've been deploying many multithreaded Delphi 6 apps on HT machines,
and while there have been some 'surprisees', these have not been
attributable to fundamental problems with Delphi 6 itself!
If you're doing Win32 only you can safely use D6, but I'd
recommend installing the free replacement memory manager
FastMM4 (fastmm.sourceforge.net, IIRC)
which improves performance of multithreaded apps.
But even that isn't strictly necessary.
Furthermore I would of course recommend using Delphi 2006
just for the general improvements it brings to the table.
But none of those are directly addressing HT issues, AFAIK.
--
Kristofer
 

 

No only machines that are using hyperthreading then memory usage can go out
of control get very high
and the server will fall over. On non hyper threaded machines this does not
happen.
"Piotr Szturmaj" <XXXX@XXXXX.COM>writes

Mike writes:
post) a go. The RTL MM is known to "mismanage" memory in a threaded
environment.
--
 

D6 haven't no general problem with HyperThreaded/MultiCore-CPUs.
I think some of the used Controls/Components have problems.
But this isn't a general Delphi-Problem. Some years ago we have problems
with VS-Application (AFAIK Visual Studio 5/6) we get TCP/IP-Problems
when more than one CPU is used by Windows. We solved this by "binding"
the process to one CPU.
Mike schrieb:

Mike writes:
potential, and if you have controls that do threading without you
controlling the thread, what once was in your control no longer is.
I had issues with the Indy Telnet control in this senario. I told it I
wasnt in a threaded environment, as it wasnt, and under this
cercomstance, it went mental with HT.
The VCL has never been deemed "thread safe" specifically, so I guess,
if you've ever called application.processmessages or so on, now you may
feel the pain.
--
Liz the Brit
Delphi things I have released: www.xcalibur.co.uk/DelphiThings
 

one cpu so OS "sees" two cpus. I guess you ran into some synchronization
issue,
when 2 cpu's have write access to the same object. While one cpu can run one
thread at once HyperThreaded cpu can run 2 threads simultaneously.
regards
Piotr Szturmaj
 

Francois Malan writes:
AFAIK the biggest problem when threading with the old RTL MM was that
it slows down. I am unfamiliar with the old MM causing the problems
described -- and I do a good bit of multi-threaded code.
Do note that you must set IsMultiThread TRUE when using the old MM and
threading, but that TThread does this for you if you use it.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: learningtowhistle.blogspot.com
 

"Mike" <XXXX@XXXXX.COM>writes
is a design problem somewhere in your code or that of a third party
component. Something is not written or designed properly for multithreaded
use.
You may be able to run away from this problem for a while by updating to a
decent memory manager like FastMM4 (which is the default memeory manager in
D2006, but can be used in Delphi 6 applications also), but the real problem may be
the way your app handles resources and objects. Eg, in a multithreaded
environment you need to minimize the amount of time you hold on to resources
and memory.
 

If your code is thread-safe, it will run nicely on any PC (single cpu,
hyperthreading and dual-core).
Writing thread-safe code means making sure that all of your threads
(including the main thread) will be able to run at the same time, without
getting to a situation where more than one thread will try to write to a
memory location which is being used by some other thread (either reading
from or writiting to it).
Memory (objects, properties, variables, etc) is the one thing you need to
take care of when writing multithreaded apps. One memory location may either
be written to from one thread, or read from any number of threads. But, you
may not write to the same memory location from more than one thread at a
time, nor write to a memory location from which another thread is currently
reading. In other words, memory is a single-write or multiple-read resource.
Also, only the Main Thread may access the GUI, which means that you need to
synchronize all events which need to access the GUI with the Main Thread.
--
Danijel Tkalcec - Team RTC
www.deltasoft.hr/rtc
 

two virtual cpus and all should run fine if code is thread safe.
 

Danijel Tkalcec [RTC] writes:
the old MM.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
How to ask questions the smart way:
www.catb.org/~esr/faqs/smart-questions.html
 

danny heijl writes:
problem which applies *only* to hyper-threaded processors? I don't.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Useful articles about InterBase development:
blogs.teamb.com/craigstuntz/category/21.aspx
 

The problem with the old RTL MM (not the one in D2006 and newer) is high
memory fragmentation, which this isn't only the case in multithreaded apps,
it can also happen in single-threaded applications with high memory needs.
Since Borland was clever enough to make it possible to for third-party
vendors to write replacement memory managers, while there are a number of
such memory managers available for free, I don't see a problem.
Even before I started using FastMM (sourceforge.net/projects/fastmm),
I haven't had a single case of memory corruption using the RTL MM. The only
problems with the RTL MM were lower performance and high memory
fragmentation (with performance getting worse as fragmentation increases).
Since high fragmentation can eventually cause an application to run out of
memory, even though there would be enough smaller free blocks available, the
old RTL MM isn't the best choice for writing high-memory-load applications
like Servers. But, even the old RTC MM will be sufficient for most desktop
or client applications.
--
Danijel Tkalcec - Team RTC
www.deltasoft.hr/rtc