davrosthedalek

I think Aaron was not an MIT student. So not really authorized on that network in the first place.

Exactly, never the same state. And still doesn't halt. That's the point. You cannot detect all non-halting programs by detecting if they go into the same state again. They can, but don't have to.

I am not sure I follow? But maybe I misunderstood your quote. It seems any given TM (And for a fixed N, there are only finite many), there are only the two option: it halts, or it doesn't halt. There is no third option? Of course, the question whether you can proof that it doesn't halt, in ZF or ZFC, is a different question. (You can always proof that it halts if you know that it halts. You run it until it halts)

Yes, doesn't change the fact that you do not have to hit such a state to have a non-halting program. I already gave an example: a program that continuously writes to the tape will not stop, and since the tape is always different, will not trigger your loop detection.

What other option is there?

First, TMs don't have a stack. Second, still no recurrent state needed.

Extending a state with additional variables doesn't make a unique state less unique anyway, so "total state" is always more or same unique as "just tape".

Correct, but that's comparable to streaming from CPU memory to GPU memory, which seems to work OK for MOE models. Then again, if model sizes are so large that you need SSDs, maybe not so much.

There is no requirement to have a recurring state when not halting. Indeed, the most trivial machine "write 1 and move right", will never have the same tape state.

Because they want the hype to make the stock go up.

Exactly. And that labeled data could be collected by just recording what they feed jev and what the decision is.

Really needs some details on what hardware is in there / what models it can run.

Well, I guess it's "fast paced".

The price is that you essentially glue CPU and GPU together, which limits total compute, from a size and thermal perspective.

This is really not a limit because of unified memory -- in principle, PCIe GPUs could read/write main memory without the CPU. But it's a limit for /fast/ unified memory, because fast means close.

So unified memory is great as long as the integrated GPU is strong enough. Then it has two advantages: a) probably faster transfer CPU<->GPU (but that's an implementation choice for the non-unified case b) If you either need a lot of memory for the CPU or the GPU, but not for both at the same time, you pay for memory only once.

regarding my brain, my mother might disagree on the laundry part.

And I would say it's actually a more secure future demand channel than the hyperscalers. Openai and co can build their own chips, so they won't buy from NVidia. But they probably won't sell them to somebody else, so everyone who wants to run their own install (and can, not the least because of HF), will buy Nvidia.