On 2009-10-28, Ignoramus27237 <ignoramus27237 at (no spam) NOSPAM.27237.invalid> wrote:
On 2009-10-28, DanS <t.h.i.s.n.t.h.a.t at (no spam) r.o.a.d.r.u.n.n.e.r.c.o.m> wrote:
Ignoramus27237 <ignoramus27237 at (no spam) NOSPAM.27237.invalid> wrote in
news:QtidnSTzfZ1mE3rXnZ2dnUVZ_tadnZ2d at (no spam) giganews.com:

I wrote a test perl script,

why would anyone use PERL for performance...


This was a test. The actual app is in C++. But a perl; script is a
much cleaner test because it is much simpler.

Then it?s not very representative of the actual task.

It may not be representative of the actual task, but it is not very
far.

I really do not want the discussion to stray into this area.

And what DO you want? You are using a kernel that predates your CPU.
It is NOT optimized to run on your CPU, and will NOT run optimally.
If you'd like to test the performance, test it on a kernel that has
been built and optimized for the CPU you are running it on.

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Tue, 27 Oct 2009 17:31:58 -0500, Ignoramus27237 wrote:


At work, we have some users who ru a multithreaded app, and they need
every single bit of performance we can squeeze from computers.


snip

This is Ubuntu Hardy, 2.6.24 kernel.

Thanks

IME, the 2.6.2x kernel series performance was all over the map*. IMO,
you'd be better off investigating the "latest and greatest," beginning
with a new kernel in the 2.6.3x series. This is especially true if you
are truly seeking the best performance. The kernel's changelog shows major
modifications with respect to its scheduler, block io, and filesystem
subsystems.

I tried 2.6.31.5, made no difference, same shit exactly. I spent all
morning googling. Still looking.

i

Caveat: I am not running Ubuntu.

On Wed, 28 Oct 2009 11:56:54 -0500, Ignoramus8868 wrote:

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Tue, 27 Oct 2009 17:31:58 -0500, Ignoramus27237 wrote:


At work, we have some users who ru a multithreaded app, and they need
every single bit of performance we can squeeze from computers.


snip

This is Ubuntu Hardy, 2.6.24 kernel.

Thanks

IME, the 2.6.2x kernel series performance was all over the map*. IMO,
you'd be better off investigating the "latest and greatest," beginning
with a new kernel in the 2.6.3x series. This is especially true if you
are truly seeking the best performance. The kernel's changelog shows major
modifications with respect to its scheduler, block io, and filesystem
subsystems.

I tried 2.6.31.5, made no difference, same shit exactly. I spent all
morning googling. Still looking.

i

Caveat: I am not running Ubuntu.

If you did not compile the kernel, then you should at least verify
what the critical kernel configuration parameters are for the kernel
that you are using.

CPU architecture
SLAB/SLUB
block io elevator

Note: it is possible to test various block elevators via a boot parameter.
I have had the best result with the anticipatory scheduler, and I avoid
the CFQ. YMMV.

Also, hyperthreading is only one method for increasing
performance. AFAIK, it is less effective than separate "physical"
cores.

It works by making sure that processor pipelines are well
utilized. For a while it went out of fashion (i.e. upon transition
from Pentium IV to Core 2 architecture). Hyperthreading is being
reintroduced with the Atom and i7 architectures. What specific
hardware is deployed to the power users?

The results were actually a disappointment, if the number of tasks was
equal to the number of physical cores. For the test with four parallel
subprocesses, on four CPUs, It takes longer to run it with HT than
without HT.

On 10/27/2009 03:31 PM, Ignoramus27237 wrote:
...
The results were actually a disappointment, if the number of tasks was
equal to the number of physical cores. For the test with four parallel
subprocesses, on four CPUs, It takes longer to run it with HT than
without HT.

Sorry, no answers but, I remember this being an issue in FreeBSD for a
number of years. AFAIK, two things have changed the situation for the
better: they rewrote ULE from a "Giant Lock" scheduler to a more
granular locking mechanism in circa FreeBSD 6. Also, apparently HTT is
substantially reworked in Intel's new i7 line.

There's some discussion & testing of it by a gent named Graaf in the
FreeBSD forums at:

http://forums.freebsd.org/showthread.php?t=2561
http://forums.freebsd.org/showthread.php?t=3185

On Wed, 28 Oct 2009 11:56:54 -0500, Ignoramus8868 wrote:

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Tue, 27 Oct 2009 17:31:58 -0500, Ignoramus27237 wrote:


At work, we have some users who ru a multithreaded app, and they need
every single bit of performance we can squeeze from computers.


snip

This is Ubuntu Hardy, 2.6.24 kernel.

Thanks

IME, the 2.6.2x kernel series performance was all over the map*. IMO,
you'd be better off investigating the "latest and greatest," beginning
with a new kernel in the 2.6.3x series. This is especially true if you
are truly seeking the best performance. The kernel's changelog shows
major modifications with respect to its scheduler, block io, and
filesystem subsystems.

