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!"

Comments

Pipes? Phbbt.

[gosand]

What good are pipes anyway? Unless there is a GUI attached to them, they are worthless, right?

Ask your local MCSE, they'll tell you.

ROFL.

Re:Pipes? Phbbt.

[Hertog]

Any good MCSE will tell you that the windows-logo screensaver is much nicer then the pipes-screensaver..

Gr.

Hertog

Premature

[johnnyb]

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.

Re:Premature

[tmark]

What if Windows sockets are faster? What if Windows Disk IO is faster? What about Windows Asynchronous I/O?

I would expect that if any benchmarks came out favoring Windows, and if they were reported here, they would be roundly and loudly shot down with 1) criticisms of the testing protocol, and/or 2) criticisms of the bias of the testing agency. Of course, the same criticisms are just as valid in this case, but of course they are here largely ignored (one poster so far excepted).

All of which just goes to show that the essence of the whole 'Linux-rocks/Windows-sucks' horse that is always being flogged here is that this horse is ultimately flogged by (sometimes blind) faith. Few of the Linux zealots here are going to believe any benchmark/test unless it favors Linux (in which case, they will all praise the study to high heaven) - just look at the lengths people here go to argue that GNOME/KDE provide better-than-mediocre desktops. Similarly, few Windows advocates are going to be convinced that their platform of choice is inferior.

Since all these articles thus amount to preaching to the converted, I suggest that the Slashdot editing team hereafter mark all such articles of theirs as 'Redundant'.

Hey, why can't we rate parent Slashdot articles, anyways ??

Re:Premature

[Score Whore]

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.

pipes for IPC on windows?

[kangasloth]

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.

And yet it still sells...

[MosesJones]

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.

Re:And yet it still sells...

[jgerman]

, 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.

Thus spake the virgin programmer. That bullshit about hardware invalidating the need for fast efficient code, is the bullshit rhetoric taught in college classes that brought us the blue screen of death in the first place. Speed and performance do matter as does not hogging memory and efficiency. You will always run into limits on what a machine can do, and in the case of business, writing code that allows 5 servers to do the work of ten at helf the bandwidth is a big deal.

The key to success has already been gained by Linux, it is used by the people who matter (not matter as in personal worth but matter as in matter to the advancement of computing). I couldn't give two shits about Joe Schmoe who wants to check his email and surf for porn, let him use Windows, it's not necessary for everyone to use the same operating system. Use the right tool for the job, and for developement *nix is the best tool.

Re:Can you say "flamebait"?

[benwb]

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...)

Re:Can you say "flamebait"?

[little alfalfa]

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.

This should come as no surprise

[sting3r]

Windows pipes are much lower on the evolutionary ladder than Linux IPC mechanisms. Consider:

• Windows pipes cannot exist in arbitrary places on the filesystem. Therefore service hijackings are easy if you can DOS the existing service into dying. On Linux, an ordinary user can't create /dev/log or /dev/printer (even if they kill syslogd/lpd), but on Windows anyone can name a pipe whatever they want (as long as it doesn't already exist).
• Windows pipes have no access control. Hmm, didn't SANS just report on the sorry state of Windows security?
• Windows pipes do not support ancillary data or OOB data. This makes them limited communication facilities.
• Linux pipes use copy-on-write instead of straight out copying. Therefore the paging mechanisms enhance speed because the data is simply remapped, not manually copied.
• Linux provides a much richer set of IPC mechanisms, such as semaphores, shm, messages, as well as the socket based facilities.
• Linux pipes are much easier to write for. Win32 pipes are difficult to use in a C program and subtle programming errors can cause many problems in unrelated modules.

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

Re:This should come as no surprise

[TummyX]

Windows pipes have no access control. Hmm, didn't SANS just report on the sorry state of Windows security?


It does so. You pass the SECURITY_ATTRIBUTES to CreatePipe or CreateNamedPipe.


Linux provides a much richer set of IPC mechanisms, such as semaphores, shm, messages, as well as the socket based facilities.


Duh. So does Windows and every other real OS.
Windows provides much more (like completion ports, events, mutexes etc). Also, it is MUCH easier to use them from Windows than linux. sem_init, pthread_create etc are complex to use compared to CreateSemaphore, CreateThread etc.

