kernel 2.6 speed

kernel 2.6 speed

[Ciprian]

Hi guys!

I got a question for you. Apparently kernel 2.6 is
much slower then 2.4 and about 30 times slower then
the windows one.

I'm not an OS guru, but I ran a little and very simple
test. The program bellow, as you can see, measures the
number of cycles performed in 30 seconds.

//----------------- START CODE --------------------

#include <stdio.h>
#include <time.h>


int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;


time(&initialTime);
testTime = initialTime;

printf("Here we go...\n");

while((testTime-initialTime) < 30)
{
time(&testTime);
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf("No. of cycles: %ld\n", counter);

return 0;
}

//---------------- END CODE -------------------


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 published my little test on several forums and I
wasn't the only one who got these results. All the
other users using 2.6 kernel obtained similar results
regardless of the CPU they had (Intel or AMD). 

Also I downloaded the latest kernel (2.6.12),
configured it specifically for my machine, disabled
all the modules I don't need and compiled it. The
result was a 1.7 MB kernel on which KDE moves faster,
but the processing speed it's the same - same huge
speed ratios.

Also, it shouldn't have any importance, but my HDD is
SATA so the specific modules were required. I don't
think its SCSI modules have any impact on the
processing speed, but you know more on the kernel
architecture then I do.

Now, can anyone explain this and suggest what other
optimizations I should use? The 2.4 version was a lot
faster. I thought the newer versions were supposed to
work faster (or at least just as fast) AND to offer
extra features.

Any help would appreciate.

Thanks,
Ciprian



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: kernel 2.6 speed

[Brice Goglin]

Le 24.07.2005 21:12, Ciprian a écrit :
> while((testTime-initialTime) < 30)
> {
> time(&testTime);
> test /= 10;
> test *= 10;
> test += 10;
> test -= 10;
> 
> counter ++;
> 
> }

> 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.

Hi,

This test gives you the price of the time function on each OS
since the 4 arithmetical operations are shorter to compute
(several cycles against tons of cycles). It appears that the time
function costs about 3 us on Linux against 0.1 us on Windows.
This function is probably very OS-dependant since it depends on
how the kernel handles timing. You can't compare anything as small
as these arithmetical operations like this.  Using rdtsc would be
much better.

Anyway, if you just want to measure the cost of arithmetic
operations, there shouldn't be any difference in the results
between Linux and Windows (with a safe timing method).

Brice

Re: kernel 2.6 speed

[Dag Nygren]

> 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 published my little test on several forums and I
> wasn't the only one who got these results. All the
> other users using 2.6 kernel obtained similar results
> regardless of the CPU they had (Intel or AMD). 

Looking at the gcc-produced code from youe test program I 
can see the floating point math beeing optimized away all
together as you are not using the result and the rest more
or less boils down to the call to time() and a few moves
and compares of the time values.
In other words it seems like you are testing the efficiency of
the time() function...

BRGDS
Dag

Re: kernel 2.6 speed

[Puneet Vyas]

Ciprian wrote:

>Hi guys!
>
>I got a question for you. Apparently kernel 2.6 is
>much slower then 2.4 and about 30 times slower then
>the windows one.
>
>I'm not an OS guru, but I ran a little and very simple
>test. The program bellow, as you can see, measures the
>number of cycles performed in 30 seconds.
>
>//----------------- START CODE --------------------
>
>#include <stdio.h>
>#include <time.h>
>
>
>int main()
>{
>time_t initialTime;
>time_t testTime;
>long counter = 0;
>double test = 1;
>
>
>time(&initialTime);
>testTime = initialTime;
>
>printf("Here we go...\n");
>
>while((testTime-initialTime) < 30)
>{
>time(&testTime);
>test /= 10;
>test *= 10;
>test += 10;
>test -= 10;
>
>counter ++;
>
>}
>
>printf("No. of cycles: %ld\n", counter);
>
>return 0;
>}
>
>//---------------- END CODE -------------------
>
>
>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 published my little test on several forums and I
>wasn't the only one who got these results. All the
>other users using 2.6 kernel obtained similar results
>regardless of the CPU they had (Intel or AMD). 
>
>Also I downloaded the latest kernel (2.6.12),
>configured it specifically for my machine, disabled
>all the modules I don't need and compiled it. The
>result was a 1.7 MB kernel on which KDE moves faster,
>but the processing speed it's the same - same huge
>speed ratios.
>
>Also, it shouldn't have any importance, but my HDD is
>SATA so the specific modules were required. I don't
>think its SCSI modules have any impact on the
>processing speed, but you know more on the kernel
>architecture then I do.
>
>Now, can anyone explain this and suggest what other
>optimizations I should use? The 2.4 version was a lot
>faster. I thought the newer versions were supposed to
>work faster (or at least just as fast) AND to offer
>extra features.
>
>Any help would appreciate.
>
>Thanks,
>Ciprian
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Want to increase the latest kernel "speed" by 5 times ? Use the 
follwoing code instead. :)

