FullyFunctional

Ollama made it trivial for me to use claude code on my 48GB MacMini M4P with any model, including the Qwen3.5…nvfp4 which was so far the best I’ve tried. Once Ollama has a Mac friendly version of Gemma4 I’ll jump right on board (and do educate me if I’m missing something).

absolute n00b here is very confused about the many variations; it looks like the Mac optimized MX versions aren’t available in Ollama yet (I mostly use claude code with this)

Thanks :) I’ll try to remember

AV1 on RK3576, which has very preliminary support

This peaked my interest, but I have no idea which device might have a RK3576

Backwards. The incompetent Transmeta board picked a VP from NVIDIA to be the CEO and his first action was to kill the IBM contract and move to TSMC, and forced TSMC to use a new unqualified process. This left us without chips to sell for over a year and notebook venders were furious and never returned.

This is what killed Transmeta, not all the technical details.

The Dynamo project was the genesis of a similar effort at Sun Microsystems which was the genesis of Transmeta Corp (all founders came from Sun). The question remains if the original study was flawed or if the situation was just too different for our x86 workloads.

I wrote an entire graphical Go-game tree based editor in Lisp, with a stylus on PalmPilot. I considered it an artistic expression.

As I hate tapping on glass, mistyping non-stop, I’m always evaluating options. This is an awesome project and a great write up, but we want more! :) Please consider published a video so we might see it in action (also showing the build process would be appreciated).

Twiddler really isn’t the same product at all

Yes, but this is way beyond that IMO. Really lovely project that I of course must build

Back then it was extremely rare for me to play anything more than a few minutes but Syndicate was fun, not too hard, and I remember finishing it. I was recently feature on a retro gaming YT channel which I suppose is why it’s here.

I haven’t tried it, but it claims to compress better than zstd which is a bold claim. The perf claims are meaningless without citing the exact benchmark platform details.

Completely false. The 4 KiB page size came from a machine with a total of 512 KiB (1962 Atlas, 3072B pages, 96k 48b words). It hasn’t scaled at all for inertia reasons and it has real and measurable costs. 64 KiB would have been the better choice IMO, but 16 is better than 4.

Or some combination of the two. Obviously sounds expensive but 20 years ago this would have been fiction. I think it’s entirely likely that energy storage and production will continue to fall enough in price to make this realistic.

why is that funny? I’ve done exactly this (in a processional setting): c2rust to get something functional and then incrementally rewrote the code while producing unit tests (approval tests via insta are particularly handy). The end result was a codebase which was much easier to maintain, with much better tooling and tests.

I vaguely remember the NEWS workstation at the time, but it was seen as weirdly different and it wasn’t that cheap compared to the competition. Also, loads of companies came out with diskless terminals — is there any evidence that Sony was a frontrunner here?

It is fun to contemplate the alternative universe in which Sony stayed in the workstation market, but I think Sony was more like DEC than Sun, and it would have ended the same way for all.

Hmmm, I still don’t understand why I would care. Andy’s videos show a UI that is geektastic, as in, I could probably work with this but my non-technical peers couldn’t be bothered with anything more complicated than WhatsApp or Signal.

That’s pretty neat. I’ve always been in two minds about J/APL but at least now I can read the semantics in a precise manner.

Thanks. I'm curious about the internal representation. Is Turboshaft using literal SSA names for sources and destinations, or are destination implicit somehow?

Thanks, finally a signal in this thread of noise. I found it unbelievable that all media presented it as if it was his decision. Of course it wasn't.

I "predicted" this three months ago (really, it was inevitable), but gave it 1-6 months.

Now for the what-happens-next popcorn. In a normal world, they would go bankrupt, but this is very much not a normal world.

The floppy drive in the Itanium I owned used the IDE interface. Go figure.

That's not even true as you can get lots of exceptions for the same instruction. For example a load can all of these and more (but only one will be reported at a time): instruction fetch page fault, load misaligned, and load page fault.

More characteristic are assumptions about side effects (none for integer, and cumulative flags for FP) and number of register file ports needed.

Example: this is a small program

int main() { for(;;); }

That was my first introduction to C and I hacked a lot on that code. A very enjoyable time was had.

My only regret with Rust is that a “Small Rust Compiler” will be an order of magnitude larger.

I have 40 years of C muscle memory and it took me many tries and a real investment to get into Rust, but I don’t do any C anymore (even for maintenance- I’d rather rewrite it in Rust first).

Rust isn’t in a difference class from C, it’s a different universe!

I didn't read the whole thing, but the author briefly mentions VFIO which would have given him access to interrupts so it would have been possible (but for flat-out performance, polling is the only thing fast enough).

I wrote a small NVMe user-space driver using VFIO more than a decade ago this way. Coming from having virtualized ATAPI (SATA) and SCSI, NVMe was such a refreshingly excellent design.

These features keeps me solidly with ZFS (since a decade):

0. Cross-platform (I use ZFS on Linux, FreeBSD, and [previously] macOS).

1. Pervasive check-summing/scrubbing, protection from silent bitrot

2. Low-cost COW snapshots (which can be directly accessed with ~/.zfs/snapshot)

3. Steaming file system state with zfs send / zfs receive (this is super important for backup and replication)

AFAIK, no other FS has all of this.

There is a lot of stuff behind the scene you don't know. You statement about "other companies" is completely wrong.

The expansion of a 16-bit C insn to 32-bit isn't the problem. That part is trivial. The problem (and it is significant) is for a highly speculative superscalar machine that fetches 16+ instructions at a time but cannot tell the boundary of instructions until they are all decoded. Sure, it can be done, but that doesn't mean that it doesn't cost you in mispredict penalties (AKA IPC) and design/verification complexities that could have gone to performance.

It is also true that burning up the encoding space for C means pain elsewhere. Example: branch and jump offsets are painfully small. So small that all non-toy code need to use a two instruction sequence to all call (and sometimes more).

These problems don't show up on embedded processors and workloads. They matter for high performance.

Due to speculative out-of-order execution, it's not just "a few cycles". The LSU has a hard, small, limit on the number of outstanding loads and stores (usually separate limits, on the order of 8-32) and once you fill that, you have to stop issuing until commit has drained them.

This discussion is yet another instance of the fallacy of "Intel has optimized for the current code so let's not improve it!". Other examples include branch prediction (correctly predicted branch as a small but not zero cost) and indirect jump prediction. And this doesn't even begin to address implementations that might be less aggressive about making up for bad code (like most RISCs and RISC-likes).