6 ms·

C/C++ are cheating by using Intel specific instructions, like _mm_cvtpd_ps. I.e. they are with hardware-specific acceleration. If standard library will be used

C/C++ are cheating by using Intel specific instructions, like _mm_cvtpd_ps. I.e. they are with hardware-specific acceleration. If standard library will be used instead, or if Rust code will be updated to use same instructions, we will see different results.

p0nce 8y ago
If you use a LLVM compiler, _mm_cvtpd_ps just translate to LLVM IR and is not Intel specific anymore.
- giancarlostoro 8y ago
  They're using g++ though, afaik that's just using GCC is it not? But good catch altogether.
Const-me 8y ago
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.

p0nce 8y ago

If you use a LLVM compiler, _mm_cvtpd_ps just translate to LLVM IR and is not Intel specific anymore.

giancarlostoro 8y ago
They're using g++ though, afaik that's just using GCC is it not? But good catch altogether.

Const-me 8y ago

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.