MEP 3 – Tensor API 设计规范

编号

3

标题

Tensor API 设计规范

作者

高华佐，曹骁威

状态

草稿

类型

信息

创建时间

2021-09-16

摘要

我们预计通过该提案确定在 MegEngine 中所使用的 Tensor API 规范，以便符合一致的开发和使用理念； 并提倡现在开始为采纳《 数组 API 标准 》做好相应的准备，后者将允许用户写出更具移植性的代码。 在该提案中将阐明 Tensor API 和社区标准之间的差异点，以及补充说明社区标准中未明确的部分。

背景与动机

Python 用户可以选择各种不同的用于数值计算、数据科学、机器学习和深度学习的库和框架。 新框架几乎每年都在出现，百家争鸣所导致的一个后果便是基本数据结构 —— 多维数组（又名张量）的碎片化， 几乎每一个 API 都非常相似，但是它们之间又存在着足够的差异，导致用户很难编写适用于多个库的代码。

考虑到 NumPy 中所使用的设计和约束未必是最理想的，比如没有考虑到非 CPU 设备、基于图形的库或 JIT 编译器， 以及一些已有设计存在着副作用（比如基于值的类型提升规则），在一些情况下反而对库本身的开发形成了限制， 因此一些库在必要情况下选择了不遵循 NumPy 的部分设计，包括 MegEngine 也是如此。

Python 数据 API 标准联盟 在 2020 年发布了《 数组 API 标准 》，目前正接受社区审查。 它不规定任何有关如何实现功能的内容——只关心语法（如函数签名）和语义（预期输出是什么——形状、数据类型、数值结果） ， 而不是性能、算法选择或获得数值结果的精度。NumPy 在自己的 NEP 47 提案中表明了积极适配的倾向， 并提出了一些参考实现，但该提案在相当长的一段时间内仍将处于草案状态。 MegEngine 的 Tensor API 设计也应当考虑尽可能地与社区其它成员相互兼容，但也有额外需要关注的地方：

  • 上述标准并不能覆盖到 MegEngine Tensor API 的全部使用情景，如一些神经网络编程情景；

  • 必须尽力保障不向现有的 Tensor API 设计引入兼容性破坏（Breaking Change），这将被主要讨论。

基于以上背景，我们需要一份提案（或许在很长一段时间内也将以草案的形式存在），来确定当前的 Tensor API 规范。 而术语《数组 API 标准》更多用于指代目前正在处于发展阶段的社区标准，只是它当前还不够完整，无法被直接使用。 《数组 API 标准》某种意义上可以看作是 Tensor API 设计规范的子集， 我们将在本提案中讨论 MegEngine 将要如何支持社区标准，不遵循社区标准的部分，以及为了避免兼容性破坏可能采取的措施。

警告

由于《数组 API 标准》本身仍处于发展变化状态中，因此本 MEP 也有随时进行更新的可能性。

旧版 API 设计原则

以下为 MegEngine Tensor API 在设计之初所采取的基本原则：

  • 与数组科学计算相关的 API 设计，如果在 NumPy 中存在相应实现，优先以 NumPy 作为参考标准；

  • 与神经网络编程相关的 API 设计，如果在 PyTorch 中存在相应实现，优先以 PyTorch 作为参考标准；

  • 如果一些 API 在 NumPy 和 PyTorch 中都有实现，默认优先以 NumPy 作为参考标准；

  • 所有的 API 变更操作（包括新增），最终都需要经过 MegEngine API 委员会的审核。

另外，在 NumPy 中被认为不科学的 API 命名没有被 MegEngine 采纳，如 concatenate 被改为 concat. 上述原则已被模糊地实施了几个版本，但未形成详细的参考规范，因此在实施新的规范时，需要保证向后兼容。

