mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Andy Isaacson <adi@hexapodia.org>
Cc: max@vortex.physik.uni-konstanz.de,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.0-test4 shocking (HT) benchmarking (wrong logic./phys. HT CPU distinction?)
Date: Tue, 26 Aug 2003 15:12:46 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0308261455590.4526@chaos> (raw)
In-Reply-To: <20030826135051.A16285@hexapodia.org>

On Tue, 26 Aug 2003, Andy Isaacson wrote:

> On Tue, Aug 26, 2003, max@vortex.physik.uni-konstanz.de wrote:
> > in our fine physics group we recently bought a DUAL XEON P4 2666MHz, 2GB,
> > with
> > hyper-threading support and I had the honour of making the thing work.
> > In the
> > process I also did some benchmarking using two different kernels (stock
> > SuSE-8.2-Pro 2.4.20-64GB-SMP, and the latest and greatest vanilla
> > 2.6.0-test4). I benchmarked
> >
> > [2] running time of a multi-threaded numerical simulation making
> > extensive use of FFTs, using the fftw.org library.
>
> One thing to watch out for, with fftw:  I believe it will benchmark
> various kernels, and decide which one to use, at run-time.  If the
> scheduler fools it into thinking that a particular kernel is going to
> perform better, it might do the wrong thing.
>
> Does fftw have a switch to write a debug log?
>
> ("kernel" in this context means "the small section of code used to solve
> the fft", not "the OS code running in privileged mode".)
>
> -andy

The benchmarks in the fftw.org libraries are useful only as
time-sinks. At least on ix86, our tests show that a generic
fft, perhaps 10 years old, with no special treatment except
using pointers instead of indexes, when using 'double' as
float, is, within the test noise, as fast as their "self-
adapting" fft.

Also, the nature of a fft, reduces the influence of the kernel.
Even with some kind of parallelism, for which there is little
chance because of the serial nature of a fft, you are testing
threads, not the kernel. To the kernel, a fft is just some
CPU bound math.

If you are going to do a lot of math simulation and are not
going to be creating a lot of separate tasks that communicate,
your choice of kernel (or operating system) is irrelevant.
This kind of math-code just sits in user's memory plugging
along until it writes its results to something, somewhere.
The kernel is not involved until the answers are available.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



  reply	other threads:[~2003-08-26 19:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-26 13:52 max
2003-08-26 16:36 ` Stan Bubrouski
2003-08-26 18:50 ` Andy Isaacson
2003-08-26 19:12   ` Richard B. Johnson [this message]
2003-08-27 13:40     ` Andrew Theurer
2003-08-26 19:20 ` bill davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.53.0308261455590.4526@chaos \
    --to=root@chaos.analogic.com \
    --cc=adi@hexapodia.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max@vortex.physik.uni-konstanz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®