Error handling in C

masonwheeler

~~The anti-goto fanatics~~ Ignorant developers with no understanding of the reasoning behind general principles tend to also be hyper-keen on not using break, continue or more than one return.

FTFY. Gotos are still bad, but I have no problem with structured control flow constructs.

LB_

@sloosecannon the combination of RAII and exceptions is the true power of C++. Without one, the other becomes less useful. The tragic flaw is that many of the original standard library components were designed closer to C-style error flags and such, with optional exception handling bolted on as an afterthought. In new code, though, exceptions are great.

LaoC

@asdf said in Error handling in C:

The first version is much less efficient though;

Wait, what? Why should it be less efficient? The only possible difference is the size of the compiled program.

With memory speed as slow as it is in comparison to CPUs, that makes it slower already.

@cvi said in Error handling in C:

@asdf said in Error handling in C:

I don't know if any compilers actually do this (because what's the point?), but it shouldn't be too hard to recognize identical basic blocks up to a certain number of instructions.

Both GCC and Clang do this. ;-) See compiler explorer.

OK, scratch that one, I saw it coming :D

asdf

@LaoC said in Error handling in C:

With memory speed as slow as it is in comparison to CPUs, that makes it slower already.

So you're saying that the less blocks there are, the more likely the correct one is prefetched? Not sure that's how it works, but OK, maybe.

dkf

@asdf said in Error handling in C:

So you're saying that the less blocks there are, the more likely the correct one is prefetched?

As long as the memory has been copied into L1 cache by the time the CPU actually wants it, it isn't too big a deal.

wharrgarbl

@dkf why the if instruction still doesn't have a way to tip the compiler what's the more likely path? It's not like we don't know it most of the time, no need for fancy profiling optimisers.

dkf

@wharrgarbl said in Error handling in C:

why the if instruction still doesn't have a way to tip the compiler what's the more likely path? It's not like we don't know it most of the time, no need for fancy profiling optimisers.

LaoC

@wharrgarbl said in Error handling in C:

@dkf why the if instruction still doesn't have a way to tip the compiler what's the more likely path? It's not like we don't know it most of the time, no need for fancy profiling optimisers.

The P4 had that and so do PowerPC and Itanium. On later x86s they seem to have decided it's not worth the code (it always added a byte to the jump on x86 while the PPC does it with some flag bits or other) so the compiler is just supposed to lay out the code the way the CPU expects it according to its static prediction rules like "backward jumps are usually taken".

cvi

@wharrgarbl said in Error handling in C:

why the if instruction still doesn't have a way to tip the compiler what's the more likely path? It's not like we don't know it most of the time, no need for fancy profiling optimisers.

Currently, you have __builtin_expect() on GCC and Clang (and perhaps others that pretend to be compatible, like PGI/ICC). MSVC doesn't seem to have any equivalent, though (unless they sneakily added something in VS2017, but I've not heard anything to suggest so).

I think there was a suggestion sometime to add it as a standardized C++11-style attribute (using the [[...]]) syntax, but I don't know if that went anywhere.

FWIW, the compiler explorer link I included above includes a commented __builtin_expect() in the define of UNLIKELY(). If you change the define, you can see how the hint affects the generated code.

djls45

@wharrgarbl said in Error handling in C:

@dkf why the if instruction still doesn't have a way to tip the compiler what's the more likely path? It's not like we don't know it most of the time, no need for fancy profiling optimisers.

IIRC from my assembly and compiler classes, x86 guesses that a conditional jump to a later point in the code (e.g. if, for, while) and conditional jumps to earlier points (i.e. the ends of loops, usually) will usually be taken, so setting up the conditions so that the most common ifs are first is generally best practice.

For example, this:

if(condition)
{
    /* code rarely executed */
}
else
{
    /* code executed often */
}

is not really good code layout. It should be rearranged to this:

if(!condition)
{
    /* code executed often */
}
else
{
    /* code rarely executed */
}

The ! might also be able to be eliminated by refactoring the condition to invert it, or a different conditional jump instruction could be used, though a good compiler should be able to figure that out based on the conditional test. But that's a different optimization point; I'm mostly concerned here with instruction prefetch caching.

dkf

@djls45 said in Error handling in C:

It should be rearranged to this

Actually, you just tell the compiler which branch is unlikely and it does the code rearrangement.

djls45

@dkf said in Error handling in C:

@djls45 said in Error handling in C:

It should be rearranged to this

Actually, you just tell the compiler which branch is unlikely and it does the code rearrangement.

Is there a flag or something that let's you do that? I don't know of any in C. Ordering the conditionals like this is the only way of signalling that to the compiler that I know of.

cvi

@djls45 See my post above.

