Subj : Re: hyperthreading in database-benchmarks
To   : comp.arch,comp.programming.threads
From : Chris Thomasson
Date : Tue Oct 11 2005 05:14 am

"Oliver S." <Follow.Me@gmx.net> wrote in message 
news:434b7d0d$0$66453$892e7fe2@authen.white.readfreenews.net...
>> It depends on application design.
>> Two threads on the same core are tightly coupled together.
>
> I don't want to talk about SMT in general, but SMT in secarios where
> a lot of load-stalls occur in each thread.
>
>> You would need to try to ensure that reader threads that are bound
>> to a single SMT core access similar data, and preferably execute
>> down similar code-paths. Cache locality is very important, false-sharing, 
>> cache-blocking, ect...
>> Usually, lock-free designs that avoid atomic operations and StoreLoad
>> style memory barriers are able to make "some" performance gains on an
>> SMT system...
>
> Aaaaah, it's unbelievable - you are such an IDIOT!
> You're again mis-using a thread with very common blah-blah to demonstrate
> your lock-free and thrading competencies and not to really contribute to
> the discussion. Please shut up until you understood the constraints of
> database-engines.


http://groups.google.com/group/comp.arch/msg/2f40a2aaeb8cacb6?hl=en

:O

.