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!
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.
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
You know, if you want to come off as being fair and circumspect about these things - and not as a flame or troll - you might want to reconsider that last paragraph.
Successful business(sic) don't use linux?
Please - you're as guilty of the bias you're complaining about as the story is.
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
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.
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?
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.
"... 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
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
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 :)
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.
"tell me again why we pay this Dr. to test pipes? And howcome half of his budget goes towards delivery pizza??"
It's not a flame, it's flame bait. Succesful businesses do use Linux, we do. In fact it out performs Solaris for our applications. I'm just happy I get to use a *nix instead of windows. Keep windows where it belongs, catering to people who don't know what they're doing.
I'm the big fish in the big pond bitch.
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.
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
In the comments it's noted that the tests were done on Win2k Advanced Server. Just a FYI. :)
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
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
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.
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.
No it isn't.
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.
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
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.
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.
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
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.
Comment removed based on user account deletion
We're talking about named pipes here. It would be ambitious to generate a 15-long chain of named pipes :)
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...
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.
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
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
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.
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.
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.
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
"- 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.
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.
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.