Hacker News Reader

Comment by StilesCrisis | Hacker News Reader

I don’t think there is a version of UB that gives you a predictable 90%, though. Either your program is exception-safe or it’s not. There’s no such thing as 90% safe.

View on HN

A possible compromise could be to be able to tell the compiler, "I don't care about structured exceptions anywhere else, so do all your instruction reordering stuff there, but this one section of code I know could throw structured exceptions, so be more conservative here." It might need to generate duplicated code for some functions, though.

Throw in a couple of barriers.

The majority of a program's runtime is usually spent in only a tiny section of its code. That is where optimization benefits are. If it helps to separate out that code and compile it with different compiler switches, the additional maintenance burden for the program structure and build system might be acceptable.

That's not a useful description of desktop "creative" software. Even though it might be true for audio that in many cases, the majority of the run time is spent handling the "process callback" from the audio subsystem, once the user starts actually working on things, the slow parts of the code (and the ones that impede the user or degrade their experience) are far removed from that core. This is a little less true of visual applications (video, drawing, image editing etc.) but I would imagine that similar considerations apply there too.

> The majority of a program's runtime is usually spent in only a tiny section of its code. That is where optimization benefits are.

People who keep repeating this have only ever either looked at the profiles of zero or one types of programs.

Go look at profiles for programs which have been written with performance in mind. Operating systems, databases, game engines, web servers, some compilers, video/audio/3d editing packages come to mind. I 100% guarantee these programs do not spend the majority of their runtimes in a tiny section of code. What you said is nearly-unilaterally untrue, at least for programs that care about real performance.

Static web servers I've actually seen spend most of their time in a couple of very hot paths (mostly the kernel's TCP stack). The others I agree with 100%, and also of course if your web server is doing any dynamic page work. Web browsers, too, and probably many important categories of software.

I do write and profile software of that kind and this experience is why I know this isn't a myth. Any mature program has a whole lot of code that actually isn't performance critical at all. For example, 3d software needs a really huge amount of GUI and other support code that isn't performance critical at all. The performance hotspots are really just individual functions doing the core of the processing work for any of the features it offers. The initiation/scaffolding code around that just doesn't matter. The same translates to all other software that that I have worked on.

Reply on news.ycombinator.com