Hacker News Reader

Comment by likoya | Hacker News Reader

I put labels on each return, and took their addresses to get the base and delta. The creator of c++ always says that such kind of code has to work "because it is c++", meaning the programmer should be able to do whatever he wants. Anyways I also used assembler to make it work (had to include nop instructions to pad the addresses, because the goto can't go to any byte. So it consumed a lot of instruction l1 cache, which is not as bad as data cache, but it ended being slow anyways because gotos trigger branch prediction. In the end the fastest method was to pack the array in uint64 and do (x >> i) & 111b

View on HN

But did you use the address of every single return or did you assume they all had the same delta?

I can't find the quote you're talking about but I'll be surprised if it extends to assuming memory locations. If any pointer has to support touching any variable, even ones you never took the address of, that ruins so many basic and sensible optimizations.

Unless I'm misunderstanding, a normal computed goto would have an array of all the destinations. And hopefully it would compile to a delta multiply. But if you need to force it... maybe a compile time check that all the labels are delta bytes apart would let you do that math? I don't know, it's not part of the actual standard, it might be janky.

Did a plain old switch statement compile into something you didn't like?

A switch compiled into an array lookup table

>>I can't find the quote you're talking

Not that exact quote, but the spirit of it at 44:22.

https://youtu.be/uTxRF5ag27A?t=2662

Quote: "A zero-overhead principle. It basically says that if you have an abstraction, it should not cost anything compared to writing the equivalent code at a lower level."

I don't think that's a very close spirit? Saying abstractions that do exist should have no runtime cost is very different from saying which controls need to be available. This isn't really about abstractions at all, this is about micromanaging which variant of MOV the compiler uses because of knock-on effects on the cache.

You don't get Marssaxman's point: the problem is that "compiler authors treat undefined behavior as a license for user-hostile behavior".

Bjarne Stroustrup's criterion for language design is that C++ is an abstraction in itself over writing in assembly, and the language design should not get in the way by introducing overhead costs. C++ should allow the programmer to express their intent without losing performance relative to assembly, and it fails in this case due to undefined behavior.

So when the compiler doesn't let you implement your low-level code, it is a failure of the language and compiler relative to the design criteria of C++.

But "without losing performance" and "without having bugs" are completely different criteria. I get the original point, and I'm not saying the compilers are justified in all their aggressive optimizations, but I don't think the quote you gave is talking about the same thing.

There are things you simply can't write in C. I think that's okay. But even if you don't think that's okay, it doesn't conflict with zero-overhead.

But also, when it comes to jumping by address to a goto you didn't check is at that address, I'm on the side of the compiler here. That's not how computed goto is supposed to work. You're supposed to use an address you can know is right by reading the code.

Checking-the-address is overhead.

It's like checking for overflow in an arithmetic operation. Other languages do the checking, and that's why they're slower. But C++ doesn't check because it offloads the responsibility to the coder, so the coder can write faster code if he makes sure there are no bugs.

If the coder knows there will be four return values and writes them one after the other, the return (or MOV) instructions are distanced the same. The goto hack should work.

> Checking-the-address is overhead.

In the same way that initializing a variable is overhead. But if you assume the variable will have a 7 in it because that's what it compiled to one time, it's not the compiler's fault when it compiles it to not be 7.

Except it's actually less overhead than that. You don't need to do any verification at runtime if your compiler cooperates. If it works like other pointers then you can get the same "base + delta * i" opcodes but without undefined behavior.

I shouldn't have used the word "check". A better way to phrase it is "knowing for sure". You need to know for sure where the goto is, which means using && and keeping track of what it tells you in some way.

> If the coder knows there will be four return values and writes them one after the other, the return (or MOV) instructions are distanced the same. The goto hack should work.

You can't know that. Sometimes other things will be in there, and sometimes the padding won't be so consistent.

Do what you're supposed to do. && every label you might jump to. And then you can check if they're spaced evenly at compile time. If they are you can treat them as spaced evenly at runtime.

Reply on news.ycombinator.com