Hacker News Reader

Comment by Retr0id | Hacker News Reader

Something that frustrates me a little is that my system (apple silicon) has unified memory, which in theory should negate the need to shuffle data between CPU and GPU. But, iiuc, the GPU programming APIs at my disposal all require me to pretend the memory is not unified - which makes sense because they want to be portable across different hardware configurations. But it would make my life a lot easier if I could just target the hardware I have, and ignore compatibility concerns.

View on HN

You can. There are API extensions for persistently mapping memory, and it's up to you to ensure that you never write to a buffer at the same time the GPU is reading from it.

At least for Vulkan/DirectX12. Metal is often weird, I don't know what's available there.

Unified memory doesn't mean unified address space. It frustrates me when no one understands unified memory.

If you fix the pages tables (partial tutorial online) you can have continuous unified address space on Apple Silicon.

Let’s be honest, saying “just fix the page tables” is like telling someone they can fly if they “just rewrite gravity.”

Yes, on Apple Silicon, the hardware supports shared physical memory, and with enough “convincing”, you can rig up a contiguous virtual address space for both the CPU and GPU. Apple’s unified memory architecture makes that possible, but Apple’s APIs and memory managers don’t expose this easily or safely for a reason. You’re messing with MMU-level mappings on a tightly integrated system that treats memory as a first-class citizen of the security model.

I can tell you never programmed on an Amiga.

Oh yes I programmed all the Amiga models, mostly in assembly level. I reprogrammed the ROMs. I also published a magazine on all the Commodore computers internals and build lots of hardware for these machines.

We had the parallel Inmos Transputer systems during the heyday of the Amiga, they where much better designed than any the custom Amiga chips.

Inmos was a disaster. No application ever shipped on one. EVER. It used a serial bus to resolve the problems that should have never been problems. Clearly you never wrote code for one. Each oslink couldn't reach more than 3 feet. What a disaster that entire architecture was.

I shipped 5 applications on an 800 Inmos Transputer supercomputer. Sold my parallel C compilers, macro Assembler. Also an OS, Macintosh Nubus interface card, Transputer graphics cards, a full paper copier and laserprinter. I know of dozens of successful products.

Sure you did. What were they? The only successful transputer was the T414 and it never made it outside academia.

Well, I believe there were military radar projects that shipped in reasonable quantities and served for reasonable lifetimes.

I think I remember some medical imaging products as well?

I don’t dispute that the Transputer was ultimately unsuccessful, but it wasn’t completely unused in real-world products.

See also TI’s C40, which was quite similar and similarly successful.

Hey don't shit on my retro alternative timeline nostalgia. We were all writing Lisp programs on 64 CPU Transputer systems with FPGA coprocessors, dynamically reconfigured in realtime with APL.

/s/LISP/Prolog and you've basically described the old "Fifth Generation" research project. Unfortunately it turns out that trying to parallelize Prolog is quite a nightmare, the language is really, really not built for it. So the whole thing was a dead-end in practice. Arguably we didn't have a real "fifth-gen" programming language prior to Rust, given how it manages to uniquely combine ease of writing parallel+concurrent code with bare-metal C like efficiency. (And Rust is now being used to parallelize database query, which comfortably addresses the actual requirement that Prolog had been intended for back then - performing "search" tasks on large and complex knowledge bases.)

You probably already know about https://github.com/mthom/scryer-prolog are you saying we should accelerate scryer-prolog with a Grayskull board?

Also, the Fifth Generation computer project subscribed to the old AI paradigm, not based on statistics.

Not true. "just fix the page tables" took me 4 hours. And only 15 minutes with the Linux kernel on Apple Silicon.

Obviously you missed the sarcasm.

I know the APIs don't make it easy, that's precisely why I want different APIs.

Reply on news.ycombinator.com