source: docs/Working/icXML/conclusion.tex @ 2512

Last change on this file since 2512 was 2512, checked in by nmedfort, 7 years ago

rough conclusion

File size: 1.4 KB
1\section{Conclusion and Future Work}
3This paper presented the \icXML{} parser and discussed the key architectural differences between it and Xerces.
4\icXML{} was architected to utilize SIMD parallelism, facilitated by the Parabix framework. \icXMLp{} extended on
5this by incorporating pipeline parallelism through the concept of layers and streaming content models.
7Two applications were selected for the performance evaluation: SAXCount and GML2SVG. The former to assess the
8the speed up of \icXML{} over Xerces itself, and the latter to test it within a reasonably complex application.
9{\bf something about the final speed up rates in both SAXCount and GML2SVG}
11Although only a two-thread version was explored, more is possible---but the value of using more is dependent on
12the application utilizing the \icXML{} library.
13As the application becomes more complex there are diminishing returns w.r.t. additional thread-level parallelism.
14A more interesting use of additional threads could be in the inclusion of an XPath and XQuery modules that could
15eliminate unneeded data prior to the \MP{} stage.
16Finally, the concepts used within \icXML{} and \icXMLp{} are not restricted to XML processing: \icXML{} should be considered a
17proof-of-concept work that shows it is possible to parallelize some finite-state machines by restructing the application
18(and therefore the problem domain) to one that is more in line with current processor technology.
Note: See TracBrowser for help on using the repository browser.