Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the state of C++ vs. Rust?

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 156 posts

Re: Ask HN: What is the state of C++ vs. Rust?

#121

Post by burntsushi »

Const-me wrote: post #119
burntsushi wrote: post #115

Earlier quoted context omitted.

Rust's regex library uses manually vectorized code to speed up its search algorithms, so it follows that Rust's type system is more than OK with such things.

They were lucky. Those regexps were OK only using a single register representation, u8x16. That’s not always the case. To write efficient SSE code, you need to understand __m128i is a just a hardware register, and use whatever representation you need for particular instruction. Example: http://stackoverflow.com/a/17355341/126995 The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the register…

It's not impossible at all. You can use the raw intrinsics in Rust just like you'd use them in C if you want to.

> The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2

That's false. It might be impossible to implement that code safely using the current simd crate as is (which is not in the standard library), but the simd crate is an abstraction over the raw intrinsics and isn't blessed by the language. You can reach in and use the raw intrinsics (or unsafely cast between SIMD types). If you look more closely at the SIMD algorithm in the regex crate I wrote, you can see that I'm already doing this (to convert from an `&[u8]` to an `u8x16` without bounds checks).

Popping up a level, I can understand why this is not obvious from an outside observer. The SIMD story on Rust is very much still evolving, and we don't have it all completely worked out yet. When we do, I predict it will be awesome. :-) I have a whole bunch of ideas on how to use it to improve text search even more!

Re: Ask HN: What is the state of C++ vs. Rust?

#122

Post by UtherII »

dom0 wrote: post #104
computerphage wrote: post #61

Earlier quoted context omitted.

One thing that's nicer is that because Rust is a compiled language, Cargo produces a (statically-linked ) binary. Python and your Python environment always needs to be set up on the machine that you're going to run it on. statically-linked by default except for on Linux where it links to glibc dynamically by default IIRC, but going fully static there is easy, and going fully dynamic is easy too.

fully static (including libc) can cause a lot of trouble on Linux. Static binaries (with system libc) on Linux are okayish, if all the systems are the same distro, or at least have a libc of the same vintage, but breaks frequently if you try to go further (eg. deploying to LTS distros like deb oldstable, centos, ...). Doesn't really compare to eg. Windows, where you just bundle the MSVCRT with the installer and unles…

That's why on Linux, by default, Rust link everything statically except the libc. But you sill can make a fully static executable by using the "musl" target.

Re: Ask HN: What is the state of C++ vs. Rust?

#123

Post by burntsushi »

the_why_of_y wrote: post #120
Const-me wrote: post #114

Earlier quoted context omitted.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

So very fast code in C is not actually C code, but written in a non-standard extended C dialect that is also platform specific - thanks for clarifying. I'm curious if there is a way to limit the entries in the Benchmark Game to just those that actually use only the language standards, where those exist...

To be clear, using SIMD doesn't require some "non-standard extended C dialect." We very much want a better SIMD story on Rust, and the benchmark game entries should definitely be allowed to use SIMD.

SIMD will get you into platform specific woes unfortunately, but that shouldn't stop us. :-)

Re: Ask HN: What is the state of C++ vs. Rust?

#124

Post by Const-me »

the_why_of_y wrote: post #120
Const-me wrote: post #114

Earlier quoted context omitted.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

So very fast code in C is not actually C code, but written in a non-standard extended C dialect that is also platform specific - thanks for clarifying. I'm curious if there is a way to limit the entries in the Benchmark Game to just those that actually use only the language standards, where those exist...

What are you talking about? Intrinsics are perfectly valid C99 code. __int64i is a union with 8 different arrays in it, and intrinsics are library functions.

Re: Ask HN: What is the state of C++ vs. Rust?

#125

Post by bjourne »

steveklabnik wrote: post #116
bjourne wrote: post #112

Earlier quoted context omitted.

But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is still significantly faster than Rust which follows that C++ is too" That is still true because we are discussing the current state of the languages and what you wrote does not affect that. Btw, the last time this topic was discussed we measured the performance using a microbenchmark. Here is the C version: https://gist.github.com/bjourne/4599a…

Yes, but you then also went on to say that no language will ever do it. Rust _has_ consistently beaten C on many of these benchmarks in the past, and continues to remain very close in the ones that it's not. I actually don't think microbenchmarks are a good way to think about performance anyway. There's two reasons: First, Rust's safety guarantees let you get away with more dangerous things. Consider scoped threads,…

No, I didn't say that no language will ever beat C. I can't predict the future. Rust has not beaten any highly optimized microbenchmarks that I know of. Like it beats C on the mandelbrot benchmark, but is then beaten by Swift, suggesting that the C implementation isn't very good (http://benchmarksgame.alioth.debian.org/u64q/performance.php...).

The reason we have micro benchmarks is because it is so hard to reason about the average case. Yes, code written in Rust could on average be faster than C due to its safety features. But so could Python, Java or Haskell so we're back were we started and can't say anything about relative language performance.

