Re: kernel 2.6 speed
[EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
[EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
- Original Message - From: "Florin Malita" <[EMAIL PROTECTED]> To: "Linux Kernel Mailing List" Sent: Monday, July 25, 2005 12:10 AM Subject: Re: kernel 2.6 speed > On 7/24/05, Alan Cox <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
- Original Message - From: Florin Malita [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
On Mon, Jul 25, 2005 at 12:10:15AM -0400, Florin Malita wrote: > On 7/24/05, Alan Cox <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
On 7/24/05, Alan Cox <[EMAIL PROTECTED]> 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() ... :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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();
while(count++ < LOTS) {
Do_stuff
}
time()
and you'll find the numbers on pure CPU work are essentially CPU bound
not OS affected at all
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
>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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
On 7/24/05, Ciprian <[EMAIL PROTECTED]> 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(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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
#include
int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;
time();
testTime = initialTime;
printf("Here we go...\n");
while((testTime-initialTime) < 30)
{
time();
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 [EMAIL PROTECTED]
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
#include
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel 2.6 speed
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
#include
int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;
time();
testTime = initialTime;
printf("Here we go...\n");
while((testTime-initialTime) < 30)
{
time();
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kernel 2.6 speed
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
On 7/24/05, Ciprian [EMAIL PROTECTED] 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(). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
On 7/24/05, Alan Cox [EMAIL PROTECTED] 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() ... :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6 speed
On Mon, Jul 25, 2005 at 12:10:15AM -0400, Florin Malita wrote: On 7/24/05, Alan Cox [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
