[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Different corba implementations
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-06-15 23:10:02
[Download RAW message or body]

Hi,

On Wed, 16 Jun 1999 weis@stud.uni-frankfurt.de wrote:

> Hi,
> 
> I met the guy who is responsible for ACE/TAO.
> 
> a) He is a pig

I should not have said that. However, I really dont like him
for several reasons but want to apologize for bashing people
because of my preferences/dislikes.
However he seems to have commercial interest and always talks
about flying planes with ACE/TAO. My Professor asked:
Would you fly with a plane that uses ACE/TAO ?
Answer: No, we have dummies for that.

Especially he talked about military planes and that the
ORB has to be fast to launch rockets at the correct time.
Please understand that I refuse to use a product that
is developed for a military environment.

Bye
Torben

> b) Last time I looked at the code it had license problems.
>    We could not just put mediators etc. in our libs as we
>    do with mico.
> c) ACE is terrible.
> d) The code is even more wired then MICO
> e) I would even go with Orbit before using ACE/TAO.
> 
> Bye
> Torben
> 
> 
> On Tue, 15 Jun 1999, pbrown wrote:
> 
> > I know some people don't like to hear this brought up, but I was
> > investigating alternate corba implementations for reasons of speed and
> > memory-usage recently.  MICO is nice but it sure is a pig.
> > 
> > I have found that TAO (the ORB on top of ACE, the Adaptive Communication
> > Environment) seems to concern itself with these issues to some degree, and
> > has attempted to combat it:
> > 
> > "Conventional implementations of CORBA suffer from excessive dynamic
> > memory management and data copying overhead. Dynamic memory
> > management is problematic for hard real-time systems because heap
> > fragmentation can yield non-uniform behavior for different message sizes
> > and different workloads. Likewise, excessive data copying throughout an
> > ORB endsystem can significantly lower end-to-end performance. 
> > 
> > Existing ORBs use dynamic memory management for several purposes. The ORB
> > Core typically allocates a memory buffer for each incoming client
> > request. IIOP demarshaling engines typically allocate memory to hold the
> > decoded request parameters. Finally, IDL dynamically allocate and delete
> > copies of client request parameters before and after an upcall,
> > respectively.
> > 
> > These memory management policies are important in some circumstances
> > (e.g., to protect against corrupting internal CORBA buffers when upcalls
> > are made in threaded applications that modify their input). However, this
> > strategy needlessly increases memory and bus overhead for real-time
> > applications, as well as for streaming applications (such as satellite
> > surveillance and teleconferencing) that consume their input immediately
> > without
> > modifying it.
> > 
> > TAO is designed to minimize and eliminate data copying at multiple points.
> > For instance, TAO's ``zero-copy'' buffer management system described
> > in allows client requests to be sent and received to and from the network
> > without incurring any data copying overhead. Moreover, these buffers can
> > be preallocated and passed between various processing stages in the ORB.
> > In addition, Integrated Layer Processing (ILP) can be used to reduce
> > data movement. Because ILP requires maintaining ordering constraints, we
> > are applying compiler techniques (such as control and data flow
> > analysis) to determine where ILP can be employed effectively. 
> > 
> > Using compiler techniques for presentation layer and memory management
> > functionality allows us to optimize performance without modifying
> > standard OMG IDL and CORBA applications."
> > 
> > Has anyone else checked out TAO?
> > 
> > ---
> >   Preston Brown                                    Systems Engineer
> >   pbrown@redhat.com                                Red Hat, Inc. 
> > 
> > 
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]