Hacker News Reader

Comment by Aissen | Hacker News Reader

I'm wondering if this isn't solving a problem only with a local optimum. How much better would be to have a standard way (i.e, not device-specific) to memzero (or memset) directly into the DRAM chips ? Or to use DMA for memcpy, while the CPU does other things ? Now of course, this could be a nightmare for cache coherency, but I've seen worse things done for performance.

View on HN

In fact the Cell CPU [1] had a DMA facility accessible from the SPU cores by non-privileged software [2]. This worked cleanly, as all DMA operations were subject to normal virtual memory paging rules.

But then the SPU did not have direct RAM access (only 256 kB of local S-RAM addressible from the CPU instructions), so DMA was something that followed naturally from the general design. Also not having any cache meant there were none of the usual cache coherency problems (though you may run into coherency problems during concurrent DMA to shared memory from multiple SPUs).

[edit] note also that the SPUs did not usually do any multitasking / multi-threading, which also simplified handling of DMA. Otherwise task switches would have to capture and restore the whole DMA unit's state (and also potentially all 256 kB of local storage as these cannot be paged).

[1] https://en.wikipedia.org/wiki/Cell_(microprocessor)

[2] https://arcb.csc.ncsu.edu/~mueller/cluster/ps3/SDK3.0/docs/a...

> all DMA operations were subject to normal virtual memory paging rules.

That's the key right there. Many embedded SoC's I've worked with have DMA engines, but they are all behind the MMU and only work with physical addresses. It makes using them for something like "accelerated memcpy" kind of cumbersome and usually not even worth it unless it's moving HUGE chunks of memory (to overcome the page table walk that you have to do first).

Thankfully we're starting to get IO-MMUs on larger systems with DMA controllers like that. Much easier to pass around.

Well, I recently found the Cortex-M SoCs to be a blessing in that regard: no MMU, no need to run a fully fledged operating system, but still with LwIP, FreeRTOS&friends, they can handle surprisingly complex software tasks, while the lack of MMU and privilege-separation means that all the hardware: DMA-engines, communication interfaces and accelerator facilities (2-D GPU) are right at the tip of your hands.

Tis a real shame we did not see SPU-like cores in later generations. The problem that I saw was that instead of embracing the power of a new architectural paradigm people just considered it weird and difficult.

I think had they provided (very slow but) normal path for accessing memory it would have made the situation much more acceptable to nominal developers.

The difficulty in adopting the PS3 basically killed the idea of Many-Core as the future for high performance gaming architecture.

This instruction doesn’t prevent the implementation of doing that, it just gives a standard interface.

Actually, I think it does: you cannot be using the core while it's doing the memset or memcpy, so it's technically not what I'm describing. Even if it did: a cross-industry reference implementation would go a long way into making this a reality.

I'm willing to bet that within 5 years we'll see a CPU that effectively embeds a DMA engine used through this instruction. The way I'd implement it is a small FSM in the LLC that does the bulk copy while the CPU keeps running, while maintaining a list of addresses reads/writes to avoid (i.e. stall on) until the memcpy is finished.

Reply on news.ycombinator.com