emacs28

First author here. The hardware architectures are realistic - we developed & evaluated real example hardware implementations for them, validated on FPGA, and they achieved state-of-the-art ResNet performance in a deep learning accelerator system implementation compared to prior accelerators evaluated on similar FPGAs. See the associated accelerator system source code here:

https://github.com/trevorpogue/algebraic-nnhw

The hardware architectures focused on in the paper are systolic array designs, an efficient type of hardware design for matrix multiplication (e.g., the Google TPU uses this), as opposed to more SIMD-like vector architectures like GPUs. It may be possible to extend the proposed KMM algorithm to other types of hardware architectures also in future work. Regarding floating point - this work is applicable for integer matrix multiplication acceleration, it may be possible to extend the concept to floating point data types in future work also.

It produces identical/bit-equivalent results as conventional/naive matrix multiplication for integer/fixed-point data types

For everyone discussing the reduced accuracy/numerical stability of the algorithms in floating-point, this is true. But note that the application of the algorithms in the work is explored for fixed-point MM/quantized integer NN inference, not floating-point MM/inference. Hence, there is no reduction in accuracy for that application of it compared to using conventional fixed-point MM.

you have to build hardware that matches the dimensions of the algorithm

Yes the benefits are realized in custom hardware designs as opposed to software, however, the hardware architectures work for multiplying matrices of arbitrary dimensions by splitting up larger matrices into smaller tiles, then summing up the tile products to form the final larger matrix products (i.e. GEMM)

Thanks, good summary. Regarding numerical stability, the application is for fixed-point arithmetic, and therefore numerical stability is not an issue (the result is identical compared to using the conventional inner-product)

IMHO, for fixed-point MM accelerators, there is no catch, I think it's an overlooked algorithm. It's based on an algorithm by Winograd who coincidentally also proposed another unrelated algorithm that later became very popular for CNN acceleration which would take some visibility away from this other algorithm by Winograd... But that is speculative

Personally I love my overpriced Samsung z fold, I don't use a laptop anymore (just a desktop), I can easily read double-column research articles wherever I am, it's great for drawing diagrams, and all of that without having to remember both your phone and a tablet everywhere you go.

CCX stands for Core Complex

CCD stands for Core Complex Die (and neither terms refer to the IO die)

This can be resolved by changing the cells' format from General to Text. This makes the cells display the text exactly as entered. Select the relevant cells -> right click on them -> Format Cells... -> Text -> Ok

One good approach could be to base the architecture on the TPU v1 from [1]. There are also open-source accelerators you could get inspiration from, for example [2][3]. If you want to do less work/not hand code the RTL yourself then you could look into methods for automatically mapping OpenCL to an FPGA accelerator architecture (or a service like [3] provides pre-designed architectures for multiple FPGAs).

[1] https://arxiv.org/abs/1704.04760

[2] https://github.com/jofrfu/tinyTPU

[3] https://github.com/tensil-ai/tensil

The best productivity hack is to get a keyboard with programmable QMK firmware and remap the keys however/wherever you want.

When in Emacs I use a custom command that converts lowercase underscore-separated words to uppercase after typing the word out in lowercase so I don't have to use shift or capslock.

Yeah I haven't seen it done elsewhere, but I started doing that because those 2 inside keys on the third row are where my thumbs sit naturally if fully rest my hands.

I'm down to a 32-key layout, you can see my layout here

https://configure.zsa.io/moonlander/layouts/wyyxP/latest/0

(The layout currently has more than 32 keys due to extra function keys on the sides and modifiers on the bottom that I only use very rarely. I also no longer use the top pinky keys anymore.)

I have a vim-inspired modal mapping with three main modes: normal (navigation with arrows, pgup/dn, tab switching, etc.), mouse (to move the mouse), and qwerty (for typing). There is one always-present key for each mode that is dedicated only to switching permanently to that mode. These keys are on each of my thumbs, and the third on my right pinky. Each mode also has several unique (and some shared) temporary layers accessible by temporarily holding other keys.

