C++ Headers are Expensive • Hacker News Board

Re: C++ Headers are Expensive

#31

Post by Someone » Tue, Jan 08, 2019, 1:29 AM UTC

kccqzy wrote: post #24

shereadsthenews wrote: post #9

Earlier quoted context omitted.

pImpl pattern is great for those who don’t care about performance but it’s inappropriate for most header libraries. You wouldn’t want a library that hides the implementation of std::vector for example. With a visible implementation the compiler compile e.g. operator[] down one x86 instruction. With a pImpl pattern it will be an indirect function call in all likelihood that will be hundreds of times slower. It can mak…

Using the pimpl pattern doesn't mean an indirect function call. The function to be called is always known. It's just an extra indirection in the data member. It's cheap. Think of it as Java style memory layout: everything that's not primitive stored in an object is a reference and therefore behind one level of indirection. The performance of Java is acceptance in the vast majority of use cases. Using pimpl will be th…

”It's just an extra indirection in the data member. It's cheap”

That extra indirection often means a cache miss. That isn’t cheap. Accessing each item traversed through a pointer can easily halve program speed.

Java tries hard to prevent the indirections (local objects may live in the stack, their memory layout need not follow what the source code say, objects may even only exist in cpu registers)

Re: C++ Headers are Expensive

#32

Post by [deleted] » Tue, Jan 08, 2019, 1:30 AM UTC

nikanj wrote: post #20

nanolith wrote: post #11

Earlier quoted context omitted.

This depends on what you are building. Don't commit the sin of early optimization. Does a client of the framework you are writing -- which is probably using STL internally -- need a single instruction operation for adding a value for a call that you make less than 0.001% of the time? Optimization is about end results. Apply the Pareto Principle, and don't forget that your users also need to compile your code in a rea…

Overall user experience, mobile battery life, and many other metrics are really hard to fix by micro-optimizing a few functions. The key to a system that doesn't feel sluggish is being conscious of performance issues when making design decisions. This pendulum swings back and forth, and we went from "every bit counts" madness of the early days, to the polar opposite of "just burn cycles, whatever". Systems where ever…

[deleted]

Re: C++ Headers are Expensive

#33

Post by shereadsthenews » Tue, Jan 08, 2019, 1:31 AM UTC

nanolith wrote: post #29

erubin wrote: post #25

Earlier quoted context omitted.

you may not be aware but your comment came off as somewhat condescending, given that you don't really have any idea where parent poster is coming from or what their background is

If someone says that premature optimization isn't a thing, I don't think it is condescending to point out that it is by posting original source material. :-)

Well, to the extent that it is a thing it only wastes the programmer’s time. I happen to think programmers are spending too little time, so that doesn’t bother me. Wasting CPU time on the other hand bothers me a lot!

Re: C++ Headers are Expensive

#34

Post by nanolith » Tue, Jan 08, 2019, 1:32 AM UTC

nikanj wrote: post #22

nanolith wrote: post #18

Earlier quoted context omitted.

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf

Knuth wasn't saying "just ignore performance altogether", he was saying "stop making things needlessly complicated for the last bit of juice".

For instance, pulling in the STL for an interface header instead of encapsulating these details. :-)

No one is claiming that we should ignore performance all together. But, understanding through profiling where performance issues are and designing toward a faster implementation is more important than trying to inline definitions up front.

Re: C++ Headers are Expensive

#35

Post by Someone » Tue, Jan 08, 2019, 1:39 AM UTC

fizwhiz wrote: post #2

Isn't this the reason precompiled headers are a thing?

It is, but precompiled headers are a pain in the a… (often less so than not using them, but still)

They force programmers to tell the compiler what intermediate result to cache. Finding the best intermediate result to cache is a black art, and that set will change when your source code grows, forcing you to either accept that your precompiled headers may not help that much, or to spend large amounts of time optimizing build times.

Re: C++ Headers are Expensive

#36

Post by cgrealy » Tue, Jan 08, 2019, 1:44 AM UTC

nanolith wrote: post #29

erubin wrote: post #25

Earlier quoted context omitted.