I tried 2.6.31.5, made no difference, same shit exactly. I spent all
morning googling. Still looking.

i

Caveat: I am not running Ubuntu.

If you did not compile the kernel, then you should at least verify what
the critical kernel configuration parameters are for the kernel that you
are using.

CPU architecture
SLAB/SLUB
block io elevator

Note: it is possible to test various block elevators via a boot
parameter. I have had the best result with the anticipatory scheduler,
and I avoid the CFQ. YMMV.

Also, hyperthreading is only one method for increasing performance.
AFAIK, it is less effective than separate "physical" cores. It works by
making sure that processor pipelines are well utilized. For a while it
went out of fashion (i.e. upon transition from Pentium IV to Core 2
architecture). Hyperthreading is being reintroduced with the Atom and i7
architectures. What specific hardware is deployed to the power users?

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Wed, 28 Oct 2009 11:56:54 -0500, Ignoramus8868 wrote:

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Tue, 27 Oct 2009 17:31:58 -0500, Ignoramus27237 wrote:


At work, we have some users who ru a multithreaded app, and they need
every single bit of performance we can squeeze from computers.


snip

This is Ubuntu Hardy, 2.6.24 kernel.

Thanks

IME, the 2.6.2x kernel series performance was all over the map*. IMO,
you'd be better off investigating the "latest and greatest," beginning
with a new kernel in the 2.6.3x series. This is especially true if you
are truly seeking the best performance. The kernel's changelog shows major
modifications with respect to its scheduler, block io, and filesystem
subsystems.

I tried 2.6.31.5, made no difference, same shit exactly. I spent all
morning googling. Still looking.

i

Caveat: I am not running Ubuntu.

If you did not compile the kernel, then you should at least verify
what the critical kernel configuration parameters are for the kernel
that you are using.

I did compile it by myself.

I noted, later on, that my architecture was set to Pentium 4. I
changed it to i586/i686 and will try it again. I do not expect any
improvement, but it deserves a try.

I see something like that under "processor family":

CPU architecture
SLAB/SLUB
block io elevator

Note: it is possible to test various block elevators via a boot
parameter. I have had the best result with the anticipatory scheduler,
and I avoid the CFQ. YMMV.

How would I explore and change those values?

