Re: hyperthreading

drak0nian_at_yahoo.com (Paul Drake) wrote in message news:<1ac7c7b3.0401121754.3864e038_at_posting.google.com>...
> joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0401121158.42cf7609_at_posting.google.com>...
> > Mladen Gogala <mgogala_at_adelphia.net> wrote in message news:<pan.2004.01.11.06.15.24.204294_at_adelphia.net>...
> > > On Fri, 09 Jan 2004 14:42:18 -0800, Joel Garry wrote:
> > >
> > > >
> > > > Now all we need is the 2.6 kernel and Oracle properly threaded to use
> > > > it.
> > >
> > > You would like to replace fork-ed processes with threads?
> > > Why would that be good? The problem is that threads all share
> > > the same address space while processes have their own address
> > > spaces. Shared are only certain critical sections which are
> > > known as "Shared Global Area". I should also add that the threads
> > > implementations are OS specific (ranging from light-weight processes
> > > to user mode thread which are actually serially executed in such a
> > > way that user thinks that threads are run concurrently. The latter are
> > > know as "green threads".). Using threads instead of fork & SYSV IPC would
> > > probably have disastrous consequences for performance. It would turn even
> > > the best Unix systems into an Xtreme Perversion, XP for short.
> >
> > I was hoping there would be coding that could be done on the Oracle
> > side to take advantage of hyperthreading. The idea is to use hardware
> > capabilities to improve things (I would speculate that such things as
> > SGA buffer maintenance could benefit from this). If you get 30%
> > improvement by using these capabilities, after the expense of a 50%
> > decrease simply moving away from forks, that would indeed be silly.
> > But if we're going to compete with other products optimized to use
> > perversion, we must look at how everything works together and not be
> > religious about ... whatever.
> >
> > jg
>
> there was a recent posting on 2cpu.com regarding benchmarking dual
> Xeon 2.8 GHz MP cpus vs single 3.2 GHz P IV.
>
> http://www.2cpu.com/articles/ht_explored/index.html
>
> The most impressive point had to do with memory bandwidth, as the dual
> Xeon MP at 2.8 GHz was stomped by the single 3.2 GHz chip due to the
> faster front side bus (400 MHz vs 533 MHz).
> Also noteworthy was the author's point that its likely that
> hyperthreading was thrashing the level 1 and level 2 caches, in some
> cases causing loss of performance relative to a non-hyperthreaded
> configuration.
>
> If the case that you are attempting to benchmark is use of the
> parallel query option where you are performing full table scans and
> frequently waiting on physical IO to take place, hyperthreading sounds
> like it would help, as while one thread is stalled the processor is
> busy executing on the other logical CPU.
>
> If you have a seriously heinous nested query running on both the
> physical and logical CPUs that performs no physical IOs and is
> completely memory bound (BCHR setter), I would think would provide a
> little or negative performance increase.
>
> guess the only way to find out is to benchmark them.
> I do have access to a Dell PE 2650 3.06 GHz 1 MB L3 cache server this
> week that has 9.2.0.4 loaded on both w2k3 server and RH 8.0, but
> that's not happening for me this week. Maybe next weekend.
>
> Pd

oh.
the OP linked to the article. How bout that? I don't know what to say other than, its a small internet after all, at least in hardware geek circles.

can't blame this one on anything, other than my own stupidity. and getting to post about dual 3.06 GHz 1 MB L3 Xeons.

Pd Received on Tue Jan 13 2004 - 00:41:56 CST