5 ms·
What types of languages do you see would enable more efficient VLIW compilers? From my limited perspective, I find C one of the easier languages to write optim
by xorcist 5y ago
What types of languages do you see would enable more efficient VLIW compilers?
From my limited perspective, I find C one of the easier languages to write optimizing compilers for, and would therefore expect optimizing compilers to be the most efficient there. 40 years of collective experience of optimizing for C-like languages also helps of course.
Or is it the lack of explicit parallelism in the language that is limiting? Somehow I suspect the limited uptake of better suited languages to be a sign that they aren't very helpful most of the time, and most of the parallel operations people do is more like serving a lot of individually sequential transactions per second, which is something C and unix is pretty good at.
- throwaway81523 5y agoOne well known obstacle to optimizing C is the difficulty of alias analysis. It's easier to do that for languages that don't have C's unrestricted pointers.
- pantulis 5y agoSo Rust comes to mind, right? Anything else?
- rwmj 5y agoFORTRAN or any language with lots of arrays and matrices.
- Semaphor 5y agoSo, APL?
- rwmj 5y agoAbsolutely yes that would make sense (or more likely the modern "derivatives" like J & K)
- jabl 5y agoI suspect if you want a HW architecture for running array operations you'll end up with something like a vector machine (e.g. ARM SVE(2) ) or a GPU rather than a VLIW CPU?
- marcosdumay 5y agoVLIW is basically a more flexible kind of vector machine.
- jabl 5y agoAnd a traditional scalar architecture is more flexible still. The trick is to pick the correct set of tradeoffs for the targeted applications. I claim that for most array style workloads vector/GPU architectures are flexible enough, and offer better perf/watt and perf/chip area.
- jonathrg 5y agoDoesn't the restrict keyword solve this?
- user-the-name 5y agoI don't think anyone has ever used the restrict keyword, or understood what it does.
- moonbug 5y agoderp.
- jonathrg 5y agoWhat? I use it whenever I have a function that takes two or more pointers if I know they can't refer to overlapping memory. And it's part of the signature for memcpy since C99
- IshKebab 5y agoWhen he said "anyone" he meant "almost anyone". You're an outlier if you use `restrict` regularly. I checked on grep.app, there are 10k results for `restrict` for C code, compared to 700k for `struct` (I know they're not directly comparable but that gives an idea.
- jonathrg 5y agoThat seems like about the right proportion to me - struct solves a much more common problem than restrict does. And to be fair, it is a lesser known feature. But user-the-name is implying that restrict is somehow difficult to use or understand, which I don't agree with at all.
- icedchai 5y agoThat probably explains it. In many shops, C may as well have stopped at C89. I've been working with C since the early 90's. I've never seen any code use restrict.
- jiggawatts 5y agoC is very "pointer heavy", and much code involves chasing linked lists and the like. This tends not to suit VLIW well. Modern languages like Rust tend to produce more instructions for the same high-level logic, but those instructions are easier to schedule for superscalar CPUs. It typically ends up as a bit of a wash on CISC processors, but could be better than C/C++ on VLIW. I guess we'll never know now...
- secondcoming 5y agoC is pointer heavy if you write pointer heavy code
- TickleSteve 5y agoThe TMS320C6678 (C66x architecture) DSPs still use VLIW and work pretty well. Like most DSPs, they're typically programmed using C, for which TI supplies optimised libraries for processor-intensive operations. IIRC, the compiler itself was fairly standard.
- chalst 5y agoC is hard to optimise. Graydon Hoare gave a nice introductory compilers talk that went into some of the reasons why http://venge.net/graydon/talks/CompilerTalk-2019.pdf http://venge.net/graydon/talks/CompilerTalk-2019.pdf
- lmm 5y ago> What types of languages do you see would enable more efficient VLIW compilers? I was thinking of languages where dependencies are more explicit and the idea of a global evaluation order isn't there in the first place. I'd be very interested to see a reduceron-style effort that implemented graph-reduction evaluation on a VLIW processor. > Somehow I suspect the limited uptake of better suited languages to be a sign that they aren't very helpful most of the time, and most of the parallel operations people do is more like serving a lot of individually sequential transactions per second, which is something C and unix is pretty good at. Heh, that was the idea that those barrel-processor SPARCs were designed around. But they weren't so successful in the market either in the end.