diff options
Diffstat (limited to 'ACE/docs/ACE-subsets.html')
| -rw-r--r-- | ACE/docs/ACE-subsets.html | 196 |
1 files changed, 196 insertions, 0 deletions
diff --git a/ACE/docs/ACE-subsets.html b/ACE/docs/ACE-subsets.html new file mode 100644 index 00000000000..ef2a1e0dcd1 --- /dev/null +++ b/ACE/docs/ACE-subsets.html @@ -0,0 +1,196 @@ +<!-- $Id$ --> + +<html> + <head> + <title>ACE+TAO Subsetting</title> + <link rev=made href="mailto:ace-users@cs.wustl.edu"> + </head> + +<body text = "#000000" + link="#000fff" + vlink="#ff0f0f" + bgcolor="#ffffff"> + +<hr><p> +<H2>ACE+TAO Subsetting</H2> + +<p> +We are involved in ongoing activities to subset ACE+TAO to make them +more flexible and to reduce their memory footprint for embedded +systems. This document describes what we've done thus far, what we're +planning to do next, and how to leverage our efforts to minimize the +size of your ACE+TAO applications. </P> + +<hr> +<h3>Contents</h3> +<ul> + <li><a href="#pastwork">Past Work</a> + <li><a href="#futurework">Future Work</a> +</ul> + +<hr> +<h3><a name="pastwork">Past Work</a></h3> +<p> + +Previous ACE+TAO subsetting efforts were mainly concerned with +breaking up ACE into multiple libraries. Although this was a worthy +goal, the existing component definitions in <a +href="../ace/ace.mpc">ace.mpc</a> are too tightly coupled. Even if +ACE was compiled into multiple libraries, therefore, applications +would still have to link almost every one of them.</p> + +<p> +Potentially more satisfying results can be obtained through the use of +namespaces, e.g., ACE_OS, and/or breaking up large cpp's into smaller +ones to decrease the size of object files, and statically linking them +into the application.</p> + +<p> +In fact, this technique was applied systematically to ACE_OS in 2003, +and resulted in a <a +href="http://www.dre.vanderbilt.edu/Stats/footprint.shtml">10-15% +decrease in overall footprint</a> for statically linked applications. +Interestingly, these techniques also helped reduce <a +href="http://www.dre.vanderbilt.edu/~isisbuilds/auto_compile_logs/CP_Metrics/metrics/">compilation +times by ~50%</a>.</p> + +<p> +Another very powerful technique for reducing the size of shared +libries is <a href="../apps/soreduce/README">The Shared Library +Reduction (<CODE>soreduce</CODE>) tool</a>. <code>soreduce</code> +also benifits from the techniques listed above and should give +results comparable to static linking. In fact, when deploying multiple +applications, use of shared libraries with <code>soreduce</code> will +result in smaller overall footprint than static linking.</p> + +<hr> +<h3><a name="futurework">Future Work</a></h3> +<p> + +Depending on funding and contributions from the ACE community, future +work on subsetting in ACE can be divided into two thrusts: <P> + +<UL> + +<LI> <B>Code refactoring</B>, which helps to reduce the coupling +between applications and ACE C++ wrappers and frameworks. The amount +of coupling that's in ACE currently yields larger compiled size for +executable applications, increased link times, and indirect dependency +on a large amounts of code that may not be needed for many embedded +applications. <P> + +<LI> <B>Functionality Refactoring</B>, which enables application +developers to choose lightweight reusable classes and frameworks, +rather than monolithic and heavyweight implementations, to decrease +compilation times, link times, and compiled memory footprint of +embedded applications. <P> + +</UL> + +Our ideas for performing each of these thrusts is described in detail +below. + +<h4>ACE Code Refactoring</H4> + +ACE is currently designed in such a way that application developers +must link many classes and methods of ACE with their application, even +if they use a small number of classes and functions in their +application. As a result, static memory resource utilization is +unnecessarily high for common use cases. This section describes +techniques to address the existing code structuring complexities in +ACE, which were originally driven by the poor quality of C++ tools +that were available in the 1990's. For example, early C++ compilers +in the embedded domain lacked support for namespaces, which forced +developers to write classes that had a number of utility functions +useful for network programming. Now that modern C++ compilers have +better support for standard C++, we propose the following +optimizations to ACE: <P> + +<UL> + +<LI> We will identify ACE classes and utility functions that serve a + common goal, and move them into a namespace of their own. Since C++ + allows a single namespace to be reopened in multiple translation + units, we plan to split the operations into multiple C++ source + files, giving the linker a chance to choose a smaller sized object + files while creating an executable. <P> + +<LI> Currently, ACE inlines many of its methods, which tradesoff run-time + performance for larger footprint. We propose to examine the contents + of inlined files in ACE, and evaluate whether inlining is required in + every instance. ACE aggressively inlined functions to get better + performance from the tool chains, but this has lead to increased code + coupling within ACE, as well as increased coupling between + applications that use ACE. We will evaluate the tradeoffs associated + with inlining and performance of certain functions and selectively + inline those methods. These optimizations are described further in + <A +HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0201379503/104-7731669-1857527?v=glance">Efficient +C++: Performance Programming Techniques</A> by Dov Bulka and + David Mayhew. +</UL> + +We expect that we will be able to reduce footprint by ~25-30% for ACE +applications, and a ~15-20% reduction in compile and link time of +applications. <P> + +<H4>Functionality Refactoring</H4> + + This section proposes to address additional compile-time and memory +footprint problems that can be solved by functionality refactoring. +During the past decade, ACE has been designed and built based on many +unique requirements from users around the globe. Though this input +enhanced the flexibility of ACE and increased the visibility of ACE, +it also led to functionality "clumping," i.e., many classes in ACE +have functionality associated with them that are not required for many +applications. For example, the ACE_Svc_Handler serves as an event +handler for the ACE Reactor framework, serves as a handler to +implement the thread-per-connection strategies, and can be dynamically +loaded from shared libraries using the ACE Service Configurator +framework, which in turn depends on the ACE Reactor framework. Though +all these dependencies and functionalities are required for some +applications, they yield excessive coupling and overhead for +applications (such as clients) that only want to use the ACE +Acceptor/Connector framework to connect and send messages to remote +servers. <P> + + To address the issues of tight-coupling outlined above, we propose +to refactor the code and functionality of the existing ACE frameworks +and wrapper classes to offer finer-grained components that can be +selectively included by embedded applications. Our initial efforts +would focus on the following key ACE frameworks: +<UL> +<LI> Logging +<LI> Service Configurator +<LI> Object Manager +<LI> Reactor +<LI> Framework Component +<LI> Thread Manager +<LI> Proactor +</UL> + +We propose to apply the techniques we have mentioned above. As a +result, we expect that we will be able to reduce footprint by another +~20-25% for certain classes of ACE applications, and a ~15-20% +reduction in compile- and link-time of applications. <P> + + Collectively, the optimizations we propose above will greatly +reduce the memory footprint and speedup the compilation and link time +for ACE-based applications. <P> + +<p> Anyone interested in contributing time or funding to these efforts +should please contact <a +href="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</a>. +If you have questions about ACE and/or ACE subsetting and footprint +reduction please post these questions to the <A +HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE mailing +list</A>.</p> + +<P><HR><P> +Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> +home page.<BR> +Back to <A HREF="index.html">ACE Documentation Home</A>. + +<!--#include virtual="/~schmidt/cgi-sig.html" --> +</BODY> +</HTML> |