Subj : Re: hyperthreading in database-benchmarks To : comp.arch,comp.programming.threads From : dgay Date : Tue Oct 11 2005 10:34 am "Chris Thomasson" <_no_spam_cristom@no_spam_comcast._net> writes: > "Oliver S." 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 The first entry in my new kill file! -- David Gay dgay@acm.org .