It's a small niche, yes, but some people absolutely need to squeeze out every gram of performance, and they should continue to prefer C over Rust.

Re: Ask HN: What is the state of C++ vs. Rust?

#126

Post by EpicEng »

kibwen wrote: post #84
EpicEng wrote: post #83

Earlier quoted context omitted.

>Furthermore, I attend Rust meetups all over the country and invariably meet people using Rust for various tasks at their job, even if their company doesn't choose to deliberately advertise itself as a Rust shop. Shocking that you would find people using rust at rust meetups. I'm sure they're a good representation of the programming sector as a whole.

No need to be so dismissive, my friend. The parent poster asked for references of people using Rust professionally, and I can confirm that I have spoken to many who do.

It's a bad reference, so I dismiss it. To be extreme, you may as well say the earth is flat because you met a bunch of people at a local gathering of the flatlander society who believe it to be true. Obviously people are going to be enthusiastic about rust if they're taking time from their weekends to go hang out with others to talk about it. It's just an irrelevant data point.

Re: Ask HN: What is the state of C++ vs. Rust?

#127

Post by the_why_of_y »

Const-me wrote: post #124
the_why_of_y wrote: post #120

Earlier quoted context omitted.

So very fast code in C is not actually C code, but written in a non-standard extended C dialect that is also platform specific - thanks for clarifying. I'm curious if there is a way to limit the entries in the Benchmark Game to just those that actually use only the language standards, where those exist...

What are you talking about? Intrinsics are perfectly valid C99 code. __int64i is a union with 8 different arrays in it, and intrinsics are library functions.

The words "SIMD", "intrinsic", "__m64", "__m128" do not occur in the C11 draft text; the word "vector" occurs once in example code for an array-with-length struct.

http://www.iso-9899.info/n1570.html

Intrinsics are not library functions - they would hardly provide the desired performance benefit if they were.

Intrinsics are "magic" functions that the compiler has built-in support for, and thus I would call them language extensions.

For example from GCC header avxintrin.h:

  extern __inline __m256d __attribute__((__gnu_inline__, __always_inline__, __artificial__))
  _mm256_permute2f128_pd (__m256d __X, __m256d __Y, const int __C)
  {
    return (__m256d) __builtin_ia32_vperm2f128_pd256 ((__v4df)__X, (__v4df)__Y, __C);
  }
Over here the word "__builtin_ia32_vperm2f128_pd256" occurs in the "cc1" and "cc1plus" binaries and "avxintrin.h", but nowhere else. Notably there is no externally visible definition.

Re: Ask HN: What is the state of C++ vs. Rust?

#128

Post by Const-me »

the_why_of_y wrote: post #127
Const-me wrote: post #124

Earlier quoted context omitted.

What are you talking about? Intrinsics are perfectly valid C99 code. __int64i is a union with 8 different arrays in it, and intrinsics are library functions.

The words "SIMD", "intrinsic", "__m64", "__m128" do not occur in the C11 draft text; the word "vector" occurs once in example code for an array-with-length struct. http://www.iso-9899.info/n1570.html Intrinsics are not library functions - they would hardly provide the desired performance benefit if they were. Intrinsics are "magic" functions that the compiler has built-in support for, and thus I would call them langu…

I don’t know why authors of GCC invented that non-standard extended C dialect, you better ask them.

In Visual C++, the prototype of that intrinsic is valid C99 code:

    extern __m256d __cdecl _mm256_permute2f128_pd(__m256d, __m256d, int);

Re: Ask HN: What is the state of C++ vs. Rust?

#129

Post by FT_intern »

vesak wrote: post #100
seren wrote: post #2

Rust is promising but C++ is here to stay. If you have a legacy C++ code base, it is much easier to sell that you are just upgrading the compiler to get new language features, that you are rewriting everything from scratch. Now we'll have to see in the next few years if, for new projects, Rust is chosen over C++ wherever it was used traditionally and in which proportion.

Java is promising but Cobol is here to stay. Kind of true, but one can rise in popularity while the other dwindles, even if not completely dying. Thing is that 90% of new developers who get to see both Rust and C++ will choose Rust.

but the companies that they want to work for have codebases in C++

Re: Ask HN: What is the state of C++ vs. Rust?

#130

Post by human_error »

pslam wrote: post #31
blub wrote: post #18

Wrong place to ask the question. HN has a high proportion of people with an unusual interest in trying out programming languages and I would say the average visitor doesn't particularly like C++. From my point of view, Rust doesn't offer any benefits that would justify a switch. I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something t…

* can I get a good job programming in this? Without moving to another country or continent. Yes, there are many large companies which are either actively deploying Rust, or planning to. Easily found if you search. * is my industry showing interest in it? Yes: security, high reliability, availability and safety oriented industries. Any industry looking to get themselves out of the entrenchment of C/C++ but still needs…

This is rubbish. You make huge claims without providing a single proof.
Post reply on HN