you may not be aware but your comment came off as somewhat condescending, given that you don't really have any idea where parent poster is coming from or what their background is

If someone says that premature optimization isn't a thing, I don't think it is condescending to point out that it is by posting original source material. :-)

> it only wastes the programmer’s time. ... Wasting CPU time on the other hand bothers me a lot!

As always the answer is... it depends. Programmer time costs money, CPU time is cheap by comparison.

If you're building something that runs occasionally, or is IO/UI/network bound... CPU time is largely irrelevant. But if you're building something that runs in a tight loop or a library that will be compiled in millions of lines of code, then the wasted programmer time will absolutely be worth the ROI.

Re: C++ Headers are Expensive

#37

Post by cgrealy » Tue, Jan 08, 2019, 1:47 AM UTC

loeg wrote: post #26

RcouF1uZ4gsC wrote: post #15

> The test was done with the source code and includes on a regular hard drive, not an SSD. In my opinion, this makes any conclusion dubious. If you really care about compile times in C++, step 0 is to make sure you have an adequate machine (at least quadcore CPU/ lot of RAM/SSD). If the choice is between spending programmer time trying to optimize compile times, versus spending a couple hundred dollars for an SSD, 99…

> The test was performed by compiling the source code below 128 times, calculating the average time. Presumably, 127/128 runs have both the test file and the single header file in memory cache, so the distinction is moot. Also, I find the conclusion that we should all just buy top end machines and ignore performance problems that don't manifest there fairly unconvincing. I think that kind of thinking is responsible f…

There's a difference between development (read: build) performance and runtime performance.

For any kind of even vaguely profitable software, your developers should all have kick arse machines.

But they should test on a $200 laptop :)

Re: C++ Headers are Expensive

#38

Post by shereadsthenews » Tue, Jan 08, 2019, 1:51 AM UTC

cgrealy wrote: post #36

nanolith wrote: post #29

Earlier quoted context omitted.

If someone says that premature optimization isn't a thing, I don't think it is condescending to point out that it is by posting original source material. :-)

> it only wastes the programmer’s time. ... Wasting CPU time on the other hand bothers me a lot! As always the answer is... it depends. Programmer time costs money, CPU time is cheap by comparison. If you're building something that runs occasionally, or is IO/UI/network bound... CPU time is largely irrelevant. But if you're building something that runs in a tight loop or a library that will be compiled in millions of…

Yes, but, again, this article is about standard headers. Since it is impossible for STL library authors to decide that they are or are not writing for a performance-sensitive audience, it behooves them to provide completely visible header-only implementations of everything.

Re: C++ Headers are Expensive

#39

Post by ChrisSD » Tue, Jan 08, 2019, 2:04 AM UTC

beached_whale wrote: post #12

nanolith wrote: post #4

I recommend three things for wrangling compile times in C++: precompiled headers, using forward headers when possible (e.g. ios_fwd and friends), and implementing an aggressive compiler firewall strategy when not. The compiler firewall strategy works fairly well in C++11 and even better in C++14. Create a public interface with minimal dependencies, and encapsulate the details for this interface in a pImpl (pointer to…

One hickup is that with unique_ptr you now have a rule of 5 thing, you need to declare a destructor which means you need to declar the copy/move constructor and assignment too. Not usually a big deal, but is extra code.

This is why the rule of zero advocates are getting louder.

Re: C++ Headers are Expensive

#40

Post by nanolith » Tue, Jan 08, 2019, 2:05 AM UTC

CyberDildonics wrote: post #27

nanolith wrote: post #18

Earlier quoted context omitted.

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf

Software still needs to be architected for performance from the start. Trying to micro optimize a loop before you know you need it what Knuth was saying to avoid.

Right. Much like avoiding pImpl because it might make a function call that occurs 0.001% of the time faster. That is the basis of the thread I was replying to.

Understanding what you are optimizing FOR and where the most attention should be spent is the crux of Knuth's argument. Trying to be clever up-front is often counter-productive.

There is nothing wrong with making some architectural decisions up front, but that is much different than avoiding pImpls at all costs because indirection is slower. Indirection doesn't always matter, and it should only be tackled when and where it does.