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

Zig got a new ELF linker and it's fast

github.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Zig got a new ELF linker and it's fast

#41

Post by bbatha »

0-R-1-0-N wrote: post #27
scuff3d wrote: post #22

Earlier quoted context omitted.

I agree, and I try to ignore that stuff, but there are a few things that I think are a little more fundamental then that. This one is fairly minor, but the overly granular namespacing drives me nuts. I shouldn't have to go four or five layers deep to get fairly common functionality. The pattern of returning structs from within structs from within structs just gets old. Maybe that has to do with the way the language h…

Reader and writers were interfaces before 0.15.1. What’s new is that they are buffered. I don’t think that zig discourages interfaces, just that the language doesn’t hide anything. An interface in all system languages is a struct with a vtable just like in zig but that they have an easy way of creating one. If you need one in zig you can go that approach or use a tagged union just that zig is open about what an inter…

> f you need one in zig you can go that approach or use a tagged union just that zig is open about what an interface is.

Perl objects worked like this and the ecosystem is a mess as a result. There's a built in `bless` to add a vtable. There's some cool stuff you can do with that like blessing arrays to do array of structs vs struct of arrays and making it look like a regular object in user code. The problem is there are like 4 popular object libraries that provide base stuff like inheritance, meta objects, getters/setters etc and they're not all compatible and they have subtle tradeoffs that get magnified when you have to pull multiple in to get serious work done.

Re: Zig got a new ELF linker and it's fast

#42

Post by altfredd »

olivia-banks wrote: post #8
squirrellous wrote: post #7

Between mold and this, the linker space appears to be going through a renaissance. Does anyone know if it’s reasonably easy to use elf2 as a standalone linker in a c/c++ toolchain? Or is it specially built just for Zig?

Looking in the source tree, it doesn't look like it has it's own entry point. Zig is heading in the direction of a very verticall integrated compilation stack (I believe this is where most of the speed up comes from), so I'm not really sure of the utility with using it outside of the Zig world. https://github.com/jacobly0/zig/tree/4508c2543508e04253471e1... https://github.com/jacobly0/zig/blob/4508c2543508e04253471e1…

> this is where most of the speed up comes from

I might be mistaken, but the brief look at code shows that the speed up appears to come from combination of async architecture (the selling point of Mold) and intelligent usage of PUNCH_HOLE/INSERT_RANGE fallocate() operations.

Surprisingly enough PUNCH_HOLE and friends have already matured to be production ready, with viable support from ext4 and xfs filesystem. The possibilities!

Re: Zig got a new ELF linker and it's fast

#43

Post by dmit »

squirrellous wrote: post #7

Between mold and this, the linker space appears to be going through a renaissance. Does anyone know if it’s reasonably easy to use elf2 as a standalone linker in a c/c++ toolchain? Or is it specially built just for Zig?

> Between mold and this, the linker space appears to be going through a renaissance.

No kidding. There are also https://github.com/davidlattimore/wild and https://github.com/kubkon/bold.

Re: Zig got a new ELF linker and it's fast

#44

Post by scuff3d »

0-R-1-0-N wrote: post #40
scuff3d wrote: post #30

Earlier quoted context omitted.

Yes I know. I see the same statement every single time this conversation comes. Let me ask this: hypothetically if they wanted to, would it be possible for Zig to add a language feature called Interface which provided to the user "...an easy way of creating one".

Creating an interface is fairly easy once you know how. I would say that it is as easy as in rust for a beginner. You get used to it and I don’t believe it needs a special keyword.

That's not what I asked.

Re: Zig got a new ELF linker and it's fast

#45

Post by olivia-banks »

altfredd wrote: post #42
olivia-banks wrote: post #8

Earlier quoted context omitted.

Looking in the source tree, it doesn't look like it has it's own entry point. Zig is heading in the direction of a very verticall integrated compilation stack (I believe this is where most of the speed up comes from), so I'm not really sure of the utility with using it outside of the Zig world. https://github.com/jacobly0/zig/tree/4508c2543508e04253471e1... https://github.com/jacobly0/zig/blob/4508c2543508e04253471e1…

> this is where most of the speed up comes from I might be mistaken, but the brief look at code shows that the speed up appears to come from combination of async architecture (the selling point of Mold) and intelligent usage of PUNCH_HOLE/INSERT_RANGE fallocate() operations. Surprisingly enough PUNCH_HOLE and friends have already matured to be production ready, with viable support from ext4 and xfs filesystem. The po…

I stand corrected! It would be interesting to try and use the Zig linker for something else, would be a neat weekend project.

Re: Zig got a new ELF linker and it's fast

#47

Post by int_19h »

hansvm wrote: post #38
int_19h wrote: post #25

Earlier quoted context omitted.

> I've been using it as an experimental backend for my language project with great results. One annoyance that I've ran into when using Zig as a transpiler backend is the lack of unstructured goto. Many languages don't need that, but if you're dealing with the one that does, converting such code is non-trivial.

