There are many cases of UB that would be cheap to check, but there are many more that are incredibly expensive to check.

There's nothing in LLVM itself that makes it use larger sizes, it just depends on the ABI and what's fastest when ABI doesn't matter.

C however states :

> When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects that are neither lock-free atomic objects nor of type volatile sig_atomic_t are unspecified, [...] The representation of any object modified by the handler that is neither a lock-free atomic object nor of type volatile sig_atomic_t becomes indeterminate when the handler exits.

This wording is not present in C++, as it instead defines how signal handlers fit into the memory model.

This means that (with adjustments for C atomics):

  int val = 0;
  std::atomic flag{false};
  
  void handler(int sig) {
    if (!set) {
      val = 1;
      flag = true;
    }
  }

  int main(void) {
    signal(SIGINT, handler);
    while (!flag) { /* Spin waiting for flag */ }
    return val;
  }

In C++ there's actually a lot more freedom. You can access non-atomic non-volatile-std :: sig_atomic_t variables as long as you don't violate the data race rules.

However, this is a reasonable rare circumstance, and it's only getting easier to charge.

Also the power consumption makes this mostly useless for battery operation. Overall I'm still not impressed by the 2040. I'll stick with the NRF52840.

This is very obviously wrong. The economics of crypto mining are almost entirely dominated by power cost. Nvidia's decision here simply means they will use other hardware, not more of the LHR hardware.

Nvidia already can't make enough GPUs to satisfy demand. Why would they try to increase undesirable demand (which is going away soon anyway, at least for ETH).

ASLR has nothing to do with the type of memory layout discussed here. ASLR only impacts compiled code/data, and only entire shared objects/executables at a time.

A bad memory layout can have a huge impact on perf. A simple example is iteration order of a 2d array, where not doing sequential access can result in a ~5x slow down.

> Computer thermals when running the test can contribute 40%.

Only if you forgot to apply thermal paste.

Not quite true. For example quite a few orbits around the moon are unstable and you will end up crashing into the surface. This is due to essentially all celestial objects not being spherical.