# Changeset 2869 for docs/Working/icXML

Ignore:
Timestamp:
Jan 30, 2013, 5:15:11 PM (6 years ago)
Message:

Abstract and conclusion

Location:
docs/Working/icXML
Files:
3 edited

### Legend:

Unmodified
 r2852 This paper presented the \icXML{} parser and discussed the key architectural differences between it and Xerces. \icXML{} was architected to utilize SIMD parallelism, facilitated by the Parabix framework. \icXMLp{} extended on this by incorporating pipeline parallelism through the concept of layers and streaming content models. This paper is the first case study documenting the significant performance benefits that may be realized through the integration of parallel bit stream technology into existing widely-used software libraries. In the case of the Xerces-C++ XML parser, the combined integration of SIMD and multicore parallelism was shown capable of dramatic producing dramatic increases in throughput and reductions in branch mispredictions and cache misses. The modified parser, going under the name \icXML{} is designed to provide the full functionality of the original Xerces library with complete compatibility of APIs.  Although substantial reengineering was required to realize the performance potential of parallel technologies, this is an important case study demonstrating the general feasibility of these techniques. Two applications were selected for the performance evaluation: SAXCount and GML2SVG. The former to assess the the speed up of \icXML{} over Xerces itself, and the latter to test it within a reasonably complex application. {\bf something about the final speed up rates in both SAXCount and GML2SVG} The further development of \icXML{} to move beyond 2-stage pipeline parallelism is ongoing, with realistic prospects for four reasonably balanced stages within the library.  For applications such as GML2SVG which are dominated by time spent on XML parsing, such a multistage pipelined parsing library should offer substantial benefits. Although only a two-thread version was explored, more is possible---but the value of using more is dependent on the application utilizing the \icXML{} library. As the application becomes more complex there are diminishing returns \wrt{} additional thread-level parallelism. A more interesting use of additional threads could be in the inclusion of an XPath and XQuery modules that could eliminate unneeded data prior to the \MP{} stage. Finally, the concepts used within \icXML{} and \icXMLp{} are not restricted to XML processing: \icXML{} should be considered a proof-of-concept work that shows it is possible to parallelize some finite-state machines by restructuring the application (and therefore the problem domain) to one that is more in line with current processor technology. The example of XML parsing may be considered prototypical of finite-state machines applications which have sometimes been considered embarassingly sequential'' and so difficult to parallelize that nothing works.''  So the case study presented here should be considered an important data point in making the case that parallelization can indeed be helpful across a broad array of application types. To overcome the software engineering challenges in applying parallel bit stream technology to existing software systems, it is clear that better library and tool support is needed. The techniques used in the implementation of \icXML{} and documented in this paper could well be generalized for applications in other contexts and automated through the creation of compiler technology specifically supporting parallel bit stream programming.