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

81–90 of 99 posts

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

#81

Post by masklinn »

loup-vaillant wrote: post #68
masklinn wrote: post #20

Earlier quoted context omitted.

> Given the scope of the project: you guys must be doing something that is so different that it couldn't be rolled into a library Memory safety and static checking. > A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++ * let comes from ML and similar languages (e.g. Haskell), which are a huge inspiration of Ru…

If I had to guess, I'd say "box" is a reference to "boxed values" mentioned in many papers about functional language compilation. Typically, the stack of these implementation would either be "unboxed values", or pointers to "boxes" on the heap. Clearly, some of those folks have worked on ML or Haskell implementations.

> If I had to guess, I'd say "box" is a reference to "boxed values"

Yes, that's the start of it but it was expanded to multiple box classes (and maybe eventually user-defined ones) rather than just boxed and unboxed values: a developer can currently use box(HEAP) and box(GC) (a bare `box` is an alias for `box(HEAP)`)

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

#82

Post by AnimalMuppet »

loup-vaillant wrote: post #70
bad_user wrote: post #36

Earlier quoted context omitted.

> If memory management is a serious problem for the software you work on, I've never found the boost library lacking. As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare and no amount of libraries can solve it. Say you receive a pointer from somewhere. Is the referenced value allocated on the stack or on the heap? If allocated on the heap, do you need to free it yourself…

> if a C++ project doesn't have multiple conflicting ways of dealing with memory management and multiple String classes, then it's not mature enough. Hmm… How can I tell maturity from rot?

bad_user's definition of maturity sounds an awful lot like rot to me...

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

#83

Post by AnimalMuppet »

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…

There are few viable competitors that: - give access to as low a level as you need, in a way that you can tell what the costs of various actions are going to be, - lets you manage different pools of memory differently, - lets you use higher level abstractions (clear up to lambdas), - gives you confidence that it will still be around in a decade or two (I have worked on code bases that lasted two decades), and that coders will still be available in that language.

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.

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

#84

Post by twic »

pjmlp wrote: post #12
NAFV_P wrote: post #6

Earlier quoted context omitted.

> 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. I don't think there are many popular high level languages that target systems programming in the first place.

The problem was the trend in the mid-90's to move away from native AOT compilers to VM JITs, thus leaving C and C++ as the main to go languages most mainstream developers know, as other options faded out of sight. 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.

I think the real problem is the move from manual memory management to garbage collection. Garbage collection has immense advantages, and is indisputably the right choice for most application programming, but it only goes fast if you feed it lots of memory.

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.

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

#85

Post by noct »

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…

As a developer who's worked in games, embedded, and real-time situational awareness software (ex. air traffic control), my feeling is exactly the opposite.

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.

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

#86

Post by pjmlp »

twic wrote: post #84
pjmlp wrote: post #12

Earlier quoted context omitted.

The problem was the trend in the mid-90's to move away from native AOT compilers to VM JITs, thus leaving C and C++ as the main to go languages most mainstream developers know, as other options faded out of sight. 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.

I think the real problem is the move from manual memory management to garbage collection. Garbage collection has immense advantages, and is indisputably the right choice for most application programming, but it only goes fast if you feed it lots of memory. 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 collect…

What does it have to do with VMs, though?

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.

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

#87

Post by pcwalton »

seertaak wrote: post #24
pcwalton wrote: post #5

Earlier quoted context omitted.

I feel pretty good about it. For one, we have significantly better aliasing information than C++, and we use most of the guts, including all the optimizations and code generation, of a C++ compiler (clang/LLVM). There are also some optimizations around move semantics that are open to us but not for C++ as standardized. That said, there are definitely performance bugs that have yet to be fixed. But I would definitely…

> There are also some optimizations around move semantics That piqued my curiosity -- would you mind going into a little more detail, or point me to somewhere where these are discussed?

https://github.com/mozilla/rust/issues/5016 is the main optimization (and we have more discussed but not written up). Since we have a very strict notion of liveness, we don't have to zero out moved data since the compiler can just not run the destructor.

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

#88

Post by [deleted] »

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

[deleted]

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

#89

Post by berkut »

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…

When you're IO or network / database bound, then, you won't notice.

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.

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

#90

Post by DerekL »

ahy1 wrote: post #28
comex wrote: post #13

Earlier quoted context omitted.

> 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. A key feature of Rust is being memory safe by default without sacrificing too much performance. In C++ it's not really possible to be completely safe, and pretty much all real-world C++ I've seen doesn't even come close to that ideal, using raw pointers frequently; the result is that crashes can b…

> Most C++ code uses switch frequently, usually without taking advantage of fallthrough. I am not so sure about this. Thinking back on my uses of switch in C and C++, I am not able to remember using switch without taking advantage of fallthrough. Maybe I am just not a typical C++ programmer...

There's two different kinds of fallthrough in C++. The most common is using the same code for multiple values. Rust already supports this by allowing multiple values and ranges of values for each pattern.

The much more rare use of fallthrough is executing code for one case, and then continuing on to execute the code for the next case. This seems to be much more rare. In fact, in my large Android application, I turned on warnings for this type of fallthrough, and out of hundreds of switch statements, only eight used it, and all but one was a mistake.

Post reply on HN