linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: ORBit speed measure
@ 2000-12-14 17:10 Chris Lattner
  2000-12-14 21:44 ` Mike Castle
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Lattner @ 2000-12-14 17:10 UTC (permalink / raw)
  To: Xavier Ordoquy; +Cc: orbit-list, linux-kernel


>> There is a large perception of CORBA being slow, but for the most part
>> it is unjustified.  

> Well, I've measured using function calls through ORBit is 300 times
> slower than using dynamic loading.
> ...
> Which gives me the dl is about 333 times faster than ORBit.

You leave so many details out, and you sortof miss the point with my
statement.  The idea is that CORBA doesn't specify a transport to use _at
all_ except when doing inter-orb communication (which you basically have
to use IIOP to be compatible).  This is why, for example, if you
ior-decode ORBit IORs that they contain two parts: an IIOP portion, and a
Unix domain socket portion.  Basically ORBit is optimizing the
intramachine case, because it is very common for purposes that ORBit is
mainly used: GNOME.

You didn't specify, but I assume that you were using the Unix sockets
transport for your benchmark.  I am also assuming that the two things
communicating were in different processes.  If you wanted to make a more
fair test case, you would have to use some form of IPC mechanism to
communicate between two distinct processes.  Comparing a function call to
an RPC mechanism will never look good.  :)

There are many other optimizations that one can make the transport faster
that ORBit doesn't implement.  For example, you could mmap (shared) data
buffers between the two processes communicating (of course, you still need
to wake processes up, which is why it hasn't been done yet), or you could
use pipes (if you can control forkness) or any number of things.  If you
are communicating with a server in the same process as your client
(because it was dynamically loaded) you can even do a direct function
call.

When I said that "for the most part it is unjustified" to think that CORBA
is slow, what I meant is that CORBA isn't slow: implementations are.  Just
look at the difference between ORBit and all those other orbs out
there... orders of magnitude speed differences, with little or no
functionality differences.

What CORBA gives you is the power to have optimizations for important
special cases (in kORBit's case, one of those would be User->kernel),
WITHOUT sacrificing the big picture or the ability to be interoperable...

I am not claiming that kORBit is where it needs to be right now.  :)

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/MagicStats/
http://korbit.sourceforge.net/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ORBit speed measure
  2000-12-14 17:10 ORBit speed measure Chris Lattner
@ 2000-12-14 21:44 ` Mike Castle
  2000-12-15  0:22   ` Erik Mouw
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Castle @ 2000-12-14 21:44 UTC (permalink / raw)
  To: linux-kernel

On Thu, Dec 14, 2000 at 11:10:24AM -0600, Chris Lattner wrote:
> There are many other optimizations that one can make the transport faster
> that ORBit doesn't implement.  For example, you could mmap (shared) data
> buffers between the two processes communicating (of course, you still need
> to wake processes up, which is why it hasn't been done yet), or you could

This is not necessarily faster.

I recently came across some discussions on the web from Jim Gettys that
discussed similar issues for X (unix sockets vs shared memory).  I seem to
remember that the over head of synchronizing stuff to keep the shared
memory in a sane state ate away at any gains one had with using shared
memory.  It works ok for large chunks of data (say, things on the order of
sizes of pixmaps), but not for smaller pieces, like say, function call
arguments.

Then again, isn't Jim some how involved in ORBit and GNOME?  Or just a big
supporter?  :->

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ORBit speed measure
  2000-12-14 21:44 ` Mike Castle
@ 2000-12-15  0:22   ` Erik Mouw
  0 siblings, 0 replies; 3+ messages in thread
From: Erik Mouw @ 2000-12-15  0:22 UTC (permalink / raw)
  To: Mike Castle, linux-kernel

On Thu, Dec 14, 2000 at 03:44:01PM -0600, Mike Castle wrote:
> Then again, isn't Jim some how involved in ORBit and GNOME?  Or just a big
> supporter?  :->

Jim works on XFree86 (among other things). So yes, he is indeed
*somehow* involved in GNOME ;-)


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-12-15  0:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-12-14 17:10 ORBit speed measure Chris Lattner
2000-12-14 21:44 ` Mike Castle
2000-12-15  0:22   ` Erik Mouw

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).