And threads, semaphores, mutexes, events, processes etc in windows are all waitable. You use the SAME functions to wait on one or more of them. In linux you have to use pthread_wait, wait(), sem_wait() etc...all different functions for different types (what's worse is some certain object types don't have certain wait functions). In windows, you just use WaitForObject() or WaitForMultipleObjects() on EVERY type of handle.


Linux pipes are much easier to write for. Win32 pipes are difficult to use in a C program and subtle programming errors can cause many problems in unrelated modules.


Um. Like how? Why are Win32 pipes difficult to use in a C program? Huh? You just made that up didn't you?


subtle programming errors can cause many problems in unrelated modules.


Like? Give me an example. What do you mean by "unrelated modules" and "subtile programming errors"? What kind of crap is that? Why don't you just say: "The sky is blue therefore microsoft sucks".

How is this hard?

// create a pipe with 1K buffer
CreateThread(&read, &write, NULL, 1024);
WriteFile(write, buffer, 1024, &d, 0);

Hardware manufacturers want slow software.

[Futurepower(tm)]

"... 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?

Not good Windows Code

[cppgodjavademigod]

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.

Re:Written by IBM?

[johnnyb]

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.

Pipe speeds

[jd]

The relevence of this comparison escapes me, for the moment. Hey, I'm no Windows fan, but most benchtests for ANY one parameter invariably produce a wildly misleading result.

Some things to ponder:

• How fast are Linux pipes, if you patch the kernel with LSM? MOSIX? A different scheduler? (eg: RTSCHED, RT-Linux, RTHAL, HP's Scheduler Plugin Architecture?)
  
• How long can a given OS sustain a given data rate, under different conditions? (eg: Many processes running, non-interruptable events, miltiple processors, etc.)
  
• What kind of resources are consumed, per pipe, per unit of data, per unit time? Do any of the OS' allow/use smoothing, to reduce system load?
  
• What results do you get for architectures at the extreme ends of each OS? (ie: Compare ALL the OS' on the minimum suggested and maximum usable settings for Linux, Windows XP, Windows 2000. See if there is a range in which one OS has the advantage, rather than assuming that if it has the advantage at one point, it must have the advantage always.)
  

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... :)

This is not the fastest way to do IPC on Win32.

[Jeremy Allison - Sam]

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.

The Minority View

[TopShelf]

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...

Run on a Thinkpad?

[corky6921]

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.

Performance usually the least of my considerations

[eyeball]

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.

Wrong, Jeremy

[throx]

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.

Re:Can you say "flamebait"?

[Telek]

But this guy doesn't appear to know what he's talking about... He's comparing apples to oranges here... No, apples to watermelons... Now I'm not all that up to speed on linux pipes, but from what I can tell they are completely different from windows pipes. At least from windows named bi-directional pipes, which is what he tested them against. (And lets completely forget here for a second that he works for IBM, which has all but pronounced vendetta on Microsoft... No possible bias there.)

Under windows, there are many things the he "neglected" to notice:

• pipes in Windows have ACLs (access control lists).
  
• There are two types of pipes: Anonymous pipes and named pipes. Anonymous pipes require less overhead than named pipes, but offer limited services. He "neglected" to test anonymous pipes on Windows platforms (which BTW are faster).
  
• Windows Named pipes can be used to provide communication between processes on the same computer or between processes on different computers across a network.
  
• Windows XP can provide encryption for pipes, which might explain the drastically lower rates. Since XP is based on the same kernel as Windows 2000 there's obviously some additional setting that is on by default now that is causing the decreased rates.
  

Also:

the term pipe server refers to a process that creates a named pipe, and the term pipe client refers to a process that connects to an instance of a named pipe. This is why you have one method to Create the pipe, and one to Open it. BTW -- the Opening method is a universal resource opening method on windows PCs.

You can go here if you want to know more about pipes on windows.

AND

I also tried his programs, and you don't need that mystical +24 to get it to work. I don't know why he needed it. Perhaps because he was using some old or wierd cl? I'd also suggest that he try to compile it with MSVC (unless he got the cl.exe from there) as I would bet that would make it faster as well.

So, from what I read he basically said "Well, I'm gonna compare this thingy called a 'pipe' over here on windows to this really old and simple 'pipe' thingy over here on linux" without checking to see what was actually under the hoods of the two beasts he was comparing.

Man, /. really has turned into a tabloid lately.