4 ms·
Great article but I've got one question. If they have to read the assembly created by the compiler to understand how to write Rust code that the compiler could
by pmontra 5y ago
Great article but I've got one question. If they have to read the assembly created by the compiler to understand how to write Rust code that the compiler could optimize, why didn't they directly write assembly code?
- dtgriscom 5y agoPortability?
- shadowofneptune 5y agoIt's much easier to read assembly code than to write it. You're only looking for the necessary performance in a few hot-spots. Everywhere else the convenience of a high-level language is welcome. With the tail-call optimization, it's really only a fact of how programming languages are implemented that you need to look at the assembly. In a language that guarantees tail calls, or has a special tail-call keyword, you could forget about what's going on at the instruction level.
- dspillett 5y agoPortability: one you hand-code assembler for an architecture you lose compatibility for others. Unless you provide multiple code paths to account for this, but that increases testing and maintenance requirements. Future optimisations using better on-chip features, or other new techniques: new instructions that reduce the task might get used by the compiler but it won't update your section in hand-coded assembler. Maintainability: you don't want to force larger parts of your workforce/community to be familiar with assembly if it is not useful day-to-day, or lock your assembly capable people to maintaining those hand-written-assembly portions.
- pmontra 5y agoUnderstood. About maintainability I guess that that code must be marked as do not modify, or the compiler will walk out of the optimization path. Future developers on that project must know very well why that code is written like that. Furthermore any new compiler or CPU could break the optimizations.