Well sure they matter, but “yaoioum” wasn’t really the main point of the post. It was more of a threat; “add refinement types to Rust, or yoric will continue building poorly named static analyzers.”

Yup. I absolutely would throw `#[from]` on everything when I started using thiserror, but now only do so in incredibly obvious cases like

  enum CarWontMove {
      EngineTroubles(EngineTroubles),
      WheelsFellOff(WheelsFellOff),
  }

Even then, there’s often some additional context you can affix at that higher level.

SNAFU follows much the same idea: we have an attribute you can add [0] when you want to allow directly implementing `From`. Like thiserror, you can also mark an error as transparent [1] when even the error existing doesn't provide useful information.

[0]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#disabli...

[1]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#delegat...

The FromIterator impl for Vec is specialized with unsafe code for these cases.

FromIterator is the trait that the collect method uses.

Specialization isn’t a stable feature in Rust, but is used extensively in the standard library.

Are the tweaked reduction rules what you have on this website? I might be misunderstanding, but rule 3 certainly looks different on your website than in Barry’s book.

Could you link typed_program_analysis.pdf? I can’t seem to find it.

I would assume the inverse relationship. That enabling the op cache would reduce power draw. Though I also wouldn’t be surprised if they’re always running the decoder.

The very reason for the Loop Buffer was to let decoder power down within tight loops, so I'd assume micro op cache would have similar effect, except with more impact on performance.

Very curious as to the typical strategy for implementing low power modes on things that are highly latency sensitive like a decoder.

Like would whatever mechanism they’ve got behave well if fetches were alternating between cache hits and cache misses?

it would be cool if the mentioned path traced reference mode was an option in the game.

Exceptions are a special case of general effect systems which do include the capability you describe.

reminds me of nix-shell shebang [0] which enables a similar pattern for scripts of arbitrary languages.

[0]: https://nixos.wiki/wiki/Nix-shell_shebang

and the repo for this project: https://github.com/microsoft/BitNet

The demo they showed was full of repeated sentences. The 3B model looks quite dense, TBH. Did they just want to show the speed?

3B models, especially in quantized state, almost always behave like this.

There was a guess somewhere in the video comments that I found convincing. (I watched the video a few days ago and can no longer find the comment).

It claimed some old chess engines used time limits on certain computations as a means of configuring difficulty. Given more time, the engine may be able to look further ahead.

If such limits were tuned for older hardware, then upgrading the computer could significantly increase the difficulty.