sir*_*usa 5 algorithm parallel-processing parsing
对于已经以拆分格式给出的大量输入数据（例如大量的单个数据库条目），解析器的并行化似乎很容易，或者很容易通过快速的预处理步骤进行拆分（例如，将句子的语法结构解析为大型）文本。
似乎很难进行并行解析，这已经需要付出很多努力才能在给定输入中定位子结构。通用编程语言代码看起来像一个很好的例子。在Haskell之类的使用布局/缩进分隔单个定义的语言中，您可能会在找到新定义的开始后检查每行的前导空格数，跳过所有行，直到找到另一个定义并传递每个定义跳过块到另一个线程进行完全解析。
对于使用平衡括号定义范围的C，JavaScript等语言，进行预处理的工作量会更高。您需要遍历整个输入，从而计算大括号，注意字符串文字中的文本，等等。对于XML之类的语言而言，情况更糟，您还需要在打开/关闭标签中跟踪标签名称。
我发现CYK解析算法的并行版本似乎适用于所有无上下文语法。但是我很好奇还有什么其他通用概念/算法可以使解析器并行化，包括上述大括号计数这样的事情，它们仅适用于有限的一组语言。这个问题不是关于特定的实现，而是关于这些实现的思想。
我认为您会发现McKeeman于1982年发表的有关并行LR解析的论文非常有趣，因为它似乎很实用并且适用于广泛的语法。
基本方案是标准的LR解析。聪明的是，（大概长的）输入被分成了大约N个相等大小的块（对于N个处理器），并且每个块都被分别解析。因为块的起点可能（必须！）在某些生产的中间，所以与经典的LR解析器不同，McKeemans的单个解析器从所有可能的左上下文（要求增强LR状态机）开始确定哪个LR。项目适用于块。（在单个解析器确定什么状态真正适用之前，不应该花费太多的令牌，因此这并不是很低效）。然后将所有解析器的结果缝合在一起。
他有点回避在令牌中间划分输入的问题。（您可以想象一个任意大的字符串文字，其中包含看起来像代码的文本，以欺骗解析器从中间开始）。似乎发生的情况是解析器遇到错误并放弃了解析；左侧的解析器占用了空闲时间。可以想象，分块器会使用一些聪明的方法来避免这种情况。
他将演示一个真正的解析器，可以在其中获得加速。
的确如此。