Slashdot Mirror
Who Has Faster Pipes? Linux, Win2000, WinXP Compared
SeaBait writes: "This revealing article about the High-performance programming techniques on Linux and Windows shows that Linux rules. The performance testing was on Pipes(interprocess communication mechanism available on both Windows and Linux and UNIX). Although I new Linux would fare the best, the poor performance of Windows XP was a surprise. Windows 2000 actually did better than XP!"
I'm a fan of Slashdot, but I get a little sick of the Windows/Linux comparisons, -especially- when the post includes something like "but THIS test shows that Linux rocks!" Yay. Are we going to argue over PCs vs. Macs next?
DrPascal: Not the language, the mathematician.
Ask your local MCSE, they'll tell you.
ROFL.
My beliefs do not require that you agree with them.
From the article..
Another distinction might the the "feature" of Windows pipes where there is no fixed buffer size. For the first test we stopped at a 4K buffer size in deference to the Linux buffer. Windows advocates might suggest that the arbitrary buffer sizes associated with Windows named pipes are a benefit. To demonstrate the arbitrary size of the Windows named pipe buffers, we can simply run the single threaded program with arbitrarily large block sizes. I did a run with pipespeed2.cpp on Windows and specified a 256 MB buffer size. Windows obliged by swelling the buffer size to hold 256 MB of data before the ReadFile() was issued. The system slowed to a crawl and I didn't wait until the operation completed. Whether this "feature" of Windows is useful or not is up to the public.
Well, i am sure it started out as a feature..
Rapid Nirvana
This is very premature. This was only testing ONE aspect of Windows vs Linux, which is not even used very much in the Windows world. This is meant to be an overall test of Windows vs Linux in performance, but the article is going to span over several weeks/months. Only after the series is finished will a good comparison be made. To say that Linux rocks just because it's pipes are faster means jack squat. What if Windows sockets are faster? What if Windows Disk IO is faster? What about Windows Asynchronous I/O? Eventually, this article series will answer such questions. However, this article ONLY answered the question of whose pipes are faster. Nothing else should be read into it.
Engineering and the Ultimate
Who you kidding? I'm no windows developer, but even I know you don't use pipes for IPC in windows, it's all COM. COM on windows versus CORBA or DCOP might be interesting.
You'd almost think that a half-decent GUI and a huge set of tools were the most important things rather than inter-process communication.
Amazing. Stunningly the IBM OS/390 wipes the floor with all of these entries. Great desktop machine. Linux is a good OS, its not the best, it doesn't beat Solaris for reliability, it doesn't beat Windows for usability, and it doesn't come near the Mainframe architectures for speed. But it does have its place, but petty things like this are surely pointless. If a HCI group found that Linux was _easier_ to use, then that would be something to applaud but in the days of Gigabit networks and massive processor speeds and huge RAM these sorts of performance things are less important than ever.
The key to success is ease of use, ease of deployment, Linux is getting there, but having fast pipes won't progress it.
An Eye for an Eye will make the whole world blind - Gandhi
Dell announces that Windows XP outperforms Linux. Slashdot denounces study as biased.
As is often the case, Microsoft just threw something together and called it "infrastructure." Linux developers drew on 25 years of UNIX evolution and experience, and made a better product as a result.
-sting3r
"... the poor performance of Windows XP was a surprise. Windows 2000 actually did better than XP!"
This has been happening since the days of the VAX minicomputers, and probably before. Hardware manufacturers want slow, poor performing software, because that makes users buy more hardware. Most of Microsoft's sales are to hardware manufacturers, not to users.
Secrecy destroys democracy: What should be the Response to Violence?
Bush's education improvements were
It's not like IBM has anything to gain from publishing a comparison of this kind.
Let me first say I love Linux. I have 2 Linux boxes and 2 Windows boxes here. I use Linux every day.
But the Windows code does not use completion ports to do the I/O. If you want the best performance of Windows I/O, completion ports are the way to go. I'm Windows would do much better if the code was optimized for Windows.
I have writen high speed data I/O applications for Win2K and it performed as well or better than the *nix boxes, when completion ports were used.
The nice thing about the tests is that all of the information about the tests are published, as well as the scope of what the test means (it has a very small scope of applicability). So, it's easy for anyone to reproduce the tests, and mention any problems with the tests.
Engineering and the Ultimate
If you've read the the other article(s) (how long it takes to perform a memcpy) in this series, it seems he is trying to desparately find holes where he can say "Linux is better".
For the record I have 4 PCs, 1 of which runs Linux permanently, the other 3 being dual boot. Desipite being in favour of Linux, these articles give benchmarking a bad name. Most rounded benchmarks show Linux about equal (with some pluses and minuses) to Windows performance, which for me is good enough, since given you can have Linux for free, why pay for an OS that is only just as good ?
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Ok, I don't know why you bothered posting this, probably pointless flamage you post freqently, but I just thought I'd comment. First of all your VB experience doesn't mean anything in linux, I'm pretty sure there isn't a linux compiler for VB. Second of all you said you configured the system from scratch, and recompiled all the programs in what you believed to be a better compiler. Sounds to me like you built everything yourself, then blamed someone else when it didn't all work perfectly. Personally I have never (never meaning sometime after linux became well known, of course in the early days in had to be done by scratch) heard of anyone who first introduced themselves to linux without the help of a basic distribution. So either your a lier, or an idiot.
Posting +1 cause I have karma to burn!!
Some things to ponder:
This is not to diss IBM, or even to suggest Windows XP/2000 would even win in such a battle, although I suspect they would for massive SMP arrays, simply because Linux doesn't handle those as well.
I also suspect Linux would find itself struggling, when put into a hard real-time setting, an ultra-secure setting, or a distributed setting. The overheads involved would not be huge, but if you have a huge number of processes, each with the maximum number of open pipes, the overheads are being applied a huge number of times. That adds up.
All in all, this suggests that some really severe, rigorous benchmarking needs to be done, under a wide enough variety of conditions to be meaningful. This test just doesn't meet the kinds of conditions I'd expect from a truly determined test.
Now, if I can only convince IBM to loan me a few dozen boxes, I'd be more than happy to do the testing for them...
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Unfortunately this article is
comparing apples and oranges.
The Win32 call you need to use is
CreatePipe(), not CreateNamedPipe().
CreatePipe is exactly equivalent to
the UNIX pipe() call. CreateNamedPipe
with the \\pipe prefix is equivalent
to mkfifo on UNIX.
No wonder Win32 is much slower, you're
going through many more layers in the
kernel.
Regards,
Jeremy Allison,
Samba Team.
This is just saying which OS has faster pipes:
Linux or Win2K
(We can eliminate IBM's so called XP comparison....doesn't seem to have much basis)
All IBM is saying is that if you have some specific app that absolutely needs to have best pipe speed/bandwidth then install LINUX damn it!
This is not:
Linux vs Windows
Linux is harder/easier than Windows
Linux Rox, Windows Sux
Windows Rox, Linux Sux
Tux smashes Windows, news at 11
Grow up people: When will people realize that there is not one defacto OS standard.
I love Linux
I love Windows
I use Linux for Web Server/FTP Server/IMAP server/DNS/filesharing/
I use Windows for browsing the web, playing games, Designing web pages, etc.
Why? Simply because I use the whatever works for whatever I need.
Why must we have one OS that does everything?
Seriosly.... if there is some solid reason please tell.
Just my 2 cents...
Eddy.WriteLinux.Com
I don't use Linux - and I've been a regular /.er for years. Comparisons like this are interesting, as the previous poster noted - MS spends zillion$ to get their word out, so I see nothing wrong with posting alternative viewpoints here...
Stop by my site where I write about ERP systems & more
I would expect that if any benchmarks came out favoring Windows, and if they were reported here
Benchmarks did come out favoring Windows. They were indeed loudly shot down with criticisms of the testing protocol, and with criticisms of the (Microsoft-funded, in this case) bias of the testing agency. And yes, both those criticisms were just as valid: e.g. not very.
The testing protocol, just as in this case, deliberately chose an aspect of performance that didn't have much practical meaning (load balancing between many 100MB NICs rather than using one GB card; using pipes on Windows instead of sockets/COM).
The testing agency, just as in this case, was horribly biased.
So what was the difference? Well, first of all, the biases were a lot more real before. People pointed out hand-tuning that was applied to NT and not Linux, hardware choices that seemed to deliberately use the least supported options, and misconfigurations of the Linux software. Do you have any similar things to point out here, other than "Everybody knows you shouldn't use pipes on Windows"?
The second difference? Even after those biases were taken into account, there was still aspects in which Linux's performance could be improved, and so it was, gradually over the next 18 months, until it now beats Windows in the same configurations. Do you think that the converse will be true, and Windows 2003 will have blazing performance in all forms of IPC? Would you like to bet money?
In the discussion forums, the guy who posted these results admits, "I ran the tests on a thinkpad."
I'm sorry, but what does this prove? Linux runs better on a laptop? Is he comparing Linux, the server OS, to Windows 2000 Pro, the consumer OS? What version of Windows XP is he running?
These tests are really subjective, not only because pipes aren't really used in Windows, but also because he used a laptop to test it (and didn't give details of the Windows OSes he was running.) If anything, I wish he would have used some bigger iron (a Xeon-based system, perhaps, or some of IBM's middle-of-the-line servers.)
I think the best conclusion we can draw from this is that Linux may indeed be a better OS than Windows in some ways, but that this test doesn't prove it.
As a systems architect at a very large (non dot-com company I might add), when considering platforms and technology for adoption, speed of certain aspects of an os are usually pretty low on my list of priorities. Tops are:
- Available human resources: do we have developers that know x technology. If not, how available are they?
- Business: are there any benefits to adopting a certain technology, such as existing or potential partnerships? i.e.: existing support contracts, brand name recognition
- Liability: is there someone to blame when things go wrong? (like it or not)
- Scalability: can the adoption of a technology come with a guarantee that some aspect of performance doesn't hit a brick wall?
Among others.
_______
2B1ASK1
No it isn't.
Unfortunately this article is
comparing apples and oranges.
The Win32 call you need to use is
CreatePipe(), not CreateNamedPipe().
CreatePipe is exactly equivalent to
the UNIX pipe() call. CreateNamedPipe
with the \\pipe prefix is equivalent
to mkfifo on UNIX.
No wonder Win32 is much slower, you're
going through many more layers in the
kernel.
Regards,
Jeremy Allison,
Samba Team.
I thought the same thing initially, but when I tried using CreatePipe() instead of CreateNamedPipe() I actually got a performance degradation of about 5%. Looking deeper into this, I found that CreatePipe() actually creates a named pipe and places security descriptors on each end which restrict it to unidirectional access (hence the slowdown).
From the MSDN documentation:
Windows NT/2000: Anonymous pipes are implemented using a named pipe with a unique name. Therefore, you can often pass a handle to an anonymous pipe to a function that requires a handle to a named pipe.
Fear: When you see B8 00 4C CD 21 and know what it means
NT4 is the best OS MS ever made
Maybe at it's current service pack state, but holy shit did it take them a long time and a lot of service packs to get it into that state! In fact, the original release of NT4 was a bag of shite - constantly rolling over and dying. Not until service pack 3 did it become stable. And then we had service pack 4 - what a joy that was *NOT!*.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
I see a lot of comments here bashing the article for not giving the whole picture and you're right, it doesn't give the whole picture, but neither was it intended to.
As a programmer doing cross-platform software development I find it interesting and useful. What I want to know is that if I use pipes for IPC, how does it affect performance on the different platforms? I'm not interested in any additional features of Microsoft's implementation of it, because in my project I just want an easy, simple and fast way for cross-program communication that works very similarly on all platforms.
When I wrote BladeEnc I envisioned that the pipe-support I included in around 0.80 would be useful for using BladeEnc in for example realtime recording applications. Now I know that solution would give quite some performance penalty on WinXP systems and thanks to the detailed graphs I also know better how to tweak the size of the chunks I send/receive to gain some performance.
Take this article for what it is, a guiding light for software developers that helps them to write better and more efficient applications. It was written by a programmer for programmers (it's on developerWorks) and doesn't make any claims to be a valid benchmark between the platforms in general. It just shows what performance you can expect on different platforms if you use pipes in the most simple way for IPC, combined with different chunksizes.