Comment by ggm | Hacker News Reader

Comment by ggm | Hacker News Reader

Parent Full thread

My favourite myth is that I still believe it's possible to write code which operates totally out of L1 and L2 cache. Not just tight ASM on bare metal: C code or similar, compiled down, to run under a modern UNIX/POSIX os on a multi-core host.

I have never explored HOW this would work, or WHAT I would do to achieve it, but I believe it, implicitly. For it to be true I would have to understand the implications of every function and procedure call, stack operations, actual size of objects/structs under alignment, optimisations in the assembler to align or select code which runs faster in the given ALU, none of which I know (if I ever did, certainly not any more)

But still: I believe this myth. I believe I know somebody who has achieved it, to test some ideas about CPU's ability to saturate a NIC at wire-rate, with pre-formed packets. He was able to show by binding affinity to specific cores and running this code, he could basically flood any link his CPU was capable of being exposed to, for a given PCI generation of NIC speeds available to him. (as I understand it) -But that assumes that walking off L2 cache would somehow make it run SLOW enough, to not be able to do this.

So I think it remains a myth, to me.

As mentioned in another comment, this literally happens during system bringup when you don't have working RAM yet - link training involves a lot of state and you can't do it in registers alone, so the cache is configured in such a way that you can use it as RAM (I /think/ this is just a special case of write-back where you never actually do the write?). As long as you're not doing DMA I don't see any reason why you wouldn't be able to bring up a system with empty RAM sockets and just launch Doom out of firmware flash.

> I /think/ this is just a special case of write-back where you never actually do the write?

Sort of! A typical implementation (from what I've seen, anyways) is that you have a memory mapped region which, when cache-as-RAM is activated, directly indexes into some cache (typically the LLC). From a hardware perspective, it's a full second address decode mode where you essentially just access the data array without performing tag check/write. When coming in to CAR mode, the cache typically needs to flush, but when leaving it really doesn't need to do anything (assuming it didn't update the tag array and left all lines as invalid).

With the size of some modern SoC's LLC, you could fairly easily run DOOM out of CAR. It'll depend on the SoC, but there's no reason why DMA wouldn't work as other agents would still be able to send read and write requests to the CAR memory region.

Modern CPUs are pushing 1MB L1 and 8MB L2 or more. You can fit a dozen FreeRTOS instances in that space. It would be pretty cool to see someone build a system that used a high end CPU but didn't have any installed ram, though I'm not sure if the CPU microcode would be ok with that.

Those numbers are for all cores. No modern CPU has anywhere near that of L1 and L2 per core.

Modern, no.

Some used to, however.

PA-RISC PA-8200 (1997) had 2MB iCache and dCache, up from 1MB of PA-8000. The last two PA-RISC models did 768kB L1 per core, with 32MB or 64MB of L2

Apple’s p-cores have 192kB L1 (data, another 128k i$) and 4MB L2 per core. The L2 number is at least “close” to what GP said, I guess.

For context, the latest 7950x has 64KB of L1 per core, and 1MB L2

And I know we were talking about L1/2, but Epycs can have over 1GB of total L3.

You could boot Windows XP or Linux in that comfortably. Even run an older web browser or computer game. That’s crazy!

The L2 especially is more than enough for FreeRTOS though, thats 3 times the amount of memory my board has.

In the '80s you could run a fully preemptive-multitasking OS with a point-and-click GUI, games and office applications on 1MB of RAM.

Some SoCs will let you directly/explicitly use the cache as (ostensibly secondary) RAM, remapping your configuration from

    [cpu] -- [cache] -- ram

to

          [   cpu    ]
            |      |
        [cache]  [ram]

Here's TI's documentation on doing just that CC13x2/CC26x2 family of MCUs: [0]. In this case, it's a seemingly paltry 8K of "RAM" but that's a lot for microcontroller developers! In this configuration and for this particular MCU, the CPU will actually run at a reduced speed (60% of its norm), probably because it needs to synchronize directly against the RAM. If you were to use it in CaR-only mode (which I don't think TI exposes), i.e. with the cache being used instead of rather than in addition to any RAM, you probably wouldn't need to run at those reduced speeds (and might even be able to run at higher clock speeds!).

[0]: https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_...

I mean, your computer likely does this during boot when it’s in cache-as-RAM mode

I guess that means my favourite myth that I've done it. Get the os out of the way, cpu pinning, user level network stack, no system calls after setup, lay out all your memory carefully in a cache line aware fashion noting the virtual addresses & bits 6-10. io via shared memory to another core on the same package.

I convinced myself looking at latency benchmarks as I went about optimising it that it was all in L1.

ISTR that is how a modern CPU will boot, before the DRAM interfaces have been calibrated and brought up. The initial startup code uses cache as RAM.

If you only boot one EFI process, or a small linux kernel + single binary small enough, you can get there.

so I'm imagining speedyOS which assumes one core for the OS, and runs its userspace jobs on the other cores, and if you wire a job to a core and its been coded to fit in L1/L2 then.. it just "does" -as long as the other jobs are somehow co-erced to run in the other cores, "swapping" in and out as need be. If you can prevent any clicktick disrupting your run state on this one "golden" user core, it just runs as fast as it can, subject to the OS timeslice effects on it, and any unavoidable synchronisation into other bits of the combined CPU/ALU/Memory/Bus system as a whole.

Doesn’t KDB+ and one of the more esoteric array-based languages (J/Q or such?) essentially claim this?

Sort of (not in the sense meant by the parent), and it's nonsense regardless https://mlochbaum.github.io/BQN/implementation/kclaims.html#...

Well cool, TIL!

Reply on news.ycombinator.com