Who Has Faster Pipes? Linux, Win2000, WinXP Compared 534
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!"
Can you say "flamebait"? (Score:3, Troll)
Re:Can you say "flamebait"? (Score:2)
Re:Can you say "flamebait"? (Score:3, Interesting)
The Minority View (Score:5, Interesting)
Re:Can you say "flamebait"? (Score:2)
Re:Can you say "flamebait"? (Score:5, Insightful)
Re:Can you say "flamebait"? (Score:2, Insightful)
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.
Re:Can you say "flamebait"? (Score:5, Informative)
Under windows, there are many things the he "neglected" to notice:
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 [microsoft.com] 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,
Re:Can you say "flamebait"? (Score:2)
Re:Can you say "flamebait"? (Score:4, Insightful)
Re:Can you say "flamebait"? (Score:2)
I use a named pipe for the commands that control my jukebox. Simple. Elegant. Easy to code. Why use complex sockets when you don't really need them? What can be easier than dumping commands to a file and having the listening daemon act accordingly?
Re:Can you say "flamebait"? (Score:3, Insightful)
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.
Re:Can you say "flamebait"? (Score:2)
If PIPES don't work, why do they support them?
Pipes have a place (Score:2)
Also, there's a performance issue: Windows' high-level IPC stuff is slower, and if you don't need all that functionality, you can be better off with a lower-level mechanism.
Written by IBM? (Score:2, Redundant)
Are they a little biased?
I'd prefer a neutral party to do the test and the results placed on a neutral site, personally...
Re:Written by IBM? (Score:2, Offtopic)
IBM has every bit as much to gain or lose as any other PC/Server manufacturer does in an 386 platform.
Re:Written by IBM? (Score:2, Insightful)
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...
Re:Written by IBM? (Score:2)
back before 2k, we did tests on loopback device performance on win95 and winNT. win95 was really bad, NT wasn't great. we ended up writing our own support using shared memory on windows to get the speed we needed. IIRC linux on a 486 beat win95 on a P-233 and I think it was on par with winNT on a PPro-200. The code to do this was in C++ and we abstaracted it behind a generic interface and on linux we used the straight OS support since it was plenty fast.
Re:Written by IBM? (Score:4, Insightful)
Pipes? Phbbt. (Score:5, Funny)
Ask your local MCSE, they'll tell you.
ROFL.
Re:Pipes? Phbbt. (Score:5, Funny)
Gr.
Hertog
Loved the "Bug or Feature" part.. (Score:3, Funny)
Another distinction might the the "feature" of Windows pipes where there is no fixed buffer size. For the first test we stopped at a 4K buffer size in deference to the Linux buffer. Windows advocates might suggest that the arbitrary buffer sizes associated with Windows named pipes are a benefit. To demonstrate the arbitrary size of the Windows named pipe buffers, we can simply run the single threaded program with arbitrarily large block sizes. I did a run with pipespeed2.cpp on Windows and specified a 256 MB buffer size. Windows obliged by swelling the buffer size to hold 256 MB of data before the ReadFile() was issued. The system slowed to a crawl and I didn't wait until the operation completed. Whether this "feature" of Windows is useful or not is up to the public.
Well, i am sure it started out as a feature..
Re:Loved the "Bug or Feature" part.. (Score:2)
I unix admin for a living, I hold no special love for Windows. But for fucks sake... does demonstrating that an OS allows a developer to be a fucking cretin highlight a failure in the OS or a failure in the developer?
Premature (Score:4, Insightful)
Re:Premature (Score:5, Insightful)
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:3, Insightful)
Re:Premature (Score:4, Interesting)
Re:Premature (Score:2)
*cough* Mindcraft
What Mindcraft proved was that there were signifigant problems with Linux and it performed horribly compared to Windows.
Yeah, it was picked apart... but they used the pickings to solve real issues.
You don't remember Mindcraft? (Score:3, Interesting)
Benchmarks did come out [slashdot.org] 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 [lwn.net] 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 [kegel.com], 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?
Re:Premature (Score:2)
I don't agree, or at least I think you're leaving out a significant point. I think the /. community rails against Microsoft-funded tests, but otherwise takes these tests to heart. Just look at the recent ZDNet testing that showed NT could barf out static Web pages faster than Linux. There were calls of bias, to be sure, but what actually happened was a bunch of Linux users jumped up and re-did the tests, and then a few leaders in the community went to ZDNet to watch the tests being run. And guess what? The tests were right, and rather than poo-poo the results, the developers actively worked to fix the errors. This community is self-correcting. Give us real results that we can reproduce, and we'll take it not as an attack but as a springboard for improvement. Or at least, that's what recent history indicates.
pipes for IPC on windows? (Score:5, Insightful)
Re:pipes for IPC on windows? (Score:3, 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).
Re:pipes for IPC on windows? (Score:3, Interesting)
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?
Re:pipes for IPC on windows? (Score:3, Interesting)
Re:pipes for IPC on windows? (Score:3, Insightful)
That would have been a better test.
BTW, The source code examples in the article did a great job of reminding me why I hate coding for windows
Dave
And yet it still sells... (Score:4, Insightful)
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... (Score:3, Insightful)
It's not the only thing, but it is pretty major.
If there's a bottleneck, that means poor scaling of applications to larger loads.
There's a lot that's not in the article, and the article itself says so. There's no information on sockets, RPC, or other means of IPC. That is all coming in future articles. However, it is silly to say that IPC speeds are not worthwhile.
Re:And yet it still sells... (Score:2)
2 points 1)this was the first Suse distro I have ever tried, and I'm not into any type if Distro wars.
2)I have used both Gnome and kde, until KDE2 I found gnome to be my preference, but KDE is really easy to use. My wife figured out how to get to all the 'desktop user' stuff(spreadsheet, browser etc...) w/o any help. My wife only other computer experience consists of Windows, and the Apple ][ c.
Re:And yet it still sells... (Score:2)
You just shot down your own statement. Of course an operating system is "at least as easy to use as Windows" if you've been using it for years. Heck, I thought the menu screen on the TI-99/4A was just dandy.
I think from a "this metaphor works" standpoint, Mac OS got it right the first try (too bad the underlying code sucks -- we'll see with OS X slowly gaining popularity). Windows 95 was pretty revolutionary on a few fronts. XP is bar none the easiest Windows system to use, with the task panes on the folders saying "here you can delete, here you can write to this CD". I showed that to my mom and she instantly understood it (even though, like most of America, she still doesn't know what a "shortcut" in the Start Menu means).
On the *NIX side, I find KDE to be my desktop of choice. But I've noticed something -- I think I like it because it's so close to Windows. You tend to like OS's you work with often enough, once you learn the underlying tricks (that's one of the reasons I installed POSIX utilities for the command line in Windows 2000/XP). :)
Re:And yet it still sells... (Score:5, Insightful)
, 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:And yet it still sells... (Score:2)
Re:And yet it still sells... (Score:3, Insightful)
Object-oriented programming and other "silver bullets" have been around for awhile. Bill Gates, while he may not be a legendary programmer, isn't the guy who's creating those BSODs now. It's the newer people, straight out of college, whose idea of important algorithms includes bubble sorting and who only have a 50-50 chance of distinguishing a pointer from a coconut. New programming methodologies won't make programs better -- only better educated programmers can do that.
Deja vu? (Score:2)
I think Windows NT 4.0 marked Microsoft's pinnacle of acheivement. If it wasn't for the lack of USB support I would have never upgraded. Even for a server role, there are a lot of USB devices that a modern server needs to access (like DSL modems, many newer UPS's, cameras for security, additional serial/parallel devices, etc).
Why oh why can't someone develop a third party solution? Or does one exist? DirectX and translucency I can do without...but USB is just too useful to do without.
- JoeShmoe
Re:Deja vu? (Score:2)
NT4 is the best OS MS ever made, but Win2k is a good update to NT4. USB support is uber useful: serial and parallel are too slow and scsi and firewire are too expensive.
Re:Deja vu? (Score:3)
Maybe at it's current service pack state, but holy shit did it take them a long time and a lot of service packs to get it into that state! In fact, the original release of NT4 was a bag of shite - constantly rolling over and dying. Not until service pack 3 did it become stable. And then we had service pack 4 - what a joy that was *NOT!*.
Re:Deja vu? (Score:2)
I made the mistake of copying some data to a NTFS 5.0 drive, got an error message, rebooted and found my $volume had become corrupt. Microsoft's attitude was "Shit Happens, restore from backup". That's all fine well and good, if the hard drive had physically died I would have accepted the data loss...but Microsoft's whole attitude is that it's more important to have new features than reliability. Backups should never been my first line of defense. The OS should have the smarts to recover SOME portion of the data. Given that OnTrack EasyRecovery wasn't able to find anything, I had to lose the data...but I swore I would never again touch NTFS 5.
- JoeShmoe
In other news... (Score:3, Funny)
Re:In other news... (Score:2)
They're looking for any way they can cut Microsoft out of the picture, the same reason Oracle is investing so heavily in Linux. If IBM sell a server with a free OS, that's a few extra dollars they get to keep instead of sending to Microsoft.
Think about it.
Re:In other news... (Score:2)
They mainly want to make sure Microsoft can't extend it's monopoly into these areas as well. That means establishing Linux as a credible alternative and commoditising the OS space, while building additional services around it.
Pretty sound strategy for them, Linux fans had better hope it works because right now it's the main chance Linux has ofd displacing Microsoft to any significant degree.
This should come as no surprise (Score:5, Interesting)
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 (Score:2)
So true, so true. My experience with kernel-level *n?x programming (no MS kernel experience, call me biased...) has instilled great respect for their reliance on developing from a clean, tight model. Because an entity can only be a file or a process, access control is intrinsic, never an afterthought.
A good analogy is the difference between the DoD TCP/IP and OSI networking layer models. The TCP/IP model was developed to accomodate an application; OSI applications are developed to fit the model. Like POSIX, the OSI model ensures clean separation between layers in applications. POSIX, etc. dictates a true multiuser multimachine system, whereas Windows (pre-2K) is a kludge built to extend DOS--a single user, single machine O/S that was actually good for its time (early 1980's).
A valid point against the strictly layered models is the potential performance penalty from inter-layer communication. I think it's a small price to pay in this age, where the potential cost of vulnerabilities is exorbitant.
Re:This should come as no surprise (Score:2)
Re:This should come as no surprise (Score:2, Insightful)
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.
Re:This should come as no surprise (Score:3, Insightful)
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.
Re:This should come as no surprise (Score:5, Informative)
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:This should come as no surprise (Score:2, Interesting)
1. Writing debuggers is NOT what 99.99% developers do when programming for Windows.
2. I never said nobody uses pipes on Windows. I said , compared to other IPC mechanism, pipes are not what one would call "popular technique".
Security? (Score:2)
Pipes are only useful for outdated programming techniques. Sure, there are prob. design patterns for it, but no large system would base it's communication on it.
Pipe's moto: The world's a File.
-sigh-
Remember who's doing this (Score:2)
Although in this case, it does like like they at least tried to find a regime in which Windows would do better, which is admirable, but there's still room for skepticism.
Maturity of the pipe APIs? (Score:2)
Of course, MS could be simply re-using the 2K API in XP, something they should REALLY take a second look at doing given these results.
Hardware manufacturers want slow software. (Score:4, Insightful)
"... 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? [hevanet.com]
Of course it's a trustworth report... (Score:3, Insightful)
Snide, aren't you? (Score:2)
That way, you would find yourself being quoted in all sorts of national tech magazines about IBM's fraudulent benchmarks, rather than just being modded up for some dumbass insinuations on Slashdot.
Go on. We're waiting.
Not good Windows Code (Score:4, Informative)
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:Not good Windows Code (Score:2)
XP better than 2000 (Score:2)
Now that MS has monopoly, they just "improve" their OS by adding all this fancy stuff and trying to hold the monopoly. Once they will lose it, there will be plenty of space (that they help to create now, but crippling their products) to improve their performance.
This is good news for techies, but... (Score:2)
For consumers: we all know that MHz is not all that you should be looking for and yet if you ask any consumer about a PC, their mouth and eye will open wide once they hear about a faster MHz.
For applications: well, how many applications use pipe? Even those that do use them, what % of the time do they spend in pipes?
So, yes, this is good news for techies, but that is about it.
And yes, I may sound like flamebeat -- but, its is time to see the bigger picture for what Linux needs to bring it to the main stream. Mr. Torvalds already recognized this some time ago. This is why he is now focusing on stuff that consumers react to, such as UI.
Articles this guy writes are trite... (Score:3, Insightful)
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 ?
Re:Articles this guy writes are trite... (Score:3, Insightful)
Each article goes into depth over a single API call, and compares the systems.
When he gets through about 10-15 articles, he will probably have something useful. Especially since he carefully explains his methodology and reasoning behind each step. This is much better than the traditional benchmarks which do 1 mammoth test and say X is better than Y. In this article series, he's going down and testing, in depth, feature by feature.
Of course Win2k did better than XP (Score:2, Insightful)
AIX (Score:2, Funny)
Pipe speeds (Score:5, Insightful)
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...
The Source Code (Score:2)
x = mult*nbytes + 24;
when he sets mult=1
but this only explains for one wasted instruction. On the other handside I would take a close look at the Windows ReadFile and WriteFile functions. These, IMHO, could very well account for the poor performance the author is seeing. There are too many variables mixed into his test program to tell whether this is only the named pipes performing bad
Decent Windows (Score:2)
That said, I was kind of expecting XP to perform slower than 2000. 2000 is a modicum of strong engineering -- the only example of truly great software I've ever seen come out of Microsoft. Now, they add the sheen which -- while more user-friendly -- is sure to drag everything else down.
Meanwhile in an IBM Exec's office... (Score:2, Funny)
Read the article first. (Score:2, Insightful)
This is an important victory because... (Score:2)
Results unsurprising and meaningless (Score:2, Informative)
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. (Score:5, Informative)
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 (Score:5, Informative)
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:This is not the fastest way to do IPC on Win32. (Score:2)
Windows NT/2000 and later: 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:This is not the fastest way to do IPC on Win32. (Score:2)
that being said, I have winxp final and I find it multitasking a little strange. For example having it read from a cdrom that is badly scratched causes the machine to almost die. this doesn't happen under win2k, however I would expect it under win9x.
I only have vague assumptions that I pulled out of my ass for why this happens though.
-Jon
Read the Headline (Score:3, Insightful)
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...
Re:Read the Headline (Score:2)
"Why must we have one OS that does everything?"
Are you kidding? I'm a professional computer admin and serious geek, and I don't like switching between OSes any more than necessary. I don't like rebooting. I don't like any excess (i.e. unnecessary) work just to switch applications. You can imagine how much the average user is thrilled by the idea of needing multiple OSes just to browse the web, write memos, and play games.
Run on a Thinkpad? (Score:4, Insightful)
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 (Score:4, Interesting)
- 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.
Unix Sockets (Score:2, Insightful)
Named pipes vs. unnamed pipes? (Score:2, Insightful)
grammer? (Score:2, Funny)
I know this my sound a little.....stupid coming from me, for those that know my postings, but even I am not this bad.
This is not the fastest way to do IPC on Win32. (Score:2)
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.
Amiga zealots, round 2 (Score:2)
So, yay, Linux fanatics can start bragging that they have faster pipes. And the rest of the world can get even more annoyed with the weird rantings of said Linux fanatics.
The real surprise (Score:2, Insightful)
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.
It's what's IN the pipes that matters... (Score:2, Informative)
CreateNamedPipe vs. CreatePipe (Score:2)
The CreateNamedPipe call creates a pipe that can be connected to a pipe potentially on another host addressed by UNC name. MS admits that this is slow and that sockets should be used instead if raw performace is desired. The benifits are that they are authenticated and mediated by the CIFS networking layer (thus the slow down).
To more accurately compare pipes as IPC mechanisms they should have used the CreatePipe call which creates an anonymous named pipe that only goes through the Kernel and back. These should be quite fast by comparison. Of course a much more interesting comparison would be to compare shared memory -- a much more critical IPC mechanism used by high performace appclications like databases.
BTW if you want to access NamedPipes and TransactNamedPipes in 100% Java the http://jcifs.samba.org [samba.org] project has implemented everything necessary to interoperate with MS NamedPipe servers.
I actually find this study useful... (Score:3, Insightful)
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.
Re:Tired (Score:2, Insightful)
Successful business(sic) don't use linux?
Please - you're as guilty of the bias you're complaining about as the story is.
Re:Tired (Score:2)
Re:Tired (Score:2)
Re:Windows has pipes? (Score:2, Insightful)
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?
Re:My Experience with the Linux Operational System (Score:3, Insightful)
Posting +1 cause I have karma to burn!!
Re:This may NOT be the fastest way to do this... (Score:3, Interesting)
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.