Hacker News Reader

Comment by throwaway7645 | Hacker News Reader

I like the simplicity of the website and the authors dedication to releasing both updates & informative articles.

My question (I'm not a systems coder), is how is this really better than C? How can it be even remotely as efficient as a compiler with decades of optimization witchcraft and sorcery? Is it really that much easier to write? I'd be curious in seeing a small 1/2 page code sample difference and seeing benchmarks on performance, compile times...etc. Nim normally jumps to mind as an easy to write language that transpiles to C and is therefore usually fairly equivalent, but is almost as easy to write as python. How does Zig fit in? Also, good luck on the project!

View on HN

> How can it be even remotely as efficient as a compiler with decades of optimization witchcraft and sorcery?

This is just a frontend. The optimization witchcraft and sorcery all lives in the middle/backend, which in this case is LLVM. LLVM can do a decent job optimizing pretty much anything you throw at it, though broadly speaking it works better the more the IR looks like C. For example, Rust does a lot of moves of large structures, unlike C/C++; IIRC pcwalton submitted some optimizations involving those to LLVM, which are language-neutral but which nobody had bothered to implement before because C/C++ didn't need them as much.

Ah didn't know it was using LLVM...thanks.

>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.

Haskell 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.

Plenty 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.

I 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.

Obviously, we should not compare small personal project languages with decades-old industry languages by factors determined by the sheer amount of work thrown in. We compare them mostly by fundamental design principles.

In this case, partial evaluation is a massively more principled and efficient way of doing metaprogramming than preprocessing or macros. There are limitations compared to Lisp-style unrestricted untyped metaprogramming, but not any that I would much miss in practice.

With partial evaluation, we automatically get type and scope safety, and also only need one language instead of several. Optimizations also cascade in a principled way: we can compile code-generating code to fast machine code, which we then use to generate faster code or generate it faster, but the then-resulting code can be also used to generate code, and so on.

I knew I was missing something. Thank you.

At the same time, Zig is basically only a thin layer on top of LLVM. Since it's a low-level language itself, it can get away with having close to no static flow analysis beyond this partial evaluation (and maybe types?)

How can it be even remotely as efficient as a compiler with decades of optimization witchcraft and sorcery?

Using LLVM (which Zig does) gives you access to the same middle-end and back-end optimizations as clang.

Reply on news.ycombinator.com