4 ms·

That instruction is SSE2. SSE2 instruction set is guaranteed to be supported on all x86-64 CPUs, be it Intel, AMD or VIA. Similarly, the intrinsics are support

That instruction is SSE2. SSE2 instruction set is guaranteed to be supported on all x86-64 CPUs, be it Intel, AMD or VIA. Similarly, the intrinsics are supported by all modern C and C++ compilers for decades already. Some compilers even generate SSE code by default for code like double x = 42.0 * y, in place of older x87 floating point instructions. x87 code is slower, and has multiple numerical stability issues.

steveklabnik 8y ago
A lot of this depends on the rules. For example, rust (rightfully) cannot use nightly, and unstable features. If it could, you could use these too. Rust will have these in the next stable release[1], so we’ll see after that ships! These intrinsics aren’t part of the C or C++ languages, but compilers provide their own, so it’s sorta like a language extension. Since they don’t use the same stability model Rust compilers do, it’s legal for them to use them. This generally means that C and C++ have a bit more leeway to use less stable/standard things. I think that’s a fine rule, given how the different languages work, but it’s a good example of how tricky all of this is. [1]: https://doc.rust-lang.org/beta/core/arch/x86/fn._mm_cvtpd_ps.html https://doc.rust-lang.org/beta/core/arch/x86/fn._mm_cvtpd_ps... and https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd_ps.html https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd...
- Const-me 8y ago
  > C and C++ have a bit more leeway to use less stable/standard things Here’s a link to the GCC header from 2002 that includes that _mm_cvtpd_ps intrinsic: https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269f8533b5690726512c1dfc#diff-cc7669063ed468bc1ab52f51b8e21ec7 https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269... If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. About standardization… I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. For example, by the time when ISO has adopted large parts of STL into the new standard, there was already a consensus in the industry that STL is the standard library.
  - steveklabnik 8y ago
    > If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. That's not what I'm saying, to be clear. What I'm saying is this: > I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. This is very true for C and C++, but less true for Rust. This means that, depending on how you define the rules, certain things are allowed or disallowed. Rust provides that exact same header, yet isn't allowed to use it. Rust is effectively limited to "what's in the standard," whereas C and C++ are not. I think that the rules the way they are makes perfect sense. I'm not trying to complain one or the other is hobbled here. I'm trying to point out how language differences can matter when trying to come up with good benchmarks.
    - Const-me 8y ago
      > This is very true for C and C++, but less true for Rust Right, Rust has essentially a single implementation, and its standard is written by the developers of that implementation. C++ standard is set by huge international standard-setting body with headquarters in Switzerland. That’s why authors of Rust specs are doing much better job keeping the spec in sync with the actual language and its libraries. IMO this difference is mostly about quality of the language standards, but is almost irrelevant to the actual language.
      - steveklabnik 8y ago
        Agreed 100%.
        Const-me 8y ago
        By the way, if you’re going to add SIMD intrinsics into the Rust standard, I think you better contact Intel and ask them whether they OK that. Or seek legal advice. According to google patents, Intel has 4537 patents related to SIMD. The reason why GCC is OK with their intrinsics, in 2002 they were put there by Intel employees. Intel obviously wants people to use them because this helps Intel sell their CPUs. But having them standardized can potentially decrease Intel’s profits by undermining these patents and enabling hardware and software emulators.

steveklabnik 8y ago

A lot of this depends on the rules. For example, rust (rightfully) cannot use nightly, and unstable features. If it could, you could use these too. Rust will have these in the next stable release[1], so we’ll see after that ships! These intrinsics aren’t part of the C or C++ languages, but compilers provide their own, so it’s sorta like a language extension. Since they don’t use the same stability model Rust compilers do, it’s legal for them to use them. This generally means that C and C++ have a bit more leeway to use less stable/standard things. I think that’s a fine rule, given how the different languages work, but it’s a good example of how tricky all of this is. [1]: https://doc.rust-lang.org/beta/core/arch/x86/fn._mm_cvtpd_ps.html https://doc.rust-lang.org/beta/core/arch/x86/fn._mm_cvtpd_ps... and https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd_ps.html https://doc.rust-lang.org/beta/core/arch/x86_64/fn._mm_cvtpd...

Const-me 8y ago
> C and C++ have a bit more leeway to use less stable/standard things Here’s a link to the GCC header from 2002 that includes that _mm_cvtpd_ps intrinsic: https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269f8533b5690726512c1dfc#diff-cc7669063ed468bc1ab52f51b8e21ec7 https://github.com/gcc-mirror/gcc/commit/d3ceaee1b851570b269... If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. About standardization… I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. For example, by the time when ISO has adopted large parts of STL into the new standard, there was already a consensus in the industry that STL is the standard library.
- steveklabnik 8y ago
  > If you think something that hasn’t changed in 16 years is unstable, I’d like to hear your definition of stability. That's not what I'm saying, to be clear. What I'm saying is this: > I don’t think the fact that ISO has standardized some parts of the language but not other is hugely important. This is very true for C and C++, but less true for Rust. This means that, depending on how you define the rules, certain things are allowed or disallowed. Rust provides that exact same header, yet isn't allowed to use it. Rust is effectively limited to "what's in the standard," whereas C and C++ are not. I think that the rules the way they are makes perfect sense. I'm not trying to complain one or the other is hobbled here. I'm trying to point out how language differences can matter when trying to come up with good benchmarks.
  - Const-me 8y ago
    > This is very true for C and C++, but less true for Rust Right, Rust has essentially a single implementation, and its standard is written by the developers of that implementation. C++ standard is set by huge international standard-setting body with headquarters in Switzerland. That’s why authors of Rust specs are doing much better job keeping the spec in sync with the actual language and its libraries. IMO this difference is mostly about quality of the language standards, but is almost irrelevant to the actual language.
    - steveklabnik 8y ago
      Agreed 100%.
      - Const-me 8y ago
        By the way, if you’re going to add SIMD intrinsics into the Rust standard, I think you better contact Intel and ask them whether they OK that. Or seek legal advice. According to google patents, Intel has 4537 patents related to SIMD. The reason why GCC is OK with their intrinsics, in 2002 they were put there by Intel employees. Intel obviously wants people to use them because this helps Intel sell their CPUs. But having them standardized can potentially decrease Intel’s profits by undermining these patents and enabling hardware and software emulators.