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

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.

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

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

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.

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.

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

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.