Ask HN: What is the state of C++ vs. Rust?
I would love to hear the thoughts of people who have kept up with the developments in both these languages.
Some of the stuff I'm wondering along is features, safety, performance, simplifying the language and so on.
C++11/14 brought good things to the table, perhaps C++17 will bring more improvements?
I havent gone through the proposals for upcoming features in either language but seems like the pace of Rust development is really good.
But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether.
Just curious to hear anyone's thoughts on the state of these two languages.
155 comments
[ 3.7 ms ] story [ 179 ms ] threadIf 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.
In my experience I find Rust to be more productive than C++ and easier to write. Obviously that's a pure opinion.
However, in big organizations, which are not exactly nimble, this is even hard to say, "Okay we've been developing in C++ for 20 years, now the next part of our infrastructure will be written in Rust".
This will be seen as an unwanted risk, associated with a training cost. You will have to demonstrate unequivocally Rust's advantage.
There are long lists of dead languages still in legacy systems, C and C++ aren't there yet, but I think they are headed that way.
I tend to agree with you (and I'm a big fan of Rust), but I'm nearly certain I heard people saying exactly that ~20 years ago. I don't remember which was the language that was expected to replace C/C++, perhaps Java or Obj-C or perhaps some variant of ML. So far, it hasn't quite happened.
While C/C++ seem to have become much more niche languages in these ~20 years, I suspect that they won't become legacy language any time soon.
Now, I may be wrong. Maybe some revolutionary Rust-base game engine (VR engine? IoT platform?) will shift the landscape drastically any day now, but that's hard to predict.
On the Apple side of the fence, C++ was mostly used for IOKit with everything else that wasn't inherited from UNIX, being Java or Obj-C.
Only later on they decided to drop Java, focus on Obj-C and their C++ usage only increased when they decided to sponsor LLVM and move their toolchains to it.
Now we have LLVM as one of the major research compilers available, including for Rust, with all three major desktop companies sponsoring it.
However I think this is probably the area where they will stay, systems programming infrastructure.
Is that truly easy? I would expect all kinds of incompatibilities that would require going through a C layer (object layout, difference in virtual method calling, object ownership, etc). For example, calling a C++ function that takes a pair of iterators from Rust and returns a std::map, passing iterators pointing into a Rust hash table, is that easily done?
Take a look at the rust ffi omnibus that I posted in this thread. It's object examples show some decent strategies.
Getting into C++ now is harder then getting into Rust.
I've heard people stating that C is gaining more ground that C++ and it could be for, I imagine, similar reasons.
The poster asks whether new C++ will bring more improvements. It will certainly bring more... "more". And with it, the bar to entry is raised a little more; every new feature designed to resolve some issue or edge-case with a previous addition.
Mozilla seems to put much time into getting the community right, which will get much younger people on board. Then time will do its thing.
Thing is that 90% of new developers who get to see both Rust and C++ will choose Rust.
I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or have a worthy alternative.
That is I think Rust really needs a killer app/platform/problem similar to how Swift has Apple devices and DevOps now have Go.
If Rust could get into a gaming platform or have a really good gaming library like Unity it could have a good starting point to move over mind share.
Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had).
Rust's current niche (ie users) is language aficionados which historically hasn't been a good niche (ie Haskell) for language propagation. That is I think Rust could get more popular if it can get heavily used by a set of niche users at first.
Besides mircoservices and games an interesting niche might be Arduino and IOT [1]. That might be a good niche/platform to dethrone C++.
[1]: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...
It's built around futures and mio, so Tokio services are async, and elegant.
I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, etc. Building something in Rust would be much more painful.
That being said one would argue if you are going the microservices route you shouldn't need an exceptional amount of routing anyway. You only need to really handle raw HTTP for the most part (also I would not say HTTP is the end all for microservices... I have been using a Rust AMQP library with some success [2]).
Also although Go has green threads it is still debatable if that is the right way or golden way particularly when so many backends like databases (e.g. postgres) can't handle async (tons of connections) anyway. Old school one thread per request libraries in Java like dropwizard can still do fairly well. I think Rust made the right choice with native threads and hopefully some interesting green thread or reactive libraries will come forth soon (or already here ... haven't googled it).
Also I'm just not sure I really buy into Go's channels but that is just a personal opinion at the moment.
[1]: https://youtu.be/pTQxHIzGqFI?t=964A
[2]: https://github.com/Antti/rust-amqp
I think the sweet spot with rust might leveraging metaprogramming, for instance, generating a REST database API from a schema and having the resulting code compile to something faster the most languages like python or ruby, and at least on par with Go, Java, or swift.
Go may have more of those things and it may be easier to find copy-pastable examples for them, but rust has them too, and its not painfull. The things you mentioned are there and are working fine.
http://www.arewewebyet.org/
I've done most of my web service work in either Java or Go, but I'd like to give Rust a try for comparison at some point.
Edit: I meant to say that I have heard from many of them that the content of that is outdated and in need of an update. There was talk of the community taking it over but I don't have the latest on that.
For actual examples of using Rust with other languages through these libraries this site is great: http://jakegoulding.com/rust-ffi-omnibus/
[1]- https://github.com/carols10cents/rust-out-your-c-talk
[2] - http://jakegoulding.com/rust-ffi-omnibus/
Since C++ has been around much longer the situation is likely "many C++ experts try Rust, the ones that love it become Rust experts", basically if "preferring Rust" ends up being a soft prerequisite to becoming a Rust expert then those who are experts in both will prefer Rust.
I also think there's a bunch of other factors that lead to a similar bias: general pride in favor of the less mainstream languages, for languages like Rust or Haskell it is probably the case that more of the code in that language is written by "hardcore" people, which means code written in that language is higher quality (but not necessarily through any intrinsic benefit of the language, instead through a selection of who is writing that language).
I'd say that such selection is intrinsic benefit of the language.
First, please be careful with the "experts" broad brush. Not all, and possibly not most, experts will agree on many things. Moreover, actual experts will understand that there are pros and cons that are context dependent. I would hesitate to label as "expert" anybody who categorically prefers one over the other for all cases. That's more like zealotry than expertise.
Second, for my part the biggest hurtles are in two parts. One is that at the boundaries of speed versus provable safety. At some point I don't need and can't afford the cycles added by boundary checks and other Rust guarantees, and the mechanisms provided to mitigate them are as cumbersome as writing (unprovably) safe C++ code (e.g. "const&", "std::move" and other similar constructs) compared with the equivalent Rust. The other is a more a branding problem: gratuitous maligning of C++ is problematic, and projects a sort of arrogance that I find subjectively distasteful.
As with anything, some people who like Rust might get a bit enthusiastic about discussing its benefits compared to other languages, but this is frowned upon and IME usually called out, especially in spaces with some sort of "official" Rust moderation presence.
Anecdotally, Rust developers are the only group I've interacted with that consistently focus on the positives of other languages when discussing different features or concepts, while acknowledging the tradeoffs and clearly outlining the reasoning behind Rust's choice.
While I'm impressed with the changes in modern C++11/14/17, it has both the feature and problem of still including classic C and C++. There's a reasonable subset of C++ to program in, but nobody can quite agree on what that is, and a codebase can't easily enforce that. And C++ is still a very large language, with quite a bit of surface area in the language itself; I prefer a smaller language with a large library ecosystem.
Rust is still quite young. It's incredibly fun to program in, has the most welcoming community I've ever seen, and can help you write safe, expressive, high-performance code. (Tip: check out the "rayon" crate for incredibly easy parallelism.) It has an extensive library ecosystem, and a robust FFI to call (or be called by) C code. However, depending on what you're doing and and how many boundaries you're pushing, you may find some corners of the language still under active development; for instance, if you want to embed some Rust code into a broader build system that builds various other components under other languages, support for that just went into Cargo.
If you're writing pure Rust code, or Rust code that calls out to C, you should find the language and ecosystem ready now. If you're trying to embed Rust into an existing project, expect to play with various experimental bits for a while.
I think this is the reason why Java is so popular and Go is becoming increasingly popular. The average programmer can succeed with combination and become productive faster.
1. No memory corruptions/null pointers. Legit holds up to the promises here.
2. The path of least resistance is single-ownership which is far and away the best way I've seen to structure C/C++ applications.
3. Cargo: Pure awesome. Simply one of the best dependency management/build tools I've used.
4. Dead simple x-platform support. Windows, Linux, all just works. Heck I just built an android arm-eabi target yesterday on windows with no NDK/etc.
5. Tagged unions, pattern matching. The best effing iterator class I've seen bar none. Once you've used these you don't want to go back.
6. Great built-in unit testing support(combines with Cargo above).
7. Amazing community, no ego and tons of people happy to help.
I still work regularly on C++0x11 codebases but any greenfield stuff I've moved over to Rust fulltime.
I still like C++ but it's so much more painful to use. Heck just earlier today I got bit by <locale> not compiling on OSX due to some obscure compiler differences that worked on MSVC and GCC. There's certainly good improvements coming to C++ but they have to support so much legacy code that I don't think they could ever make the large breaking changes that Rust has to produce a better experience.
As far as I can tell, you have two files in both systems: One with the dependencies you'd ideally like to use, and one with the ones you actually used (and tested with). That way, you can update when convenient, but people who get your software have an exact known good environment.
What makes Cargo that much better than pip-tools?
I haven't used pip-tools, but I have used pip, npm, bower, and other more modern dependency mangers that work for non-systems programming languages. Cargo has never given me any trouble. Pip has occasionally given me weird issues about things not being installed in the right places or on my path. NPM regularly required `rm -r node_modules` and starting from scratch. Bower has had the same trouble as npm. It's not that these tools don't work for me, I've always been able to google the error message and find someone with the same problem. It's that Cargo has never given me an error message that wasn't my fault like "This package doesn't exist" when it's a typo. It just works.
You're right on the dependencies, there's a lock file to make sure you get the exact build environment. So from a dependency management perspective it sounds similar.
What I like about Cargo is it's just slightly opinionated about how you want to build a Rust project. Creating a new project is as simple as "cargo new myproject" and boom, away you go. Same thing with unit testing, running all tests in a Rust project is as simple as "cargo test".
If you've worked on a moderately large C/C++ codebase you'll know that those two things alone can be a huge source of annoyance.
It also makes it really easy to install Rust-based tools like racer/rustfmt/etc with "cargo install <tool>" which pulls the source, builds and puts the executable on your path.
In short, all the annoying stuff around project management that in C/C++ is neatly handled into a few short commands. In my mind it's a huge productivity win.
I agree that being opinionated is a big help. Everyone in Python-land uses virtualenv and pip, but it would be great if (as is actually happening now), they were bundled with the language and were the One Blessed way of creating a new project:
virtualenv myenv
source env/bin/activate
pip-compile requirements.in
pip-sync requirements.txt
Rust does get a few benefits from being statically linked, but yes, I see now that people compare cargo to mostly C/C++ tooling, and not to something like Python, thank you.
`pip` and Python are riddled with problems. Native modules fail to compile all the time and since Python is so slow, it requires a lot of native code. python2 vs python3 share `PYTHONPATH` and `virtualenv` is inheriting it: http://stackoverflow.com/questions/24583777/why-does-virtual... which leads to many weird problems.
Not to mention some python stuff is not available on `pip` (like PyQt, last time I tried).
Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D
Python software really works only in it's developer sandbox, or when very carefully prepared by Linux-distribution maintainers. Otherwise it's a mess.
Part of the reason why Docker got so popular was because it solved an impossible task of running several separate programs written in Python reliably side by side, on many boxes. Since it works reliably only in developer's sandbox, we now ship the whole sandbox and call it "application container".
I've gave up on using any software written in Python on my boxes. I just avoid it. Not to mention that Python software rarely works reliably...
> Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D
You don't need to activate a virtualenv to run an application from it. Eg. some_virtualenv/bin/some_binary just works, regardless of other active virtualenvs or what Python/Java/C program invokes that.
And maybe this bit here:
> So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install?
The commands he mentioned would be used to create a new project, not to install anything.
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.
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 unless you're API incompatible the application will just work everywhere.
... but that's not due for another year!
Many compilers are already supporting a number of C++17 features, and by the time the spec is out it might be almost complete for most major vendors.
http://en.cppreference.com/w/cpp/compiler_support
C+0x was what turned into C++11. The 0x part was just a placeholder for 08 or 09, but it actually ended up taking a few years longer to ratify.
Maybe people confuse C++11 with C++0x to get C++0x11.
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 that's not a particularly pressing issue for me.
Furthermore, I think many developers obsess about languages and keep searching for a perfect language that doesn't exist and even if it did wouldn't have a big impact on productivity and the business anyway. The major challenges in organisations are of a social or process nature.
They're also biased in a surprising way by social factors such as who created a PL or the community. Meanwhile PHP, Java, C++ and C# and C make the world go round.
Key questions for me when evaluating whether to learn Rust (or any language):
* can I get a good job programming in this? Without moving to another country or continent.
* is my industry showing interest in it?
* is any industry showing interest?
The answer to all these questions seems to be "no".
As with each case, it depends. If you've got a well scoped project that is happy with a C ABI(or just stand alone exec) I think there's a compelling case for Rust.
I'd also argue if you're looking for top candidates having Rust in-house could be a perk rather than a negative.
Yes, there are dozens of companies doing some project in Rust. That's true for almost any programming language.
I am guessing that it's going to be another 5-10 years until I would need to seriously consider learning Rust, assuming it will be able to break into the mainstream.
Safety-wise it could make sense for my industry, which seems to be overwhelmed by C and C++ (see Toyota).
However, the point I was making is there's not a binary switch between C/C++/Rust. There's a great interop/FFI story that allows a targeted/gradual adoption.
Learning a new language though is not a wasted effort, even if eventually the language becomes obsolete. It only takes a few days to get going with something new, and the lessons learned are useful regardless of if you use the language in the future or not.
But to say that there's no interest at all is pretty ridiculous, and there's plenty of people looking at rust and deploying it. That last statement made me feel you might just be a bit burnt out by change in general. Don't lose perspective. Going out of your comfort zone might be exactly what you need.
In contrast I finished an architecture course recently that I expect will bring me 10x value of knowing both of the above languages.
Please see my answer to vvanders regarding interest vs industry interest.
Reading the book should be a very useful first step when learning about architecture.
If one decides to go to the course it's essential that there are also experienced architects participating and that one has an architectural case study that can be discussed.
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 at least one of the major reasons why it persists.
* is any industry showing interest?
I haven't found any industry, primarily focused on software development, which isn't interested. I've been actively poking around to see which way the wind is blowing. I honestly haven't come across any industry which would actively say "No we're good with C", other than those were software is an annoyance which they grudgingly have to be involved in.
[1] http://stackoverflow.com/jobs?sort=i&searchTerm=rust
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.
We also have a large internal list of contacts at companies using Rust (publicly or otherwise) that we use to schedule periodic conference calls to discuss the needs of production users in order to prioritize language development (e.g. Dropbox and Mozilla really, really want faster compile times, which is why that's been a determined focus for this cycle).
Overall we're quite encouraged by how many folks are willing to use Rust in a production capacity considering how young and unproven the language still is. :)
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.
The standard here is not to LMGTFY every few words.
Rust could have absolutely 0 memory safety features over C++ and it would still be a massive improvement over the mess that is C++ package management and build systems with Cargo. Same is true for many other features. It's not quite there yet in terms of maturity and adoption but there's significant momentum and interest from big players that learning it now will likely put you in demand in a few years.
This black and white thinking is just a sign of immaturity, not of knowledge of a deeper truth.
All mainstream languages are capable of delivering business value. I happen to prefer certain characteristics that led me to C++, but I also found Java to be quite fine. I don't think I'd mind doing PHP or even JS for an interesting project. I've done both in the past.
I'm not saying we should be completely dispassionate about our tools, it's normal to have likes (I do like C++). But hating languages is rather pathetic and unhealthy.
> The answer to all these questions seems to be "no".
In conclusion you shouldn't be learning it and good luck to the company trying to hire people for Rust positions?
You're saying you should only learn what the industry is pushing towards. The thing is that the industry is pushing towards what sort of talent they can acquire - this is a vicious cycle.
If there's a worthwhile project that I want to contribute to, I will learn Rust. At least in automotive the industry is not necessarily pushing towards specific tools, they have constraints that limit choices to particular languages.
Let's see if that first mover decides to show up.
May i ask why memory issues are not a pressing issue for you? having to hunt down memory corruptions / access to dangling pointer / memory leaks is a pretty frequent occupation for me (as a C/C++ developer). There are tools like valgrind that help, but well, it is a pain to deal with these issues.
This is not as reliable as Rust's compile-time safety checks, but in practice it works well enough for me. I don't think this is typical for all C++ projects or programmers e.g. I am not particularly impressed by the (little) Firefox code I've seen.
I hope C++ continues to evolve safety features and get closer to Rust's guarantees. I don't think automotive or aviation will switch too soon.
In my numerous-though-irregular years as a C++ programmers, I haven't seen any project producing code that's convincingly safe. I won't list all the pitfalls of C++ here, but, well, who doesn't have war stories of bugs-because-of-aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-pointer-is-still-being-used-after-its-mutex-has-been-released, bugs-because-collection-has-somehow-been-mutated-during-traversal, etc? I have reached the point where I feel I can't trust any non-trivial C++ code, so I gladly switched to Rust for all my new non-webdev projects.
But back to the question, I would be really happy to see convincingly safe C++ subsets in action. I certainly hope that this would improve my life as a C++ developer, at least for future projects. As a side question, I wonder how many C++ developers actually produce such code.
Also, I just realized that doing this right might require dropping lots of legacy C++ code, more or less as would starting in Rust.
What about a team? If you are leading a team of programmers, would you rather use Rust (where finding if the code is doing anything unsafe using a simple grep) or C++ where finding dangerous code is a lot harder?
I think the point of using langauges like Rust and Haskell only comes into play when the development is done by a team. It is one thing to hope that every one in your team is as disciplined as yourself (including yourself on a bad day), and knowing for certain that the language won't allow bad stuff to happen...
We can't start using any languages we want, we have to consider industry standards, resource availability and other constraints.
especially if you are dealing with a large code base with shifting requirements, where the code has been written over a long time by a lot of people; in a real world system you just can't make these assumptions regarding 'skill' at all. Even skilled people will have to deal with issues like invalidated iterators / containers that have been modified in non obvious ways / lots of other goodies as well.
there are a lot of projects/products like this, my guess is that this is the case with the majority of projects.
Now good luck solving that with smart pointers and reference counting, etc.
I've worked on C++ codebases where I just never spent any time on this stuff, at all.
I've worked on C++ codebases where I just never spent any time on this stuff, at all.
Some bad news for you though: all automotive companies typically use the same tools and processes. Aviation is also like that. And they use a ton of C and C++.
I am totally fine with a high level tool emitting C. C is a fine portable target. But the high level system should pass some provable rigor.
Just last week I had to land a pretty major refactoring (swapping out a single wrapper type for a differentiable "operator" with an implicit operator graph instead). It basically just worked out of the box as soon as I got it to compile. Definitely something to be said for working _with_ the compiler and its messages on moving, borrowing, mutability etc. (Incidentally, if I had to program exclusively in C++11/14, thanks to Rust I'd have become much better at programming in C++.)
* N-D dense arrays, fashionably simply called tensors these days ;) (this I wrote from scratch to suit my own needs, but there are several implementations of this in Rust, as well as in C++)
* linear algebra (bindings to BLAS, LAPACK etc.)
* numerical integration (bindings to GSL or QUADPACK)
* optimization and machine learning (this I work on day-to-day)
* neural networks (I also work on this)
* multicore/manycore/GPU/distributed support (and this)
There's also the more practical aspects of using Pandas/iPython (Jupyter)/Spark for data science, including ETL, interactive work, and plotting, which IMO are not quite there yet in the Rust ecosystem. But I think that a lot of the pieces are there, e.g. bleeding fast CSV parsing libraries (https://github.com/BurntSushi/rust-csv), and what's left is the important last mile of bringing these things together in ergonomic libraries or frameworks.
There is no "ignoring legacy C++", when you will have to deal with this or that library written 10/15 years ago. C++ is a language where you can't just ignore some parts of it just because they are inconvenient.
As for C++ vs Rust, Rust is memory safe, C++ is not and will never be despite all the bells and whistles it gets.
On my daily work I get to use JVM, .NET and C++.
Although my C++ usage is restricted to giving a little help to JVM or .NET applications, if at all required, which happens very seldom.
Here is where I still see Rust lacking, due to the language being young.
On those platforms the vendor's tooling supports mixed debugging, out of box integration with their platform libraries and a few other goodies.
For example, for UWP applications Rust tooling is still catching up with C++/CX and C++/WinRT.
Modern C++ does feel like a rejuvenated language, but the problem is that you require a team that is willing, or able, to force it across their code.
Otherwise you just get a mix of C++98, C++03, C++11, C++14, C++17, depending on which library you are looking at. Not to mention having to get your head around meta-programming tricks like SFINAE, as workaround for many of the C++17 features.
So although Modern C++ feels good, there is the question when one takes a C++ at random company X, how much they are allowed to actually use from it.
So I think a reboot into new systems programming languages is required, and Rust is one of the possible candidates.
Which will surely get its place.
There's been some talk for a long time of a rust oracle for code indexing (to support ide use), but there hasn't been much progress (or interest?).
Rust's promise is if it compiles it's probably good code, as that compiler is exceptionally picky. Most common C++ errors that cause "undefined behaviour" are not possible due to the strict checking.
Aliasing rules in C make some optimizations not possible in C. Good luck putting that `restrict` everywhere to compensate. Generics with static dispatch makes it possible to get a code that is way better than what a sane person can write with C's preprocessor. Practical developer will very often sacrifice performance for sanity in C codebase. Memory safety makes it easy to write correct, reliable multithreaded programs in Rust and actual package manager makes it practical to reuse well-written and optimized code.
Even if there are some microbenchmarks where C gives better results, it's because Rust version doesn't "cheat" by using `unsafe` constructs. Essentially in Rust one can write functionally exactly same code that C uses, including inline asm etc. which is useful for performance-critical libraries that wrap it in safe abstractions, but would be frowned upon in a tiny synthetic benchmark program that is supposed to benchmark idiomatic code.
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.
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 registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2
> 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!
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...
SIMD will get you into platform specific woes unfortunately, but that shouldn't stop us. :-)
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:
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.In Visual C++, the prototype of that intrinsic is valid C99 code:
The likely answer is "none", as these are built-in to Visual C++ in a similar way to GCC, with only superficial differences such as an apparent lack of indirection to some __builtin_foo.
https://msdn.microsoft.com/en-us/library/26td21ds(v=vs.100)....
"An intrinsic is a function known by the compiler that directly maps to a sequence of one or more assembly language instructions. Intrinsic functions are inherently more efficient than called functions because no calling linkage is required."
https://msdn.microsoft.com/en-us/library/y0dh78ez(v=vs.100)....
"The use of intrinsics affects the portability of code, because intrinsics that are available in Visual C++ might not be available if the code is compiled with other compilers and some intrinsics that might be available for some target architectures are not available for all architectures."
C99 language spec says nothing about the things you’re talking about. It only specifies the language, not how C compilers implement various features.
From the programmer’s point of view (except when the programmer works on the compiler itself), intrinsics are just C library functions, only inline, and very performant if done right. Fully compliant with C99 and C++ language specs.
(Rust is currently beating C on one benchmark, within a few tenths of a second on a few more, and then way slower on the SIMD-reliant ones)
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/4599a387d24c80906475b26b8ac9... None of the Rust aficionados were able to produce a Rust program (using the nightly build of Rust even) that came close.
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, or non-atomic reference counting.[1] You _could_ write this in C, and you'd do so for a microbenchmark, but not for a real codebase, as it's far too dangerous. Or, you might do it, but end up with bugs that you don't detect, that aren't there in the Rust version.
1: http://blog.faraday.io/saved-by-the-compiler-parallelizing-a...
Secondly, microbenchmarks are often "can the best person at language X write something faster than the best person at language Y"? I don't think that's nearly as interesting as "When an average programmer of languages X and Y write a program, which is faster?" Rust's default patterns and style is already extremely fast. It's not a guarantee, mind you, but for real-world usage, it's the average case that matters more.
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.
That was last year, before rustc 1.0.0-alpha
> There's been a lot of variance on the benchmark game lately
With Swift, because programs written for Swift 2.0 failed with Swift 3.0
I guess you missed this in the sibling, but ripgrep does this today, and it works on Windows, Mac and Linux, and should be as fast or faster than GNU grep. See benchmarks: http://blog.burntsushi.net/ripgrep/#single-file-benchmarks See binaries: https://github.com/BurntSushi/ripgrep/releases
I've written quite a bit of comments before on Rust, since it's not the first time someone asks similar question. You can read my past comments: https://news.ycombinator.com/threads?id=dpc_pw
Just to sum up, IMO: Rust blows C++ out of the water on almost everything. It's not established enough so there are almost no jobs, and there's a learning curve, lack of tools, slow compilation, business reasons, etc. so you can't just blindly use Rust over C++, but when you can and have time to learn: go for it. The existing tooling is amazing, community is awesome, you will learn really interesting stuff, save time on debugging.
As for C++17 features... I don't really care anymore. C++ is death by thousands little cuts (undefined behavior is my "favorite") it's not going to change much anyway.