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!"
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
You know, if you want to come off as being fair and circumspect about these things - and not as a flame or troll - you might want to reconsider that last paragraph.
Successful business(sic) don't use linux?
Please - you're as guilty of the bias you're complaining about as the story is.
Especially since Pipes are basically unused for server applications on Windows. The only significant place that Microsoft still recommends their use is when your connecting to a SQL Server database that resides on the same box as you components. Other than that you're pretty much dealing with console processes. Windows has much better IPC mechanism (COM and COM+ Events and Method Calls, Local Procedure Calls, Memory Mapped Files...)
The big deal about this one is that the testing is done by a real company. It's written by a senior programmer at IBM. Many of us would hesitate to dismiss what he says here. This is not some sponsored study as were many tests that have been done in the past.
Lets see... IBM supports Linux... but guess what? They make a hell of a lot more money selling Windows systems. Both Desktop and Server. And look at IBM services? They're just going to suddenly roll over and say we don't support Windows anymore?
Sheesh people. IBM is way too big. This guy writing the article has nothing to do with marketing, he's a programmer or in R&D. Sure he's a Linux advocate. But something this minor doesn't make it in the conspiracy business...
Since when is a shell (decent or otherwise) required to use pipes?
Pipes are for communicating between various process *including* those launched from a GUI.
Granted the Windows shell is cack - but then the GUI is so good who needs any more than a basic shell?
"... 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.
And IBM has a vested interest in the success of what operating system? Maybe ... Li-NUX?
It all depends on who you trust - me, I don't trust any camp, MS or OS. There's just too much religious fanaticism and not enough rational discussion on either side.
Well, at least not here anyway.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
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!!
They compared the Win2k Advanced Server version to the WinXP Desktop version. As we all know, IBM isn't biased at all :)
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)
The article mentioned is well written and informative. Based on the comments, many people comment on the substance based on the lead-in Slashdot posting. I say, before you comment on things like "Home version" or "biased", you should learn to read.
First of all IPC isn't as important in Windows because Windows developers drew on many years of experience of other OS developers and wrote it to support threads from the start. Yes we still need IPC but we can also choose to have code run in the same process and avoid a lot of overhead.
Second, pipes aren't the prefered IPC mechanism in Windows like i'm guessing they are in Linux. So you're only complaing that Windows doesn't work like Linux.
Pipes do have access control. And it's a lot more flexible than three sets of RWX flags.
Windows also provides semaphores, shm, messages, as well as the socket based facilities for IPC.
OOB may be provided by sockets. Not sure here.
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
You can create named pipes; The OS-supplied ones include CON:, NUL:, PRN:, and so on. It is in fact possible to create new ones.
It's still better to have printer drivers, though. It's a feature that UNIX needs (and is getting, of course, through that new printing system whose name I forgot, and the linking of which someone else will probably get karma for.) Printer drivers are user friendly.
Why use complex sockets when you don't really need them? Later extensibility. Of course, if you're the only one who will ever see your code, you're right, it doesn't really matter.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
I think an intersting comparison would be winxp's implemention of unix sockets compared against Linux's implementation.
Yes but every time I try to see it your way, I get a headache.
Anyone else bothered by the fact that the tests on Windows were using named pipes while the Linux ones were using unnamed pipes? I'm rather certain that named pipes would be slower in the first place...
However, the significant performance degradation in any feature from one version of Windows to the next is a pretty damning result. It would seem to legitimize the feeling that many Windows users have that XP is a big downgrade from 2K.
Windows pipes aren't in the filing system, they are in the kernel namespace - which is to all intents and purposes equivalent to /dev.
Windows kernel objects all have full access control, including pipes.
Windows provides all those IPC mechanisms you mention, and more, including IO Completion Ports which are VERY fast [a friend just implemented a 160us turnaround on a raw socket under WinNT in user space using IO Completion Ports].
Windows pipes are files just like Linux pipes, so they are not at all harder to program. In fact, with variable buffer sizes they can be a lot easier to manage.
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.