为何Intel IPP部分函数不支持8s有符号字节数据类型

Intel IPP 通用函数普遍缺失Ipp8s（8位有符号字节）类型支持，是库设计阶段结合场景需求、优化成本、使用效率做的明确取舍，不是文档疏漏，具体原因可以归纳为三点：

• 实际场景需求占比极低
  8位有符号整数的动态范围仅为-128_{127，做数值计算时极容易溢出，在IPP覆盖的图像处理、音视频处理、通用信号处理、数据压缩等主流场景中，8位数据几乎都是无符号类型（`Ipp8u`，取值0}255，刚好匹配8位灰度像素、8位PCM音频采样的取值范围），需要直接对Ipp8s做排序、拷贝、算术运算的场景非常少。
• 多类型支持的优化成本过高
  IPP的所有性能敏感函数都是针对SSE、AVX、AVX-512等各代x86指令集做手写汇编级优化的，每新增一个数据类型支持，就要为所有支持的指令集架构单独编写、调试、测试对应的优化实现，还会增加函数动态分发的分支开销、加大库的安装体积。对于需求量极低的Ipp8s类型，投入产出比极低。
• 替代实现成本几乎可以忽略
  官方没有做原生支持的另一个重要原因是，开发者不需要依赖原生接口就能零成本/极低成本实现对应功能：
  • 对于Copy这类逐字节操作、不涉及数值语义判断的函数，直接将Ipp8s*类型的指针强转为Ipp8u*传入即可，两种类型位宽完全一致，内存拷贝的结果没有任何区别，没有额外性能损耗。
  • 对于SortAscend、SortDescend这类涉及数值大小比较的函数，只需要给每个Ipp8s值加128的偏移，将值域平移到0~255转成Ipp8u类型，调用对应8u版本的函数完成操作后，再给结果减128还原即可。平移转换可以用IPP现有8u向量接口批量完成，性能损耗可以忽略。

补充说明：目前Ipp8s类型仅在少数有明确行业需求的专用函数（比如部分定点数转换、特定8位有符号定点卷积实现）中提供支持，通用工具类、基础运算类函数基本不会覆盖该类型，这个设计从IPP早期版本延续至今，没有调整计划。

内容的提问来源于stack exchange，提问作者jonicho