bigcheesegs

> 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<bool> 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;
  }

Is valid in C++, but not in C.

Comment · 3 years ago

For 1) lock-free atomics are also allowed.

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.

Comment · 3 years ago

libc++ was open sourced May 11th 2010. 13 years ago. https://blog.llvm.org/2010/05/new-libc-c-standard-library.ht...

Comment · 4 years ago

The LAION dataset, which SD was trained on, is just a list of URLs and textual descriptions. There's no illegal copying going on when StabilityAI trained SD. It's also not illegal for you to do the same thing.

Comment · 4 years ago

I think the much more likely outcome is further research on making the prompts smarter and more human like.

Comment · 4 years ago

Very surprised 17net only has 1.

Comment · 4 years ago

There's lots of overnight street parking in the bay area, but there are lots of other opportunities to charge. The actual hard case is someone that drives a significant amount during the day, doesn't have charging at work, and can't have charging overnight. Here really the only option is DC fast charging.

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

Comment · 4 years ago

I'm surprised there's no 802.15.4/Thread support on a new IoT platform in 2022.

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.

Comment · 4 years ago

No. The economics of Proof of Work mean that increases in compute per watt just lead to an increase in global hash rate. Total energy usage never goes down as long as it's sufficiently profitable to use the energy.

Comment · 4 years ago

Encoding space, not die space.

Comment · 4 years ago

> it seems very obviously a move to force miners to use more GPUs in parallel

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).