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

Rust for C++ programmers – part 4: unique pointers

featherweightmusings.blogspot.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Rust for C++ programmers – part 4: unique pointers

#71

Post by ben0x539 »

bambam12897 wrote: post #8

I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++. Here is my feedback: 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main sell…

Features-wise, C++ probably subsumes a lot of languages, so from a certain perspective, everything else looks like a weird syntax for a subset of C++.

And it's true that Rust is edging closer and closer to C++ in some ways. It certainly didn't start there, old ("old", 2010 or so) Rust looks pretty weird with lots of esoteric features (effects! structural types!) and built-in magic. Over time Rust probably ~focused on its core values~ etc, which resemble that of C++, and also grew more powerful as a language so that most things can now live in the library rather than in the compiler, which is I guess something that C++ also prides itself with.

But more seriously, the whole motivation for Rust isn't what features it gives, but what it takes away. All the traits and algebraic datatypes and type inference and other shiny Rust features, if someone walked up to the Rust people with an implementation of that as a source filter for C++ or whatever, it still wouldn't sell. The mission of Rust (as I see it, from the distance) isn't to make a more convenient or powerful C++, it's to make a language convenient and powerful enough that people won't miss C++'s laissez-faire attitude towards memory safety.

To that effect, Rust isn't really aiming to compete with C++ on a feature-for-feature basis, but it has to include features that enable a style of programming that is competitive with C++ performance and convenience without relying on memory-unsafe features.

(I guess the `unsafe { }` sub-language comes off as an admission that that won't work, but it's arguably just a way to introduce new safe primitives that requires particularly careful manual checking, just like adding features to the language that the compiler assumes are safe, and anyway it's mostly equivalent to linking to arbitrary C code without which the language would pretty much be a non-starter anyway.)

Re: Rust for C++ programmers – part 4: unique pointers

#72

Post by malkia »

loup-vaillant wrote: post #66
rdtsc wrote: post #4

Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again. 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…

> 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. 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…

Game at 60fps is hard-to achieve if something is taking more than few milliseconds to finish (since there are other things to finish too), even if it's occasionally - it'll produce a noticeable frame-drop.

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.

Re: Rust for C++ programmers – part 4: unique pointers

#73

Post by malkia »

Pxtl wrote: post #59
rdtsc wrote: post #4

Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again. 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…

Nobody will ever beat C/C++ for raw soft-real-time speed. Even a language like Rust that may have the linguistic features to be blazingly fast will never close that massive gap in historical optimization. Rust will never have an Intel-compiler. 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 l…

Well, it's already been beaten on most common hardware, though not fairly and not on the same "cpu" chip, but on the gpu: OpenCL, Cuda, DX/GL Shaders. Can't beat that (yet)!

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.

Re: Rust for C++ programmers – part 4: unique pointers

#74

Post by pohl »

kirab wrote: post #32
akavel wrote: post #29

Earlier quoted context omitted.

I assumed it reads more or less like: Foo *****y; Or, probably, more like: std::unique_ptr >>>> y;

Thanks, I hope this is never needed anywhere, ever.

I suspect it's a deliberately-perverse example, meant only to illustrate how deeply method calls will automatically dereference.

Re: Rust for C++ programmers – part 4: unique pointers

#75

Post by pohl »

loup-vaillant wrote: post #69
pohl wrote: post #67

Earlier quoted context omitted.

they greatly overestimate the performance gap between C++ and garbage collected languages 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.)

I'm not sure. If you start using smart pointers in C++, you can get the same problem: instead of a GC pause, you get a cascading delete pause. To eliminate it, you have to devise a smarter memory scheme, at which point you probably don't underestimate the determinism cap. Also don't forget that garbage collectors can often be tuned. Granted, many of them suck, but a generational, incremental collector whose parameter…

A cascading delete pause may be undesirable, but is it nondeterministic?

Re: Rust for C++ programmers – part 4: unique pointers

#76

Post by jerf »

pohl wrote: post #75
loup-vaillant wrote: post #69

Earlier quoted context omitted.

I'm not sure. If you start using smart pointers in C++, you can get the same problem: instead of a GC pause, you get a cascading delete pause. To eliminate it, you have to devise a smarter memory scheme, at which point you probably don't underestimate the determinism cap. Also don't forget that garbage collectors can often be tuned. Granted, many of them suck, but a generational, incremental collector whose parameter…

A cascading delete pause may be undesirable, but is it nondeterministic?

In the same way that GC is, yes. Technically both are probably fully deterministic, just not readily determinable by casual examination of the code at compile time.

Re: Rust for C++ programmers – part 4: unique pointers

#77

Post by twic »

berkut wrote: post #43
masklinn wrote: post #42

Earlier quoted context omitted.

> Aligning memory is pretty important for high-performance apps using SSE/AVX 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'…

> Er… yes? Did I say it was unimportant anywhere? 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.

I would imagine that "most cases" don't require this kind of alignment, because most cases don't involve vector instructions.

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.

Re: Rust for C++ programmers – part 4: unique pointers

#78

Post by pohl »

jerf wrote: post #76
pohl wrote: post #75

Earlier quoted context omitted.

A cascading delete pause may be undesirable, but is it nondeterministic?

In the same way that GC is, yes. Technically both are probably fully deterministic, just not readily determinable by casual examination of the code at compile time.

I guess I didn't mean nondeterministic in the philosophical indeterminism sense, but in the sense that different runs might produce different behavior.

http://en.wikipedia.org/wiki/Nondeterministic_algorithm

Re: Rust for C++ programmers – part 4: unique pointers

#79

Post by rdtsc »

pohl wrote: post #67
loup-vaillant wrote: post #66

Earlier quoted context omitted.

> 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. 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…

they greatly overestimate the performance gap between C++ and garbage collected languages 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.)

Very good point. Performance folds in latency (determinism) and throughput. There is usually a trade-off between the two. GC might handle throughput reasonably, latency is a bit tougher. You are sort of left tweaking knobs on a black box hoping to get good results in the end.

Re: Rust for C++ programmers – part 4: unique pointers

#80

Post by AnimalMuppet »

pohl wrote: post #75
loup-vaillant wrote: post #69

Earlier quoted context omitted.

I'm not sure. If you start using smart pointers in C++, you can get the same problem: instead of a GC pause, you get a cascading delete pause. To eliminate it, you have to devise a smarter memory scheme, at which point you probably don't underestimate the determinism cap. Also don't forget that garbage collectors can often be tuned. Granted, many of them suck, but a generational, incremental collector whose parameter…

A cascading delete pause may be undesirable, but is it nondeterministic?

Even a single delete/free is nondeterministic. How long it takes depends on the state of the heap (true of new/malloc as well).
Post reply on HN