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

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.

Results unsurprising and meaningless

[Florian Weimer]

'Named pipes' on Win32 and 'pipes' on POSIX do not have much in common, except the name and the fact that you can send data over it. Win32 pipes are more similar to UNIX domain sockets, and while GNU/Linux might still be faster even if UNIX domain sockets are used, it wouldn't be by that much. It would have been interesting to see how real POSIX pipes behave on Windows (for example, in the POSIX subsystem or on Interix, or even on Cygwin).

Finally, as far as I know, the Win32 API provides other IPC mechanisms, and for transferring large amounts of data, other interfaces are usually used by Win32 programs. That's why the throughput of pipes is not so important on Win32 systems, and performance has not been optimized.

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.

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:What a Surprise.

[TRoLLaXoR]

it's running well. i never installed Classic and I haven't felt an urge to go back...

I have three bitches about it--

1. my 3rd party USB burner is not supported. i expect it to be at some point, as it was in Mac OS 9.

2. the gui plays catchup. there's a slight delay between going over a menu title and having it drop down, or hitting a button and having the action begin.

3. graphics acceleration is not as fast as it could be.

None of those things are bad at all, and 10.1 is my primary OS.

the ibook itseld is small, light... DVD play is great.

anything else you wanna know?

It's what's IN the pipes that matters...

[SeaCrazy]

Well, Linux may have better pipes, but we all know that Microsoft has lots of more money so they can afford to buy much better crack which more than makes up for the poor quality pipes.

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

Re:pipes for IPC on windows?

[partingshot]

> How do you think that COM actually
> communicates ?

One module loads another module and gets
the offset to the vtable. The COM designers
designed a binary standard that (not coincidentally)
mimics the layout of the c++ vtable.
So. COM uses function pointers to communicate.
And that's a helluva lot faster than any network
operation.