SSE 优化代码的性能与普通版本类似
我想迈出使用英特尔 SSE 的第一步，因此我遵循了发布的指南 此处，区别在于，我不是为 Windows 和 C++ 开发，而是为 Linux 和 C 开发（因此我不使用任何 _aligned_malloc 但posix_memalign ）。
我还在不使用 SSE 扩展的情况下实现了一种计算密集型方法。令人惊讶的是，当我运行该程序时，两段代码（带 SSE 的代码和不带 SSE 的代码）花费的运行时间相似，通常使用 SSE 的代码的时间略高于另一代码的时间。
这正常吗？ GCC 有可能已经使用 SSE 进行了优化（也使用 -O0 选项）吗？我也尝试了 -mfpmath=387 选项，但没办法，还是一样。
I wanted to take my first steps with Intel's SSE so I followed the guide published here, with the difference that instead of developing for Windows and C++ I make it for Linux and C (therefore I don't use any _aligned_malloc but posix_memalign).
I also implemented one computing intensive method without making use of the SSE extensions. Surprisingly, when I run the program both pieces of code (that one with SSE and that one without) take similar amounts of time to run, usually being the time of the one using the SSE slightly higher than the other.
Is that normal? Could it be possible that GCC does already optimize with SSE (also using -O0 option)? I also tried the -mfpmath=387 option, but no way, still the same.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于浮点运算，您可能看不到 SSE 的巨大优势。大多数现代 x86 CPU 都有两个 FPU，因此双精度 SIMD 与标量的速度可能大致相同，而单精度可能会为 SIMD 提供比标量快 2 倍的速度。但对于整数运算，例如 8 或 16 位的图像或音频处理，您仍然可以通过 SSE 获得巨大的好处。
For floating point operations you may not see a huge benefit with SSE. Most modern x86 CPUs have two FPUs so double precision may only be about the same speed for SIMD vs scalar, and single precision might give you 2x for SIMD over scalar on a good day. For integer operations though, e.g. image or audio processing at 8 or 16 bits, you can still get substantial benefits with SSE.
GCC 有一个非常好的内置代码矢量化器（iirc 在 -O0 及以上启动），因此这意味着它将在任何可以使用 SIMD 的地方来加速标量代码（它也会稍微优化 SIMD 代码）如果可能的话）。
很容易确认这确实是这里发生的事情，只需反汇编输出（或者让 gcc 发出注释的 asm 文件）。
GCC has a very good inbuilt code vectorizer, (which iirc kicks in at -O0 and above), so this means it will use SIMD in any place that it can in order to speed up scalar code (it will also optimize SIMD code a bit too, if its possible).
its pretty easy to confirm this is indeed whats happening here, just disassemble the output (or have gcc emit commented asm files).