Posted by
michael
on from the make-kpkg-kernel_image dept.
Sivar writes "Andrew Morton of EXT3 fame has posted benchmarks of Linux 2.5.47 prerelease compared with the latest from the current 2.4 series. With some tasks more than tripling in performance, the future looks very promising."
Re:Can't get a speedup of more than 10
by
Zorton
·
· Score: 3, Insightful
So in other words the more time you spend rescheduling things the less time you have for executing the code you have scheduled.
Hmm..... sounds like modern business management:)
Re:Make it simple please
by
straponego
·
· Score: 2, Insightful
You mean, when will compiling a Linux kernel, which most users will never need to do, become as straightforward as recompiling your Windows kernel, which you can't do?
make xconfig && make dep && make bzImage && make modules && make modules_install && make install
Re:Nice to see Linux "Growing Up"
by
iabervon
·
· Score: 3, Insightful
IBM is also going to stay in the high-end hardware department; it'll be "Sure commodity hardware is great for the workstation, but what about your 8 TB database that has to survive even if someone saws it in half down the middle?" This also puts them in, essentially, the BIOS department for these machines (you want to run you web site off of whatever portion of your database machine isn't actually being used by the database, without risking problems if the web server gets hacked).
Re:By Sturgeon's Law
by
rangek
·
· Score: 2, Insightful
The parent post should be ignored. The information content, while real, is misapplied, and that "10" number is pulled out of his ass.
That is what I thought at first, too. But the orignal poster is right (in a way), a factor of 10 is about the best you can hope for when parallelizing code. Since Amdahl's (or some other guy's) law also says something like 90% of the time is spent in 10% of the code. That makes s=10 and p=90. The limit of his equation, (s+p)/(s+p/n), as n goes to infinity is 10. A number not pulled out of anyone's ass.
Maybe the original poster should be moderated down because I don't think the stuff here is really about parallelization (they talk about speed ups on uniproc systems too), but for the parallel case, he seems to be right.
Re:By Sturgeon's Law
by
Daniel+Phillips
·
· Score: 2, Insightful
the orignal poster is right (in a way), a factor of 10 is about the best you can hope for when parallelizing code. Since Amdahl's (or some other guy's) law also says something like 90% of the time is spent in 10% of the code. That makes s=10 and p=90.
No it doesn't. How do you know the 90% is serializable and the 10% isn't? Answer: you don't, there is no relationship whatsoever.
Karma whore or just trolling?
by
Dante
·
· Score: 3, Insightful
If I pulled a gif compleatly out of context as proof of anything would you trust me?
-- "think of it as evolution in action"
Re:This is This is the exact opposite of my findin
by
Sivar
·
· Score: 2, Insightful
The P4 has notoriously slow context switching performance.
The Pentium IV has notoriously slow performance in some areas, but a processor being slow in context switching doesn't make sense. Depending on the context(English context, not computer context), context switching is either the system switching from kernel mode (running kernel code) to user mode (user applications) or vice-versa, OR it is simply moving from one execution path to another (as was scheduled by the, um, scheduler)
The processor has nothing to do with it. Context switching in BOTH instances is handled entirely by the operating system. While Windows NT 3.1 may have "slow context switching" and Linux with the O(1) scheduler may have "fast context switching", the Pentium IV cannot "have fast or slow context switching" because it doesn't have anything to do with the Pentium IV.
One might theorize that the original poster's comment was refering to the Pentium IV being particularly slow at the actual instructions used in context switching. Regarding the discussion of the kernel scheduler, the meaning of "context switching" that we are using probably refers to switching between tasks (AKA multitasking), so the important instructions would simply be jump instructions like "jmp", which AFAIK are not particularly slow on the Pentium IV like, say, bit shifting (which is glacially slow on the Pentium IV).
-- Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Re:Make it simple please
by
momobaxter
·
· Score: 3, Insightful
A home user (meaning non hacker) never has the need to recompile a kernel. NEVER. Your distribution has all the modules available and if you're running the more popular distros, they will even detect your hardware and load the module for you.
Sometimes people shouldn't mess with stuff, the kernel is one of those things. RedHat does a good job with their builds and an average user doesn't need to rebuilt it at all. A more experienced user might want to tweak, but then he can use make menuconfig or make config...and choose his options.
My grandmother will never recompile her kernel.
-- "Full sources for linux currently runs to about 200kB compressed" --Linus Torvalds 31-Jan-1992
Re:Make it simple please
by
Anonymous Coward
·
· Score: 1, Insightful
The kernel only has an expert mode. It would be nice if there were a higher order config that asked you basic questions and built the things you were most likely to need
There are. They are called RedHat, Mandrake, SuSE, etc.
> would be to tag certain processes so that they > will never be moved into swap for disk buffers
I beleive that this is what the sticky bit was intended for. Before I go about explaining what it is and how to use it, does anyone know if Linux actually *honors* the sticky bit or does it just have it for compatibility?
Slashdot Mirror
So in other words the more time you spend rescheduling things the less time you have for executing the code you have scheduled.
:)
Hmm..... sounds like modern business management
make xconfig && make dep && make bzImage && make modules && make modules_install && make install
IBM is also going to stay in the high-end hardware department; it'll be "Sure commodity hardware is great for the workstation, but what about your 8 TB database that has to survive even if someone saws it in half down the middle?" This also puts them in, essentially, the BIOS department for these machines (you want to run you web site off of whatever portion of your database machine isn't actually being used by the database, without risking problems if the web server gets hacked).
That is what I thought at first, too. But the orignal poster is right (in a way), a factor of 10 is about the best you can hope for when parallelizing code. Since Amdahl's (or some other guy's) law also says something like 90% of the time is spent in 10% of the code. That makes s=10 and p=90. The limit of his equation, (s+p)/(s+p/n), as n goes to infinity is 10. A number not pulled out of anyone's ass.
Maybe the original poster should be moderated down because I don't think the stuff here is really about parallelization (they talk about speed ups on uniproc systems too), but for the parallel case, he seems to be right.
the orignal poster is right (in a way), a factor of 10 is about the best you can hope for when parallelizing code. Since Amdahl's (or some other guy's) law also says something like 90% of the time is spent in 10% of the code. That makes s=10 and p=90.
No it doesn't. How do you know the 90% is serializable and the 10% isn't? Answer: you don't, there is no relationship whatsoever.
Sheesh.
Have you got your LWN subscription yet?
If I pulled a gif compleatly out of context as proof of anything would you trust me?
"think of it as evolution in action"
The P4 has notoriously slow context switching performance.
The Pentium IV has notoriously slow performance in some areas, but a processor being slow in context switching doesn't make sense. Depending on the context(English context, not computer context), context switching is either the system switching from kernel mode (running kernel code) to user mode (user applications) or vice-versa, OR it is simply moving from one execution path to another (as was scheduled by the, um, scheduler)
The processor has nothing to do with it. Context switching in BOTH instances is handled entirely by the operating system. While Windows NT 3.1 may have "slow context switching" and Linux with the O(1) scheduler may have "fast context switching", the Pentium IV cannot "have fast or slow context switching" because it doesn't have anything to do with the Pentium IV.
One might theorize that the original poster's comment was refering to the Pentium IV being particularly slow at the actual instructions used in context switching. Regarding the discussion of the kernel scheduler, the meaning of "context switching" that we are using probably refers to switching between tasks (AKA multitasking), so the important instructions would simply be jump instructions like "jmp", which AFAIK are not particularly slow on the Pentium IV like, say, bit shifting (which is glacially slow on the Pentium IV).
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
A home user (meaning non hacker) never has the need to recompile a kernel. NEVER. Your distribution has all the modules available and if you're running the more popular distros, they will even detect your hardware and load the module for you.
Sometimes people shouldn't mess with stuff, the kernel is one of those things. RedHat does a good job with their builds and an average user doesn't need to rebuilt it at all. A more experienced user might want to tweak, but then he can use make menuconfig or make config...and choose his options.
My grandmother will never recompile her kernel.
"Full sources for linux currently runs to about 200kB compressed" --Linus Torvalds 31-Jan-1992
There are. They are called RedHat, Mandrake, SuSE, etc.
> would be to tag certain processes so that they
> will never be moved into swap for disk buffers
I beleive that this is what the sticky bit was intended for. Before I go about explaining what it is and how to use it, does anyone know if Linux actually *honors* the sticky bit or does it just have it for compatibility?