source: docs/Balisage13/Bal2013came0601/Bal2013came0601.xml @ 3038

Last change on this file since 3038 was 3038, checked in by ksherdy, 6 years ago

Moved over Bal 09 document to use as a template. Document validates agains 1-3.dtd.

File size: 87.8 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!-- MODIFIED DTD LOCATION -->
3<!DOCTYPE article SYSTEM "balisage-1-3.dtd">
4<article xmlns="http://docbook.org/ns/docbook" version="5.0-subset Balisage-1.3"
5  xml:id="HR-23632987-8973">
6   <title>Parallel Bit Stream Technology as a Foundation for XML Parsing Performance</title>
7   <info>
8<!--
9      <confgroup>
10         <conftitle>International Symposium on Processing XML Efficiently: Overcoming Limits on
11            Space, Time, or Bandwidth</conftitle>
12         <confdates>August 10 2009</confdates>
13      </confgroup>
14-->
15      <abstract>
16         <para>By first transforming the octets (bytes) of XML texts into eight parallel bit
17            streams, the SIMD features of commodity processors can be exploited for parallel
18            processing of blocks of 128 input bytes at a time. Established transcoding and parsing
19            techniques are reviewed followed by new techniques including parsing with bitstream
20            addition. Further opportunities are discussed in light of expected advances in CPU
21            architecture and compiler technology. Implications for various APIs and information
22            models are presented as well opportunities for collaborative open-source
23         development.</para>
24      </abstract>
25      <author>
26         <personname>
27            <firstname>Rob</firstname>
28            <surname>Cameron</surname>
29         </personname>
30         <personblurb>
31            <para>Dr. Rob Cameron is Professor and Director of Computing Science at Simon Fraser
32               University. With a broad spectrum of research interests related to programming
33               languages, software engineering and sociotechnical design of public computing
34               infrastructure, he has recently been focusing on high performance text processing
35               using parallel bit stream technology and its applications to XML. He is also a
36               patentleft evangelist, advocating university-based technology transfer models
37               dedicated to free use in open source. </para>
38
39         </personblurb>
40         <affiliation>
41            <jobtitle>Professor of Computing Science</jobtitle>
42            <orgname>Simon Fraser University</orgname>
43         </affiliation>
44         <email>cameron@cs.sfu.ca</email>
45      </author>
46      <author>
47         <personname>
48            <firstname>Ken</firstname>
49            <surname>Herdy</surname>
50         </personname>
51         <personblurb>
52            <para> Ken Herdy completed an Advanced Diploma of Technology in Geographical Information
53               Systems at the British Columbia Institute of Technology in 2003 and earned a Bachelor
54               of Science in Computing Science with a Certificate in Spatial Information Systems at
55               Simon Fraser University in 2005. </para>
56            <para> Ken is currently pursuing graduate studies in Computing Science at Simon Fraser
57               University with industrial scholarship support from the Natural Sciences and
58               Engineering Research Council of Canada, the Mathematics of Information Technology and
59               Complex Systems NCE, and the BC Innovation Council. His research focus is an analysis
60               of the principal techniques that may be used to improve XML processing performance in
61               the context of the Geography Markup Language (GML). </para>
62
63         </personblurb>
64         <affiliation>
65            <jobtitle>Graduate Student, School of Computing Science</jobtitle>
66            <orgname>Simon Fraser University </orgname>
67         </affiliation>
68         <email>ksherdy@cs.sfu.ca</email>
69      </author>
70      <author>
71         <personname>
72            <firstname>Ehsan</firstname>
73            <surname>Amiri</surname>
74         </personname>
75         <personblurb>
76            <para>Ehsan Amiri is a PhD student of Computer Science at Simon Fraser University.
77               Before that he studied at Sharif University of Technology, Tehran, Iran. While his
78               graduate research has been focused on theoretical problems like fingerprinting, Ehsan
79               has worked on some software projects like development of a multi-node firewall as
80               well. More recently he has been developing compiler technology for automatic
81               generation of bit stream processing code. </para>
82
83         </personblurb>
84         <affiliation>
85            <jobtitle>Graduate Student, School of Computing Science</jobtitle>
86            <orgname>Simon Fraser University</orgname>
87         </affiliation>
88         <email>eamiri@cs.sfu.ca</email>
89      </author>
90<!--
91      <legalnotice>
92         <para>Copyright &#x000A9; 2009 Robert D. Cameron, Kenneth S. Herdy and Ehsan Amiri.
93            This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative
94            Works 2.5 Canada License.</para>
95      </legalnotice>
96-->
97      <keywordset role="author">
98         <keyword/>
99         <keyword/>
100         <keyword/>
101      </keywordset>
102   </info>
103   <section>
104      <title>Introduction</title>
105      <para> While particular XML applications may benefit from special-purpose hardware such as XML
106         chips [<xref linkend="XMLChip09"/>] or appliances [<xref linkend="Datapower09"/>], the bulk
107         of the world's XML processing workload will continue to be handled by XML software stacks
108         on commodity processors. Exploiting the SIMD capabilities of such processors such as the
109         SSE instructions of x86 chips, parallel bit stream technology offers the potential of
110         dramatic improvement over byte-at-a-time processing for a variety of XML processing tasks.
111         Character set issues such as Unicode validation and transcoding [<xref linkend="PPoPP08"
112         />], normalization of line breaks and white space and XML character validation can be
113         handled fully in parallel using this representation. Lexical item streams, such as the bit
114         stream marking the positions of opening angle brackets, can also be formed in parallel.
115         Bit-scan instructions of commodity processors may then be used on lexical item streams to
116         implement rapid single-instruction scanning across variable-length multi-byte text blocks
117         as in the Parabix XML parser [<xref linkend="CASCON08"/>]. Overall, these techniques may be
118         combined to yield end-to-end performance that may be 1.5X to 15X faster than alternatives
119            [<xref linkend="SVGOpen08"/>].</para>
120      <para>Continued research in parallel bit stream techniques as well as more conventional
121         application of SIMD techniques in XML processing offers further prospects for improvement
122         of core XML components as well as for tackling performance-critical tasks further up the
123         stack. A newly prototyped technique for parallel tag parsing using bitstream addition is
124         expected to improve parsing performance even beyond that achieved using sequential bit
125         scans. Several techniques for improved symbol table performance are being investigated,
126         including parallel hash value calculation and length-based sorting using the cheap length
127         determination afforded by bit scans. To deliver the benefits of parallel bit stream
128         technology to the Java world, we are developing Array Set Model (ASM) representations of
129         XML Infoset and other XML information models for efficient transmission across the JNI
130         boundary.</para>
131
132      <para>Amplifying these software advances, continuing hardware advances in commodity processors
133         increase the relative advantage of parallel bit stream techniques over traditional
134         byte-at-a-time processors. For example, the Intel Core architecture improved SSE processing
135         to give superscalar execution of bitwise logic operations (3 instructions per cycle vs. 1
136         in Pentium 4). Upcoming 256-bit AVX technology extends the register set and replaces
137         destructive two-operand instructions with a nondestructive three-operand form. General
138         purpose programming on graphic processing units (GPGPU) such as the upcoming 512-bit
139         Larrabee processor may also be useful for XML applications using parallel bit streams. New
140         instruction set architectures may also offer dramatic improvements in core algorithms.
141         Using the relatively simple extensions to support the principle of inductive doubling, a 3X
142         improvement in several core parallel bit stream algorithms may be achieved [<xref
143            linkend="ASPLOS09"/>]. Other possibilities include direct implementation of parallel
144         extract and parallel deposit (pex/pdep) instructions [<xref linkend="Pex06"/>], and
145         bit-level interleave operations as in Larrabee, each of which would have important
146         application to parallel bit stream processing.</para>
147
148      <para>Further prospects for XML performance improvement arise from leveraging the
149         intraregister parallelism of parallel bit stream technology to exploit the interchip
150         parallelism of multicore computing. Parallel bit stream techniques can support multicore
151         parallelism in both data partitioning and task partitioning models. For example, the
152         datasection partitioning approach of Wu, Zhang, Yu and Li may be used to partition blocks
153         for speculative parallel parsing on separate cores followed by a postprocessing step to
154         join partial S-trees [<xref linkend="Wu08"/>].</para>
155
156      <para>In our view, the established and expected performance advantages of parallel bit stream
157         technology over traditional byte-at-a-time processing are so compelling that parallel bit
158         stream technology should ultimately form the foundation of every high-performance XML
159         software stack. We envision a common high-performance XML kernel that may be customized to
160         a variety of processor architectures and that supports a wide range of existing and new XML
161         APIs. Widespread deployment of this technology should greatly benefit the XML community in
162         addressing both the deserved and undeserved criticism of XML on performance grounds. A
163         further benefit of improved performance is a substantial greening of XML technologies.</para>
164
165      <para>To complement our research program investigating fundamental algorithms and issues in
166         high-performance XML processing, our work also involves development of open source software
167         implementing these algorithms, with a goal of full conformance to relevant specifications.
168         From the research perspective, this approach is valuable in ensuring that the full
169         complexity of required XML processing is addressed in reporting and assessing processing
170         results. However, our goal is also to use this open source software as a basis of
171         technology transfer. A Simon Fraser University spin-off company, called International
172         Characters, Inc., has been created to commercialize the results of this work using a
173         patent-based open source model.</para>
174
175      <para>To date, we have not yet been successful in establishing a broader community of
176         participation with our open source code base. Within open-source communities, there is
177         often a general antipathy towards software patents; this may limit engagement with our
178         technology, even though it has been dedicated for free use in open source. </para>
179
180      <para>A further complication is the inherent difficulty of SIMD programming in general, and
181         parallel bit stream programming in particular. Considerable work is required with each new
182         algorithmic technique being investigated as well as in retargetting our techniques for each
183         new development in SIMD and multicore processor technologies. To address these concerns, we
184         have increasingly shifted the emphasis of our research program towards compiler technology
185         capable of generating parallel bit stream code from higher-level specifications.</para>
186   </section>
187
188   <section>
189      <title>A Catalog of Parallel Bit Streams for XML</title>
190      <section>
191         <title>Introduction</title>
192         <para>In this section, we introduce the fundamental concepts of parallel bit stream
193            technology and present a comprehensive catalog of parallel bit streams for use in XML
194            processing. In presenting this catalog, the focus is on the specification of the bit
195            streams as data streams in one-to-one correspondence with the character code units of an
196            input XML stream. The goal is to define these bit streams in the abstract without
197            initially considering memory layouts, register widths or other issues related to
198            particular target architectures. In cataloging these techniques, we also hope to convey
199            a sense of the breadth of applications of parallel bit stream technology to XML
200            processing tasks. </para>
201      </section>
202
203      <section>
204         <title>Basis Bit Streams</title>
205         <para>Given a byte-oriented text stream represented in UTF-8, for example, we define a
206            transform representation of this text consisting of a set of eight parallel bit streams
207            for the individual bits of each byte. Thus, the <code>Bit0</code> stream is the stream
208            of bits consisting of bit 0 of each byte in the input byte stream, <code>Bit1</code> is
209            the bit stream consisting of bit 1 of each byte in the input stream and so on. The set
210            of streams <code>Bit0</code> through <code>Bit7</code> are known as the <emphasis>basis
211               streams</emphasis> of the parallel bit stream representation. The following table
212            shows an example XML character stream together with its representation as a set of 8
213            basis streams. <table>
214               <caption>
215                  <para>XML Character Stream Transposition.</para>
216               </caption>
217               <colgroup>
218                  <col align="left" valign="top"/>
219                  <col align="left" valign="top"/>
220                  <col align="left" valign="top"/>
221                  <col align="left" valign="top"/>
222                  <col align="left" valign="top"/>
223                  <col align="left" valign="top"/>
224               </colgroup>
225               <tbody>
226                  <tr valign="top">
227                     <td>Input Data</td>
228                     <td>
229                        <code>&lt;</code>
230                     </td>
231                     <td>
232                        <code>t</code>
233                     </td>
234                     <td>
235                        <code>a</code>
236                     </td>
237                     <td>
238                        <code>g</code>
239                     </td>
240                     <td>
241                        <code>/</code>
242                     </td>
243                     <td>
244                        <code>&gt;</code>
245                     </td>
246                  </tr>
247                  <tr valign="top">
248                     <td>ASCII</td>
249                     <td>
250                        <code>00111100</code>
251                     </td>
252                     <td>
253                        <code>01110100</code>
254                     </td>
255                     <td>
256                        <code>01100001</code>
257                     </td>
258                     <td>
259                        <code>01100111</code>
260                     </td>
261                     <td>
262                        <code>00101111</code>
263                     </td>
264                     <td>
265                        <code>00111110</code>
266                     </td>
267                  </tr>
268                  <tr valign="top">
269                     <td>Bit0</td>
270                     <td>
271                        <code>0</code>
272                     </td>
273                     <td>
274                        <code>0</code>
275                     </td>
276                     <td>
277                        <code>0</code>
278                     </td>
279                     <td>
280                        <code>0</code>
281                     </td>
282                     <td>
283                        <code>0</code>
284                     </td>
285                     <td>
286                        <code>0</code>
287                     </td>
288                  </tr>
289                  <tr valign="top">
290                     <td>Bit1</td>
291                     <td>
292                        <code>0</code>
293                     </td>
294                     <td>
295                        <code>1</code>
296                     </td>
297                     <td>
298                        <code>1</code>
299                     </td>
300                     <td>
301                        <code>1</code>
302                     </td>
303                     <td>
304                        <code>0</code>
305                     </td>
306                     <td>
307                        <code>0</code>
308                     </td>
309                  </tr>
310                  <tr valign="top">
311                     <td>Bit2</td>
312                     <td>
313                        <code>1</code>
314                     </td>
315                     <td>
316                        <code>1</code>
317                     </td>
318                     <td>
319                        <code>1</code>
320                     </td>
321                     <td>
322                        <code>1</code>
323                     </td>
324                     <td>
325                        <code>1</code>
326                     </td>
327                     <td>
328                        <code>1</code>
329                     </td>
330                  </tr>
331                  <tr valign="top">
332                     <td>Bit3</td>
333                     <td>
334                        <code>1</code>
335                     </td>
336                     <td>
337                        <code>1</code>
338                     </td>
339                     <td>
340                        <code>0</code>
341                     </td>
342                     <td>
343                        <code>0</code>
344                     </td>
345                     <td>
346                        <code>0</code>
347                     </td>
348                     <td>
349                        <code>1</code>
350                     </td>
351                  </tr>
352                  <tr valign="top">
353                     <td>Bit4</td>
354                     <td>
355                        <code>1</code>
356                     </td>
357                     <td>
358                        <code>0</code>
359                     </td>
360                     <td>
361                        <code>0</code>
362                     </td>
363                     <td>
364                        <code>0</code>
365                     </td>
366                     <td>
367                        <code>1</code>
368                     </td>
369                     <td>
370                        <code>1</code>
371                     </td>
372                  </tr>
373                  <tr valign="top">
374                     <td>Bit5</td>
375                     <td>
376                        <code>1</code>
377                     </td>
378                     <td>
379                        <code>1</code>
380                     </td>
381                     <td>
382                        <code>0</code>
383                     </td>
384                     <td>
385                        <code>1</code>
386                     </td>
387                     <td>
388                        <code>1</code>
389                     </td>
390                     <td>
391                        <code>1</code>
392                     </td>
393                  </tr>
394                  <tr valign="top">
395                     <td>Bit6</td>
396                     <td>
397                        <code>0</code>
398                     </td>
399                     <td>
400                        <code>0</code>
401                     </td>
402                     <td>
403                        <code>0</code>
404                     </td>
405                     <td>
406                        <code>1</code>
407                     </td>
408                     <td>
409                        <code>1</code>
410                     </td>
411                     <td>
412                        <code>1</code>
413                     </td>
414                  </tr>
415                  <tr valign="top">
416                     <td>Bit7</td>
417                     <td>
418                        <code>0</code>
419                     </td>
420                     <td>
421                        <code>0</code>
422                     </td>
423                     <td>
424                        <code>1</code>
425                     </td>
426                     <td>
427                        <code>1</code>
428                     </td>
429                     <td>
430                        <code>1</code>
431                     </td>
432                     <td>
433                        <code>0</code>
434                     </td>
435                  </tr>
436               </tbody>
437            </table>
438         </para>
439         <para> Depending on the features of a particular processor architecture, there are a number
440            of algorithms for transposition to parallel bit stream form. Several of these algorithms
441            employ a three-stage structure. In the first stage, the input byte stream is divided
442            into a pair of half-length streams consisting of four bits for each byte, for example,
443            one stream for the high nybble of each byte and another for the low nybble of each byte.
444            In the second stage, these streams of four bits per byte are each divided into streams
445            consisting of two bits per original byte, for example streams for the
446            <code>Bit0/Bit1</code>, <code>Bit2/Bit3</code>, <code>Bit4/Bit5</code>, and
447               <code>Bit6/Bit7</code> pairs. In the final stage, the streams are further subdivided
448            in the individual bit streams. </para>
449         <para> Using SIMD capabilities, this process is quite efficient, with an amortized cost of
450            1.1 CPU cycles per input byte on Intel Core 2 with SSE, or 0.6 CPU cycles per input byte
451            on Power PC G4 with Altivec. With future advances in processor technology, this
452            transposition overhead is expected to reduce, possibly taking advantage of upcoming
453            parallel extract (pex) instructions on Intel technology. In the ideal, only 24
454            instructions are needed to transform a block of 128 input bytes using 128-bit SSE
455            registers using the inductive doubling instruction set architecture, representing an
456            overhead of less than 0.2 instructions per input byte. </para>
457      </section>
458
459      <section>
460         <title>General Streams</title>
461         <para>This section describes bit streams which support basic processing operations.</para>
462
463         <section>
464            <title>Deletion Mask Streams</title>
465            <para>DelMask (deletion mask) streams marks character code unit positions for deletion.
466               Since the deletion operation is dependency free across many stages of XML processing,
467               it is possible to simply mark and record deletion positions as deletion mask streams for future processing. A single
468               invocation of a SIMD based parallel deletion algorithm can then perform the deletion of
469               positions accumulated across a number of stages through a bitwise ORing of deletion
470               masks. For example, deletion arises in the replacement of predefined entities with a
471               single character, such as in the replacement of the &amp;amp; entity, with the
472               &amp; character. Deletion also arises in XML
473               end-of-line handling, and CDATA section delimeter processing. Several algorithms to
474               delete bits at positions marked by DelMask are possible [<xref linkend="u8u16"/>]. </para>
475            <para>The following table provides an example of generating a DelMask in the context of
476               bit stream based parsing of well-formed character references and predefined entities.
477               The result is the generation of a DelMask stream. <table>
478                  <caption>
479                     <para>DelMask Stream Generation</para>
480                  </caption>
481                  <colgroup>
482                     <col align="left" valign="top"/>
483                     <col align="left" valign="top"/>
484                  </colgroup>
485                  <tbody>
486                     <tr valign="top">
487                        <td>Input Data</td>
488                        <td>
489                           <code>&amp;gt; &amp;#13; &amp;#x0a;</code>
490                        </td>
491                     </tr>
492                     <tr valign="top">
493                        <td>GenRefs</td>
494                        <td>
495                           <code>_11______________</code>
496                        </td>
497                     </tr>
498
499                     <tr valign="top">
500                        <td>DecRefs</td>
501                        <td>
502                           <code>_______11________</code>
503                        </td>
504                     </tr>
505                     <tr valign="top">
506                        <td>HexRefs</td>
507                        <td>
508                           <code>______________11_</code>
509                        </td>
510                     </tr>
511                     <tr valign="top">
512                        <td>DelMask</td>
513                        <td>
514                           <code>111__1111__11111_</code>
515                        </td>
516                     </tr>
517                     <tr valign="top">
518                        <td>ErrorFlag</td>
519                        <td>
520                           <code>_________________</code>
521                        </td>
522                     </tr>
523                  </tbody>
524               </table>
525            </para>
526         </section>
527
528         <section>
529            <title>Error Flag Streams </title>
530            <para>Error flag streams indicates the character code unit positions of syntactical
531               errors. XML processing examples which benefit from the marking of error positions
532               include UTF-8 character sequence validation and XML parsing [<xref linkend="u8u16"
533               />].</para>
534            <para>The following table provides an example of using bit streams to parse character
535               references and predefined entities which fail to meet the XML 1.0 well-formedness
536               constraints. The result is the generation of an error flag stream that marks the
537               positions of mal-formed decimal and hexical character references respectively. <table>
538                  <caption>
539                     <para>Error Flag Stream Generation</para>
540                  </caption>
541                  <colgroup>
542                     <col align="left" valign="top"/>
543                     <col align="left" valign="top"/>
544                  </colgroup>
545                  <tbody>
546                     <tr valign="top">
547                        <td>Input Data</td>
548                        <td>
549                           <code>&amp;gt; &amp;#, &amp;#x; </code>
550                        </td>
551                     </tr>
552                     <tr valign="top">
553                        <td>GenRefs</td>
554                        <td>
555                           <code>_11___________</code>
556                        </td>
557                     </tr>
558                     <tr valign="top">
559                        <td>DecRefs</td>
560                        <td>
561                           <code>______________</code>
562                        </td>
563                     </tr>
564                     <tr valign="top">
565                        <td>HexRefs</td>
566                        <td>
567                           <code>______________</code>
568                        </td>
569                     </tr>
570                     <tr valign="top">
571                        <td>DelMask</td>
572                        <td>
573                           <code>111__11__111__</code>
574                        </td>
575                     </tr>
576                     <tr valign="top">
577                        <td>ErrorFlag</td>
578                        <td>
579                           <code>_______1____1_</code>
580                        </td>
581                     </tr>
582                  </tbody>
583               </table>
584            </para>
585         </section>
586
587      </section>
588
589      <section>
590         <title>Lexical Item Streams</title>
591         <para>Lexical item streams differ from traditional streams of tokens in that they are bit
592            streams that mark the positions of tokens, whitespace or delimiters. Additional bit
593            streams, such as the reference streams and callout streams, are subsequently constructed
594            based on the information held within the set of lexical items streams. Differentiation
595            between the actual tokens that may occur at a particular point (e.g., the different XML
596            tokens that begin “&lt;”) may be performed using multicharacter recognizers on the
597            bytestream representation [<xref linkend="CASCON08"/>].</para>
598         <para>A key role of lexical item streams in XML parsing is to facilitate fast scanning
599            operations. For example, a left angle bracket lexical item stream may be formed to
600            identify those character code unit positions at which a “&lt;” character occurs.
601            Hardware register bit scan operations may then be used by the XML parser on the left
602            angle bracket stream to efficiently identify the position of the next “&lt;”. Based
603            on the capabilities of current commodity processors, a single register bit scan
604            operation may effectively scan up to 64 byte positions with a single instruction.</para>
605         <para>Overall, the construction of the full set of lexical item stream computations
606            requires approximately 1.0 CPU cycles per byte when implemented for 128 positions at a
607            time using 128-bit SSE registers on Intel Core2 processors [<xref linkend="CASCON08"/>].
608            The following table defines the core lexical item streams defined by the Parabix XML
609            parser.</para>
610         <para>
611            <table>
612               <caption>
613                  <para>Lexical item stream descriptions.</para>
614               </caption>
615               <tbody>
616                  <tr>
617                     <td align="left"> LAngle </td>
618                     <td align="left"> Marks the position of any left angle bracket character.</td>
619                  </tr>
620                  <tr>
621                     <td align="left"> RAngle </td>
622                     <td align="left"> Marks the position of any right angle bracket character.</td>
623                  </tr>
624                  <tr>
625                     <td align="left"> LBracket </td>
626                     <td align="left"> Marks the position of any left square bracker character.</td>
627                  </tr>
628                  <tr>
629                     <td align="left"> RBracket </td>
630                     <td align="left"> Marks the position of any right square bracket
631                     character.</td>
632                  </tr>
633                  <tr>
634                     <td align="left"> Exclam </td>
635                     <td align="left"> Marks the position of any exclamation mark character.</td>
636                  </tr>
637                  <tr>
638                     <td align="left"> QMark </td>
639                     <td align="left"> Marks the position of any question mark character.</td>
640                  </tr>
641                  <tr>
642                     <td align="left"> Hyphen </td>
643                     <td align="left"> Marks the position of any hyphen character.</td>
644                  </tr>
645                  <tr>
646                     <td align="left"> Equals </td>
647                     <td align="left"> Marks the position of any equal sign character.</td>
648                  </tr>
649                  <tr>
650                     <td align="left"> SQuote </td>
651                     <td align="left"> Marks the position of any single quote character.</td>
652                  </tr>
653                  <tr>
654                     <td align="left"> DQuote </td>
655                     <td align="left"> Marks the position of any double quote character.</td>
656                  </tr>
657                  <tr>
658                     <td align="left"> Slash </td>
659                     <td align="left"> Marks the position of any forward slash character</td>
660                  </tr>
661                  <tr>
662                     <td align="left"> NameScan </td>
663                     <td align="left"> Marks the position of any XML name character.</td>
664                  </tr>
665                  <tr>
666                     <td align="left"> WS </td>
667                     <td align="left"> Marks the position of any XML 1.0 whitespace character.</td>
668                  </tr>
669                  <tr>
670                     <td align="left"> PI_start </td>
671                     <td align="left"> Marks the position of the start of any processing instruction
672                        at the '?' character position.</td>
673                  </tr>
674                  <tr>
675                     <td align="left"> PI_end </td>
676                     <td align="left"> Marks the position of any end of any processing instruction
677                        at the '>' character position.</td>
678                  </tr>
679                  <tr>
680                     <td align="left"> CtCD_start </td>
681                     <td align="left"> Marks the position of the start of any comment or CDATA
682                        section at the '!' character position.</td>
683                  </tr>
684                  <tr>
685                     <td align="left"> EndTag_start </td>
686                     <td align="left"> Marks the position of any end tag at the '/' character
687                        position.</td>
688                  </tr>
689                  <tr>
690                     <td align="left"> CD_end </td>
691                     <td align="left"> Marks the position of the end of any CDATA section at the '>'
692                        character position. </td>
693                  </tr>
694                  <tr>
695                     <td align="left"> DoubleHyphen </td>
696                     <td align="left"> Marks the position of any double hyphen character.</td>
697                  </tr>
698                  <tr>
699                     <td align="left"> RefStart </td>
700                     <td align="left"> Marks the position of any ampersand character.</td>
701                  </tr>
702                  <tr>
703                     <td align="left"> Hash </td>
704                     <td align="left"> Marks the position of any hash character.</td>
705                  </tr>
706                  <tr>
707                     <td align="left"> x </td>
708                     <td align="left"> Marks the position of any 'x' character.</td>
709                  </tr>
710                  <tr>
711                     <td align="left"> Digit </td>
712                     <td align="left"> Marks the position of any digit.</td>
713                  </tr>
714                  <tr>
715                     <td align="left"> Hex </td>
716                     <td align="left"> Marks the position of any hexidecimal character.</td>
717                  </tr>
718                  <tr>
719                     <td align="left"> Semicolon </td>
720                     <td align="left"> Marks the position of any semicolon character.</td>
721                  </tr>
722               </tbody>
723            </table>
724         </para>
725         <para> The following illustrates a number of the lexical item streams. </para>
726         <para>
727            <table>
728               <caption>
729                  <para>Lexical Item Streams</para>
730               </caption>
731               <colgroup>
732                  <col align="left" valign="top"/>
733                  <col align="left" valign="top"/>
734               </colgroup>
735               <tbody>
736                  <tr valign="top">
737                     <td>Input Data</td>
738                     <td>
739                        <code>&lt;tag&gt;&lt;tag&gt; text &amp;lt;
740                           &amp;#x3e; &lt;/tag&gt;&lt;/tag&gt;</code>
741                     </td>
742                  </tr>
743
744                  <tr valign="top">
745                     <td>LAngle</td>
746                     <td>
747                        <code>1____1______________________1_____1_____</code>
748                     </td>
749                  </tr>
750                  <tr valign="top">
751                     <td>RAngle</td>
752                     <td>
753                        <code>____1____1_______________________1_____1</code>
754                     </td>
755                  </tr>
756                  <tr valign="top">
757                     <td>WS</td>
758                     <td>
759                        <code>__________1____1____1______1____________</code>
760                     </td>
761                  </tr>
762                  <tr valign="top">
763                     <td>RefStart</td>
764                     <td>
765                        <code>________________1____1__________________</code>
766                     </td>
767                  </tr>
768                  <tr valign="top">
769                     <td>Hex</td>
770                     <td>
771                        <code>__1____1____1___________11_____1_____1__</code>
772                     </td>
773                  </tr>
774
775                  <tr valign="top">
776                     <td>Semicolon</td>
777                     <td>
778                        <code>___________________1______1_____________</code>
779                     </td>
780                  </tr>
781                  <tr valign="top">
782                     <td>Slash</td>
783                     <td>
784                        <code>_____________________________1_____1____</code>
785                     </td>
786                  </tr>
787               </tbody>
788            </table>
789         </para>
790
791      </section>
792
793      <section>
794         <title>UTF-8 Byte Classification, Scope and Validation Streams</title>
795         <para> An XML parser must accept the UTF-8 encoding of Unicode [<xref linkend="XML10"/>].
796            It is a fatal error if an XML document determined to be in UTF-8 contains byte sequences
797            that are not legal in that encoding. UTF-8 byte classification, scope, XML character
798            validation and error flag bit streams are defined to validate UTF-8 byte sequences and
799            support transcoding to UTF-16.</para>
800
801         <section>
802            <title>UTF-8 Byte Classification Streams</title>
803            <para>UTF-8 byte classification bit streams classify UTF-8 bytes based on their role in
804               forming single and multibyte sequences. The u8Prefix and u8Suffix bit streams
805               identify bytes that represent, respectively, prefix or suffix bytes of multibyte
806               UTF-8 sequences. The u8UniByte bit stream identifies those bytes that may be
807               considered single-byte sequences. The u8Prefix2, u8Prefix3, and u8Prefix4 refine the
808               u8Prefix respectively indicating prefixes of two, three or four byte
809            sequences respectively.</para>
810         </section>
811
812         <section>
813            <title>UTF-8 Scope Streams</title>
814            <para> Scope streams represent expectations established by UTF-8 prefix bytes. For
815               example, the u8Scope22 bit stream represents the positions at which the second byte of a
816               two-byte sequence is expected based on the occurrence of a two-byte prefix in the
817               immediately preceding position. The u8scope32, u8Scope33, u8Scope42, u8scope43, and
818               u8Scope44 complete the set of UTF-8 scope streams.</para>
819            <para> The following example demonstrates the UTF-8 character encoding validation
820               process using parallel bit stream techniques. The result of this validation process
821               is an error flag stream identifying the positions at which errors occur.</para>
822            <para>
823               <table>
824                  <caption>
825                     <para>UTF-8 Scope Streams</para>
826                  </caption>
827                  <colgroup>
828                     <col align="left" valign="top"/>
829                     <col align="left" valign="top"/>
830                  </colgroup>
831                  <tbody> <tr valign="top"><td>Input Data</td><td><code>A Text in Farsi:&#160;ى&#160;ك&#160;&#160;م&#160;ت&#160;ن&#160;&#160;ف&#160;ا&#160;ر&#160;س&#160;ى</code></td></tr>
832                     
833                     <tr valign="top">
834                        <td>High Nybbles</td>
835                        <td>
836                           <code>42567726624677632D8DBDBDAD82D8DAD82D8D8</code>
837                        </td>
838                     </tr>
839                     <tr valign="top">
840                        <td>Low Nybbles</td>
841                       
842                        <td>
843                           <code>10458409E061239A099838187910968A9509399</code>
844                        </td>
845                     </tr>
846                     <tr valign="top">
847                        <td>u8Unibyte</td>
848                        <td>
849                           <code>11111111111111111__________1______1____</code>
850                           
851                        </td>
852                     </tr>
853                     <tr valign="top">
854                        <td>u8Prefix</td>
855                        <td>
856                           <code>_________________1_1_1_1_1__1_1_1__1_1_</code>
857                        </td>
858                     </tr>
859                     
860                     <tr valign="top">
861                        <td>u8Suffix</td>
862                        <td>
863                           <code>__________________1_1_1_1_1__1_1_1__1_1</code>
864                        </td>
865                     </tr>
866                     <tr valign="top">
867                        <td>u8Prefix2</td>
868                       
869                        <td>
870                           <code>_________________1_1_1_1_1__1_1_1__1_1_</code>
871                        </td>
872                     </tr>
873                     <tr valign="top">
874                        <td>u8Scope22</td>
875                        <td>
876                           <code>__________________1_1_1_1_1__1_1_1__1_1</code>
877                           
878                        </td>
879                     </tr>
880                     <tr valign="top">
881                        <td>ErrorFlag</td>
882                        <td>
883                           <code>_______________________________________</code>
884                        </td>
885                     </tr>
886                     
887                  </tbody>
888               </table>
889               
890
891            </para>
892         </section>
893
894         <section>
895            <title>UTF-8 Validation Streams</title>
896            <para> Proper formation of UTF-8 byte sequences requires that the correct number of
897               suffix bytes always follow a UTF-8 prefix byte, and that certain illegal byte
898               combinations are ruled out. For example, sequences beginning with the prefix bytes
899               0xF5 through 0xFF are illegal as they would represent code point values above 10FFFF.
900               In addition, there are constraints on the first suffix byte following certain special
901               prefixes, namely that a suffix following the prefix 0xE0 must fall in the range
902               0xA0–0xBF, a suffix following the prefix 0xED must fall in the range 0x80–0x9F, a
903               suffix following the prefix 0xF0 must fall in the range 0x90–0xBF and a suffix
904               following the prefix 0xF4 must fall in the range 0x80–0x8F. The task of ensuring that
905               each of these constraints hold is known as UTF-8 validation. The bit streams xE0,
906               xED, xF0, xF4, xA0_xBF, x80_x9F, x90_xBF, and x80_x8F are constructed to flag the
907               aforementioned UTF-8 validation errors. The result of UTF-8 validation is a UTF-8
908               error flag bit stream contructed as the ORing of a series of UTF-8 validation tests.
909            </para>
910         </section>
911
912         <section>
913            <title>XML Character Validation Streams</title>
914            <para>The UTF-8 character sequences <emphasis>0xEF 0xBF 0xBF</emphasis> and
915                  <emphasis>0xEF 0xBF 0xBE</emphasis> correspond to the Unicode code points 0xFFFE
916               and 0xFFFF respectively. In XML 1.0, 0xFFFE and 0xFFFF represent characters outside
917               the legal XML character ranges. As such, bit streams which mark 0xEF, 0xBF, and 0xBE
918               character are constructed to flag illegal UTF-8 character sequences. </para>
919         </section>
920
921         <section>
922            <title>UTF-8 to UTF-16 Transcoding</title>
923            <para>UTF-8 is often preferred for storage and data exchange, it is suitable for
924               processing, but it is significantly more complex to process than UTF-16 [<xref
925                  linkend="Unicode"/>]. As such, XML documents are typically encoded in UTF-8 for
926               serialization and transport, and subsequently transcoded to UTF-16 for processing
927               with programming languages such as Java and C#. Following the parallel bit stream
928               methods developed for the u8u16 transcoder, a high-performance standalone UTF-8 to
929               UTF-16 transcoder [<xref linkend="u8u16"/>], transcoding to UTF-16 may be achieved by
930               computing a series of 16 bit streams. One stream for each of the individual bits of a
931               UTF-16 code unit. </para>
932            <para>The bit streams for UTF-16 are conveniently divided into groups: the eight streams
933               u16Hi0, u16Hi1, ..., u16Hi7 for the high byte of each UTF-16 code unit and the eight
934               streams u16Lo1, ..., u16Lo7 for the low byte. Upon conversion of the parallel bit
935               stream data back to byte streams, eight sequential byte streams U16h0, U16h1, ...,
936               U16Hi7 are used for the high byte of each UTF-16 code unit, while U16Lo0, U16Lo1,...,
937               U16Lo7 are used for the corresponding low byte. Interleaving these streams then
938               produces the full UTF-16 doublebyte stream.</para>
939         </section>
940
941         <section>
942            <title>UTF-8 Indexed UTF-16 Streams</title>
943            <para>UTF-16 bit streams are initially defined in UTF-8 indexed form. That is, with sets
944               of bits in one-to-one correspondence with UTF-8 bytes. However, only one set of
945               UTF-16 bits is required for encoding two or three-byte UTF-8 sequences and only two
946               sets are required for surrogate pairs corresponding to four-byte UTF-8 sequences. The
947               u8LastByte (u8UniByte , u8Scope22 , u8Scope33 , and u8Scope44 ) and u8Scope42 streams
948               mark the positions at which the correct UTF-16 bits are computed. The bit sets at
949               other positions must be deleted to compress the streams to the UTF-16 indexed form.
950            </para>
951         </section>
952      </section>
953
954      <section>
955         <title>Control Character Streams</title>
956         <para>The control character bit streams marks ASCII control characters in the range
957            0x00-0x1F. Additional control character bit streams mark the tab, carriage return, line
958            feed, and space character. In addition, a bit stream to mark carriage return line
959            combinations is also constructed. Presently, control character bit streams support the
960            operations of XML 1.0 character validation and XML end-of-line handling.</para>
961
962         <section>
963            <title>XML Character Validation</title>
964            <para>Legal characters in XML are the tab, carriage return, and line feed characters,
965               together with all Unicode characters and excluding the surrogate blocks, as well as hexadecimal OxFFFE and
966               OxFFFF [<xref linkend="XML10"/>]. The x00_x1F bit stream is constructed and used in
967               combination with the additional control character bit streams to flags the positions
968               of illegal control characters.</para>
969         </section>
970
971         <section>
972            <title>XML 1.0 End-of-line Handling</title>
973            <para>In XML 1.0 the two-character sequence CR LF (carriage return, line feed) as well as
974               any CR character not followed by a LF character must be converted to a single LF
975               character [<xref linkend="XML10"/>].</para>
976            <para>By defining carriage return, line feed, and carriage return line feed bit streams,
977               dentoted CR, LF and CRLF respectively, end-of-line normalization processing can be
978               performed in parallel using only a small number of logical and shift operations.</para>
979            <para/>
980            <para>The following example demonstrates the generation of the CRLF deletion mask. In
981               this example, the position of all CR characters followed by LF characters are marked
982               for deletion. Isolated carriage returns are then replaced with LF characters.
983               Completion of this process satisfies the XML 1.0 end-of-line handling requirements.
984               For clarity, this example encodes input data carriage returns as
985               <emphasis>C</emphasis> characters, whereas line feed characters are shown as
986                  <emphasis>L</emphasis> characters.</para>
987            <para>
988               <table>
989                  <caption>
990                     <para>XML 1.0 End-of-line Handling</para>
991                  </caption>
992                  <colgroup>
993                     <col align="left" valign="top"/>
994                  </colgroup>
995                  <tbody>
996                     <tr valign="top">
997                        <td>Input Data</td>
998                        <td>
999                           <code>first line C second line CL third line L one more C nothing
1000                           left</code>
1001                        </td>
1002                     </tr>
1003                     <tr valign="top">
1004                        <td>CR</td>
1005                        <td>
1006                           <code>-----------1-------------1------------------------1-------------</code>
1007                        </td>
1008                     </tr>
1009                     <tr valign="top">
1010                        <td>LF</td>
1011                        <td>
1012                           <code>--------------------------1------------1------------------------</code>
1013                        </td>
1014                     </tr>
1015                     <tr valign="top">
1016                        <td>DelMask</td>
1017                        <td>
1018                           <code>--------------------------1-------------------------------------</code>
1019                        </td>
1020                     </tr>
1021                  </tbody>
1022               </table>
1023
1024            </para>
1025         </section>
1026
1027      </section>
1028
1029      <section>
1030         <title>Call Out Streams</title>
1031         <para> Call out bit streams mark the extents of XML markup structures such as comments,
1032            processing instruction and CDATA sections as well as physical structures such as character and
1033            entity references and general references.  Call out streams are also formed for logical markup structures such
1034            start tags, end tags and empty element tags. </para>
1035         <section>
1036            <title>Comment, Processing Instruction and CDATA Section Call Out Streams</title>
1037            <para>Comments, processing instructions and CDATA sections call out streams, Ct_Span,
1038               PI_Span and CD_Span respectively, define sections of an XML document which
1039               contain markup that is not interpreted by an XML processor. As such, the union of
1040               Ct_Span, PI_Span and CD_Span streams defines the regions of non-interpreteable markup.
1041               The stream formed by this union is termed the CtCDPI_Mask.</para>
1042            <para>The following tables provides an example of constructing the CtCDPI_Mask. </para>
1043            <table>
1044               <caption>
1045                  <para>CtCDPI Mask Generation</para>
1046               </caption>
1047               <colgroup><col align="left" valign="top" /><col align="left" valign="top" /></colgroup>
1048               <tbody> <tr valign="top"><td>Input Data</td><td><code>&lt;?php?&gt; &lt;!-- example --&gt; &lt;![CDATA[ shift: a&lt;&lt;1 ]]&gt;</code></td></tr>
1049                 
1050                  <tr valign="top"><td>CD_Span</td><td><code>___________________________1111111111111111111111_</code></td></tr>
1051                  <tr valign="top"><td>Ct_Span</td><td><code>___________111111111111___________________________</code></td></tr>
1052                  <tr valign="top"><td>PI_Span</td><td><code>_11111____________________________________________</code></td></tr>
1053                  <tr valign="top"><td>CtCDPI_Mask</td><td><code>_111111__111111111111111__111111111111111111111111</code></td></tr>
1054                  <tr valign="top"><td>ErrorFlag</td><td><code>__________________________________________________</code></td></tr>
1055                 
1056               </tbody>
1057            </table>
1058           
1059           
1060           
1061           
1062            <para> With the removal of all non-interpreteable markup, several phases of parallel bit
1063               stream based SIMD operations may follow operating on up to 128 byte positions on
1064               current commondity processors and assured of XML markup relevancy. For
1065               example, with the extents identification of comments, processing instructions and
1066               CDATA secions, XML names may be identified and length sorted for efficient symbol
1067               table construction. </para>
1068            <para> As an aside, comments and CDATA sections must first be validated to ensure
1069               that comments do not contain "--" sequences and that CDATA sections do not contain illegal
1070               "]]&gt;" sequences prior to ignorable markup stream generation.</para>
1071         </section>
1072
1073         <section>
1074            <title>Reference Call Out Streams</title>
1075            <para>The reference call out streams are the GenRefs, DecRefs, and HexRefs streams. This
1076               subset of the call out streams marks the extents of all but the closing semicolon of
1077               general and character references.</para>
1078            <para>Predefined character
1079               (<![CDATA[&lt;,&gt;,&amp;,&apos;,&quot;]]>) and numeric character
1080               references (&amp;#nnnn;, &amp;#xhhhh;) must be replaced by a single character
1081                  [<xref linkend="XML10"/>]. As previously shown, this subset of call out streams enables the construction of a DelMask for
1082               references.</para>
1083         </section>
1084
1085         <section>
1086            <title>Tag Call Out Streams</title>
1087            <para>Whereas sequential bit scans over lexical item streams form the basis of XML
1088               parsing, in the current Parabix parser a new method of parallel parsing has been
1089               developed and prototyped using the concept of bitstream addition. Fundamental to this
1090               method is the concept of a <emphasis>cursor</emphasis> stream, a bit stream marking
1091               the positions of multiple parallel parses currently in process. </para>
1092            <para>The results of parallel parsing using the bit stream addition technique produces a
1093               set of tag call out bit streams. These streams mark the extents of each start tag,
1094               end tag and empty element tag. Within tags, additional streams mark start
1095               and end positions for tag names, as well as attribute names and values. An error flag
1096               stream marks the positions of any syntactic errors encountered during parsing.</para>
1097            <para> The set of tag call out streams consists of the ElemNames, AttNames, AttVals, Tags,
1098               EmptyTagEnds and EndTags bit streams. The following example demonstrates the bit
1099               stream output produced which from parallel parsing using bit stream addition. </para>
1100            <table>
1101               <caption>
1102                  <para>Tag Call Out Streams</para>
1103               </caption>
1104               <colgroup>
1105                  <col align="left" valign="top"/>
1106                  <col align="left" valign="top"/>
1107               </colgroup>
1108               <tbody>
1109                  <tr valign="top">
1110                     <td>Input Data</td>
1111                     <td>
1112                        <code>&lt;root&gt;&lt;t1&gt;text&lt;/t1&gt;&lt;t2
1113                           a1=&apos;foo&apos; a2 =
1114                           &apos;fie&apos;&gt;more&lt;/t2&gt;&lt;tag3
1115                           att3=&apos;b&apos;/&gt;&lt;/root&gt;</code>
1116                     </td>
1117                  </tr>
1118
1119                  <tr valign="top">
1120                     <td>ElemNames</td>
1121                     <td>
1122                        <code>_1111__11___________11_______________________________1111__________________</code>
1123                     </td>
1124                  </tr>
1125                  <tr valign="top">
1126                     <td>AttNames</td>
1127                     <td>
1128                        <code>_______________________11_______11________________________1111_____________</code>
1129                     </td>
1130                  </tr>
1131                  <tr valign="top">
1132                     <td>AttrVals</td>
1133                     <td>
1134                        <code>__________________________11111______11111_____________________111_________</code>
1135                     </td>
1136                  </tr>
1137                  <tr valign="top">
1138                     <td>EmptyTagEnds</td>
1139                     <td>
1140                        <code>___________________________________________________________________1_______</code>
1141                     </td>
1142                  </tr>
1143                  <tr valign="top">
1144                     <td>EndTags</td>
1145                     <td>
1146                        <code>_______________111______________________________111__________________11111_</code>
1147                     </td>
1148                  </tr>
1149
1150                  <tr valign="top">
1151                     <td>Start/EmptyTags</td>
1152                     <td>
1153                        <code>_1111__11___________1111111111111111111111___________11111111111111________</code>
1154                     </td>
1155                  </tr>
1156                  <tr valign="top">
1157                     <td>ErrorFlag</td>
1158                     <td>
1159                        <code>___________________________________________________________________________</code>
1160                     </td>
1161                  </tr>
1162               </tbody>
1163            </table>
1164
1165         </section>
1166      </section>
1167   </section>
1168   <section>
1169      <title>SIMD Beyond Bitstreams: Names and Numbers</title>
1170
1171      <para>Whereas the fundamental innovation of our work is the use of SIMD technology in
1172         implementing parallel bit streams for XML, there are also important ways in which more
1173         traditional byte-oriented SIMD operations can be useful in accelerating other aspects of
1174         XML processing.</para>
1175
1176      <section>
1177         <title>Name Lookup</title>
1178         <para>Efficient symbol table mechanisms for looking up element and attribute names is
1179            important for almost all XML processing applications. It is also an important technique
1180            merely for assessing well-formedness of an XML document; rather than validating the
1181            character-by-character composition of each occurrence of an XML name as it is
1182            encountered, it is more efficient to validate all but the first occurrence by first
1183            determining whether the name already exists in a table of prevalidated names.</para>
1184
1185         <para>The first symbol table mechanism deployed in the Parabix parser simply used the
1186            hashmaps of the C++ standard template library, without deploying any SIMD technology.
1187            However, with the overhead of character validation, transcoding and parsing dramatically
1188            reduced by parallel bit stream technology, we found that symbol lookups then accounted
1189            for about half of the remaining execution time in a statistics gathering application
1190               [<xref linkend="CASCON08"/>]. Thus, symbol table processing was identified as a major
1191            target for further performance improvement. </para>
1192         <para> Our first effort to improve symbol table performance was to employ the splash tables
1193            with cuckoo hashing as described by Ross [<xref linkend="Ross06"/>], using SIMD
1194            technology for parallel bucket processing. Although this technique did turn out to have
1195            the advantage of virtually constant-time performance even for very large vocabularies,
1196            it was not particularly helpful for the relatively small vocabularies typically found in
1197            XML document processing. </para>
1198         <para> However, a second approach has been found to be quite useful, taking advantage of
1199            parallel bit streams for cheap determination of symbol length. In essence, the length of
1200            a name can be determined very cheaply using a single bit scan operation. This then makes
1201            it possible to use length-sorted symbol table processing, as follows. First, the
1202            occurrences of all names are stored in arrays indexed by length. Then the length-sorted
1203            arrays may each be inserted into the symbol table in turn. The advantage of this is that
1204            a separate loop may be written for each length. Length sorting makes for very efficient
1205            name processing. For example hash value computations and name comparisons can be made by
1206            loading multibyte values and performing appropriate shifting and masking operations,
1207            without the need for a byte-at-a-time loop. In initial experiments, this length-sorting
1208            approach was found to reduce symbol lookup cost by a factor of two. </para>
1209         <para> Current research includes the application of SIMD technology to further enhance the
1210            performance of length-sorted lookup. We have identified a promising technique for
1211            parallel processing of multiple name occurrences using a parallel trie lookup technique.
1212            Given an array of occurrences of names of a particular length, the first one, two or
1213            four bytes of each name are gathered and stored in a linear array. SIMD techniques are
1214            then used to compare these prefixes with the possible prefixes for the current position
1215            within the trie. In general, a very small number of possibilities exist for each trie
1216            node, allowing for fast linear search through all possibilities. Typically, the
1217            parallelism is expected to exceed the number of possibilities to search through at each
1218            node. With length-sorting to separate the top-level trie into many small subtries, we
1219            expect only a single step of symbol lookup to be needed in most practical instances. </para>
1220
1221         <para>The gather step of this algorithm is actually a common technique in SIMD processing.
1222            Instruction set support for gather operations is a likely future direction for SIMD
1223            technology.</para>
1224      </section>
1225
1226      <section>
1227         <title>Numeric Processing</title>
1228         <para> Many XML applications involve numeric data fields as attribute values or element
1229            content. Although most current XML APIs uniformly return information to applications in
1230            the form of character strings, it is reasonable to consider direct API support for
1231            numeric conversions within a high-performance XML engine. With string to numeric
1232            conversion such a common need, why leave it to application programmers? </para>
1233         <para> High-performance string to numeric conversion using SIMD operations also can
1234            considerably outperform the byte-at-a-time loops that most application programmers or
1235            libraries might employ. A first step is reduction of ASCII bytes to corresponding
1236            decimal nybbles using a SIMD packing operation. Then an inductive doubling algorithm
1237            using SIMD operations may be employed. First, 16 sets of adjacent nybble values in the
1238            range 0-9 can be combined in just a few SIMD operations to 16 byte values in the range
1239            0-99. Then 8 sets of byte values may similarly be combined with further SIMD processing
1240            to produce doublebyte values in the range 0-9999. Further combination of doublebyte
1241            values into 32-bit integers and so on can also be performed using SIMD operations. </para>
1242         <para> Using appropriate gather operations to bring numeric strings into appropriate array
1243            structures, an XML engine could offer high-performance numeric conversion services to
1244            XML application programmers. We expect this to be an important direction for our future
1245            work, particularly in support of APIs that focus on direct conversion of XML data into
1246            business objects. </para>
1247
1248      </section>
1249   </section>
1250
1251   <section>
1252      <title>APIs and Parallel Bit Streams</title>
1253
1254      <section>
1255         <title>The ILAX Streaming API</title>
1256         <para>The In-Line API for XML (ILAX) is the base API provided with the Parabix parser. It
1257            is intended for low-level extensions compiled right into the engine, with minimum
1258            possible overhead. It is similar to streaming event-based APIs such as SAX, but
1259            implemented by inline substitution rather than using callbacks. In essence, an extension
1260            programmer provides method bodies for event-processing methods declared internal to the
1261            Parabix parsing engine, compiling the event processing code directly with the core code
1262            of the engine. </para>
1263         <para> Although ILAX can be used directly for application programming, its primary use is
1264            for implementing engine extensions that support higher-level APIs. For example, the
1265            implementation of C or C++ based streaming APIs based on the Expat [<xref
1266               linkend="Expat"/>] or general SAX models can be quite directly implemented. C/C++ DOM
1267            or other tree-based APIs can also be fairly directly implemented. However, delivering
1268            Parabix performance to Java-based XML applications is challenging due to the
1269            considerable overhead of crossing the Java Native Interface (JNI) boundary. This issue
1270            is addressed with the Array Set Model (ASM) concept discussed in the following section. </para>
1271         <para> With the recent development of parallel parsing using bitstream addition, it is
1272            likely that the underlying ILAX interface of Parabix will change. In essence, ILAX
1273            suffers the drawback of all event-based interfaces: they are fundamentally sequential in
1274            number. As research continues, we expect efficient parallel methods building on parallel
1275            bit stream foundations to move up the stack of XML processing requirements. Artificially
1276            imposing sequential processing is thus expected to constrain further advances in XML
1277            performance. </para>
1278      </section>
1279
1280      <section>
1281         <title>Efficient XML in Java Using Array Set Models</title>
1282         <para> In our GML-to-SVG case study, we identified the lack of high-performance XML
1283            processing solutions for Java to be of particular interest. Java byte code does not
1284            provide access to the SIMD capabilities of the underlying machine architecture. Java
1285            just-in-time compilers might be capable of using some SIMD facilities, but there is no
1286            real prospect of conventional compiler technology translating byte-at-a-time algorithms
1287            into parallel bit stream code. So the primary vehicle for delivering high-performance
1288            XML processing is to call native parallel bit stream code written in C through JNI
1289            capabilities. </para>
1290         <para>However, each JNI call is expensive, so it is desirable to minimize the number of
1291            calls and get as much work done during each call as possible. This mitigates against
1292            direct implementation of streaming APIs in Java through one-to-one mappings to an
1293            underlying streaming API in C. Instead, we have concentrated on gathering information on
1294            the C side into data structures that can then be passed to the Java side. However, using
1295            either C pointer-based structures or C++ objects is problematic because these are
1296            difficult to interpret on the Java side and are not amenable to Java's automatic storage
1297            management system. Similarly, Java objects cannot be conveniently created on the C side.
1298            However, it is possible to transfer arrays of simple data values (bytes or integers)
1299            between C and Java, so that makes a reasonable focus for bulk data communication between
1300            C and Java. </para>
1301         <para><emphasis>Array Set Models</emphasis> are array-based representations of information
1302            representing an XML document in accord with XML InfoSet [<xref linkend="InfoSet"/>] or
1303            other XML data models relevant to particular APIs. As well as providing a mechanism for
1304            efficient bulk data communication across the JNI boundary, ASMs potentially have a
1305            number of other benefits in high-performance XML processing. <itemizedlist>
1306               <listitem>
1307                  <para>Prefetching. Commodity processors commonly support hardware and/or software
1308                     prefetching to ensure that data is available in a processor cache when it is
1309                     needed. In general, prefetching is most effective in conjunction with the
1310                     continuous sequential memory access patterns associated with array
1311                  processing.</para>
1312               </listitem>
1313               <listitem>
1314                  <para>DMA. Some processing environments provide Direct Memory Access (DMA)
1315                     controllers for block data movement in parallel with computation. For example,
1316                     the Cell Broadband Engine uses DMA controllers to move the data to and from the
1317                     local stores of the synergistic processing units. Arrays of contiguous data
1318                     elements are well suited to bulk data movement using DMA.</para>
1319               </listitem>
1320               <listitem>
1321                  <para>SIMD. Single Instruction Multiple Data (SIMD) capabilities of modern
1322                     processor instruction sets allow simultaneous application of particular
1323                     instructions to sets of elements from parallel arrays. For effective use of
1324                     SIMD capabilities, an SoA (Structure of Arrays) model is preferrable to an AoS
1325                     (Array of Structures) model. </para>
1326               </listitem>
1327               <listitem>
1328                  <para>Multicore processors. Array-oriented processing can enable the effective
1329                     distribution of work to the individual cores of a multicore system in two
1330                     distinct ways. First, provided that sequential dependencies can be minimized or
1331                     eliminated, large arrays can be divided into separate segments to be processed
1332                     in parallel on each core. Second, pipeline parallelism can be used to implement
1333                     efficient multipass processing with each pass consisting of a processing kernel
1334                     with array-based input and array-based output. </para>
1335               </listitem>
1336               <listitem>
1337                  <para>Streaming buffers for large XML documents. In the event that an XML document
1338                     is larger than can be reasonably represented entirely within processor memory,
1339                     a buffer-based streaming model can be applied to work through a document using
1340                     sliding windows over arrays of elements stored in document order. </para>
1341               </listitem>
1342
1343            </itemizedlist>
1344         </para>
1345
1346         <section>
1347            <title>Saxon-B TinyTree Example</title>
1348            <para>As a first example of the ASM concept, current work includes a proof-of-concept to
1349               deliver a high-performance replacement for building the TinyTree data structure used
1350               in Saxon-B 6.5.5, an open-source XSLT 2.0 processor written in Java [<xref
1351                  linkend="Saxon"/>]. Although XSLT stylesheets may be cached for performance, the
1352               caching of source XML documents is typically not possible. A new TinyTree object to
1353               represent the XML source document is thus commonly constructed with each new query so
1354               that the overall performance of simple queries on large source XML documents is
1355               highly dependent on TinyTree build time. Indeed, in a study of Saxon-SA, the
1356               commercial version of Saxon, query time was shown to be dominated by TinyTree build
1357               time [<xref linkend="Kay08"/>]. Similar performance results are demonstrable for the
1358               Saxon-B XSLT processor as well. </para>
1359            <para> The Saxon-B processor studied is a pure Java solution, converting a SAX (Simple
1360               API for XML) event stream into the TinyTree Java object using the efficient Aelfred
1361               XML parser [<xref linkend="AElfred"/>]. The TinyTree structure is itself an
1362               array-based structure mapping well suited to the ASM concept. It consists of six
1363               parallel arrays of integers indexed on node number and containing one entry for each
1364               node in the source document, with the exception of attribute and namespace nodes
1365                  [<xref linkend="Saxon"/>]. Four of the arrays respectively provide node kind, name
1366               code, depth, and next sibling information for each node, while the two others are
1367               overloaded for different purposes based on node kind value. For example, in the
1368               context of a text node , one of the overloaded arrays holds the text buffer offset
1369               value whereas the other holds the text buffer length value. Attributes and namespaces
1370               are represented using similiar parallel array of values. The stored TinyTree values
1371               are primarily primitive Java types, however, object types such as Java Strings and
1372               Java StringBuffers are also used to hold attribute values and comment values
1373               respectively. </para>
1374            <para> In addition to the TinyTree object, Saxon-B maintains a NamePool object which
1375               represents a collection of XML name triplets. Each triplet is composed of a Namespace
1376               URI, a Namespace prefix and a local name and encoded as an integer value known as a
1377               namecode. Namecodes permit efficient name search and look-up using integer
1378               comparison. Namecodes may also be subsequently decoded to recover namespace and local
1379               name information. </para>
1380            <para> Using the Parabix ILAX interface, a high-performance reimplementation of TinyTree
1381               and NamePool data structures was built to compare with the Saxon-B implementation. In
1382               fact, two functionally equivalent versions of the ASM java class were constructed. An
1383               initial version was constructed based on a set of primitive Java arrays constructed
1384               and allocated in the Java heap space via JNI New&lt;PrimitiveType&gt;Array
1385               method call. In this version, the JVM garbage collector is aware of all memory
1386               allocated in the native code. However, in this approach, large array copy operations
1387               limited overall performance to approximately a 2X gain over the Saxon-B build time. </para>
1388            <para>To further address the performance penalty imposed by copying large array values,
1389               a second version of the ASM Java object was constructed based on natively backed
1390               Direct Memory Byte Buffers [<xref linkend="JNI"/>]. In this version the JVM garbage
1391               collector is unaware any native memory resources backing the Direct Memory Byte
1392               Buffers. Large JNI-based copy operations are avoided; however, system memory must be
1393               explicitly deallocated via a Java native method call. Using this approach, our
1394               preliminary results show an approximate total 2.5X gain over Saxon-B build time.
1395            </para>
1396         </section>
1397      </section>
1398   </section>
1399
1400
1401   <section>
1402      <title>Compiler Technology</title>
1403
1404      <para> An important focus of our recent work is on the development of compiler technology to
1405         automatically generate the low-level SIMD code necessary to implement bit stream processing
1406         given suitable high-level specifications. This has several potential benefits. First, it
1407         can eliminate the tedious and error-prone programming of bit stream operations in terms of
1408         register-at-a-time SIMD operations. Second, compilation technology can automatically employ
1409         a variety of performance improvement techniques that are difficult to apply manually. These
1410         include algorithms for instruction scheduling and register allocation as well as
1411         optimization techniques for common subexpression expression elimination and register
1412         rematerialization among others. Third, compiler technology makes it easier to make changes
1413         to the low-level code for reasons of perfective or adaptive maintenance.</para>
1414
1415      <para>Beyond these reasons, compiler technology also offers the opportunity for retargetting
1416         the generation of code to accommodate different processor architectures and API
1417         requirements. Strategies for efficient parallel bit stream code can vary considerably
1418         depending on processor resources such as the number of registers available, the particular
1419         instruction set architecture supported, the size of L1 and L2 data caches, the number of
1420         available cores and so on. Separate implementation of custom code for each processor
1421         architecture would thus be likely to be prohibitively expensive, prone to errors and
1422         inconsistencies and difficult to maintain. Using compilation technology, however, the idea
1423         would be to implement a variety of processor-specific back-ends all using a common front
1424         end based on parallel bit streams. </para>
1425
1426      <section>
1427         <title>Character Class Compiler</title>
1428
1429         <para>The first compiler component that we have implemented is a character class compiler,
1430            capable of generation all the bit stream logic necessary to produce a set of lexical
1431            item streams each corresponding to some particular set of characters to be recognized.
1432            By taking advantage of common patterns between characters within classes, and special
1433            optimization logic for recognizing character-class ranges, our existing compiler is able
1434            to generate well-optimized code for complex sets of character classes involving numbers
1435            of special characters as well as characters within specific sets of ranges. </para>
1436
1437      </section>
1438      <section>
1439         <title>Regular Expression Compilation</title>
1440
1441         <para>Based on the character class compiler, we are currently investigating the
1442            construction of a regular expression compiler that can implement bit-stream based
1443            parallel regular-expression matching similar to that describe previously for parallel
1444            parsing by bistream addition. This compiler works with the assumption that bitstream
1445            regular-expression definitions are deterministic; no backtracking is permitted with the
1446            parallel bit stream representation. In XML applications, this compiler is primarily
1447            intended to enforce regular-expression constraints on string datatype specifications
1448            found in XML schema. </para>
1449
1450      </section>
1451
1452      <section>
1453         <title>Unbounded Bit Stream Compilation</title>
1454
1455         <para>The Catalog of XML Bit Streams presented earlier consist of a set of abstract,
1456            unbounded bit streams, each in one-to-one correspondence with input bytes of a text
1457            file. Determining how these bit streams are implemented using fixed-width SIMD
1458            registers, and possibly processed in fixed-length buffers that represent some multiple
1459            of the register width is a source of considerable programming complexity. The general
1460            goal of our compilation strategy in this case is to allow operations to be programmed in
1461            terms of unbounded bit streams and then automatically reduced to efficient low-level
1462            code with the application of a systematic code generation strategy for handling block
1463            and buffer boundary crossing. This is work currently in progress. </para>
1464
1465      </section>
1466   </section>
1467
1468   <section>
1469      <title>Conclusion</title>
1470      <para>Parallel bit stream technology offers the opportunity to dramatically speed up the core
1471         XML processing components used to implement virtually any XML API. Character validation and
1472         transcoding, whitespace processing, and parsing up to including the full validation of tag
1473         syntax can be handled fully in parallel using bit stream methods. Bit streams to mark the
1474         positions of all element names, attribute names and attribute values can also be produced,
1475         followed by fast bit scan operations to generate position and length values. Beyond bit
1476         streams, byte-oriented SIMD processing of names and numerals can also accelerate
1477         performance beyond sequential byte-at-a-time methods. </para>
1478      <para>Advances in processor architecture are likely to further amplify the performance of
1479         parallel bit stream technology over traditional byte-at-a-time processing over the next
1480         decade. Improvements to SIMD register width, register complement and operation format can
1481         all result in further gains. New SIMD instruction set features such as inductive doubling
1482         support, parallel extract and deposit instructions, bit interleaving and scatter/gather
1483         capabilities should also result in significant speed-ups. Leveraging the intraregister
1484         parallelism of parallel bit stream technology within SIMD registers to take of intrachip
1485         parallelism on multicore processors should accelerate processing further. </para>
1486      <para>Technology transfer using a patent-based open-source business model is a further goal of
1487         our work with a view to widespread deployment of parallel bit stream technology in XML
1488         processing stacks implementing a variety of APIs. The feasibility of substantial
1489         performance improvement in replacement of technology implementing existing APIs has been
1490         demonstrated even in complex software architectures involving delivery of performance
1491         benefits across the JNI boundary. We are seeking to accelerate these deployment efforts
1492         both through the development of compiler technology to reliably apply these methods to a
1493         variety of architectures as well as to identify interested collaborators using open-source
1494         or commercial models. </para>
1495   </section>
1496
1497   <section>
1498      <title>Acknowledgments</title>
1499      <para>This work is supported in part by research grants and scholarships from the Natural
1500         Sciences and Engineering Research Council of Canada, the Mathematics of Information
1501         Technology and Complex Systems Network and the British Columbia Innovation Council. </para>
1502      <para>We thank our colleague Dan Lin (Linda) for her work in high-performance symbol table
1503         processing. </para>
1504   </section>
1505
1506   <bibliography>
1507      <title>Bibliography</title>
1508      <bibliomixed xml:id="XMLChip09" xreflabel="Leventhal and Lemoine 2009">Leventhal, Michael and
1509         Eric Lemoine 2009. The XML chip at 6 years. Proceedings of International Symposium on
1510         Processing XML Efficiently 2009, Montréal.</bibliomixed>
1511      <bibliomixed xml:id="Datapower09" xreflabel="Salz, Achilles and Maze 2009">Salz, Richard,
1512         Heather Achilles, and David Maze. 2009. Hardware and software trade-offs in the IBM
1513         DataPower XML XG4 processor card. Proceedings of International Symposium on Processing XML
1514         Efficiently 2009, Montréal.</bibliomixed>
1515      <bibliomixed xml:id="PPoPP08" xreflabel="Cameron 2007">Cameron, Robert D. 2007. A Case Study
1516         in SIMD Text Processing with Parallel Bit Streams UTF-8 to UTF-16 Transcoding. Proceedings
1517         of 13th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming 2008, Salt
1518         Lake City, Utah. On the Web at <link>http://research.ihost.com/ppopp08/</link>.</bibliomixed>
1519      <bibliomixed xml:id="CASCON08" xreflabel="Cameron, Herdy and Lin 2008">Cameron, Robert D.,
1520         Kenneth S Herdy, and Dan Lin. 2008. High Performance XML Parsing Using Parallel Bit Stream
1521         Technology. Proceedings of CASCON 2008. 13th ACM SIGPLAN Symposium on Principles and
1522         Practice of Parallel Programming 2008, Toronto.</bibliomixed>
1523      <bibliomixed xml:id="SVGOpen08" xreflabel="Herdy, Burggraf and Cameron 2008">Herdy, Kenneth
1524         S., Robert D. Cameron and David S. Burggraf. 2008. High Performance GML to SVG
1525         Transformation for the Visual Presentation of Geographic Data in Web-Based Mapping Systems.
1526         Proceedings of SVG Open 6th International Conference on Scalable Vector Graphics,
1527         Nuremburg. On the Web at
1528            <link>http://www.svgopen.org/2008/papers/74-HighPerformance_GML_to_SVG_Transformation_for_the_Visual_Presentation_of_Geographic_Data_in_WebBased_Mapping_Systems/</link>.</bibliomixed>
1529      <bibliomixed xml:id="Ross06" xreflabel="Ross 2006">Ross, Kenneth A. 2006. Efficient hash
1530         probes on modern processors. Proceedings of ICDE, 2006. ICDE 2006, Atlanta. On the Web at
1531            <link>www.cs.columbia.edu/~kar/pubsk/icde2007.pdf</link>.</bibliomixed>
1532      <bibliomixed xml:id="ASPLOS09" xreflabel="Cameron and Lin 2009">Cameron, Robert D. and Dan
1533         Lin. 2009. Architectural Support for SWAR Text Processing with Parallel Bit Streams: The
1534         Inductive Doubling Principle. Proceedings of ASPLOS 2009, Washington, DC.</bibliomixed>
1535      <bibliomixed xml:id="Wu08" xreflabel="Wu et al. 2008">Wu, Yu, Qi Zhang, Zhiqiang Yu and
1536         Jianhui Li. 2008. A Hybrid Parallel Processing for XML Parsing and Schema Validation.
1537         Proceedings of Balisage 2008, Montréal. On the Web at
1538            <link>http://www.balisage.net/Proceedings/vol1/html/Wu01/BalisageVol1-Wu01.html</link>.</bibliomixed>
1539      <bibliomixed xml:id="u8u16" xreflabel="Cameron 2008">u8u16 - A High-Speed UTF-8 to UTF-16
1540         Transcoder Using Parallel Bit Streams Technical Report 2007-18. 2007. School of Computing
1541         Science Simon Fraser University, June 21 2007.</bibliomixed>
1542      <bibliomixed xml:id="XML10" xreflabel="XML 1.0">Extensible Markup Language (XML) 1.0 (Fifth
1543         Edition) W3C Recommendation 26 November 2008. On the Web at
1544            <link>http://www.w3.org/TR/REC-xml/</link>.</bibliomixed>
1545      <bibliomixed xml:id="Unicode" xreflabel="Unicode">The Unicode Consortium. 2009. On the Web at
1546            <link>http://unicode.org/</link>.</bibliomixed>
1547      <bibliomixed xml:id="Pex06" xreflabel="Hilewitz and Lee 2006"> Hilewitz, Y. and Ruby B. Lee.
1548         2006. Fast Bit Compression and Expansion with Parallel Extract and Parallel Deposit
1549         Instructions. Proceedings of the IEEE 17th International Conference on Application-Specific
1550         Systems, Architectures and Processors (ASAP), pp. 65-72, September 11-13, 2006.</bibliomixed>
1551      <bibliomixed xml:id="InfoSet" xreflabel="XML Infoset">XML Information Set (Second Edition) W3C
1552         Recommendation 4 February 2004. On the Web at
1553         <link>http://www.w3.org/TR/xml-infoset/</link>.</bibliomixed>
1554      <bibliomixed xml:id="Saxon" xreflabel="Saxon">SAXON The XSLT and XQuery Processor. On the Web
1555         at <link>http://saxon.sourceforge.net/</link>.</bibliomixed>
1556      <bibliomixed xml:id="Kay08" xreflabel="Kay 2008"> Kay, Michael Y. 2008. Ten Reasons Why Saxon
1557         XQuery is Fast, IEEE Data Engineering Bulletin, December 2008.</bibliomixed>
1558      <bibliomixed xml:id="AElfred" xreflabel="Ælfred"> The Ælfred XML Parser. On the Web at
1559            <link>http://saxon.sourceforge.net/aelfred.html</link>.</bibliomixed>
1560      <bibliomixed xml:id="JNI" xreflabel="Hitchens 2002">Hitchens, Ron. Java NIO. O'Reilly, 2002.</bibliomixed>
1561      <bibliomixed xml:id="Expat" xreflabel="Expat">The Expat XML Parser.
1562            <link>http://expat.sourceforge.net/</link>.</bibliomixed>
1563   </bibliography>
1564
1565</article>
Note: See TracBrowser for help on using the repository browser.