To add to the discussion (or to the confusion) we have a similar situation of Windows. Pipes are not the fastest IPC on windows. LPC ports and in Vista ALPC ports are the fastest, then probably any homebrew shared memory scheme and then pipes. The issues are that LPC have a non officially sanctioned api, shared memory channels is the IPC used on the sandbox, its main problem is the management of arbitrary sized messages, which we don't support.
At the end of the day we could add enough code to the sandbox ipc so it resembles the semantics of the pipe, but at that point the speed is no longer what it was. Now you see, all IPC is just layers of overhead on top of shared memory reads & writes, but sometimes you want that overhead. No, I am not arguing in favor of the pipes per se. I just want us not to fall into the trap of poorly reinventing the desired ipc semantics. We always said that each platform port should take advantage of the native capabilities. Besides, we have layers of objects on top of the IPC, I'll be much more worried if we had to change their semantics or apis. More: at least on windows both sides of the pipe are not equal. One clearly is the server and the other is clearly the client and there is a asymmetric api and semantics; this complexifies peer-to-peer designs but it is very nice for client-server like schemes like browser- renderer. Connecting as client to a pipe implies a fair amount of trust in the server, even before the first byte is exchanged. So we need to be careful in other platforms not to weaken the master-slave nature of the chrome IPC architecture. If you this benchmark you need to be careful to do a fairly complete impl of both, we want to make sure we account the overhead that involves variable size (up to 256M on windows) packets, the duplex nature and what happens when one of the sides just dies or just decides to close the connection. -cpu On Nov 7, 8:06 pm, Linus Upson <[EMAIL PROTECTED]> wrote: > If you want to argue using data, we'll use that. If you want to argue > using opinions, we'll use mine. > > Linus > > On Fri, Nov 7, 2008 at 7:55 PM, Amanda Walker <[EMAIL PROTECTED]> wrote: > > They work fine, though using Apache as an example, a Linux box running > > Apache can generally handle a higher load than Mac OS X running on the same > > hardware (historically, this has been true for any BSD-based kernel, not > > just Mac OS X). That said, on modern hardware Apache is mostly limited by > > TCP throughput over Ethernet, not interprocess communication. > > 10.5 is indeed better in this regard than prior versions of Mac OS X, though > > the experience of other Mac client teams at Google show a similar > > performance differential, as do other comparisons. For a recent example, > > seehttp://www.cs.virginia.edu/~jom5x/papers/macos.pdf. While they didn't > > make a perfect apples to apples comparison, they did use comparable hardware > > and measured an almost 2:1 performance difference between Mac OS X and Linux > > when it came to latency using signals and pipes between processes. > > However, we can all go back and forth all day with "based on prior > > experience, X is faster than Y" vs. "but it shouldn't be" :-). We'll put > > together some performance tests that will let us do some testing of Mac OS X > > pipes & signals, Linux pipes and signals, and Mach IPC on the same piece of > > hardware. Having some objective measurementa should help this discussion > > immensely. > > --Amanda > > > On Fri, Nov 7, 2008 at 8:54 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote: > > >> On Thu, Nov 6, 2008 at 2:05 PM, Amanda Walker <[EMAIL PROTECTED]> wrote: > >> > Linux and Darwin are only superficially similar, and the differences get > >> > larger the closer to the kernel we get. I realize I'm being repetitious > >> > here :-), but generally speaking, starting with the assumption that one > >> > technique will work on both, especially if it involves IPC, threading, > >> > or > >> > process creation, is a mistake. > > >> I'm very surprised that this is the case for Mac OS X 10.5. It is to > >> Mac's advantage to make it easy to port Unix code to Mac OS X. > >> If Apache can run well on Mac OS X, these common system calls > >> should have a good implementation on Mac OS X. > > >> Wan-Teh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
