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

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


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