Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's New Relationship with LLVM

kristoff.it

Post reply on HN
Print view View original

11–20 of 295 posts

Re: Zig's New Relationship with LLVM

#11

Post by kristoff_it »

tom_mellior wrote: post #7

I don't understand the "in-place binary patching" bit. Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places? Is this expected to be that much faster than writing the whole binary anew? What other benefits is this supposed to have? The article doesn't seem to say. Also, how does this relate to the ob…

> Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places?

Yes.

> Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places?

I'm not an expert, but I believe the point is mostly about other computation required for "normal" linking, not just writing fewer bytes to disk.

> What other benefits is this supposed to have?

It makes the edit-compile-run loop faster when developing.

> Does linking somehow get faster or easier with in-place patching?

That's the idea. When code isn't position independent, moving a chunk of code requires recomputing a bunch of offsets, and similarly the linker needs to do more work when you don't have an indirect way of referring to functions etc.

Re: Zig's New Relationship with LLVM

#12

Post by ikskuh »

tom_mellior wrote: post #7

I don't understand the "in-place binary patching" bit. Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places? Is this expected to be that much faster than writing the whole binary anew? What other benefits is this supposed to have? The article doesn't seem to say. Also, how does this relate to the ob…

Yes, you understood that right. The existing executable file is not written completly anew.

And yes, it will be faster. The way Zig does this is by only recompiling and modifying the parts of the executable where the source has changed. Imagine a project like chromium, where your executable is 150 MB large. Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this. Less I/O, less overall work to do.

Re: Zig's New Relationship with LLVM

#13

Post by alexnask »

tom_mellior wrote: post #7

I don't understand the "in-place binary patching" bit. Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places? Is this expected to be that much faster than writing the whole binary anew? What other benefits is this supposed to have? The article doesn't seem to say. Also, how does this relate to the ob…

Yes, the compiler will open the binary and only emit modified/new code and possibly change some values in a global offset table.

As noted in the article, the same strategy will be used for hot code swapping, which is one of the benefits of doing this.

This is indeed faster than generating new object files and relinking the whole executable. The video linked in the article shows a simple example with the current ELF incremental linker, where compiling the example program takes 1.5 ms while changing a string literal and updating the executable takes about 0.5 ms

Re: Zig's New Relationship with LLVM

#14

Post by kristoff_it »

pedrow wrote: post #10

This is interesting stuff. Could you comment about optimization? LLVM has put a lot of effort into optimizing code at various levels, including the LTO stuff. Will Zig match all this by itself, or will a 'Release mode' still use LLVM to produce a final version?

LLVM is still going to be used for release builds. As of now, the self-hosted backend is dedicated to producing debug builds without optimizations (and with a few extra runtime inefficiencies, as that's the price for faster in-place binary replacement).

Re: Zig's New Relationship with LLVM

#15

Post by ikskuh »

pedrow wrote: post #10

This is interesting stuff. Could you comment about optimization? LLVM has put a lot of effort into optimizing code at various levels, including the LTO stuff. Will Zig match all this by itself, or will a 'Release mode' still use LLVM to produce a final version?

The overall idea is to have a selfhosted compiler for debug and release builds where the release build as ~80% of LLVM performance and use LLVM as an optional dependency to go 100% performance

Re: Zig's New Relationship with LLVM

#16

Post by gameswithgo »

IshKebab wrote: post #2

This looks amazing, as do many of Zig's features (e.g. comptime). It's hard to go back to memory errors after Rust, but I hope Zig becomes popular enough with some people (those that don't care about security? maybe game developers?) that it influences future languages.

Zig has a lot of features that make it really nice for game development. Easy and no overhead C interop of course, good runtime performance, fast compilation. While it doesn't have as much safety as Rust it is at least a half step between C and Rust, with option types and better management of undefined behavior. Zig probably makes more sense as a gamedev language than Rust for single player/non networked games, where a memory mistake isn't leading to leaked data or server exploits.

Re: Zig's New Relationship with LLVM

#17

Post by sam0x17 »

kristoff_it wrote: post #5
higerordermap wrote: post #3

I always like innovations in programming tooling. To me zig sounds like a system language written by system programmers, while rust is more influenced from FP and webdev communities, which is reflected in both tooling and language. To people asking why zig when there's rust, both are nice in different ways.

I think Zig will reserve a few interesting surprises also in the webdev world, it just needs a bit more time to get there.

If anything, Zig will have much fewer restrictions (no borrow checker) than Rust when it comes to web dev, once Zig matures to the point where there is a good standard HTTP client and server implementation and a package manager.

I'm a fan of Rust for things like a missile control system or a stock exchange, but not, say, writing a CRM. I'd gladly write a CRM in Zig however, given the proper library support and tooling. Why? productivity. In my experience it just takes 2-3x longer to get the same thing done in Rust vs. something like Zig/Crystal/Go and certainly vs. Ruby/Python/etc. For extremely mission critical code, this is fine, but for most startups I would argue it probably isn't appropriate.

Definitely staying tuned as Zig develops.

Re: Zig's New Relationship with LLVM

#20

Post by ikskuh »

sam0x17 wrote: post #17
kristoff_it wrote: post #5

Earlier quoted context omitted.

I think Zig will reserve a few interesting surprises also in the webdev world, it just needs a bit more time to get there.

If anything, Zig will have much fewer restrictions (no borrow checker) than Rust when it comes to web dev, once Zig matures to the point where there is a good standard HTTP client and server implementation and a package manager. I'm a fan of Rust for things like a missile control system or a stock exchange, but not, say, writing a CRM. I'd gladly write a CRM in Zig however, given the proper library support and toolin…

One experience i can share with Zig and webdev is this:

I was writing a emulator (and later: a compiler) in Zig which was originally written for PC. But i got the idea that hosting this stuff on the web page would be cool, so i learned how to do Wasm. The result was for both project a glue file with ~150 LOC Zig and ~150 JS and both compiler and emulator ran in the browser, and porting both projects took less than an afternoon of time.

Post reply on HN