Append the "elevator=" parameter to your kernel line (if using the grub

Also, hyperthreading is only one method for increasing performance.
AFAIK, it is less effective than separate "physical" cores.

Yep.

It works by making sure that processor pipelines are well utilized. For
a while it went out of fashion (i.e. upon transition from Pentium IV to
Core 2 architecture). Hyperthreading is being reintroduced with the
Atom and i7 architectures. What specific hardware is deployed to the
power users?


This is the new kind, 2.4 GHZ Intel 4 physical core hyperthreaded
processor, that can look like 8 cores to the OS. This is basically the
latest stuff, although not the highest CPU frequency.

I desperately want it to run at peak performance, like I could do with
my test script using manual allocation with "taskset".

Then it will be a huge boost to Linux use on desktop in our company for
those power users that need every bit of CPU power, and a real benefit
to my employer.

As of now, hyperthreading's benefit is elusive, and I think that the
answer lies close nearby.

i
Note: comments inline.

I'm surprised that Intel brought hyperthreading back in the I7, it adds
complexity without providing much gain.

The theory behind hyperthreading is that you can get higher
efficiency by using a pipe to process two or more unrelated
instruction streams. Unrelated streams have no dependencies between
them so you can schedule instructions based on available resources
without being constrained by the dependencies within a single
stream. This is helpful if you can't use your pipe efficiently with
a single stream. The hard problem in instruction scheduling are
conditional branches which are very common in most code. If you have
a long pipe and you guess wrong about the direction of a branch then
you end up throwing away a lot of work. The P4 had a very long pipe,
28 stages in the last incarnations of that architecture. A wrongly
predicted branch would end up costing you a lot of cycles, probably
not all 28 cycles but close to that. If you were to run two separate
streams down that pipe then it would look like two 14 stage
pipelines rather than a single 28 stage pipeline. As a result a
wrongly predicted branch is half as expensive, so in theory much
less work would be wasted.

The iCore7 has a much shorter pipeline to
begin with so the cost of a mispredicted branch is less. Also branch
prediction algorithms have been improved so the iCore7 guesses wrong
less often. As a result the potential gain from hyperthreading is
much less. Hyperthreading has a negative side also. Some resources
are in short supply, in the iCore7 this is principally cache, in the
P4 registers there weren't enough registers either. If you run more
instruction streams simultaneously you end up contending for the
scarce resource.

The iCore7 is undercached to begin with. The Core2
had 6M for two cores while the Core7 has 8M for four cores. If you
also turn on hyperthreading you are down to 1M per thread. It's
actually not as simple as that. It's a common cache so every thread
is contending for the same cache blocks. If the cache was much
larger this wouldn't be a problem but it's a pretty small cache even
for four threads let alone eight so it is an issue. Imagine 8 people
trying to share a two bedroom apartment, they would be throwing each
others things in the street all the time. My experiments on my
workload have shown that the different effects mostly cancel each
other out so I keep hyperthreading enabled but I don't think it
makes more than a 1 or 2% difference either way.

If the cache was much larger this wouldn't be a
problem but it's a pretty small cache even for four threads let alone
eight so it is an issue.

Imagine 8 people trying to share a two bedroom
apartment, they would be throwing each others things in the street all
the time.

I told you...that is my milk! And stop drinking out of the carton!

snip

On Wed, 28 Oct 2009 12:37:33 -0500, Ignoramus8868 wrote:

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Wed, 28 Oct 2009 11:56:54 -0500, Ignoramus8868 wrote:

On 2009-10-28, Douglas Mayne <doug at (no spam) sl12.localnet> wrote:
On Tue, 27 Oct 2009 17:31:58 -0500, Ignoramus27237 wrote:


At work, we have some users who ru a multithreaded app, and they need
every single bit of performance we can squeeze from computers.


snip

This is Ubuntu Hardy, 2.6.24 kernel.

Thanks

IME, the 2.6.2x kernel series performance was all over the map*. IMO,
you'd be better off investigating the "latest and greatest," beginning
with a new kernel in the 2.6.3x series. This is especially true if you
are truly seeking the best performance. The kernel's changelog shows major
modifications with respect to its scheduler, block io, and filesystem
subsystems.

I tried 2.6.31.5, made no difference, same shit exactly. I spent all
morning googling. Still looking.

i

Caveat: I am not running Ubuntu.

If you did not compile the kernel, then you should at least verify
what the critical kernel configuration parameters are for the kernel
that you are using.

I did compile it by myself.

I noted, later on, that my architecture was set to Pentium 4. I
changed it to i586/i686 and will try it again. I do not expect any
improvement, but it deserves a try.

I see something like that under "processor family":
586/K5/5x86/6x86/6x86MX.

I don't think I would choose that for my hardware. YMMV. I would choose
Pentium III- coppermine as the minimum, and when the hardware is
available, I would compile for Core 2. I am running 2.6.30.8 and I don't
see anything specific to i7, as of yet.

CPU architecture
SLAB/SLUB
block io elevator

Note: it is possible to test various block elevators via a boot
parameter. I have had the best result with the anticipatory scheduler,
and I avoid the CFQ. YMMV.

How would I explore and change those values?

Append the "elevator=" parameter to your kernel line (if using the grub
loader). See the file .../Documentation/kernel-parameters.txt in the
kernel source directory.

The iCore7 is undercached to begin with. The Core2 had
6M for two cores while the Core7 has 8M for four cores. If you also turn
on hyperthreading you are down to 1M per thread. It's actually not as
simple as that. It's a common cache so every thread is contending for the
same cache blocks. If the cache was much larger this wouldn't be a
problem but it's a pretty small cache even for four threads let alone
eight so it is an issue. Imagine 8 people trying to share a two bedroom
apartment, they would be throwing each others things in the street all
the time. My experiments on my workload have shown that the different
effects mostly cancel each other out so I keep hyperthreading enabled but
I don't think it makes more than a 1 or 2% difference either way.

General Schvantzkoph wrote:
The iCore7 is undercached to begin with. The Core2 had 6M for two cores
while the Core7 has 8M for four cores. If you also turn on
hyperthreading you are down to 1M per thread. It's actually not as
simple as that. It's a common cache so every thread is contending for
the same cache blocks. If the cache was much larger this wouldn't be a
problem but it's a pretty small cache even for four threads let alone
eight so it is an issue. Imagine 8 people trying to share a two bedroom
apartment, they would be throwing each others things in the street all
the time. My experiments on my workload have shown that the different
effects mostly cancel each other out so I keep hyperthreading enabled
but I don't think it makes more than a 1 or 2% difference either way.

So, for the price difference, would you say the i5 are comparable to the
i7, since they don't do hyperthreading?

If I were building another
system today I'd base it on the 8500 (which is a little faster than the
8400).

General Schvantzkoph wrote:
If I were building another
system today I'd base it on the 8500 (which is a little faster than the
8400).

Overclocking aside; you'd still prefer the e8500 over any of the core2
quads (excluding the i5/i7 quads of course)?

On Thu, 29 Oct 2009 00:04:13 -0400, johnny bobby bee wrote:
Overclocking aside; you'd still prefer the e8500 over any of the core2
quads (excluding the i5/i7 quads of course)?

Absolutely. Even if you don't overclock, the 8500 is a 3.16 GHz processor
at $189. The 920 is a 2.66GHz processor for $289, the 950 is a 3GHz