If you decide to not use __builtin_expect(), I recommend checking the output in the cases where you really care. There are other things that cause compilers to infer which branch is likely and which is not. For example (and IIRC), GCC will consider branches that end in either a [[noreturn]] function or a throw to be unlikely (since they are most likely error handling). It also uses the conditional as a heuristic (the rules for this are documented, but I can't find the link right now).

Helix

@dkf
How can something look like an embedded system and not be one?

dkf

@Helix said in Error handling in C:

How can something look like an embedded system and not be one?

When it is one of these.

Research Groups: APT - Advanced Processor Technologies (School of Computer Science - The University of Manchester)

Each node is effectively an embedded system (i.e., same sorts of restrictions, some funky stuff with memory) but we've got 18 of them per chip and we've tens of thousands of chips all attached to our custom multicast networking fabric. It's a mad monster of a computer.

Helix

@dkf
The project's objectives are two-fold:

To provide a platform for high-performance massively parallel processing appropriate for the simulation of large-scale neural networks in real-time, as a research tool for neuroscientists, computer scientists and roboticists
As an aid in the investigation of new computer architectures, which break the rules of conventional supercomputing, but which we hope will lead to fundamentally new and advantageous principles for energy-efficient massively-parallel computing

So.. it's not an embedded system.

Arantor

@Helix no but you program it like one given that you're programming many, many, many small nodes with on-board memory that interconnect. The usual boxes that embedded ticks - weird memory management, no/limited file system, limited resources, weird networking - all apply here.

dkf

@Helix said in Error handling in C:

So.. it's not an embedded system.

True, but each little bit looks a lot like a classic embedded system that's just talking to some weird comms hardware. (It's got an ARM core, a very odd memory layout, no filesystem at all, no hardware floating point, etc.)

Jaloopa

@Helix said in Error handling in C:

So.. it's not an embedded system.

But it looks like one

wharrgarbl

@dkf are making an IOT botnet?

cvi

@wharrgarbl said in Error handling in C:

@dkf are making an IOT botnet?

Nah, seems like they are researching a neural network architecture that could later be deployed on an IOT botnet.

Helix

@Arantor said in Error handling in C:

@Helix no but you program it like one given that you're programming many, many, many small nodes with on-board memory that interconnect. The usual boxes that embedded ticks - weird memory management, no/limited file system, limited resources, weird networking - all apply here.

Managing going in and out of low power states?
Coding for low power?
Squeezing computation out of a strict number of cycles?
Squeeze code into smaller flash memory?
Severe memory shortage?
Devices designed to execute for a number of years without a reboot?
Code written to safety integrity levels?
No networking, gui, output streams etc?
Highly expensive or impossible to change code once deployed?

Apart from that just the same.

dkf

@cvi said in Error handling in C:

Nah, seems like they are researching a neural network architecture

that could later be deployed on an IOT botnet.

No, IoT doesn't support the sort of bandwidth required.

dkf

@Helix said in Error handling in C:

Managing going in and out of low power states?
Coding for low power?
Squeezing computation out of a strict number of cycles?
Squeeze code into smaller flash memory?
Severe memory shortage?
No networking, gui, output streams etc?

Yes to all the above. :p

Except output streams. We can do things there but it is weird and only really interesting for people wanting to connect some types of robot.

Devices designed to execute for a number of years without a reboot?
Code written to safety integrity levels?
Highly expensive or impossible to change code once deployed?

But none of these. (Well, the watchdog controller in it is checked to a much higher level of integrity than the rest of the system, but we have running research-grade code as an explicit objective which directly means we won't be doing the other things you list.)

cvi

@dkf said in Error handling in C:

No, IoT doesn't support the sort of bandwidth required.

Killjoy. What good is my IoT toaster if it can't host a few neurons of future skynet? Somebody should get working on that ASAP.

(Alas, ~50GB/s is pretty formidable. I wonder what the bisection BW of a typical IoT botnet is. Btw - sounds like a fun machine to work on. :-))

dkf

@cvi said in Error handling in C:

Alas, ~50GB/s is pretty formidable.

That's only the Gen-1 machine. We're planning the next one where we switch to much smaller transistors, which will let us out far more on each chip for the same power budget. I'm not sure what we're going to do for the comms fabric, but we'll probably use a similar amount of machine room once the build is done. I'd guess that maybe the generation after that would be capable of making a serious attempt at the scale of a human brain? (If not that, one more generation should do it.) The main remaining software “problem” is that with that many synapses, you need more bits of address space for the message routing, which impacts bandwidth in terms of messages-per-second…

sounds like a fun machine to work on

When it isn't being an annoying piece of hardware with next to no tooling, sure. ;)

Arantor

@dkf That's why they hired you, right?

JazzyJosh

B is fine if THEY'RE NOT FUCKING GOTOS

LaoC

@JazzyJosh said in Error handling in C:

B is fine if THEY'RE NOT FUCKING GOTOS

We're at C already™

djls45

@dkf said in Error handling in C:

...
Yes to all the above. :p

Except output streams.
...
But none of these.

No output? But then how do you know it ran correctly?

ben_lubar

@djls45 said in Error handling in C:

@dkf said in Error handling in C:

...
Yes to all the above. :p

Except output streams.
...
But none of these.

No output? But then how do you know it ran correctly?

Next OMGWTF competition will be an optimizing compiler for pure functional languages with no return values.

dkf

@djls45 said in Error handling in C:

No output? But then how do you know it ran correctly?

Actually a totally reasonable point. We run a different program to splat the slow-memory contents out. (Some parts of the machine can talk to the outside world, but only via UDP and only using the most horribly inefficient protocol. The internal stuff is very different to what the outside world does.)