Labeled switches come pretty close. Is there a particular case you have in mind where they don't suffice?

Ah, I wasn't aware of those - they seem to be a fairly recent addition? It definitely does simplify things for many common patterns, but not all, unfortunately; consider the case of a goto into the middle of a loop in C, or even something like Duff's Device.

Re: Zig got a new ELF linker and it's fast

#48

Post by scuff3d »

bsder wrote: post #31
scuff3d wrote: post #23

Earlier quoted context omitted.

I said this elsewhere, but I think the awkwardness is coming from Zigs attitude towards interfaces. It seems like from a language design perspective they've been made intentionally awkward because they want to discourage their use, and fair enough. There are other options for sure. But now they want to base Io around interfaces. So Writers and Readers, it sounds like Async as well, and of course Allocators were alrea…

> It seems like from a language design perspective they've been made intentionally awkward Awkward relative to what ? Relative to C? Did you look at my link to Fastbufs? Take a look at that and then get back to me how awkward Zig is relative to that. Zig seems to be aiming to be a better C. Full stop. If you want abstraction, RAII and other higher-level stuff, C++ and Rust exist. > If they are going to become that fu…

In general I agree with you, Zig is obviously trying to give as much control as possible and avoid higher level abstractions, but it's not like they haven't added elements to the language to improve ergonomics and make the right choice the easy choice.

For loops with a capture group. Under the hood Zig is doing bounds checking and binding the result of each iteration to the variable in the capture groups.You can add a range to that and Zig will iterate it for you. One could argue this is a "higher level" abstractation compared to a traditional for loop and accessing an array by index, but it exists because it naturally pushes developers to write more robust code.

The try keyword, being short hand for catch err return err. A Go developer might argue that it's better to be explicit and not have try. But it's a common pattern and it's far more ergonomic to use the try keyword then it is to catch and return every single time.

Shit, you could argue that the entire idea of comp time is an abstraction to allow code generation. Someone like Ginger Bill would argue you're better off writing a separate program to generate source code then use meta programming.

With the upcoming IO interface and the plans for async, it seems to me that interfaces are going to play a much more prominent role in the language. It makes sense they might want to consider abstractions that push developers towards good design when working with them.

Re: Zig got a new ELF linker and it's fast

#49

Post by hansvm »

int_19h wrote: post #47
hansvm wrote: post #38

Earlier quoted context omitted.

Labeled switches come pretty close. Is there a particular case you have in mind where they don't suffice?

Ah, I wasn't aware of those - they seem to be a fairly recent addition? It definitely does simplify things for many common patterns, but not all, unfortunately; consider the case of a goto into the middle of a loop in C, or even something like Duff's Device.

Yeah, it's fairly new. Maybe 0.14.1?

Those cases are definitely supported. Here's a reasonably faithful re-interpretation of Duff's device which generates the right assembly. If you'll take my word for it, code and assembly equivalent to goto in the middle of a loop body isn't an issue either. The only thing you're losing is the unreadable syntactic interleaving you can do in C.

    pub fn copy(T: type, noalias dst: []T, noalias src: []const T, unroll: comptime_int) void {
        if (unroll  0);

        var n: usize = (src.len + unroll - 1) / unroll;
        var i: usize = 0;
        duff: switch (src.len % unroll) {
            inline 0,2...unroll => |x| {
                dst[i] = src[i];
                i += 1;
                continue :duff (unroll + x - 1) % unroll;
            },
            inline 1 => {
                dst[i] = src[i];
                i += 1;
                n -= 1;
                if (n == 0)
                    break :duff;
                continue :duff 0;
            },
            else => unreachable,
        }
    }

Re: Zig got a new ELF linker and it's fast

#50

Post by int_19h »

hansvm wrote: post #49
int_19h wrote: post #47

Earlier quoted context omitted.

Ah, I wasn't aware of those - they seem to be a fairly recent addition? It definitely does simplify things for many common patterns, but not all, unfortunately; consider the case of a goto into the middle of a loop in C, or even something like Duff's Device.

Yeah, it's fairly new. Maybe 0.14.1? Those cases are definitely supported. Here's a reasonably faithful re-interpretation of Duff's device which generates the right assembly. If you'll take my word for it, code and assembly equivalent to goto in the middle of a loop body isn't an issue either. The only thing you're losing is the unreadable syntactic interleaving you can do in C. pub fn copy(T: type, noalias dst: []T,…

To remind, the original context was transpiling another language (with semantics that allows irreducible CFGs) to Zig, not just this one specific pattern. Yes, of course, for pretty much all practical code, there is going to be a better equivalent. But the transpiler doesn't get the benefit of only working with practical code - it has to deal with whatever the source language spec says is legal. So you need to come up with a generic solution to the entire class of problems presented. Which does exist - e.g. Relooper (https://mozakai.blogspot.com/2012/05/reloop-all-blocks.html) - but the point is that it is very much a non-trivial transformation, to the point where it might actually be easier to transpile to C or something else that has full-fledged goto that you can just use directly.
Post reply on HN