# SIMD performance question

**URL:** <https://forums.swift.org/t/simd-performance-question/10285>\
**Category:** Using Swift\
**Created:** [February 24, 2018, 11:26am UTC](https://forums.swift.org/t/simd-performance-question/10285 "2018-02-24T11:26:37Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\
**Post date:** [February 25, 2018, 5:44pm UTC](https://forums.swift.org/t/simd-performance-question/10285/2 "2018-02-25T17:44:28Z")

</div>

> [@Jens](#):
>
> I would have expected [`simd_fract` to be faster than `x` - `floor(x)`].

The definition of `simd_fract(x)` is precisely "`x - floor(x)` clamped to `[0,1)`" (`fract` is defined this way because without the clamp, `x - floor(x)` produces `1.0` for tiny negative numbers, which breaks some algorithms). Why do you expect it to be faster _with_ an additional clamp? (I'm genuinely curious, because it seems like a documentation bug if this isn't clear).

As for the lack of difference between `fast_recip` and `precise_recip`, the argument to the function is a compile-time constant; I expect that the optimizer is able to propagate it through so that neither is actually evaluated at run-time. I'm not set-up to test this right now, but a quick glance at the disassembly would confirm.

---

_[View the full topic](https://forums.swift.org/t/simd-performance-question/10285)._