4 ms·

> 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: http

> 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
        Thanks! I am not a lawyer, nor was I directly involved in this, but I'll pass it up the tree.
        Const-me 8y ago
        I’m not a lawyer either, I’m a software developer; but I’ve been doing this long enough to develop certain degree of paranoia regarding patents and IP rights legal BS.
        steveklabnik 8y ago
        I hear you! Basically same here. I had not come across this one...
        burntsushi 8y ago
        I haven't either. FWIW, myself and one of your cohorts at Mozilla had a phone call with Intel (a while ago at this point), and while there were no lawyers on the line, the engineers we talked to sounded very happy about what we were doing.

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
      Thanks! I am not a lawyer, nor was I directly involved in this, but I'll pass it up the tree.
      - Const-me 8y ago
        I’m not a lawyer either, I’m a software developer; but I’ve been doing this long enough to develop certain degree of paranoia regarding patents and IP rights legal BS.
        steveklabnik 8y ago
        I hear you! Basically same here. I had not come across this one...
        burntsushi 8y ago
        I haven't either. FWIW, myself and one of your cohorts at Mozilla had a phone call with Intel (a while ago at this point), and while there were no lawyers on the line, the engineers we talked to sounded very happy about what we were doing.