// -- Start Code
#include <stdio.h>
#include <time.h>


int main()
{
clock_t initialTime;
clock_t testTime;
long counter = 0;
double test = 1;


initialTime = clock() / CLOCKS_PER_SEC;
testTime = initialTime;

printf("Here we go...\n");

while((testTime-initialTime) < 30)
{
testTime = clock()/CLOCKS_PER_SEC;
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf("No. of cycles: %ld\n", counter);

return 0;
}
// ---- End code

so essentially you are timing just the time() function.

HTH,
Puneet

Re: kernel 2.6 speed

[Florin Malita]

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().

Re: kernel 2.6 speed

[Lee Revell]

On Sun, 2005-07-24 at 17:03 -0400, Florin Malita wrote:
> the x86 timer interrupt
> frequency has increased from 100Hz to 1KHz (it's about to be lowered
> to 250Hz)

This is by no means a done deal.  So far no one has posted ANY evidence
that dropping HZ to 250 helps (except one result on a atypically large
system), and there's plenty of evidence that it doesn't.

Lee

Re: kernel 2.6 speed

[Bill Davidsen]

Lee Revell wrote:
> On Sun, 2005-07-24 at 17:03 -0400, Florin Malita wrote:
> 
>>the x86 timer interrupt
>>frequency has increased from 100Hz to 1KHz (it's about to be lowered
>>to 250Hz)
> 
> 
> This is by no means a done deal.  So far no one has posted ANY evidence
> that dropping HZ to 250 helps (except one result on a atypically large
> system), and there's plenty of evidence that it doesn't.

If nothing else it does seem to make media applications unhappy under 
some loads.

I personally think 1k should stay the default and let people with 
special needs use the other. Nice to select at boot time, people who 
need accuracy above all could use 866 (or whatever tick rate near that 
was the lowest error).
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: kernel 2.6 speed

[Jan Engelhardt]

>I got a question for you. Apparently kernel 2.6 is
>much slower then 2.4 and about 30 times slower then
>the windows one.
>
>I'm not an OS guru, but I ran a little and very simple
>test. The program bellow, as you can see, measures the
>number of cycles performed in 30 seconds.

I suggest that you take out the time stuff and measure the whole running time, 
at the shell level.
Under Linux you can do that using "time ./myprog" - how you do it under 
Windows is another concern, but you can write a small "time" program for 
windows, too.


Jan Engelhardt
-- 

Re: kernel 2.6 speed

[Alan Cox]

On Sul, 2005-07-24 at 12:12 -0700, Ciprian wrote:
> I'm not an OS guru, but I ran a little and very simple
> test. The program bellow, as you can see, measures the
> number of cycles performed in 30 seconds.

No it measures the performance of the "time()" call. Windows has some
funky optimisations that we never bother with because time() isn't a hot
path in the real world.

Instead try code which does


time(&start);
while(count++ < LOTS) {
  Do_stuff
}
time(&end)

and you'll find the numbers on pure CPU work are essentially CPU bound
not OS affected at all

Re: kernel 2.6 speed

[Florin Malita]

On 7/24/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> time() isn't a hot
> path in the real world.

That's what you would expect but I've straced stuff calling
gettimeofday() in huge bursts every other second. Obviously braindead
stuff but so is "the real world" most of the time() ... :)

Re: kernel 2.6 speed

[Willy Tarreau]

On Mon, Jul 25, 2005 at 12:10:15AM -0400, Florin Malita wrote:
> On 7/24/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > time() isn't a hot
> > path in the real world.
> 
> That's what you would expect but I've straced stuff calling
> gettimeofday() in huge bursts every other second. Obviously braindead
> stuff but so is "the real world" most of the time() ... :)

gettimeofday() is known to be called very often (after any select() or
poll() returns), and is optimized for such conditions. There was even
an implementation, which I don't know if it finally became mainstream,
which optimized this particular system call. Some networking applications
might call it tens of thousands of times per second.

But as Alan said, time() (not to be confused with gettimeofday()) is
not a hot path.

Willy

Re: kernel 2.6 speed

[Ciprian]

Thanks guys for your help. I should have asked you
this right from the beginning. :)

Ciprian

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: kernel 2.6 speed

[cutaway]

----- Original Message ----- 
From: "Florin Malita" <fmalita@gmail.com>
To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Monday, July 25, 2005 12:10 AM
Subject: Re: kernel 2.6 speed


> On 7/24/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > time() isn't a hot
> > path in the real world.
>
> That's what you would expect but I've straced stuff calling
> gettimeofday() in huge bursts every other second. Obviously braindead
> stuff but so is "the real world" most of the time() ... :)