另外，由于一些历史原因，Tensor API 的设计与 NumPy 之间也存在着不一致的地方：

  • 比如 NumPy 习惯将函数接受的输入位置参数命名为 x, 而在 MegEngine 中通常为 inp;

  • MegEngine 中提供的接口并不保证与 NumPy 完全对应，比如 dot 的实现；

这让我们的 API 设计无法脱离开 API 委员会的审核，由于缺少一份参考规范，给后续的维护引入了昂贵的成本。

采纳数组 API 标准

我们惊喜地发现，Python 数据 API 标准联盟发布的《数组 API 标准》与 MegEngine Tensor API 的设计哲学高度一致， 因此我们接下来将选择用其代替 NumPy 实现作为首要参考标准，并尽量避免引入兼容性破坏。

Tensor API 设计规范

以下是 Tensor API 设计时采取的基本原则：

注解

  1. 默认情况下，采用《 数组 API 标准 》以及 数组 API 标准补充说明 作为基本规范；

  2. 对于《数组 API 标准》中尚待形成标准的主题内容（TODO），采取如下原则：

    1. API 科学合理是首要追求，只有在几种参考选择仅仅是习惯上的区别时，优先级为 NumPy > PyTorch > 其它；

    2. 除 NumPy 和 PyTorch 外，应该总是全面地比较各框架/库的 API, 包括但不限于 TensorFlow, OpenCV 等…

一些还未被讨论的主题或许会在将来被纳入《数组 API 标准》，届时 MegEngine 中应当向标准靠拢，并保留该旧接口以免造成兼容性破坏。 例如由于目前尚未形成 random 的《标准》参考实现，而按照 Tensor API 设计规范的基本原则，目前应当参考 NumPy 中的 random 进行实现， 其中有：

  • numpy.random.permutation

  • numpy.random.shuffle

  • numpy.random.Generator.permuted

几个语义极为接近的 API. 如果将来的《标准》中提出了更加规范的定义，MegEngine 将实现新的接口，并保留旧接口调用。 另一种情况是，如果《标准》中对 NumPy 中的 API 进行了重命名，比如使用 concat 代替 concatenate, 那么 MegEngine 中将实现 concat, 并且在文档中仅向用户展示这种用法，旧的用法将不被推荐（但保证兼容历史用法）。

警告

任何 API Change 行为都需要在相关实现中给出参考标准，以便 API 委员会进行代码审核。

数组 API 标准补充说明

本小节主要用于讨论：

  • 一些《数组 API 标准》中尚未明确的主题，以及 MegEngine 目前打算如何做；

  • 由于向后兼容等历史性问题，MegEngine 的 Tensor 实现与《标准》不一致的地方;

  • 将来打算如何提供与《标准》中完全一致的实现。

现有 Tensor 实现的差异性说明

副本和视图，以及可变性（ Copy-view behaviour and mutability ）

对于该情况《标准》中没有做硬性要求，MegEngine 中的 Tensor 没有视图（View）这样的概念。 与 view 有关的操作虽然能提升效率，但在语义上加大了用户的心智负担。

警告

这不代表 MegEngine 中并不存在原地（Inplace）操作，以下行为依然是原地进行的：

  • 原地运算符（例如 *= ）

  • 元素赋值（例如 x[0] = 1 ）

但由于 MegEngine 没有视图的概念，一个 Tensor 上的原地操作一定不会影响另一个 Tensor.

数据类型与类型提升（ Data Types / Type Promotion Rules ）

  • 目前 MegEngine 中支持的数据类型可在 Tensor 数据类型 中找到，并未完全实现《标准》中要求的数据类型，例如 64 位数据类型和复数数据类型；

  • 混合类型提升在《标准》中是未定义行为，而在 MegEngine 用户指南中明确了相关行为。