I use a moonlander keyboard but my thumbs sit on the inside keys on the third row, and my palms on the top larger keys that are intended to be used for thumbs.

Do you have a CI badge to show build/test status? This signal would better reach important parties by emailing maintainers or automatically creating an issue.

I find a CI and coverage badge worthwhile because they provide a quick reassurance that the project at least has some form of test plan, which immediately distinguishes it from many other repos.

There is a standardized API for package tools to expose and invoke editable-install functionality [1] which pip install follows, but Poetry didn't implement this API before (I see it does now though as of this past February [2]).

In other words, this a more thorough explanation of my point from [3]:

Yes, if you ran poetry install you could get editable mode, but that requires every single end user of your package to install poetry and explicitly invoke a poetry install just for your package. And if someone else's package uses a different package builder, now they need to install and invoke that one. And on and on, and you end up with a six-hundred-line install script because of all the one-off "must install this developer's favorite package manager to use their package" stuff.

[1] https://peps.python.org/pep-0660/

[2] https://github.com/python-poetry/poetry/issues/34#issuecomme...

[3] https://www.reddit.com/r/Python/comments/t3p3ub/comment/hyum...

What I mean is `pip install -e` installs it outside of the virtual environment also.

Thanks, I think that the thing this still lacks compared to `pip install -e` is that the develop dependency is then only visible inside other packages configured with poetry. So it is not useful for example if you want to locally install a package you make to be accessed through cli or any other python script not using poetry.

My only gripe with poetry is that when I tried it out last year there was no equivalent for `pip install -e` which can be used to install other python package dependancies that you are simultaneously developing. I found that feature useful enough to stick with setuptools and setup.py instead.

You know what you're right, the command

  git commit --all --amend --no-edit

indent the code block to fix :)

Thanks!

Also: why this over a stash?

I just like this better because with stash you have to do one more command (stash pop) to get the changes back after switching back to the first branch, but this way the changes are already there when you switch back.

I made a simple script below I find useful that commits current changes then automatically rebases and squashes it with the previous commit, preserving the previous commit message. I find it useful for a way to quickly save current changes before switching branches, or for easily backing up work before its worth making a new separate commit:

  git add --all
  git commit --fixup=HEAD~1
  GIT_SEQUENCE_EDITOR="sed -i -re 's/^pick (.*)fixup! (.*)/fixup \1\2/'" git rebase -i --autosquash --autostash --keep-empty HEAD~2

Yeah its interesting, multiplication is essentially a convolution of the digits in the two numbers, and convolution is definitely something that FFT is used for.

Fyi I think you got the terms synchronous/asynchronous mixed up here. Synchronous logic is the commonly used technology.

One interesting thing is that modern processors have an AES instruction set [1] integrated into them so that primitive AES operations can be individually called and accelerated in hardware. You can run these instructions from C and it significantly speeds up the AES algorithm compared to writing out the algorithm explicitly in C.

[1] https://en.m.wikipedia.org/wiki/AES_instruction_set

I'm certain I've accumulated 100's - if not 1000's - of hours customizing my editor since I started learning it 6 years ago (sorry I'm an Emacs user not Neovim) and I don't regret 1 hour of it.

I would say my niche language is SystemVerilog (if you count a hardware description language in this discussion).

I've found a couple times now that the reason lsp-mode doesn't work and keeps asking to restart the server is because I had another binary in my path with the same name as the server it's trying to call. For example just today this was happening with pyright, and it worked perfectly again after running "pip uninstall pyright" in a terminal (or maybe it was called lsp-pyright). I believe the lsp-mode keeps its server binaries in a separate folder.

These are good points. Just to clarify, I can't speak for semantic release, but the github-changelog-generator I'm talking about will only add PRs (and issues if you want) to the changelog, not commits (so no non-standard commit message format needed). So you can put anything worth mentioning in a changelog into a PR, and it distinguishes between bug fix vs feature based on the tags added to the PR.

I totally agree with this, I'm not a fan of the written-in-stone nature of commit messages. Just like code, it's nice if log history is editable too in case your forgot something, or if you want the message to mention future changes that back reference it.