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

Wild – A fast linker for Linux

github.com

Post reply on HN
Print view View original

211–220 of 222 posts

Re: Wild – A fast linker for Linux

#211

Post by yellowapple »

eredengrin wrote: post #206
yellowapple wrote: post #204

Earlier quoted context omitted.

> For example, they can't assume that. x + 1 > x for unsigned ints, but are free to assume that for standard ints. No they ain't: julia> x = typemax(Int16) 32767 julia> x + Int16(1) > x false Integers are integers, and can roll over regardless of whether or not they're signed. Avoiding rollover is not a reason to stick with signed integers; indeed, rollover is a very good reason to avoid using signed integers unless…

It depends on the language. I linked a set of c++ guidelines and for c++, they are correct: it is undefined behaviour to do signed integer overflow. Some languages do specify it, eg rust, and even in c++ it might appear to work, but even then it is still undefined and should be strongly avoided.

That's what I'm saying, though: rollovers can happen regardless of whether the integer is signed or unsigned. x + 1 > x is never a safe assumption for integers of the same fixed width, no matter if they're i16 or u16. Whether it's specifically acknowledged as defined or undefined behavior doesn't really change that fundamental property of fixed-width integer addition.

(As an aside: I'm personally fond of languages that let you specify what to do if an integer arithmetic result doesn't fit. Zig, for example, has separate operators for rollover v. saturation v. panicking/UB, which is handy. Pretty sure C++ has equivalents in its standard library.)

Re: Wild – A fast linker for Linux

#212

Post by account42 »

o11c wrote: post #148
ajb wrote: post #81

2008: Gold, a new linker, intended to be faster than Gnu LD 2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold 2021: mold, a new linker, several times faster than lld 2025: wild, a new linker...

Rarely mentioned: all of these occur at the cost of not implementing a very large number of useful features used by real-world programs.

Like ICF? Wait no, everyone supports that except GNU ld.

Re: Wild – A fast linker for Linux

#213

Post by account42 »

ajb wrote: post #181
kibwen wrote: post #177

Earlier quoted context omitted.

Presumably they're talking about linker scripts, and IMO if you're one of the vanishingly rare people who absolutely needs a linker script for some reason, then, firstly, my condolences, and secondly, given that 99.999% percent of users never need linker scripts, and given how much complexity and fragility their support adds to linker codebases, I'm perfectly happy to say that the rest of us can happily use fast and…

Anyone wondering why you'd need a linker script: They are essential on bare metal, as you have to tell the linker where the hardware requires you to put stuff. There are lots in the linux kernel repo, u-boot, probably Arduino, etc.

They are also very useful if you care a lot about the size of the resulting binary.

Re: Wild – A fast linker for Linux

#214

Post by account42 »

panstromek wrote: post #166
panstromek wrote: post #165

Earlier quoted context omitted.

Tell me you don't have rust experience without telling me you don't have rust experience.

I mean, sorry for the snark but really, there's so many of these things that it's just ridiculous to even attempt to compare. e.g. I wouln't ever use something like string_view or span unless the code is absolutely performance critical. There's a lot of defensive copying in C(++), because all the risks of losing track of pointers are just not worth it. In Rust, you can go really wild with this, there's no comparison.

That you subject yourself to FUD is not an argument for anything.

Re: Wild – A fast linker for Linux

#215

Post by panstromek »

einpoklum wrote: post #203
panstromek wrote: post #201

Earlier quoted context omitted.

I don't see how modern C++ solves any of those problems, and especially without performance implications. Like, how do you make sure that you don't hold any dangling references to a vector that reallocated? How do you make sure that code that needs synchronization is synchronized? How do you make sure that non-thread safe code is never used from multiple threads? How do you make sure that you don't ever invalidate an…

> Like, how do you make sure that you don't hold any dangling references to a vector that reallocated? So, I'll first nitpick and say that's not a problem with pointer tracking. To answer the question, though: When I'm writing a function which receives a reference to a vector, then - either it's a const reference, in which case I don't change it, or it's a non-const reference, in which case I can safely assume I'm al…

