3 ms·
>How can it be even remotely as efficient as a compiler with decades of optimization witchcraft and sorcery I don't know enough to say anything myself, but i b
by setr 10y ago
>How can it be even remotely as efficient as a compiler with decades of optimization witchcraft and sorcery
I don't know enough to say anything myself, but i believe it mostly boils down to C allowing too much freedom, with tok few constructs, with too little communication between programmer and compiler.
The C compiler must derive certain facts from a given block of code to optimize it in a particular fashion; and the derivation must be correct for all edge cases. The witchcraft and sorecery is in these derivations, and handling pathological edge cases.
AFAIK these C-alt languages tend to skirt this problem by adding language constructs that make certain promises to the compiler, like Zig's comptime attribute and rust's borrow checker. They catch up to C, at least for some common classes of problems, by simply giving the programmer more expressive power.
And then, I imagine, they have an easier time taking some sequence of these (stronger) promises and combining them into further sets of optimizations.
Which is also what "higher level" languages do (more by limiting freedom of action, and increasing expressive ability, than communication with the compiler) and how you get ideas like haskell being as fast/faster than C code in the common case (but won't match handwritten optimized C). A Haskell compiler can make bigger steps more safely than a C compiler can, simply because the language offers more/bigger guarantees with each construct.
- astrange 10y agoHaskell isn't really faster than C - that is, once you know the problem I could write a C program faster[1] than yours and it wouldn't be "carefully handwritten optimized C" as much as "kind of casually handwritten C". (If this is an object-manipulating program and not a numeric one, substitute another language so I don't have do memory management.) The issue is that magic high-level-compiling compilers can't be developed because nobody has time to wait for their compile to finish. This is also why JIT never really optimizes very hard. [1] or more importantly, less memory-using and live profiling tools and gdb will work.
- joosters 10y agoPlenty of people would love to give their compiler time to optimise, in fact they already do, with hours-long build times of some projects. I don't think compile time is the thing holding back compiler development, after all, every time-consuming optimisation can be put behind a command-line switch to allow those who want it to use it, and those who want a fast compile can go without.
- astrange 10y agoI think you'll run into a problem where your optimizations are time-consuming but not actually productive. When you're going low-level like in C, optimizations are famously useless on x86 - you can barely tell if most programs are running at O0 or O3. Going higher level, they should help, but it's really an interactive process so a fast compile/run cycle is still important. You want to know how well the optimizer understands your program and which idioms are safe to use.