为何多数FFT库采用Complex结构体而非实虚部分离双数组设计

核心原因全是硬性能约束，根本不是设计习惯问题：

• 第一是CPU缓存效率的硬要求。FFT最核心的蝶形运算单元，每一步计算都必须同时读写同一个采样点的实部和虚部。如果用Complex结构体存储，同一个点的实部、虚部在内存里是紧挨着的，会被加载到同一个CPU缓存行（通常是64字节），一次缓存读取就能拿到两个值；如果拆成两个独立数组，同一个点的实部和虚部地址间隔了整整一个数组的长度，几乎肯定落在两个不同缓存行，平白多一倍缓存失效开销。做千点以上的大尺寸FFT时，这种布局带来的性能差距能到30%以上，完全是不可接受的损耗。
• 第二是SIMD向量化的适配要求。现在所有高性能FFT实现全靠SIMD指令堆性能：不管是x86的SSE/AVX，还是ARM的NEON/SVE，硬件原生支持的复数向量运算，默认要求输入内存是实部虚部交错排列的格式——比如AVX一次并行算4个复数乘法，指令本身就期望输入是re0, im0, re1, im1...的连续布局，直接从Complex结构体数组加载数据就能直接喂给运算指令，不需要额外处理。如果用分离数组，每次做向量运算前都要插一堆数据重排指令，把两个数组里的值拼成交错格式，这部分重排的开销，比你想省的那点输入拷贝时间大一个数量级都不止。

至于你提到的实信号输入要转格式浪费时间的问题，其实库作者早就解决了，根本不算痛点：

• 所有正经FFT库都单独提供了实信号专用的FFT接口，根本不需要你手动把实数组转成复数数组。比如输入是纯实的音频采样数组，直接把数组指针传给实FFT接口就行，库内部要么做零拷贝处理，要么专门走利用实信号对称性的优化计算路径，计算量比通用复数FFT还小一半，完全不需要你提前构造复数数组。
• 就算你非要用通用复数FFT接口处理实信号，现在消费级CPU的内存带宽都有几十GB/s，1ms就能拷贝几十MB数据，对于音频这种单块最多几MB的输入来说，拷贝和虚部置零的时间占总处理时间的比例连1%都不到，根本不值得为了省这点边角开销，牺牲FFT核心运算路径的性能。
• 真要手动转格式也不需要写循环一个个构造Complex对象：只要Complex结构体是标准的实部在前、虚部在后、中间无内存填充（所有主流编译器对复数类型都是这个布局约定），你直接用memcpy把实数组拷到复数数组的起始位置，再用memset把后面的虚部区域批量置0就行，速度和纯内存拷贝差不多，根本没有你想的那么大开销。

当然也不是说分离实虚部的存储格式完全没用，在极少数需要连续批量操作所有实部、全程不碰虚部的场景下，分离布局确实有优势，但FFT的绝大多数使用场景都需要同时操作实部和虚部，交错存储的综合收益高太多，所以自然成了所有库的默认选择。

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