使用 Vowpal Wabbit 的预编译版本 - 缺点？

Question

由于RHEL机器上编译大众的困难，我选择退出使用阿里尔Faigon（谢谢！）提供大众的编译版本在这里。 我正在从 Python 调用 VW，所以我计划使用 Python 的subprocess模块（我也无法编译 python 包）。 我想知道这种方法是否有任何缺点。 我会看到任何性能滞后吗？

非常感谢你的帮助！

Answer 1

通过 Python 的subprocess进程提供实时的 vawpal wabbit 进程是可以的（快速）。 只要您不为每个示例启动一个新进程并避免过多的上下文切换。 根据我的经验，在这种设置中，在典型的双核硬件上，您可以预期每秒约 50 万个特征的吞吐量。 这不如（快 10 倍）~5M 功能/秒 vw 通常在不与任何其他软件交互（从文件/缓存中读取）时处理的速度快，但对于大多数实际用途来说已经足够了。 请注意，此设置中的瓶颈很可能是附加进程的处理，而不是vovpal-wabbit 本身。

建议在输入（馈送 vw）和输出（读取 vw 响应）时分批馈送vovpal-wabbit（一次 N 个示例，而不是一次一个）。 如果您使用subprocess.Popen连接到进程，请确保传递一个大的bufsize否则默认情况下 Popen 迭代器将被行缓冲（一次一个示例），这可能会导致每个示例之间的上下文切换示例的生产者和消费者（vowpal wabbit）。

假设您的 vw 命令行在vw_cmd ，它将类似于：

vw_proc = subprocess.Popen(vw_cmd,
                   stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
                   bufsize=1048576)

一般来说，缓慢可能来自：

• 上下文切换过多（一次生成和处理一个示例）
• vw 之外的太多处理（例如首先生成示例，特征转换）
• 每个示例的启动开销（例如读取模型）。

因此，在必须与其他进程交互的情况下，避免上述所有陷阱应该可以为您提供最快的吞吐量。