bigcheesegs

UB is a choice in that we could require symbolic execution of of all code. This is incredibly slow, so we don't.

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

"state's monopoly on violence" means that a state's power to enforce its rules is rooted in its ability to use violence on those that refuse. Putting someone in jail is not physical violence, but what keeps them there (and why they even showed up to court) is the near guarantee of violence if they refuse.

LLVM does this on x86 because partial register writes don't break dependency chains in many cases, meaning that you can get stalls due to false dependencies.

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.

In C++ this violates the data race rules both with and without volatile, but because it's sig_atomic_t it has a special carve out _only_ if it's volatile. See https://eel.is/c++draft/basic#intro.races-22

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

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.

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

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.

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

Very surprised 17net only has 1.

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.

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.

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.

Encoding space, not die space.

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

Do you have any examples? std::launder fixes an issue that has existed since C++98.

You don't actually want implementation defined behavior. There is no restriction on implementation defined behavior, it just needs to be documented. Suitable documentation includes "the optimizer assumes this never happens and optimizes accordingly.", or "Look at the source code."

> I don't believe RAM layout is that important. [...]

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.

Could be 1. Just adopt the C++ std as the C std.

> they stay orbiting indefinitely

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.

This is incorrect. I participated in the committee discussions around launder, byte, pointer provenance, and implicit object creation. None of those issues show up here. This is a very simple case of using placement new into a properly aligned char buffer to create an object at that location. This has worked just fine since C++98 and is not impacted by the many other object/lifetime/pointer issues that are being discussed.

Additionally, implementers are in completely agreement here that this works. There are zero standardization/implementation concerns with this method, and I would highly advise against scaring users away from it when necessary.

How? You limit physical over the air bandwidth, that inherently limits baud, but you don't need to do so explicitly.

Yes. There are no plans for binary module compat between compilers, or different versions of the same compiler for gcc and Clang.

I love that exceptions are the classic case for this, because it's not even true that "zero-cost exceptions" are zero _runtime_ cost on the non exceptional path. The most trivial example is they block vectorization.

This is not at all how monitor marketing works. Every company gives them insane nonsense names. There is no other identifier. for XR382CQK bmijqphuzx there is no product line or model other than "monitor". That's all you get.

Compiler dev here. Do you really think we just come up with code transformations and add them to the compiler just because?

All code transformations have a compile time cost and runtime perf impact. We don't add transformations unless the runtime perf impact greatly outweighs the compile time cost.

These optimizations are added because they measurably improve the performance of real code. This comes up in every review for new or updated optimization passes. This claim that they aren't justified is actually rather insulting to the effort put in to improve perf without taking days to compile.

Yeah, I was about to post about this. Note that implementation-defined behavior and unspecified behavior are not _only_ used in places where a choice is given. Quite a few uses of implementation-defined behavior do not actually select between options. It just says the behavior is implementation-defined. So I suppose it selects between infinite options.

For this kind of behavior there is actually no limit on what the implementation is allowed to do, including assuming it never happens and optimizing accordingly. Implementations just need to document what they do.

I don't think these attempts to change the definition of UB are useful. As a compiler vendor it doesn't help to just say "it has a behavior", because that doesn't stop me from doing exactly what I do today. If people want some specific behavior, or to limit behaviors, then they need to actually say that in the spec.

To take left shift for example. Instead of saying it's implementation-defined behavior, they should say that it produces a implementation-defined non-trap value in the range of the resulting type that is consistent for the same inputs.

This would be pretty short to write in standardees, doesn't allow UB based optimizations, and allows the required implementation divergence.

I seriously doubt it. The PS4 has a custom graphics API which directly creates command buffers in the GPUs native format. There's not really much of a graphics driver at all other than what's necessary to isolate the game from the OS.

> Opening the binary with Binary Ninja revealed that clang had already managed to leverage the SSE registers.

X86-64 uses SSE registers for all floating point operations. I'm not sure that the author realized that they were looking at an -O0 binary. -O0 does not do vectorization (or anything else for that matter).

Some of things are exempt from those rules. RoHS currently exempts some medical and industrial devices.