From: Florin Malita <fmalita@gmail.com>
To: Ciprian <cipicip@yahoo.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: kernel 2.6 speed
Date: Sun, 24 Jul 2005 17:03:59 -0400 [thread overview]
Message-ID: <f89941150507241403234949be@mail.gmail.com> (raw)
In-Reply-To: <20050724191211.48495.qmail@web53608.mail.yahoo.com>
On 7/24/05, Ciprian <cipicip@yahoo.com> wrote:
> test /= 10;
> test *= 10;
> test += 10;
> test -= 10;
You're not trying to benchmark the kernel with those arithmetic
operations are you?! That's completely bogus, the kernel is not
involved in any of that.
As it has been already pointed out, the only OS-dependent and (by far)
the most expensive operation in your loop is the time() function call
- so that's the only thing you're really benchmarking there (besides
compiler optimizations).
> In windows were performed about 300 millions cycles,
> while in Linux about 10 millions. This test was run on
> Fedora 4 and Suse 9.2 as Linux machines, and Windows
> XP Pro with VS .Net 2003 on the MS side. My CPU is a
> P4 @3GHz HT 800MHz bus.
I can only speculate as of why the windoze time() call seems so much
faster: maybe it is implemented in userspace and doesn't involve a
system call. Somebody with more knowledge in the area might
confirm/infirm this.
Even in Linux your results will vary a lot depending on whether the
kernel and glibc support vsyscalls. The FC kernels disable vsyscall
because it's incompatible with NX, not sure about the Suse kernels.
Here's what I get on a P4 1.7 with a vsyscall enabled kernel
(2.6.11.12):
No. of cycles: 65688977
Check this thread for a FC4 kernel performance discussion:
http://www.redhat.com/archives/fedora-devel-list/2005-June/msg01126.html
> Now, can anyone explain this and suggest what other
> optimizations I should use? The 2.4 version was a lot
> faster.
Your bogus test aside, a certain userland performance degradation when
moving from 2.4 to 2.6 is expected as the x86 timer interrupt
frequency has increased from 100Hz to 1KHz (it's about to be lowered
to 250Hz) - so your apps are interrupted more often. But I wouldn't
expect that degradation to be substantial. If you want to dig in and
measure it you should use asm/rdtsc instead of time().
next prev parent reply other threads:[~2005-07-24 21:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-24 19:12 kernel 2.6 speed Ciprian
2005-07-24 19:41 ` Brice Goglin
2005-07-24 19:47 ` Dag Nygren
2005-07-24 20:40 ` Puneet Vyas
2005-07-24 21:03 ` Florin Malita [this message]
2005-07-24 22:49 ` Lee Revell
2005-07-25 19:52 ` Bill Davidsen
2005-07-24 21:46 ` Jan Engelhardt
2005-07-24 23:47 ` Alan Cox
2005-07-25 4:10 ` Florin Malita
2005-07-25 5:18 ` Willy Tarreau
2005-07-25 6:47 ` Ciprian
2005-07-26 5:55 ` cutaway
2005-07-26 19:45 ` Florin Malita
-- strict thread matches above, loose matches on Subject: below --
2005-08-03 15:31 Henrik Holst
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=f89941150507241403234949be@mail.gmail.com \
--to=fmalita@gmail.com \
--cc=cipicip@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
/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