[DUG] Multi Threading and HyperThreaded CPUs

[Kyley Harris]

Its good for people to test in their own conditions, but i would say that
proving the sun is shining in hamilton does not disprove that its raining in
Auckland, and that an isolated test isn't enough to really say that anyone
experiencing the issue is just badly implementing threaded coding.. :D I
know that was not your intent..

http://www.ece.wisc.edu/~wddd/2004/06_bulpin.pdf this is a very interesting
and unbiased article showing pros and cons of different scenarios.

A Quote from one of the MS SQL team,

"Our customers observed very interesting behaviour on high-end HT-enabled
hardware. They noticed that in some cases when high load is applied SQL
Server CPU usage increases significantly but SQL Server performance
degrades," wrote Ocks.

Ocks then detailed testing which showed this behaviour where a system thread
— in this case one cleaning out blocks of disk cache memory — is running at
the same time as worker threads. "With Intel HT technology, logical
processors share L1 & L2 caches. As you would guess [this] behaviour can
potentially trash L1 & L2 caches," he said.


in all my own tests that were going badly on that platform, it was using TCP
servers of one kind or another.. so perhaps something to do with the windows
socket api helps expose the problem. Who knows :D It should not effect any
dual core or AMD etc that I am aware of, only that one P4 intel chip.

Anyway.. luckily all the new dualcore multicore stuff will not have these
issues, as they are not related to software developer quality at all, or
good thread coding behaviour.

Cheers.

On Nov 13, 2007 5:15 PM, Peter Ingham <ping_delphilist at 3days.co.nz> wrote:

> A few days ago, a statement was made to the effect that using
> Hyperthreading gave no advantage to a Multi-threaded application.
>
> This did not sound at all correct, so I carefully constructed a test
> program to investigate the actual behaviour in a variety of
> configurations.   The comments below are all based on tests performed
> with this application.
>
> The program consists of a tight loop doing "Work" (no FP)  which can be
> run in a varying number of threads (The gross amount of work done is not
> affected by the number of threads).
>
> Threads do update the GUI (via Synchronise calls) infrequently (rate is
> adjustable).
>
> Due to the simplicity of the code  (No shared structures other than the
> GUI),  the "workers" do not need to resort to internal thread safety
> techniques (e.g.: Using TThreadList instead of TList).
>
> Results:
>  Single CPU, or HT OFF:    No significant difference in total time for
> 1 vs 2 or more threads (as expected)
>
>  P4 2.8 HT ON: 2 or more Threads runs at 200% the speed of 1.
>
>  AMD X2 (dual core): 2 or more Threads runs at 185% the speed of 1.
>
> So,  if you are running cpu-bound tasks on an HT system and do not see
> an improvement with 2 or more threads, then your Threading code is not
> optimal.
>
>
> HOWEVER
> Performance of a Single Threaded application with HT turned on is only
> 55% of the performance when HT is turned off.
>
> So using HT reduces the performance of a single threaded application
> (e.g. the Delphi IDE & Compiler), but provides 110% of the performance
> when multi-threading is used.
>
> Given that most Systems in the future will feature multiple cores, then
> for Compute-bound applications, then it makes sense to incorporate
> Multi-threading techniques (if you implement them correctly).
>
>
>
> Cheers
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
>



-- 
Kyley Harris
Harris Software
+64-21-671-821
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.adventureeducation.co.nz/pipermail/delphi/attachments/20071113/a4920312/attachment.html