The last oddity I wrote on a whim was a C++ MFC dialog application that was a Spirograph-like epicycle/hypocycle generator. It would would generate screen art by semi-randomly generating layered epicycles and hypocycles with evolving colors. I spent an entire week of evenings tweaking that thing and adding more and more variations before I burned out on it and moved on.

When I was in the CS department at NMSU, the Computer Science building was open to the public 24-hours a day. I suppose that's not commonly the case nowadays.

FWIW the building from the article is open to visitors during extended working hours.

Source: Currently in the building.

Every new generation of GPU seems larger and more power-hungry than their predecessor. Is there any effort to produce faster GPUs that are smaller and use less power?

Yes.

Every new GPU generation delivers more performance/W than the previous generation (mostly due to semiconductor process improvements) But the competition to have the fastest chip means that total power usage keeps growing.

Power efficient chips just doesn't generate headlines the same way.

And it doesn't help that game companies have little incentive to obsess over squeezing the absolute most performance out of the hardware when customers care more about "Jaw dropping visuals" and raytracing than knowing that the game can pull 60fps on 10 year old hardware.

There hasn't been competition to have the fastest chip for 4 generations.

We observe larger and more power hungry at the high end, because those models are selected for maximum performance - at the expense of everything else.

But GPU power efficiency (gflops/watt) has been increasing at an exponential pace as well - over the last decades it has been consistent doubling every 2-3 years. So over 10 years we have had 10-30x improvements in power efficiency. The same is true for cost efficiency (gflops/dollar).

I think the limitation here is more with the process nodes then with the GPU architecture

A multi graphics chiplet GPU could be more efficient

- Face and object detection in photos and videos

- Computational photography features like Night Mode and Smart HDR

- Real-time video processing for effects and stabilization

- Object and action recognition in videos

- Faster on-device speech recognition and natural language understanding for Siri

- Real-time translation, object detection, and scene understanding in AR

I was at NMSU during his time as head of the CS department. His interest in chess inspired to write my first chess playing program

I usually keep all my work in a stash until I'm ready to create the PR. I used to preface my intermediate commits with "WIP -" and then reset the branch and re-commit everything when I was ready to create the PR, but that was just too much effort

You don't need to reset the branch. Using rebase -i, you can squash all your WIP commits that way.

You can also use it to split and individually pick changes if you want to clean up your commits.

You can automatically fix up commits after review commits using git absorb [1].

[1] https://github.com/tummychow/git-absorb

As a big fan of interactive rebase, when cleanint up a chunk of commits I do a reset as reset the OP described (smetimes mid rebase). It's convenient for inspecting all your changes together, and you can pick and choose changes into different commits easily too... Pretty much equivalent, but I find it more straightforward for some things.

Casey Newton proposed, partly tongue in cheek I think, that as LLMs advanced, it might spur investment in and a newfound appreciation for Journalism as way to provide fresh source material for the models

How would that investment generate a return, though?

"Google and OpenAI discussing agreements to pay over using content to train AI" - https://news.ycombinator.com/item?id=36368743

Especially given GPT-based news summarization services.

I would go a step further and teach them how to read code before teaching them how to write it

It's much harder to sneak in an easter egg now that it's common practice to require all code to go through code review.

Have to try to figlet a comment banner at least.

Is it possible that Elon Musk intends to use the next six months for Tesla engineers to catch up with OpenAI? As a significant funder of The Future of Life Institute, which authored the letter, his concern for the safety of LLMs seem to contrast with Tesla's history of beta testing potentially hazardous AI software.