Anything time stamping things it processes many of will call some sort of
time function pretty often.  Could happen frequently with certain classes of
applications.    OS/2's "infoseg" approach was a pretty "high speed low
drag" way to eliminate a trip into the kernel for all but the most esoteric
time requirements.

Re: kernel 2.6 speed

[Florin Malita]

cutaway@bellsouth.net wrote:
> Anything time stamping things it processes many of will call some sort of
> time function pretty often.  Could happen frequently with certain classes of
> applications.

Right, but if the timestamp granularity is coarse and there's no 
blocking call in between it makes no sense to invoke 
gettimeofday()/time() repeatedly. I was referring to the kind of app 
that abuses them just because somebody is too lazy to reuse the previous 
value - calling gettimeofday() in 10 sequential printf() statements for eg.

There are legitimate scenarios of course, but this doesn't seem to be 
one of them:

15:22:38.825562 kill(2419, SIGRTMIN)    = 0
15:22:38.825748 gettimeofday({1122405758, 825765}, NULL) = 0
15:22:38.825801 gettimeofday({1122405758, 825812}, NULL) = 0
15:22:38.825845 gettimeofday({1122405758, 825856}, NULL) = 0
15:22:38.825888 gettimeofday({1122405758, 825899}, NULL) = 0
15:22:38.825931 time(NULL)              = 1122405758
15:22:38.825968 gettimeofday({1122405758, 825984}, NULL) = 0
15:22:38.826012 gettimeofday({1122405758, 826022}, NULL) = 0
15:22:38.826062 time(NULL)              = 1122405758
15:22:38.826099 time(NULL)              = 1122405758
15:22:38.826142 time(NULL)              = 1122405758
...

Here's another cute one, just in case you thought calling getpid() once 
should be enough ;)

15:31:15.376157 gettimeofday({1122406275, 376177}, NULL) = 0
15:31:15.376206 getpid()                = 2494
15:31:15.376238 getpid()                = 2494
15:31:15.376264 getpid()                = 2494
15:31:15.376291 getpid()                = 2494
15:31:15.376318 getpid()                = 2494
15:31:15.376344 getpid()                = 2494
15:31:15.376371 getpid()                = 2494
15:31:23.723801 getpid()                = 2494
15:31:23.723845 getpid()                = 2494
15:31:23.723873 getpid()                = 2494
15:31:23.723900 getpid()                = 2494
15:31:23.723927 getpid()                = 2494
15:31:23.723954 getpid()                = 2494
15:31:23.723984 getpid()                = 2494
15:31:23.724011 getpid()                = 2494
15:31:23.724038 getpid()                = 2494
15:31:23.724065 getpid()                = 2494
15:31:23.724091 getpid()                = 2494
15:31:23.724118 getpid()                = 2494
15:31:23.724145 getpid()                = 2494
15:31:23.724171 getpid()                = 2494
15:31:23.724198 getpid()                = 2494
15:31:23.724225 getpid()                = 2494
15:31:24.687109 getpid()                = 2494
15:31:24.687159 getpid()                = 2494
15:31:24.687197 getpid()                = 2494
15:31:24.687247 getpid()                = 2494
15:31:24.687283 getpid()                = 2494
15:31:24.687324 getpid()                = 2494
15:31:24.687364 getpid()                = 2494
15:31:24.687402 getpid()                = 2494
15:31:24.687442 getpid()                = 2494
15:31:24.687477 getpid()                = 2494
15:31:24.687512 getpid()                = 2494
15:31:24.687547 getpid()                = 2494
15:31:24.687583 getpid()                = 2494
15:31:24.687662 semop(32769, 0x430e2e0c, 1) = 0

My point: "real world" apps do stupid things.

Re: kernel 2.6 speed

[Henrik Holst]

>> 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.

> Hi,

> This test gives you the price of the time function on each OS
> since the 4 arithmetical operations are shorter to compute
> (several cycles against tons of cycles). It appears that the time
> function costs about 3 us on Linux against 0.1 us on Windows.

I know that this benchmark is totally flawed, but I couldn't refuse to 
run it on my own and
to my surprise my numbers where the reverse! Running 2.6.12 gave my 
roughly 73 million
"cycles" while WinXP only gave me 28 million "cycles".

This result made me further test the difference in time() in Linux and 
WinXP and on my hw
(Compaq Evo N800c Laptop) it turns out that the time() call takes 
roughly 0.4 us in Linux vs
1.0 us in WinXP.

Using the GetSystemTime() functions in WinXP yielded the same values as 
time() did in Linux,
so it seams like that atleast on my hw that the time() and 
gettimeofday() functions are as fast
or faster than in WinXP. The question is of course why my results differ 
so much from Ciprians.

/Henrik H