函数与方法签名（ Function and method signatures ）

  • 位置参数必须使用 PEP 570 中规定的仅位置（Positional-Only）参数，语法为 / 符。 由于该特性仅在 Python >= 3.8 版本可用，而 MegEngine 目前仍需要支持一些低于 3.8 的 Python 版本。 因此现在的做法是在文档中以示例代码的形式为用户添加指导，要求用户以仅位置参数的方式去使用它们。 另一种方式是在文档字符串的第一行重载签名内容，参考 autodoc_docstring_signature .

  • 关键字参数必须使用仅关键字（Keyword-Only）参数，且保证向后兼容性。

  • 对于只有单个 Tensor 输入作为位置参数的函数，在标准中要求使用 x 作为输入位置参数的名字。 而在 MegEngine 中，部分函数签名中的输入已经被命名为 inp, 当前此类参数命名并不统一。 由于位置参数要求以仅位置参数的形式使用，因此位置参数的名称改动将不被看作是兼容性破坏， 后续会有相应的命名变更，使之符合《标准》的要求。

  • 为了可读性，《标准》要求类型注释被排除在签名本身之外，但是需要被添加到单独的参数描述中。 目前 MegEngine 中 API 的做法是签名中的参数都需要添加类型注释，而不要求写在参数描述中。

  • 《标准》参考示例中使用了 NumPy 风格的文档字符串，而在 MegEngine 中要求使用 Google 风格。

向后兼容性处理

NumPy 的主命名空间下已经实现了非常多的 API, 为了在采用《数组 API 标准》的同时不破坏兼容性， NumPy 在 NEP 47 中提出了添加一个单独的命名空间 numpy.array_api 的做法， 类似的做法也出现在一些其它想要采用现有 NumPy 标准的库或框架中（比如 jax.numpy ）。 而 MegEngine 在接口设计之初，并没有要求主命名空间与 NumPy API 完全对应，因此不存在这样的历史负担。

我们可以继续保留现有设计， megengine.functional 中将负责提供所有与 Tensor 相关的原子操作。 如果将来用户想要找到 numpy.array_api 中的对应接口，应当确保能够在 megengine.functional 中找到。

可能导致的问题是：

MegEngine 现有的一些接口和设计（未在当前《标准》提及）可能会和后续版本《标准》中的要求起冲突， 比如同一个 API 实现功能不同，或者在后续标准中要求统一支持视图操作，届时无法保证用法完全兼容。

可能的解决方案：

如果将来《标准》中对于一些概念有了更加具体的规定，或存在着相应的需求，导致无法处理向后兼容问题， MegEngine 中或许会提供 megengine.functional.numpy 与 megengine.functional.array 命名空间， 以寻求和 NumPy 以及 Array API 标准的高度统一。也有可能不采用新的《数组 API 标准》，锁定某一个版本。

关于 NN API 的讨论

目前 MegEngine 有关于神经网络编程的接口实现都存放在 megengine.functional.nn 命名空间中， 大都以 torch.nn.functional 作为参考标准（包括命名/分类规则）。 相关 API 在《数组 API 标准》中被划分为 misc functions 一类，尚未进行具体讨论。 以下是 MegEngine 在处理此类 API 时的基本思路：

  • PyTorch 中的一些 API 命名规则是不合理的，因此最终命名需要经过 API 委员会的审核。

    例如 Pytorch 中的 fold 和 unfold 两个接口， 在 MegEngine 中对应为 sliding_window 和 sliding_window_transpose. 这样的命名是经过研发人员和用户经过讨论后确定的，相关讨论应该被记录。

  • 由于 MegEngine 不存在类似 torchvision, torchtext 这样的领域细分库， 因此规定所有的神经网络领域概念相关接口均统一放在 functional.nn 命名空间 （具体实现的源代码文件如何组织不做要求，但提供给用户的 API 入口需要统一） 包括像 l1_loss 这样的接口，也统一使用 functional.nn 调用；

  • 相关 API 对比信息应当提供在 与其它框架 API 进行对比 页面，方便用户查询。

上一页

MEP 2 – 实验性 API 管理方式

下一页

开发环境设置