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

Mold: A Modern Linker

github.com

Post reply on HN
Print view View original

81–90 of 125 posts

Re: Mold: A Modern Linker

#81

Post by 082349872349872 »

chubot wrote: post #10
CyberRabbi wrote: post #2

> I won't avoid Unix-ism when writing code (e.g. I'll probably use fork(2)). It’s probably fine to not avoid most Unix APIs but fork() is truly an exception here. Fork() is not friendly to any third party library you may use because their state may become invalidated after a fork but the library has no way to know if the process has been forked. This is especially bad if the library uses multi threading. The best way…

I can't think of any reason a linker needs to use many libraries, especially not one that start threads. A linker reads files and writes a file. It's a single-purpose tool, not a monolithic app with many dependencies. Either way, threads should be controlled by the application and not libraries. Well-written libraries like sqlite and Lua are parameterized by I/O and concurrency. They don't read files and start thread…

Forget libraries, a static linker (back in the day) only needed something like half-a-dozen different syscalls, not even a full userland or anything as bougie as libraries.

(if it's unclear, this is strong agreement with chubot. If you make the problem harder than it has to be, you have only yourself to blame...)

Re: Mold: A Modern Linker

#83

Post by rui314 »

amluto wrote: post #79
rui314 wrote: post #76

Earlier quoted context omitted.

It is safe because the child process calls munmap before telling its parent process to exit. munmap is guaranteed to act as a commit operation. Alternatively, you can call msync ( https://man7.org/linux/man-pages/man2/msync.2.html ) if you want to keep it mmapped.

Linux gives much stronger guarantees than POSIX here. I wonder if you save measurable time by skipping munmap.

Is that documented?

Re: Mold: A Modern Linker

#84

Post by XorNot »

I just want to say that this is one of the most interesting README.md's I've ever read in a project.

Those performance improvements are crazy as well: here's hoping this becomes the standard.

Re: Mold: A Modern Linker

#85

Post by agumonkey »

Twisol wrote: post #48
curlypaul924 wrote: post #39

Earlier quoted context omitted.

How interesting. Doesn't the fungus get its name from the oxidized metal though and not the other way around? Mold the form and mold the fungus seem etymologically unrelated, however.

> Doesn't the fungus get its name from the oxidized metal though and not the other way around? Huh, apparently so! So Rust-the-language isn't necessarily named after oxidized metal, but it _is_ named after something that's named after oxidized metal.

And what's the relationship between the programming language and fungi ? is it a root growing invading the world concept ? is it a pun on 'fun'-'gi' ?

Re: Mold: A Modern Linker

#86

Post by XorNot »

rui314 wrote: post #18
jdblair wrote: post #13

From a marketing perspective, "mold" meaning "a form used to cast an object from liquid" is a lot more appealing than "green fungus growing on bread." A mold for casting objects is also a lot closer, metaphorically speaking, to what a linker does. I honestly thought that was the meaning the author was trying to evoke before I saw the picture on the github page.

Author here. Haha, that's perhaps true. But at the same time, it seems like a tradition to give a silly name (e.g. "git") to a tool, and I actually like that name and the image to show that I'm not too serious. This is a fun project but not ready for production use.

Given the C was named because it was derived from B, I think there's an effective tradition in compsci of naming things by just playing with the letters.

M comes after G so the name tracks perfectly while also being weird and distinctive.

Re: Mold: A Modern Linker

#87

Post by higerordermap »

enriquto wrote: post #59
spacechild1 wrote: post #57

Earlier quoted context omitted.

> Equivalently, a tool for converting .a to .so Well, an .a file is just an archive of object files. Turning several object files into a single binary is pretty much what a linker does. However, you can't really automate this because object files might have external dependencies and the linker needs to know what these dependencies are.

> you can't really automate this because object files might have external dependencies and the linker needs to know what these dependencies are If it can be done at runtime of the program, I guess it can be done at runtime of the linker, doesn't it?

Yeah I have the same question. lld can list the dependencies right?

Re: Mold: A Modern Linker

#88

Post by baruch »

IshKebab wrote: post #68
Ecco wrote: post #67

I’m surprised by the statement that ‘cat’ is slow because it’s not multithreaded. Isn’t ‘cat’ io-bound?

I think his point is that you can match `cat`s speed because it is IO bound and you can make a linker IO bound by using lots of threads.

One way to speed up IO-bound code is to have multiple threads-of-execution (threads or async-io) in order to have multiple requests in the air. Specifically SSDs benefit a lot from multiple requests in parallel as that utilizes their internal parallelism. HDDs would benefit only a little bit but RAIDed HDDs can also benefit from parallelism.

Re: Mold: A Modern Linker

#89

Post by baruch »

rui314 wrote: post #46
hyperman1 wrote: post #38

Earlier quoted context omitted.

There might be a 'best of both worlds' idea in there: If mold mmaps the input files instead of reading them, the linker would not trash all cached files, and be faster itself as it reuses already cached files. Now the author seems a smart fellow, so maybe he did just that already, I didn't check the source.

mold uses only mmap for file IO. Not only input files but also an output file are mapped to memory using mmap(2).

Wouldn't this mean that you need to memcpy around? Maybe async-io (io_uring?) help here by doing zero-copy writes directly from the source. I don't know how much you need to mangle code (GOT/PLT, offsets) and how much it is a straight copy of object to object.

Re: Mold: A Modern Linker

#90

Post by quesera »

pwdisswordfish6 wrote: post #74
rui314 wrote: post #56

Earlier quoted context omitted.

For the record, a candidate for another name was "weld" as it joins pieces of data into a single binary. That's I think a good name, but I couldn't come up with a backronym.

That's fine, because it's not exactly clear what "ld" stands for to begin with. If anyone asks, you could just say that the W and E stand for "Weally Efficient".

Boston says: "Wicked Efficient"
Post reply on HN