What's everyone working on this week (41/2025)?

community
1

New week, new Rust! What are you folks up to?

2

Heya, I'm working on making a stack trace viewer.

Easier seen then explained:

Screenshot_20251006_204416_Firefox
Screenshot_20251006_204416_Firefox1080×940 222 KB

It:

  1. Parses the stack trace.
  2. Organises the data into hierarchical blocks.
  3. Allows you to collapse or expand the blocks, so you only need to see your frames.

Plenty of styling work to do, as well as generate buttons for detected groupings.

It's all client side as well, so it can be used at work without leaking information.

3

Experimenting witb Hopfield networks on MNIST (handwritten digits).

Hopfield networks build associative memories - encode an image, delete half the pixels and reconstruct the original...

Idea here is to encode the training images with a one-hot representation of the labels (0-9) and then on a test image, do the same except with a blank label and let the network reconstruct the label (and the image).

Usually that results in a classification - but 10% of the time there is no label or there is more than one, E.g.

classify 0: [0, 6]

               .@*
              *@@@*
            .@@@@@
           :@@@@*
          .@@@*. .*@**:
          @@@@. *@@@@@@@
         *@@@@@@@@@@@@@@*
        @@@@@@@@@*:::@@@*
        @@@@@@@:.   .@@@
      .@@@@@@@.     @@@*
      *@@@@@@      @@@.
      @@@@@*     :@@@:
     @@@@@.    .@@@@.
     @@@*    .:@@@@.
     @@@   .:@@@@:
     @@@**@@@@@:
     @@@@@@@@@
       @@@::

Accuracy at the moment is ~88% - which not high for MNIST - there are some weird digits - but you can get 98-99% correct with feed-forward networks.

Hopfield networks are not typically used for this type of task - with so many prototypes - but I like that they use integer (and bit) arithmetic - no floating point.

4

Yesterday after talking about -C target-cpu vs. CPU feature detection, it occurred to me that a simple way to systematically check whether my actual application might benefit from CPU feature detection would be to run benchmarks under -C target-cpu=native and look for the ones which get faster — those are the ones that could benefit from run-time detection (if one is trying to produce a portable, distributable binary and not merely compile with -C target-cpu=native everywhere). This only finds opportunities present on the one architecture, of course.

It's interesting that one particular benchmark takes 72% less time with -C target-cpu=native. That’s far more speedup than I’d expect for the kind of code it is (much more about accessing memory than number-crunching). I wouldn’t be surprised if there is something else to improve there and the previous codegen was suboptimal for reasons unrelated to the availability of partticular instructions — or perhaps I'll learn something new.