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!"
One has to wonder how long it'll be before the Microsoft army tries to quash this story.
Isn't there some clause in the license that prevents publishing benchmarks and reviews that are somehow negative towards the product?
'Course, this is IBM, and Billy G. might think twice about causing a dust-up over this. IBM isn't going to fold quickly nor quietly - and thereby give this story a much larger mindshare than it would get otherwise.
It'll be interesting to watch.
Microsoft has a well funded PR department to put out benchmarks that show Windows in a positive light. The Linux community doesn't. If we want to compare OSes in areas in which Linux excels (and admittedly there are some who don't) we have to use grassroots methods, such as posting it to Slashdot.
--
E_NOSIG
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
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.
While I agree with most people that it's a rather silly comparison, pipes aren't quite as dead as people think. Many "enterprise" systems still use pipes on windows. Database systems in particular...
I'm not a conspiracy kind of guy, but you could almost argue that Windows pipes are being slowed on purpose. I doubt SQL Server uses them (espescially if they're degrading this quickly) but many of MS's competitors still do (Including IBM's DB2).
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
"The conspiracy theorist in me says that MS are ensurting that Unix-style programming itself is more tricky on WNT"
Just look at the marketing for MS-SQL. Per MS, it's better because it uses native NT APIs, while it's competitors have to support multiple platforms and theremore must use slower compatibility APIs on NT.
Ever wonder why DB vendors were one of the first to jump on board with Linux?
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?
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.
COM and CORBA are probably 10 or so levels higher up as far as abstraction goes over pipes. Pipes are down and dirty C style IPC mechanisms, COM and CORBA most likely utilize them (or IP sockets) to actually get the job done.
People use COM not understanding the performance hit they're getting. Sure, it's the "Right" way to do it by MS standards these days but why diddle with it when all you really need is a few functions to wrap up some pipe() calls to get your two components speaking?
Would you care to elucidate on the power, flexibility, and customizability of your GNOME desktop wrt how it stacks up against Windows in those areas. Also please expand on how linux doesn't constantly crash. You see I find that Windows as a whole is more stable than the components of linux. Just because the webserver in my workstation doesn't go down, it doesn't mean that my work isn't interrupted when my X server/web browser/email client/cd burning software/etc. crashes. So how is it better for me that some parts of the OS are still functional? Particularily parts that are almost entirely fluff for my day to day desktop use? It would probably be wise for the Unix community to stop generalizing its arguments into pointlessness. Instead we should focus on actual strengths that can be shown as real benefits.
But then you have to design protocols and worry about blocking and aborting and so on. The good thing with COM is that they all speak the same language, and you can even find out everything you want to know about what the other end supports at runtime