Most of what you describe, especially in the multithreading part, is already a defensive practice. That's kind of the whole point. I don't deny that some modern C++ constructs help, I've used them, but the level of confidence is just not there. Note that I lump C and C++ together intentionally. For this purpose, they are almost equivalent as Rust tackles the problems they have in common.

I think it'd be better if you first try understand what actually Rust does here, for which I usually recommend this talk for C ++ developers, which describes the most important ideas on snippets of C++ and Rust side by side: https://youtu.be/IPmRDS0OSxM

That's probably my favourite demonstration.

Re: Wild – A fast linker for Linux

#216

Post by panstromek »

account42 wrote: post #214
panstromek wrote: post #166

Earlier quoted context omitted.

I mean, sorry for the snark but really, there's so many of these things that it's just ridiculous to even attempt to compare. e.g. I wouln't ever use something like string_view or span unless the code is absolutely performance critical. There's a lot of defensive copying in C(++), because all the risks of losing track of pointers are just not worth it. In Rust, you can go really wild with this, there's no comparison.

That you subject yourself to FUD is not an argument for anything.

No, it's just business. Memory corruption bugs are crazy expensive. One of those N cases goes wrong at some point and somebody will have to spend a week in gdb with corrupt stacktraces from production on some issue that's non determinstic and doesn't reproduce on dev machine.

Re: Wild – A fast linker for Linux

#217

Post by zelcon »

mistercheph wrote: post #167
Defletter wrote: post #159

Earlier quoted context omitted.

Is it? Because open source tools re-licensing themselves to be more permissive would seem to indicate whose loss it really is.

Embrace, extend, extinguish. it could take about a century, but every software company (hardware maybe next century) is in the process of being swallowed by free software. Thats not to say people can’t carve out a niche and have balling corporate retreats for a while.. until the sleeping giant wakes up and rolls over you.

Free software basically only exists because it’s subsidized by nonfree software. It also has no original ideas. Every piece of good free software is just a copy of something proprietary or some internal tool.

Re: Wild – A fast linker for Linux

#218

Post by zelcon »

amszmidt wrote: post #207
wyldfire wrote: post #173

Earlier quoted context omitted.

They do if they're AGPL licensed and the internal form software is used to provide a user facing service.

But then it isn’t “internal”…

It’s too hard to determine what pieces of your stack interact with public-facing services, particularly in a monorepo with thousands of developers. The effort involved and the legal risk if you get it wrong makes it an easy nope. Just ban AGPL.

Re: Wild – A fast linker for Linux

#219

Post by einpoklum »

panstromek wrote: post #215
einpoklum wrote: post #203

Earlier quoted context omitted.

> Like, how do you make sure that you don't hold any dangling references to a vector that reallocated? So, I'll first nitpick and say that's not a problem with pointer tracking. To answer the question, though: When I'm writing a function which receives a reference to a vector, then - either it's a const reference, in which case I don't change it, or it's a non-const reference, in which case I can safely assume I'm al…

Most of what you describe, especially in the multithreading part, is already a defensive practice. That's kind of the whole point. I don't deny that some modern C++ constructs help, I've used them, but the level of confidence is just not there. Note that I lump C and C++ together intentionally. For this purpose, they are almost equivalent as Rust tackles the problems they have in common. I think it'd be better if you…

> I don't deny that some modern C++ constructs help

This thread started because you essentially denied these constructs have any significance, as you lumped the two languages together. You are still overstating your point.

Moreover - Rust has different design goals than any of these two languages. Indeed, neither of them guarantees memory safety at the language level; Rust makes different tradeoffs, paid a certain price, and does guarantee it. I will watch that video though.

Re: Wild – A fast linker for Linux

#220

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #114

"These benchmark were run on David Lattimore's laptop (2020 model System76 Lemur pro), which has 4 cores (8 threads) and 42 GB of RAM." https://news.ycombinator.com/item?id=33330499 NB. This is not to suggest wild is bloated. The issue if any is the software being developed with it and the computers of those who might use such software.

https://news.ycombinator.com/item?id=42896619

"... I have 16 GB of ram, I can't upgrade it..."

Post reply on HN