3 ms·
I’ve been a fan of this article for years, though it does often make me think that there really aren’t any true low level languages for our super scalar modern
by legobmw99 27d ago
I’ve been a fan of this article for years, though it does often make me think that there really aren’t any true low level languages for our super scalar modern CPUs. Does anyone know of any?
- MrBuddyCasino 27d agoIn what way would exposing the true microcoded out-of-order etc nature of the beast benefit certain tasks?
- legobmw99 27d agoBetter control over the async nature of the hardware is part of what makes GPU kernels efficient, but I'm not terribly sure the same thing would be the case on the other side of the PCIe bus. But even before you get to out-of-order/speculative execution, I think most languages lack good (i.e. non-intrinsic-based) support for wide registers or anything SIMD related. I know C++ and Rust are both working on this
- 12_throw_away 27d agoIt's a good and interesting question, why is it important whether or not it will "benefit certain tasks"? And how would we even know if we haven't tried it?
- jjtheblunt 27d agoVLIW investigated this idea, where the compiler took responsibility for scheduling multiple functional units at compile time, in contrast with dynamic reordering as in superscalar. https://en.wikipedia.org/wiki/Very_long_instruction_word https://en.wikipedia.org/wiki/Very_long_instruction_word
- aDyslecticCrow 27d agoThe article does make an example quite early; > GPUs achieve very high performance without any of this logic, at the expense of requiring explicitly parallel programs. GPU cores are in some ways closer to "PDP-11", they're either acting as thousands of parallel simple processors, or expose pretty raw instructions for very parallel use-cases.
- legobmw99 27d agoThat seems fair, CUDA kernels and shader code do feel like they're at a similar level of abstraction over the hardware as C was to the PDP-11. But I do think there isn't really an equivalent for modern CPU ISAs
- aDyslecticCrow 27d agoMabie hand-rolling LLVM IR representations would count.
- jpollock 27d agoDoesn't assembly allow devs to ignore speculative execution as well? You can place LFENCE(x86)/CSDB(arm) around code blocks, but you can do that in C too.
- giancarlostoro 27d agoProbably Mojo, it doesnt just talk to your CPU it also will talk to your GPU bypassing the need for CUDA. Its early days, but I see strong potential in Mojo. Currently its primary focus is GPUs for AI inference, but give it a year or two and it will be really interesting for more than just that.
- deleted 27d ago[deleted]
- poly2it 27d agoBut Mojo is a high level language?
- giancarlostoro 27d agoWith intimate low-level capabilities. Just because a language can get deeply low-level, doesn't mean it needs to look complicated...
- poly2it 27d agoThere are many other languages we could consider low-level based on the premise of them allowing low access (e.g. "raw" assembly). We don't, because it would be nonsensical to judge the height of a language based on its abilities to forgo the abstractions it was built to provide.
- huijzer 27d agoMojo to me seems like a high level language with some additional support for low level control especially around GPUs. A bit like Rust or C but with more streamlined Python integration and more low level GPU (matrices) support.
- kllrnohj 27d agoIn the case of this article, even assembly isn't low level. It's not possible at all to write low level code for a modern superscalar CPU. So no, Mojo wouldn't be low level. It can't be.
- ferguess_k 27d agoWondering can we write microcode? That's definitely closer to the metal.
- wat10000 27d agoThat was kind of the original idea of RISC. Expose simple instructions that could be implemented without microcode. Push the complexity into the program instead of the microcode. Instead of writing a memory-to-memory add instruction that decomposes into load, load, add, store microcode, you directly write the load, load, add, store. This didn’t quite work out in the long term since hardware evolves faster than ISAs. Today’s “maps directly to the hardware” instruction is tomorrow’s “we add more hardware and play tricks to make this faster.” You explode all of the physical registers as logical registers, then a few years later you double the physical registers count and do clever mapping to extract more speed. My favorite is the MIPS branch delay slot. Instead of complicated branch prediction to hide latency, expose the pipeline directly to the programmer. And then a couple of hardware generations down the line, the pipeline becomes much longer and more complicated and the CPU is back to playing tricks to hide latency, and the weird branch delay slot remains as essentially a vestige of bygone days.
- parlortricks 26d agoIs eMIPS something along the same idea https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/ ?
- jjtheblunt 27d ago> really aren’t any true low level languages for our super scalar modern CPUs do you mean low level but higher level than assembly language for those processors (like MIPS assembly for an R10k, for example) ?
- glouwbug 27d ago[dead]
- lelanthran 27d ago[flagged]
- melodyogonna 27d agoThe thing is, you can only program what is programmable. If a CPU has some capability that isn't programmable, I don't know what C or any other language is expected to do.