Changeset 3049

Apr 19, 2013, 3:25:54 PM (6 years ago)

Add figures

1 edited


  • docs/Balisage13/Bal2013came0601/Bal2013came0601.xml

    r3048 r3049  
    899899      <section>
    900900         <title>GML2SVG</title>
    901          <para/>
     901<para>   As a more substantial application of XML processing, the GML-to-SVG (GML2SVG) application
     902was chosen.   This application transforms geospatially encoded data represented using
     903an XML representation in the form of Geography Markup Language (GML) \cite{lake2004geography}
     904into a different XML format  suitable for displayable maps:
     905Scalable Vector Graphics (SVG) format\cite{lu2007advances}. In the GML2SVG benchmark, GML feature elements
     906and GML geometry elements tags are matched. GML coordinate data are then extracted
     907and transformed to the corresponding SVG path data encodings.
     908Equivalent SVG path elements are generated and output to the destination
     909SVG document.  The GML2SVG application is thus considered typical of a broad
     910class of XML applications that parse and extract information from
     911a known XML format for the purpose of analysis and restructuring to meet
     912the requirements of an alternative format.</para>
     914<para>Our GML to SVG data translations are executed on GML source data
     915modelling the city of Vancouver, British Columbia, Canada.
     916The GML source document set
     917consists of 46 distinct GML feature layers ranging in size from approximately 9 KB to 125.2 MB
     918and with an average document size of 18.6 MB. Markup density ranges from approximately 0.045 to 0.719
     919and with an average markup density of 0.519. In this performance study,
     920213.4 MB of source GML data generates 91.9 MB of target SVG data.</para>
     923        <figure xml:id="perf_GML2SVG">
     924          <title>Performance Comparison for GML2SVG</title>
     925          <mediaobject>
     926            <imageobject>
     927              <imagedata format="png" fileref="perf_GML2SVG.png" width="500cm"/>
     928            </imageobject>
     929          </mediaobject>
     930          <caption>
     931          </caption>
     932        </figure>
     934<para>Figure \ref{perf_GML2SVG} compares the performance of the GML2SVG application linked against
     935the Xerces, \icXML{} and \icXMLp{}.   
     936On the GML workload with this application, single-thread \icXML{}
     937achieved about a 50\% acceleration over Xerces,
     938increasing throughput on our test machine from 58.3 MB/sec to 87.9 MB/sec.   
     939Using \icXMLp{}, a further throughput increase to 111 MB/sec was recorded,
     940approximately a 2X speedup.</para>
     942<para>An important aspect of \icXML{} is the replacement of much branch-laden
     943sequential code inside Xerces with straight-line SIMD code using far
     944fewer branches.  Figure \ref{branchmiss_GML2SVG} shows the corresponding
     945improvement in branching behaviour, with a dramatic reduction in branch misses per kB.
     946It is also interesting to note that \icXMLp{} goes even further.   
     947In essence, in using pipeline parallelism to split the instruction
     948stream onto separate cores, the branch target buffers on each core are
     949less overloaded and able to increase the successful branch prediction rate.</para>
     951        <figure xml:id="branchmiss_GML2SVG">
     952          <title>Comparative Branch Misprediction Rate</title>
     953          <mediaobject>
     954            <imageobject>
     955              <imagedata format="png" fileref="BM.png" width="500cm"/>
     956            </imageobject>
     957          </mediaobject>
     958          <caption>
     959          </caption>
     960        </figure>
     962<para>The behaviour of the three versions with respect to L1 cache misses per kB is shown
     963in Figure \ref{cachemiss_GML2SVG}.   Improvements are shown in both instruction-
     964and data-cache performance with the improvements in instruction-cache
     965behaviour the most dramatic.   Single-threaded \icXML{} shows substantially improved
     966performance over Xerces on both measures.   
     967Although \icXMLp{} is slightly worse \wrt{} data-cache performance,
     968this is more than offset by a further dramatic reduction in instruction-cache miss rate.
     969Again partitioning the instruction stream through the pipeline parallelism model has
     970significant benefit.</para>
     972        <figure xml:id="cachemiss_GML2SVG">
     973          <title>Comparative Cache Miss Rate</title>
     974          <mediaobject>
     975            <imageobject>
     976              <imagedata format="png" fileref="CM.png" width="500cm"/>
     977            </imageobject>
     978          </mediaobject>
     979          <caption>
     980          </caption>
     981        </figure>
     983<para>One caveat with this study is that the GML2SVG application did not exhibit
     984a relative balance of processing between application code and Xerces library
     985code reaching the 33\% figure.  This suggests that for this application and
     986possibly others, further separating the logical layers of the
     987\icXML{} engine into different pipeline stages could well offer significant benefit.
     988This remains an area of ongoing work.</para>
    902989      </section>
    903990   </section>
Note: See TracChangeset for help on using the changeset viewer.