Ignore:
Timestamp:
Oct 19, 2012, 8:20:30 PM (7 years ago)
Author:
nmedfort
Message:

rough conclusion

File:
1 edited

Legend:

Unmodified
Added
Removed
  • docs/Working/icXML/conclusion.tex

    r2500 r2512  
    1 \section{Conclusion}
     1\section{Conclusion and Future Work}
     2
     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.
     6
     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}
     10
     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 TracChangeset for help on using the changeset viewer.