That said, there are definitely performance bugs that have yet to be fixed. But I would definitely say most Rust code, if well-written, can be competitive with C++ today.
How do you do ASM in Rust?
Can you align memory in rust?
There's an asm! macro: http://static.rust-lang.org/doc/0.10/guide-unsafe.html#inlin...
> Can you align memory in rust?
I think that's an open problem for now, e.g. https://github.com/mozilla/rust/issues/4578
Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?
Er… yes? Did I say it was unimportant anywhere? (also please note that I'm not a Rust developer)
> Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?
I'm not quite sure what you're asking
* if you're asking if it's possible to use arbitrary memory returned by a third party? Then yes.
* if you're asking whether user-defined allocators or boxes are supported and you can ask the runtime to put its stuff in memory you get from e.g. a bundled jemalloc, then that's planned but not in I believe: https://github.com/mozilla/rust/issues/12038
No, but that link seemed to indicate it wasn't being planned for the first release and pcwalton seems to think it's possible to get Rust programs to run as fast as C++ programs in most cases.
(The speed of a language isn't determined by the speed of it's "first release".)
There is certainly a set of performance-critical problems where making optimal use of vector instructions is essential. It does seem that Rust is unlikely to be competitive for those today. But i think it's a minority of all problems.
It uses the LLVM support.
> How do you do ASM in Rust?
With the asm! macro.
> Can you align memory in rust?
Yes. Write an allocator that does this and use it. The language doesn't have an allocator "built-in" and has full support for custom allocators.
What do you mean by this? 1. Any scaler code might get vectorised by the LLVM if you're luckly.
or 2. You can write the instrinsics yourself in inline code, and the compiler will (almost) obey them verbatim?
In my experience, LLVM's vectorisation is behind GCC and quite a way behind ICC...
That piqued my curiosity -- would you mind going into a little more detail, or point me to somewhere where these are discussed?
I don't think there are many popular high level languages that target systems programming in the first place.
Hopefully the "going back to native" trend will move us back on track, similar to how it happened in the early 80's VM attempts.
See figure 3 of this wonderful but terrifying paper:
http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
(Caveat: that was published in 2005, and garbage collection has improved since then. However, i doubt it has improved enough to invalidate its conclusions.)
The best collector there needed ~3x as much memory as a (admittedly superhumanly perfect) manually memory management to get to a competitive speed.
There are plenty of problems where that memory is available. But there are plenty where it is not. I can justify giving loads of memory to the application that makes my company money. I can't justify giving it to some tiny little log shipper or message forwarder or other random system utility that i want to run on every machine in my infrastructure.
There are lots of languages with native code generation compilers that have GC[1] support.
Since the Xerox PARC days there have been system programming languages with automatic memory management (Cedar, Interlisp, Modula-3, Oberon, ....).
They were just ignored by the mainstream OS vendors, that were busy creating UNIX System V and VMS clones.
[1] RC is usually GC chapter 1 in CS books.
It doesn't. I think the point about VMs and JITs is a red herring.
It's not just the performance point. It's how well it's known. (Including how well the flaws are known. What's wrong with C++? Plenty, but there are people who know how to work around it. What's wrong with Rust? Presumably a fair amount as well, but we don't know what yet.) It's how mature our understanding is of how to build million line code bases that can be maintained for decades.
And, sure, people are going to scream about the memory bugs that are going to make that million-line code base a maintenance nightmare for decades. But what's going to make a Rust program a maintenance nightmare for decades? (Don't bother trying to tell me it won't be one.) You don't know. I suspect, however, that there is at least some danger that you won't be able to find many Rust programmers two decades from now.
tl;dr: C++, for all its flaws, is pretty well understood. We know that we can build at-least-somewhat-working large programs and maintain them for decades using it. We know of few other languages where that is true.
My feeling is that most often, (i) people don't need nearly as much performance as they think, and (ii) they greatly overestimate the performance gap between C++ and garbage collected languages (most notably those who are compiled to native code, such as Lisp, ML, and Haskell).
An audio mixer would be the same - it's given some fraction of the time to mix (resample, apply effects, etc.) in some short amount of time (say 5ms) - and called at regular periods.
I don't know much about web-servers, but wouldn't that be the case there - you want quick response (html).
I'm not saying going against scripting/dynamic/garbage-collected languages - they are very useful - but often there is need for the garbage collection mechanism to be exposed, so that it could be done piecewise, or fully collected at timees when it does not matter (say in a game, when transitioning from one level to another, or some UI is popped on the screen (pause), etc.).
E.g. - it's important for such things to be exposed, rather than hidden (and most of the time they are). For example reference lua, and luajit are good examples there, and other runtime implementations allow that (.NET I think there is a way to pause the garbage collectro).
But performance is needed in all mentioned applications above - physics, collision, occlusion, rendering, etc.
…is one of the most demanding application ever. And a tiny niche to boot: while prominent, games represent a tiny fraction of all programming effort. Web browsers and operating systems are an even more extreme example of this availability bias.
For interactive stuff that otherwise doesn't move (regular web browsing, GUI stuff…), 100ms response time is perfect, except maybe for text entry. GC pauses can be made negligible in that context. (Though as you said, we need access to that stuff.)
People often greatly underestimate the amount of performance sensitive software out there, often because they're used to working on software where the hardware isn't a fixed constraint, or are indirectly relying on optimized C/C++ software provided by the system itself.
Moreover, simple benchmarks which are often used for comparing languages are not a valid indicator of the performance available in a lower-level language.
For example, switching loop-processed data from a standard AOS (array of structures) to a SOA (structure of arrays) format can improve performance by orders of magnitude by reducing cache misses (on an i7, main memory latency is ~25x that of L1 cache).
With that latency difference in mind, imagine for a moment the impact of iterating an array of objects stored disparately in memory versus a tightly packed array.
Or more related to memory management, a common allocation optimization used in games is to provide a block of per-frame memory; allocations are a simple addition, and deallocation is an assignment. All the easy cleanup of GC, but with a constant (and insignificant) cost.
Certainly most of the code does not need to be C++, nor heavily optimized; even the 16/32ms per frame game industry tends towards garbage collected scripting languages for a significant portion of the code base. That does not however obviate the necessity for a systems level language to provide the capacity for such optimization.
I call availability bias: people who work on high performance niches feel everyone is underestimating the problem. People who work on low-performance niches wonder what's the big deal.
What I have personally observed is more like a fear of poor performance, coming from people who don't understand the problem like you do. So the team choose C++, which eventually leads to an unmaintainable, slow Big Ball of Mud. 'Cause as your AOS vs SOA example demonstrates, C++ doesn't magically make your code fast. Oops.
> That does not however obviate the necessity for a systems level language to provide the capacity for such optimization.
Agreed. Just two caveats: first, C++ is really a last resort, to be used when nothing else will do, not even C+Lua or similar combination. Even for high performance code, this language is way overused. Second, while we all use the high performance infrastructure you speak of, few of us get to write it.
I think you're right about that, but I also think that people greatly underestimate the determinism gap between them, too. (Not necessarily the same set of people, of course.)
Also don't forget that garbage collectors can often be tuned. Granted, many of them suck, but a generational, incremental collector whose parameters can be tweaked? Much less room for pauses.
Also, some naive simulations will adapt the length of their steps with the time it takes to compute them. Any performance variation gives you full blown unpredictability.
When you're just CPU bound without having to cope with lots of memory transfer / throughput, then you won't notice.
Without a doubt, there are many apps that don't need this pure speed, but for specialist apps and even general apps on the desktop (compare firefox to chrome and safari for example), you can notice the difference quite distinctly.
In my experience writing high performance applications for the VFX industry, where both memory performance AND memory compactness (so you can fit as much in memory as possible) are important, when profiling applications, I've found that maybe 70% of the time it's the memory allocation / deallocation that's the actual bottleneck, not actual calculations. Being able to separate stuff into separate allocators based on different use cases adds complexity, but gives huge benefits when you're memory throughput constrained.
That said, Rust will get close to C/C++ in ways that GC-based languages never will. GC languages mean memory bloat and soft-realtime problems related to GC cleaning. It will likely hit the sweet spot for a lot of embedded or gaming uses. Obviously you can do those tasks in other languages (great stuff is done on phones with GC-based languages, obviously), but you have to work around some challenges that would not exist in Rust.
Yesterday, Intel announced a project combining a clang frontend with icc's backend. [1] The backend takes LLVM IR, so hopefully Rust's LLVM IR output could be run through it.
That's most probably false: the current self-hosting implementation have an LLVM backend. So it has back end optimisations covered. As for the front end, Rust's cleaner semantics will make many optimizations easier.
Plus, it's not like the historical gap couldn't be closed by reading the gazillion papers on C++ optimization out there. Copying a known technique is much faster than developing it in the first place.
Maybe Rust will end up slower than C++ anyway, but it won't be the compiler's fault.
there exist some fairly minimal "C++" like languages for gpu, but nothing to fully deal with strings, exceptions, STL, etc.
And then there is FPGA, but probably not a fair mention since these do not exist (in general) with most common hardware (pc computers, phones, pads, etc.) - while GPU's are found almost anywhere, and on most of the devices now, one can exploit extra computing power exactly by using the GPU.
Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point. C++ compilers have been honed and tweaked for more than a decade now, so it will be a hard battle ahead.