memset 在 32 位嵌入式平台上运行缓慢

Posted 2023-02-16

【中文标题】memset 在 32 位嵌入式平台上运行缓慢

【英文标题】：memset slow on 32-bit embedded platform

【发布时间】：2019-07-26 14:58:58

【问题描述】：

我正在嵌入式设备（STM32、ARM-Cortex M4）上进行开发，预计 memset 和类似功能会针对速度进行优化。但是，我注意到行为比预期的要慢得多。我正在使用带有 -O3 优化标志的 GNU ARM 嵌入式编译器/链接器（arm-none-eabi-gcc 等）。

我查看了反汇编，memset 函数一次写入一个字节，并在每次迭代时重新检查边界。

0x802e2c4 <memset>: add r2, r0
0x802e2c6 <memset+2>:   mov r3, r0
0x802e2c8 <memset+4>:   cmp r3, r2
0x802e2ca <memset+6>:   bne.n   0x802e2ce <memset+10>
0x802e2cc <memset+8>:   bx  lr
0x802e2ce <memset+10>:  strb.w  r1, [r3], #1
0x802e2d2 <memset+14>:  b.n 0x802e2c8

当然，可以通过使用 32 位写入和/或循环展开来加速此代码，但会以代码大小为代价。实施者可能选择不对速度进行优化以降低代码大小。

memset 标头和库包含在：

C:\Program Files (x86)\GNU Tools Arm Embedded\7 2018-q2-update\arm-none-eabi\include\string.h
C:\Program Files (x86)\GNU Tools Arm Embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\cmath

此问题与现有问题类似，但不同之处在于它针对的是嵌入式平台。

在 GNU ARM 嵌入式软件包中是否有现成的优化 memset？如果是，我该如何访问它？

【问题讨论】：

如果您使用 C++ 进行开发（如标签所示），您最好使用std::fill。这很有可能被编译器优化。

“newlib”C 库的 Source Code 已经针对速度进行了优化，并且可以进行 32 位写入。仅当内存地址正确对齐时才会触发此优化，因此请确保是这种情况。基于newlib 的GCC-ARM-Embedded 发行版中的libc.a 变体都使用了上述优化。您使用的是哪个发行版，您的源代码是什么，如何编译/链接？

@SergeyA std::fill 的性能和 memset 一样。为什么会期望它比 memset 优化得更好？

@devtk 因为 memset（除非内在）是库提供的一个函数，它是什么，它可以是通用的。当您使用std::fill 时，编译器可以在站点上进行优化。但是，我必须承认，我在尝试时没有看到对 Godbolt 的优化。

@Erlkoenig 我正在使用GNU Tools Arm Embedded，确切的版本在问题的路径中。链接器命令指定“-specs=nosys.specs -specs=nano.specs”等。它说它使用 newlib，但 memset 函数显然与您链接的不匹配。

【参考方案1】：

不确定 GNU Tools ARM Embedded 是否具有优化的 memset，或者如何通过链接器选项访问它，但可以在汇编中手动对其进行优化。在定义了这个之后，链接器使用了这个版本而没有抱怨重新定义的函数，这对我来说似乎很奇怪。整体速度提升约 9 倍（即此版本所需时间约为原始字节方法的 11%）。

// optimized version of memset
// we split up the region into several segments
//
// base_ptr
// * store single bytes
// mid1
// * store words, 4 at a time
// mid2
// * store words, 1 at a time
// mid3
// * store single bytes
// end
//
// For large buffers, most of the time is spent between mid1 and mid2 which is
// highly optimized.
void * memset(void * base_ptr, int x, size_t length) 
  const uint32_t int_size = sizeof(uint32_t);
  static_assert(sizeof(uint32_t) == 4, "only supports 32 bit size");
  // find first word-aligned address
  uint32_t ptr = (uint32_t) base_ptr;
  // get end of memory to set
  uint32_t end = ptr + length;
  // get location of first word-aligned address at/after the start, but not
  // after the end
  uint32_t mid1 = (ptr + int_size - 1) / int_size * int_size;
  if (mid1 > end) 
    mid1 = end;
  
  // get location of last word-aligned address at/before the end
  uint32_t mid3 = end / int_size * int_size;
  // get end location of optimized section
  uint32_t mid2 = mid1 + (mid3 - mid1) / (4 * int_size) * (4 * int_size);
  // create a word-sized integer
  uint32_t value = 0;
  for (uint16_t i = 0; i < int_size; ++i) 
    value <<= 8;
    value |= (uint8_t) x;
  
  __ASM volatile (
  // store bytes
  "b Compare1%=\n"
  "Store1%=:\n"
  "strb %[value], [%[ptr]], #1\n"
  "Compare1%=:\n"
  "cmp %[ptr], %[mid1]\n"
  "bcc Store1%=\n"
  // store words optimized
  "b Compare2%=\n"
  "Store2%=:\n"
  "str %[value], [%[ptr]], #4\n"
  "str %[value], [%[ptr]], #4\n"
  "str %[value], [%[ptr]], #4\n"
  "str %[value], [%[ptr]], #4\n"
  "Compare2%=:\n"
  "cmp %[ptr], %[mid2]\n"
  "bcc Store2%=\n"
  // store words
  "b Compare3%=\n"
  "Store3%=:\n"
  "str %[value], [%[ptr]], #4\n"
  "Compare3%=:\n"
  "cmp %[ptr], %[mid3]\n"
  "bcc Store3%=\n"
  // store bytes
  "b Compare4%=\n"
  "Store4%=:\n"
  "strb %[value], [%[ptr]], #1\n"
  "Compare4%=:\n"
  "cmp %[ptr], %[end]\n"
  "bcc Store4%=\n"
  : // no outputs
  : [value] "r"(value),
  [ptr] "r"(ptr),
  [mid1] "r"(mid1),
  [mid2] "r"(mid2),
  [mid3] "r"(mid3),
  [end] "r"(end)
  );
  return base_ptr;

处理 32kB 数据时的速度差异：

原始 memset：197045 个刻度（每字节约 6 个） 优化的 memset：22582 个滴答声（每字节约 0.7 个） 最大理论速度：16384 滴答声

最大速度为每 4 个字节 2 个滴答声（str 指令的速度）。

原始的 memset 需要 16 个字节的代码。新的占 98 个字节。

【参考方案2】：

链接没有-specs=nano.specs。这将使用 C 库的版本，其中包括 memset，它针对速度而不是大小进行了优化。这将引入许多其他功能的更大版本（通常的嫌疑人：printf 和malloc），可以通过额外的链接器选项再次优化。检查反汇编和链接器映射文件会有所帮助。