系统信息
- 我是否编写了自定义代码（而不是使用TensorFlow中提供的常用示例脚本）：没有
- 操作系统平台和分发版（例如Linux Ubuntu 16.04）：Ubuntu 18.04版
- 移动的设备（例如iPhone 8、Pixel 2、Samsung Galaxy），如果问题发生在移动设备上：不适用
- TensorFlow安装自（源代码或二进制文件）：来源
- TensorFlow版本（使用下面的命令）：2.3.1
- Python版本：3.6.9
- Bazel版本（如果从源代码编译）：3.4.1
- GCC/编译器版本（如果从源代码编译）：Ubuntu 7.5.0- 3Ubuntu 1 ~18.04版本
- CUDA/cuDNN版本：不适用
- GPU型号和内存：不适用
描述当前行为
在s390 x上测试//tensorflow/lite/micro:micro_allocator_test时，观察到分段故障。
在调试时，我发现SSE对齐有问题。日志中有多个警告：8 bytes lost due to alignment. To avoid this loss, please make sure the tensor_arena is 16 bytes aligned. TC在分配缓冲区时进一步失败，但似乎在处理警告并将kBufferAlignment从16更改为8时解决了该问题。
为了调试，我比较了英特尔和s390 x上的TC结果。
在MicroAllocator::Create中，对于kBufferAlignment = 16，英特尔和s390 x上的其他所有内容均相同，uint8_t* aligned_result = reinterpret_cast<uint8_t*>(((data_as_uintptr_t + (alignment - 1)) / alignment) * alignment);将aligned_result返回为(uint8_t *) 0x3ffffffe1e0，其中tensor_竞技场为(uint8_t *) 0x3ffffffe1d8，而在英特尔上，相同的结果返回(uint8_t *) 0x7fffffffd2b0，其等于tensor_arena或data_as_uintptr_t的地址。如果kBufferAlignment的值为8，则aligned_竞技场与tensor_arena相同。
虽然我无法确定s390 x的Tensor缓冲区是否应对齐到8字节或16字节的SIMD扩展，但将值更改为8有助于通过TC。该值影响多个TfLite Micro相关测试用例。
据我们所知，s390 x可以处理任何字节对齐。如果我们能找出这个问题的真实的原因，并且有人能从SIMD的Angular 来研究这个问题，那就太好了。
描述预期行为
Tensor竞技场不应因对齐而丢失任何字节的数据。
重现问题的独立代码
要重现此问题，只需使用以下命令运行测试用例：bazel --host_jvm_args="-Xms1024m" --host_jvm_args="-Xmx2048m" test --host_javabase="@local_jdk//:jdk" --test_tag_filters=-gpu,-benchmark-test,-v1only,-no_oss,-oss_serial -k --test_timeout 300,450,1200,3600 --build_tests_only --test_output=errors -- //tensorflow/lite/micro:micro_allocator_test个
其他信息/日志
一个公关提出了这个变化和其他竞技场大小相关的修复。该公关被拒绝和关闭，我被要求提出一个github问题，以进一步讨论这一点。公关参考：#45790。如果我们能找出这个问题背后的真实的原因，那就太好了。@advaitjain你能帮我标记一个能在这里提供帮助的人吗？谢谢！
7条答案
按热度按时间gupuwyp21#
嗨！我有一些想法。
硬件架构变化很大，可能依赖于更大的总线带宽（如128位）与存储器进行有效通信。在相关说明中，Ethos-U 55将需要Tensor竞技场起始地址（obs：竞技场本身，而不是单个Tensor）进行16字节对齐。如今，这由微分配器处理。Tensor舞台和单个Tensor对齐取决于同一参数（kBufferAlignment），因此需要将它们分开。这是一个小改动，但可能会增加复杂性。对于Arm Cortex-M的SIMD指令，16字节Tensor对齐不会影响SIMD操作，单词对齐很好。
关于内存节省的主题。如果我正确理解了这个问题，我们可能会在最坏的情况下每个运行时Tensor释放15个字节默认的贪婪内存计划器重用运行时Tensor。因此，* 竞技场的大小由任何同时使用的Tensor的最大组合大小来确定 *，因此，对于该特定的同时使用的Tensor组合，由于对齐而导致的最坏情况的丢失将是每个运行时Tensor15字节。
用语言来描述这一点是相当复杂的，因此我将添加一个用例：
如果我们使用人员检测演示作为示例，则第3层的a）输入和B）输出Tensor表示最大组合。最坏情况下的对齐损失将为30字节，a）为15字节+b）为15字节。这导致仅约0.02%（30/136000）总136 kB竞技场的内存增加。因此，我认为改变这个排列的好处会很小。让我知道你的想法。
关于你遇到的问题，我很遗憾没有任何意见。
efzxgjgh2#
感谢@freddan80让这个更容易理解。我完全同意你的观点，在这种情况下，改变这个对齐方式的好处将是非常小的。在s390 x的情况下，据我所知，该架构可以处理任何字节对齐。尽管TC失败，我开始怀疑改变kBufferAlignment的效果。
也许，正如你提到的，我们需要将kBufferAlignment拆分为Tensor竞技场和单个Tensor对齐。我注意到，为了填充输出ArenaTensor，分配是从尾部完成的，但由于flatbuffer向量是LE格式，首先以BE格式读取Tensor这个过程看起来很复杂，好像又增加了字节对齐的问题。大字节序系统是否存在潜在的问题？
只是一个额外的信息，为了获得一个成功的结果，我确实必须增加竞技场_size以及测试用例。
j91ykkif3#
@skribm9关于BE系统的有趣观察。@advaitjain，你知道以前是否在BE系统上运行过测试吗？
s4n0splo4#
你有时间来看看这个问题吗？
nuypyhwy5#
很抱歉延迟了这么长时间@skribm9。是的，我猜这里有一些BE系统特有的东西。不幸的是，我们目前没有周期来研究BE支持，它一直是临时的，未经测试。
与当前实现代码的方式不同，我在这里的首选项是：
@skribm9，让我知道这个方向听起来是否合理，如果这是你有兴趣贡献的东西。
nzk0hqpo6#
感谢您的回复@advaitjain。我同意您的观点，flatbuffers只支持小端字节序，并且在其他几个测试用例中也会出现问题。我们讨论了Tensorflow服务代码，社区友好地同意对flatbuffers相关代码进行更改，以确保它支持小端/大端字节序转换和部署的所有潜在排列。这一点正在45009下进行跟踪
如果您认为与flatbuffer相关的更改也可以帮助解决此TFLM问题，我们当然可以等待该问题得到解决。
8ehkhllq7#
由于测试用例
//tensorflow/lite/micro:micro_allocator_test已移出tensorflow/tensorflow存储库，因此可以关闭此问题。