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!"
I'm a fan of Slashdot, but I get a little sick of the Windows/Linux comparisons, -especially- when the post includes something like "but THIS test shows that Linux rocks!" Yay. Are we going to argue over PCs vs. Macs next?
DrPascal: Not the language, the mathematician.
Tests written by IBM (who just put more investment in Linux) shows that Linux is best?
Are they a little biased?
I'd prefer a neutral party to do the test and the results placed on a neutral site, personally...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
We already did that.
Macs "lost".
Good hardware, bad marketing.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Honest, this isn't a flame:
Can we set up a mailing list of some kind to know when Slashdot is done bashing microsoft? Either way you look at it, it's getting fscking old.
Besides the fact that XP in this article could have been the Home Edition, and could be heavily influenced by a number of factors- wow. Pipes.
Does it take a rocket scientist to realize that this is probably the last factor that goes through people's heads when purchasing an OS/Platform?
Maybe the motto for Linux should be 'Fastest Pipes in the business' oh wait- successfull business don't use linux. They use BSDI. Or Solaris. Or Windows.
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.
Ask your local MCSE, they'll tell you.
ROFL.
My beliefs do not require that you agree with them.
From the article..
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..
Rapid Nirvana
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.
Engineering and the Ultimate
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.
A test using pipes on Windows, by IBM, who pushes Linux. Heh... isn't that kinda like a test using Internet Explorer on Linux, by Microsoft?
One must wonder what "pipe" these people were testing out...
(yes, I'm just being facetious, for those of you humor-challenged)
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.
An Eye for an Eye will make the whole world blind - Gandhi
somehow this seems entirely unrelated.
-b
Well, of course I always would like to see Linux come out ahead, but the real question is -- Does it really matter? While pipes are an important part of Unix programming, are they useful in Windows? I mean I have used up to 10 - 15 little utilites piped together to get a desired output on Linux. I am not sure there is a parallel under Windows. Not being a programmer under Windows I don't know what kind of IPC they prefer to use...
So in short, nice test, but does it give us any thing useful?
Wasn't there a similar article a couple years ago that shows conclusively that Windows NT 4.0 was faster than Windows 2000 and a wide range of tasks?
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
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
Dell announces that Windows XP outperforms Linux. Slashdot denounces study as biased.
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
Is it just me, or is this not so impressing as it may sound.
While being a fan of Linux, I don't find this very impressive. This only shows the practical limits of pipes in the various OSs.
May ask for what purposes one uses pipes?
To copy several MB/s between some processes?
I don't think so.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
Do the tests include micro-grained security?
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-
IBM has alot to gain by proving Linux superiority. If this were Microsoft's test and they showed the opposite, I'm sure that the /. community would immediately write it off as a rigged test.
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.
Using named pipes may not be fastest way to do interprocess communication. There's lots of ways to do interprocess communication. You could use Automation (used to be called OLE Automation, but it got folded into the COM architecture). You could also set up a shared memory page file.
There's some technique to do interprocess communications that worked pretty well in Windows 3.1 (using SendMessage, and Dynamic Data Exchange are a couple of methods that I remember).
I imagine there's even a way to do this using the TCP/IP stack. And in a worst-case scenario, you just have one application write to a file, and another application would read that file when it's done making changes.
So, the question is, is this REALLY the fastest way to do interprocess communication? Hmm....
Since when is a shell (decent or otherwise) required to use pipes?
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?
new is spelled "knew" in this context.
Editors: You edit the posts, I know you do. On main-page stories please make sure that such bvious errors are fixed, otherwise we look like a bunch of high-schoolers...
Our only way to judge people online is by their words, so it is important to get those words right!
Travis
Windows XP may have fared poorly because it's brand new and so is it's API. On the other hand, Linux and Win2K have had a few years in which their APIs have matured/improved and some of their kinks or other bottlenecks straightened out. Point being that the XP API may still have those kinks in their code, causing some slowness compared to other systems.
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.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
And linux does?
Subjective statements and reviews are pointless... I want to see objective views... This is better than that because this has 'X' would be good. It may actually prevent pointless bashing...
---
Programming is like sex... Make one mistake and support it the rest of your life.
Passing NULL to the security argument? Guess that explains IIS and Outlook.
--Won't that be grand? Computers and the programs will start thinking and the people will stop. - Dr. Walter Gibbs
"... 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?
Bush's education improvements were
These pipes are clean!
PDHoss
======================================
Writers get in shape by pumping irony.
Is it really that surprising?
Linux/UNIX and Windows come from radically different parentage. Linux/UNIX was built from the ground up over the past 30 some-odd years to be a system of fast, modular components. That philosophy of design (thankfully) has changed relatively little during that timeframe.
Conversely, Windows was built from the ground up to be more monolithic in design, with little attention payed to streamlining and modularity. This results in less than elegant implementations of features easilly expressed in other OS'es. Unix, by design, allows for such things to be accomplished with relative ease. Windows can, but not with the same degree of ease.
Bowie J. Poag
It's not like IBM has anything to gain from publishing a comparison of this kind.
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.
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.
If programs would be read like poetry, most programmers would be Vogons.
..will it ever register on the consumers radar? How about applications in use?
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.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Creating a pipe in Windows:
//
// Create named pipe in Windows
// nbytes -- block size from command line arguments.
//
// two connections
// input buffer size
// output buffer size
// timeout
// security
int mult = 1;
int x;
x = mult*nbytes + 24;
handleA = CreateNamedPipe(pipeAdult,
PIPE_ACCESS_DUPLEX,
PIPE_TYPE_BYTE,
2,
x,
x,
INFINITE,
NULL);
if(handleA == INVALID_HANDLE_VALUE) {
printf("CreateNamedPipe() FAILED: err=%d
", GetLastError());
return 1;
}
handleB = CreateFile(pipeAdult,
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if(handleB == INVALID_HANDLE_VALUE) {
printf("CreateFile() FAILED: err=%d
", GetLastError());
return 1;
}
Creating a pipe in Linux:
int fd1[2];
if(pipe(fd1)) {
printf("pipe() FAILED: errno=%d
",errno);
return 1;
}
"Now gluttony and exploitation serves eight!" - TV's Frank
If you've read the the other article(s) (how long it takes to perform a memcpy) in this series, it seems he is trying to desparately find holes where he can say "Linux is better".
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 ?
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Ok, I don't know why you bothered posting this, probably pointless flamage you post freqently, but I just thought I'd comment. First of all your VB experience doesn't mean anything in linux, I'm pretty sure there isn't a linux compiler for VB. Second of all you said you configured the system from scratch, and recompiled all the programs in what you believed to be a better compiler. Sounds to me like you built everything yourself, then blamed someone else when it didn't all work perfectly. Personally I have never (never meaning sometime after linux became well known, of course in the early days in had to be done by scratch) heard of anyone who first introduced themselves to linux without the help of a basic distribution. So either your a lier, or an idiot.
Posting +1 cause I have karma to burn!!
They compared the Win2k Advanced Server version to the WinXP Desktop version. As we all know, IBM isn't biased at all :)
a unix like OS being better at pipes than windows? no way... that just can't be. I mean, seriously, why was this article even published. I bet OSX does better too. hmmmm. WinXP is pretty darn new, and is not aimed exclusively at pipe loving coders. unix is king of the beats when it comes to pipes. they were one of the frist things I learned when coding C for unix.
slashdot would do better if they got over their anti-microsoft fixation and instead unified the open source masses instead of making them seem to be a bunch of zealots.
today i tested to create 10'000+ files on the desktop
as well as anywhere on a windows nt 4 server (ntfs)
and a) took very much time
b) even deleting them (shift-del, no paper-basket) took minutes
both in the shell! btw cpu usage was heavy
one funny thing is you can have files on desktop and attrib -h (hide them)
all testing was done using qbasic, like this
for a=0 to 10000
shell "echo bla > ",$ltrim($str(a))
next
(i know this "forks"for each file)
however deleting the files (at the prompt del *) took LONGER than creating them!!!!
my god all this is so much faster on linux (ext2)
Windoze not found: (C)heer, (P)arty or (D)ance
So why didn;t IBM show the specs for AIX as well? Did AIX do even worse than XP?
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...
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Well, first I wonder why the author would do something like
...
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
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.
Nitpick: pipe() doesn't create a named pipe. mkfifo() does. I don't know if that's a printo or what.
I don't know much about the Windows code, but it looks like it's not named, either. I hope not, or else we might have a different comparison here.
"tell me again why we pay this Dr. to test pipes? And howcome half of his budget goes towards delivery pizza??"
The article mentioned is well written and informative. Based on the comments, many people comment on the substance based on the lead-in Slashdot posting. I say, before you comment on things like "Home version" or "biased", you should learn to read.
...it's not the size of the pipe that matters but its speed.
If you actually thought that there was an ounce of deceit in IBM's comparison, you would download their published source code, install Linux (I'm guessing that step isn't something you've done already - am I right?) and try the well-documented tests yourself.
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.
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.
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.
An MCSE has nothing to do with ODBC or named pipes (just a point of reference that in this context that note was irrelevant. BTW: The "albatross" comment is just silly -> You don't have to tell anyone that you have it).
Anyways named pipes is being deprecated, as of SQL Server 7, in lieu of TCP/IP Sockets.
I don't usually follow trolls... but this guy is absolutely ridiculous. Linux does not support SMP? Then what do you call what my machine is doing right now? VB lower level than c? How??? Windows was writtin in C? Granted... this article was kind of linux FUD, but saying that 1 windows box could beat 3 linux boxes... well the only way I see that is if you installed linux on a 486 with 16 megs of ram and were too stupid to believe that it would take on a dual xeon machine with a gig of ram running win 2k advanced server. Thats shit man... absolutly shit. Look, I run a dual pIII system with a gig of ram under both linux (kernel 2.4.7, although that has some vm problems all in itself) and win2k advanced server and I'd be the first to say that there really is no noticable difference between the two (except windows does have more applications, and linux is easier to program). So my point is shut the hell up you damn troll.
ps- How hard would it be for slashcode to start a troll filter (besides labeling trolls -1) which just wipes out this crap. As I said before... the only reason I followed this troll is because he serisously pissed me off by being such a choad.
can't sleep slashdot will eat me
This is just saying which OS has faster pipes:
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...
Eddy.WriteLinux.Com
I don't know about you, but I always try to proofread. Nothing is more embarrasing than misspelling a second grade word. (Did I spell everthing okay?)
- - - If the sun is a star, why can't I see it at night?
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
nevermind... you're a waste of time... i've already checked out your history... i'd say for an asshole you're a pretty good propaganda writer ;-)
can't sleep slashdot will eat me
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?
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.
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
Are pipes even significant in Windows? Are they used in any significant manner? Seems to me like comparing something one OS was designed around to something another OS just tacked on as an afterthought. Was anybody surprised that Windows pipes are not as efficient/nice/whizbang as any *nixes pipes? Next: let's compare COM+ performance between Linux and Windows!
It's 10 PM. Do you know if you're un-American?
I think an intersting comparison would be winxp's implemention of unix sockets compared against Linux's implementation.
Yes but every time I try to see it your way, I get a headache.
Why is that news for nerds and stuff that matters has to revolve around MS so much here lately? If I wanted Windows news I would go to Microsoft.com or ActiveWin.com, not /.
Anyone else bothered by the fact that the tests on Windows were using named pipes while the Linux ones were using unnamed pipes? I'm rather certain that named pipes would be slower in the first place...
Although I new Linux would fare the best
I know this my sound a little.....stupid coming from me, for those that know my postings, but even I am not this bad.
I am the Alpha and the Omega-3
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.
Without comparisons like the one posted, how would any programmer know the strengths of the operating system that he/she is programming for?
Its clear as crystal that pipes should be avoided at all costs on Windows XP, that seems like valuable information to me!
And ofcourse Im happy that Linux comes out on top, it just shows that KISS works. Very simple pipes, very simple operations, and it does the job well.
/proton
Which OS user has the cleanest pipes from being cleaned too often? ;)
Just my hyperactive imagination at work.
Nothing to see here, move along.
-Shaunak.
Without comparing Windows pipes to Linux pipes, if XP is supposed to be based on the NT/2K kernel, then why would such a simple benchmark program produce such vastly different results unless either the benchmark systems were not configured properly, or XP is not completely a 2K offspring.
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.
Fear: When you see B8 00 4C CD 21 and know what it means
I see way too many anti-Linux comments.
XP isn't even 1/8 as fast on this benchmark as Linux is, and 2k didn't make it to half as fast. Maybe you trolls out to look at the benchmark before you say were biased. I find it interesting that Microsoft is again getting slower... first with NT being faster than 2k on SQL, XP is likely to also be slower than 2k, considering the uses of pipes on windows suggested.
As far as overall performance? Windows doesn't have a chance, sorry.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
Um, I don't think you're right on that one. Linux SMP performance is quite good, and it suports more processors as well.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
First of all, in no way is this a flame towards:
a) any operating system, or b) Slashdot itself.
But seriously, if Linux ever lost in a benchmark or some other form of test, would it get posted on Slashdot? I highly doubt it. I run Linux and Windows myself, therefore I do not flame either. I think the Slashdot community could be a little more unbiased towards operating systems such as Windows and leave the "Linux rocks, and if you don't preach it, you suck" bandwagon. Linux does rock, but Windows has it's high points too, and it just turns out that Linux showed off it's higher point in this test.
void women (int money, time_t time);
Now all Linux needs is a good set of glasspacks.
If this report had stated Windows was the more efficient platform and the report was created by a biased affiliate (see: no Unix, Windows only) of Microsoft, what would Slashdot be saying right now?
Something like this. It's unfortunate, but true. This topic is a flamewar (wait for the first Windows zealot to post) waiting to happen, as are (moreso) those topics on Slashdot which seem to represent Windows in a positive light.
Just a little something I noticed.
Do you like German cars?
Sigh. At one time the Amiga was the pinnacle of personal computer design, but the Amiga community degenerated into an inbred group that other people couldn't stand to be around. I kept wanting to scream "If you like your Amiga, then that's great, but if you think it's so superior then why do you have such a defensive tone?"
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.
i already posted a comment telling the guy that it was a good troll... i realize i was trolled, anything else would be utterly stupid. The fact that people sit around waiting for trolls is even stupider. What I wrote, I wrote quickly and without thinking... -retards
can't sleep slashdot will eat me
I may be wrong here, but I think the overhead of creating and using threads would be a more important measure than interprocess communication for high speed programming.
Sig free since 2/6/2002
A much more interesting thing to look at might be the various IPC mechanisms of both Windows and Linux and compare their performances. This would be a much more interesting and relevant article.
FWIW, even if Linux's pipes were faster, this would not necessarily mean the Windows pipes were inferior. You also have to test scalability, i.e. how much faster one or more pipes ran on a one or more processor machine.
If you look at Solaris pipes vs. Linux pipes, you'll see (or would have seen the last time I looked at it) that Linux pipes tended to be faster. This was mostly due to the many locks inside the Solaris kernel that were absent in Linux. The result is slighly worse performance for uniprocessor machines, and better performance for multiprocessor machines for Solaris.
Of course, as has been pointed out, this is all fairly moot, since pipes are apparently not used that much in Windows, which goes back to my first point.
IPC performance is a very interesting issue. Unfortunately this article doesn't really address it.
COM has it's place, but it's not the best solution in all case!!
What about cross platform apps?
What about apps that don't want to mess with the registry.
Which is a real pain during install.
COM is too complicated in many cases and locks you into Windows.
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.
Pipes? Pipes? Who the hell uses pipes? I've been a windows programmer for quite some time and have never used pipes to do anything. This is like comparing the cooling effects of rolling down the windows to in cars. Sure, the older cars get a lot more air through the car, but the new cars have AC...ok, so that's not such a good example...but I don't know anyone who uses pipes, or would even have reason to.
Is there an application where many GBs would be piped, and where this throughput difference would then matter?
the NT+ pipes do a little more (though the linux ones seem far more useful by their simplicity) so its natural that they'd be slightly slower. And slightly slower is what win2k is compared to linux. It hardly matters. XP did bad, but its almost obviously a bug that will be patched eventually/soonish.
I mean, name one application or business purpose where faster linux pipe performance would win it a contract? There just aren't any.
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.
.sig? Get your own damn
Look,
/.ers who pooh-pooh this article as being unimportant, shut up. Neither this article, nor slashdot claim to be anything more than they are.
Slashdot's motto is "News for nerds. Stuff that matters." It's not "Market analyzation. What drives sales."
This story is geek info, nothing more. It's exactly what slashdot should be posting.
NO ONE said that IPC performace is what consumers are looking for when they purchase a machine. No one said that "a half-decent GUI and a huge set of tools" are unimportant.
The article makes no claims to the effect of: "the high performance of pipes on linux will yield the imminent demise of microsoft". The series is titled "High-performance programming techniques on Linux and Windows." It is covering exactly what it should be.
So, to all those
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 project has implemented everything necessary to interoperate with MS NamedPipe servers.
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.
My ... pipes ... are ... CLEAN!
Never answer an anonymous letter. - Yogi Berra
The windows 2000 machine was running Advanced Server. The windows xp machine was running Professional. Those are different and not worth comparing.
"According to recent pipe throughput tests, MicroSoft Windows XP has yet again proven to be better than Linux as it has a considerably lower performance degradation due to increases in pipe block size!"
;) Linux drops off considerably after 100,000 while Windows XP just flatlines.
Just check the numbers!
My name fits again.
Ah, don't try to use Memory mapped files under W2k either. I don't know about XP but I have a little memory mapped file application that runs about 10x faster under linux than windows. I jumped though a bunch of hoops to get it up to only about 3x slower by setting my process quota, messing with a bunch of system cache settings, etc. I don't know what the current recomendations are for IPC on w2k but long ago I started to design all my applications for a threaded model and use TCP for any real interprocess/machine communication. This gives me realitivly easy portability off of M$ productions (unlike COM).
Which version of xp? Which build? Which version of 2000, meaning which service pack? Which build of that? What version of the linux kernel, and what version of linux itself? Was linux using gnome or a windows type of gui, or was it command line?
Oh, and what was the speed of the network?
Comment removed based on user account deletion
Pipes are old school. Apps that are really cross-platform use sockets over TCP or UDP.
Feeling superior because of your OS is pretty lame, regardless of system.
The copper bosses killed you, Joe. 'I never died', said he.
Pipes are what they used before proper IPC methods like messaging were created...
I'm just kidding. Pipes are a mechanism to allow applications to send data to each other. An app at one end can stuff date into the pipe by pretending its writing to a file, and the app at the other end can read the pipe just like a file and get the data out. In Windows, pipes are rarely used. More often, people will use messaging or implement a COM or OLE component.
A deep unwavering belief is a sure sign you're missing something...
"The number 24 in the first executable line of code above was determined experimentally. I found no mention of it anywhere in the Platform SDK. If it is not present, the program doesn't work. Apparently, the pipe facility requires a 24-byte header on each write to the pipe."
:)
I think this says alot why I don't wanna work with windows pipes...
Oh wait I forgot to site this: "Our results showed that Linux pipes are considerably faster than Windows 2000 named pipes, and Windows 2000 named pipes are much faster than Windows XP named pipes."
Anyone who wants to know alot more about pipes in UNIX/Linux should read Richard W. Stevens bible "Advanced Programming in the Unix Environment", any respectable programmer should have read that book at least one time in his/her life.
And finally it would be really interesting to see this experiment done with sockets too. Atleast Im gonna try it out.
And btw, I wouldn't want to be around when Billy G gets his hands on those guys who made this test...
2 reptiles beneath your current threshold.
I know I'm waisting my breath, I'm just in a silly mood today.
I expect to be able to configure Linux as I configure Windows2000. You can, you just have to know what your doing, its not like someone who spent their entire lives working on a Mac could just sit down and expect to be able to configure a full Windows2000 enterprise solution without any problems, so why should be expected to be able to sit down at linux and be able to run it without any learning.
Convert to VB? VB is a programming language nothing more, I'm sure if someone really wanted to they could write a VB compiler in linux,
(working around the obvious hooks to windows api) but why?
There is absolutly nothing slow about C, though I personally prefer C++, slowness is in the coding method and the complier, there is nothing "slow" about C anymore than any other language. Anyways it all comes down to the classic vi/emacs war, you can produce the same results with both of them, its just a matter of what your comfortable with.
Performance usually the least of my considerations
>>>>>>>
You must be a KDE-2 developer!
A deep unwavering belief is a sure sign you're missing something...
That'll be any client app communicating with a database using an ODBC pipe for starters.
I think are probably one or two of those out there.
You did a terrible, terrible job of linking to goatse. Slashdot puts the hostnames in brackets next to the link now, so you fooled noone. Oh, and the colon's fine. You know why? Because we got the idea! That's what writing is about! (especially in a friggin' slashdot post! it's not an essay or book!)
My other car is first.
On NT he creates a buffer with size equal to the total size of transmission data (up to hunderds Megs). He is actually mesuring the speed of paging to swap file, not speed of pipes.
What he had to do is create small buffer, like 64 Kbytes, or just like Linux's 4 Kb buffer, and work with it. This comparision has nothing to do with pipes, just with stupidity of some people.
What a shame for IBM, I've read some very good articles there, but this one is total crap.
MSDOS: 20+ years without remote hole in the default install
how often are pipes used in important server applications? yes, they are ubiquitous on the command line, but how frequently would a pipe be used over an API call? i can't imaging sticking a "system("app1 | app2 | app3");" call inside of a major server application stack. or would this be done in real life?
windows is built around API calls, not pipes, so it doesn't surprise me that pipe communications blow.
somebody fill me in...
https://www.accountkiller.com/removal-requested
Pipes are in Windows solely for compatibility with other systems and legacy stuff. If you are going to do interprocess (distributed or not) these days, you do it with COM.
The benchmark posted is meaningless.
Natural != (nontoxic || beneficial)
Forget pipes, they need to start implementing Bongs and even Hookahs! 8^}
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Of course XP runs like a dog. Have you seen it?
Maybe the bash script just ran faster under linux than windows. why not create a program that is compiled that does the pipe work instead of a bash script. There are still apples and oranges being compared here.
Silly Rabbit...Sig's are for kids.
What does B8 00 4C CD 21 mean?
WindowsXP == WindowsNT 5.1. For the personal edition they only provide a uniprocessor kernel and put some Millennium-like toys like the personal video editor and shit. It's memory management is also detuned similarly to the way memory is tuned differently between WinNT Pro and Server.
I'm a loner Dottie, a Rebel.
s/new/knew . I may only be a sophmore in high school, but even I know a spelling mistake when I see one. But it's OK--just try to pick up mistakes next time. :)
"Anyways named pipes is being deprecated, as of SQL Server 7, in lieu of TCP/IP Sockets".
....
Wow another new invention by Microsoft!
Of course I have no problem with MS adopting standard approaches to problems that other RDBMS makers (and MySQL and Postgresql) have had for years. But I just **know** it's gonna bug me when I hear this bumpf spewed back at me in the industry press as "innovation".
The same stories will then get clipped and mailed to senators and legislators by lobbyists to support the argument that MS can't be touched or the economy will crumble and we won't be innovative and have MS TCP-IP any more
sigh
I agree with your statement that they shouldn't focus on the "average user" who just wants to check email, write documents, and browse the web. If that was all users wanted to do, they could make GNU/Linux extremely simple to use. But for some reason the powers that be wanted a general purpose operating system rather than an expensive gameboy and so that implies more complexity. There is no way you can get away with a dirt-easy general purpose OS.
This is my offtopic rant of the day.
This is like saying "Joe Blow's toilet flushes faster than Joe Fish's toilet"
MODERATORS: I suggest you moderate the parent comment UP.
Microsoft probably slowed pipes in Windows XP (eXtra Pain) to accomplish some purpose. Here are some quotes from the parent comment:
'Many "enterprise" systems still use pipes on windows. Database systems in particular...'
"I doubt SQL Server uses them (especially if they're degrading this quickly) but many of MS's competitors still do (Including IBM's DB2)."
Of course, long-time Slashdot readers will find it hard to believe that Microsoft would do something against the common good. *grin*
Also, the point is not that this test shows the overall superiority of Linux. It shows an example of the code quality of Linux.
Secrecy destroys democracy: What should be the Response to Violence?
Bush's education improvements were
Pipes are one of several IPC (interprocess communication) techniques used in Unix. Type 'perldoc perlipc' for a (perl-centric) overview. Example of where I used pipes: a program that forks, with one process handling the GUI and several handling web transactions. How can the webgetters share data with the GUI? Some kind of IPC. Why did I fork? Because I didn't want the GUI stuck while downloading data from the web.
Named pipes are a bit special, because they sit there in the file system looking much like ordinary files, even when no process is using them.
He did test with a 4k buffer on NT. It was slow, so he tried the huge buffer.
that's what they teach the stockholders.
_______
2B1ASK1
Interesting that you automatically assumed that I was implying windows. I actually work with Solaris 60% of the time, 20% windows and 20% linux. Regardless, it would be pointless and retarded for me to argue performance, latency and resource hogging since all comparisons are subjective to individual projects. Which was exactly my point to begin with -- that often you have to look well beyond performance to the point of even making sacrifices in a business environment.
i.e.: I would like to use the linux RPM system for software deployment, but need to make a rational decision to go with the standard Solaris Package system since my 20 system admins refuse to learn anything new. Again, these are real world realities beyond the academic/hobbyist/startup environment.
_______
2B1ASK1
I'll take exception to that statement. It is true that I use this machine in front of me to check simple text messages and get porn much of the time.
But it STILL beats the living dogshit out of using Windows!! Why, you ask? Because when ONE piece of the code breaks it doesn't bring down the whole fucking thing!! I can kill PIDs and get on with my day.
I've learned a lot about computers since I started with a Compaq 5610 with Win98. I've learned how to code in Pascal and HTML (laugh at Pascal if you must but I like it!) I've come to expect GCC to be there when I need it. I like the idea of being able (and free) to screw things up as I see fit. I am proud to say that I *AM* Joe Schmoe and I use Linux! Don't tell me that it can't be used by amateurs because I know for a fact that they CAN!
Useless opinions, worthless observations, and more!
This is a good one, well worth considering. But following your policy without looking ahead would mean that we'd all still be doing COBOL or 360 assembler. So you also need to make strategic choices about your technical direction, not just follow the pack.
Sounds unlikely that brand name recognition has any place in product selection. Existing contracts might matter if those contracts were entered as the result of architectural choices rather than golf-course deals. Otherwise you're throwing good money after bad by expanding existing relationships with suppliers who aren't meeting your requirements.
Most legal departments will inform you that software licenses are constructed so that suits of this nature are very hard to win. Not a good consideration. Anyway, the net result of this policy is to exclude open-source software, some of which is technically superior and better-supported than commercial competitors, and with demonstrably better ROI.
This matters in instances where the application might need to scale. But there are a number of instances within a business where that might not happen, and in those cases, scalability is less important.
I think there's a simpler rule: if there's a business need for performance, implement a system that delivers that performance and will continue to do so within anticipated system growth. If you follow this rule, there will be instances where performance certainly will matter. Benchmarks like these are important for those instances.
Get your teeth into a small slice: the cake of liberty
"- Liability: is there someone to blame when things go wrong? (like it or not) "
I am sure there exists in some business school or some corporate brainwashing seminar or maybe a crack den someplace where people are told that they can hold software manufacturers responsible for crappy code. What frightens me more then anything else of course are CIOs (or perhaps some middle level drones such as yourself) actually make decisions based on this premise. One presumes of course that they are not only willing to bet the company on such a shaky understanding of reality but are also willing to go to court and sue MS because the server crashed.
So do me and all the other slashdot readers a favor and tell us the company you work for. I for one want to make sure I don't own any stock in a company that has such stupid management. I certainly want to avoid investing in companies that are willing to waste their shareholders money trying to sue Microsoft or Oracle. Besides it will be awfully embarrassing when the court documents show that not one person in the IT dept ever read a EULA.
War is necrophilia.
Oh, don't forget that WainForMultipleObject have hard limit of 64 maximum objects to be wait at once. So it is useless for web servers, you need then to use the threads anyway to be able to work with multiple clients. Linux's select is better for this.
-- Wanna textmode user interface for ruby? http://freshmeat.net/projects/jttui/
i.e.: I would like to use the linux RPM system for software deployment, but need to make a rational decision to go with the standard Solaris Package system since my 20 system admins refuse to learn anything new. Again, these are real world realities beyond the academic/hobbyist/startup environment.
Then you're not doing a good job explaining the benefits of RPM to them, or you have people who will fossilize when their preffered solution for a particular task becomes obsolete. I'm always amazed at people who let these considerations completely outweigh technical issues. At the point where solely internal politics forces you to choice something you believe is inferior, you have a problem.
I see a lot of comments here bashing the article for not giving the whole picture and you're right, it doesn't give the whole picture, but neither was it intended to.
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.
CS professors would never say "just make it work." But they wouldn't want you to strive for elegance, either. The job of CS professors is to churn out immeasurable numbers of the mindless Java programmers that the industry wants, solely so that the school can claim "Look! 94% of our graduates got a job!" and lure in more future drones.
No university I ever went to did that. In my CS classes, elegance was highly valued. Students were taught problem-solving techniques that could be applied to any language. Students were encouraged to develop a deep understanding of algorithms and data structures and orders of complexity. Projects were implemented in languages with greater pedagogical than commercial value. Many students bitched about this, but it pays off big when someone wants to hire them to program in a language nobody has ever heard of before.
I don't know where you draw your examples from; the hypothetical recent grad you described never would have passed any of my CS classes, and would never have been hired by any of my employers.
Afetr thinking about this I decided my gripe is that he's a "bottom up" benchmarker rather than a "top down" benchmarker. I personally like to see comparisons of how good a system is performing a specific task, and if the performance of that task is substantially below or above the run of the mill standard, some follow-up analysis to determine where it makes its gains/losses.
Say what you will about the MindCraft benchmarks, one result of them was a hefty rewrite of the Linux TCP/IP stack for 2.4 'cos this was revealed as a major system bottleneck. I'm not sure that the Bradford benchmarks are going to achieve the same thing, unless he follows up his simplistic benchmarking with better analysis of his results.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
What's needed is the ability to call a method of an object in another address space. CORBA (and DCOM) support this, but it's inefficient, because the mechanism in the middle is a pipe or socket. (Or protection is bypassed entirely, which is a common non-solution.)
Specifically, what's needed in the OS and hardware is the ability to call across a protection boundary. Every system call does this. The mechanism behind system calls needs to be generalized to support arbitrary inter-object calls.
This has been implemented a few times, most notably in Multics protection rings, but there's usually a hierarchy involved. The call system supports safely calling objects with more privileges than yours, but doesn't generalize.
QNX, the most successful commercial microkernel, works a lot like this. There's more copying involved than one might like, but it works fine. With better hardware (some minor mods to Pentium call gates would do it), such calls could be very low cost.
What would this all mean? CORBA without the overhead. Fewer monolithic systems. Collections of components more reliable than the individual components, like clusters. Stuff that worked.
The posting says "both Windows and Linux and UNIX". Both?
(In desperate search for a cool