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

191–200 of 222 posts

Re: Wild – A fast linker for Linux

#191

Post by qzzi »

shakna wrote: post #160
yellowapple wrote: post #141

Earlier quoted context omitted.

That would imply that such debuggers are storing line numbers as not just 16-bit numbers (which is probably sensible, considering that source files longer than that are uncommon), but as signed 16-bit numbers. I can't fathom a situation where line numbers would ever be negative.

The __LINE__ macro defaults to "int". That then gets handed to the debugger.

The __LINE__ macro, like all other macros, is expanded during the preprocessing of the source code and is not handed to the debugger in any way.

Re: Wild – A fast linker for Linux

#192

Post by michaelmrose »

Defletter wrote: post #159
jenadine wrote: post #146

Earlier quoted context omitted.

It’s their loss

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

This might indicate moreso that they believe they won't lose anything by the transition and users might ultimately benefit

Re: Wild – A fast linker for Linux

#193

Post by klibertp »

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.

Half in jest, but I'd think anybody coding in Rust already has 32GB of RAM...

(Personally, upgrading my laptop to 64GB at the expense of literally everything else was almost a great decision. Almost, because I really should have splurged on RAM and display instead of going all-in on RAM. The only downside is that cleaning up open tabs once a week became a chore, taking up the whole evening.)

Re: Wild – A fast linker for Linux

#194

Post by klibertp »

all2 wrote: post #34
fsfod wrote: post #30

Earlier quoted context omitted.

You can sort of do that with some of LLVM's JIT systems https://llvm.org/docs/JITLink.html , I'm surprised that no one has yet made a edit and continue system using it.

My parens sense is tingling. This sounds like a lisp-machine, or just standard lisp development environment.

Maybe of interest: https://github.com/clasp-developers/clasp/ (Lisp env. that uses LLVM for compilation; new-ish, actively developed.) However, my impression (I didn't measure it) is that the compilation speed is an order of magnitude slower than in SBCL, never mind CCL.

Re: Wild – A fast linker for Linux

#195

Post by bialpio »

computably wrote: post #106
prmoustache wrote: post #101

Earlier quoted context omitted.

Yes if you are the only developper and never received nor accepted external contributions or if you managed to get permission from every single person who contributed or replaced their code with your own.

> or if you managed to get permission from every single person who contributed This makes it sound more difficult than it actually is (logistically); it's not uncommon for major projects to require contributors to sign a CLA before accepting PRs.

How is the problem of "you signed a CLA without authorization by your employer to do so" solved? I'm mostly asking because I saw the following:

"I will not expose people taping out Hazard3 to the possibility of your employer chasing you for your contribution by harassing them legally. A contribution agreement does not solve this, because you may sign it without the legal capability to do so (...)"

https://github.com/Wren6991/Hazard3/blob/stable/Contributing... (this is I believe the repo with design for riscv cores running on RPi Pico 2)

Re: Wild – A fast linker for Linux

#196

Post by prmoustache »

computably wrote: post #106
prmoustache wrote: post #101

Earlier quoted context omitted.

Yes if you are the only developper and never received nor accepted external contributions or if you managed to get permission from every single person who contributed or replaced their code with your own.

> or if you managed to get permission from every single person who contributed This makes it sound more difficult than it actually is (logistically); it's not uncommon for major projects to require contributors to sign a CLA before accepting PRs.

These are the ones I refuse to contribute to.

Re: Wild – A fast linker for Linux

#197

Post by josephg »

Arelius wrote: post #60
secondcoming wrote: post #27

Earlier quoted context omitted.

Maybe I'm holding it wrong, but mold isn't faster at all if you're using LTO, which you probably should be.

Yeah, if you're development process requires LTO you may be holding it wrong.... Specifically, if LTO is so important that you need to be using it during development, you likely have a very exceptional case, or you have some big architectural issues that are causing much larger performance regressions then they should be.

> Yeah, if you're development process requires LTO you may be holding it wrong....

I spent a few months doing performance optimisation work. We wanted to see how much performance we could wring out of an algorithm & associated data structures. Each day I’d try and brainstorm new optimisations, implement them, and then A/B test the change to see how it actually affected performance. To get reliable tests, all benchmarks were run in release mode (with all optimisations - including LTO - turned on).

Re: Wild – A fast linker for Linux

#198

Post by rerdavies »

p_ing wrote: post #182
cyco130 wrote: post #130

Earlier quoted context omitted.

Not a rhetorical question: Could it be that part of the speed difference is due to the file system speed? I was shocked when I saw how much modern(ish) Windows file systems were slower than modern(ish) Linux ones.

NTFS and ReFS are high performance file systems. But yes, it is due to file system filters, which OOTB means Windows Defender, though that can be extended by 3rd parties, including Sysinternals utils such as procmon. Microsoft built a very extensible I/O stack and prior to Defender/prior to SSDs it really wasn't very noticable... back when it was originally designed well through the 90s and early 00s. Unfortunately i…

Disabling Defender on directories involved in compiling and linking speeds up compile and link times by a factor of 5x or 6x. It's not a subtle difference.

I agonize over the insanity of removing Defender protection on precisely the files that are most vulnerable on my computer each time I do it. But I do it anyway.

Interestingly, Android Studio offers to turn off Defender protection for development directories for you, and does so each time you load a project, if you haven't already done so. So I no longer feel like I'm alone in my insanity.

Re: Wild – A fast linker for Linux

#199

Post by rerdavies »

saagarjha wrote: post #136
zelcon wrote: post #135

Earlier quoted context omitted.

Corps don't want to have to release the source code for their internal forks. They could also potentially be sued for everything they link using it because the linked binaries could be "derivative works" according to a judge who doesn't know anything.

I think you should get new lawyers if this is their understanding of how software licenses work.

I'm wondering if you've ever actually asked a real corporate lawyer for an opinion on anything relating to GPL licenses. The results are pretty consistent. I've made the trip on three occasions, and the response each time was: "this was not drafted by a lawyer, it's virtually ininterpretable, and it is wildly unpredictable what the consequences of using this software are."

Re: Wild – A fast linker for Linux

#200

Post by shakna »

qzzi wrote: post #191
shakna wrote: post #160

Earlier quoted context omitted.

The __LINE__ macro defaults to "int". That then gets handed to the debugger.

The __LINE__ macro, like all other macros, is expanded during the preprocessing of the source code and is not handed to the debugger in any way.

Yes... And debuggers that implement line numbers, generally work by taking that information as part of the preprocessing stage. And the #line and __LINE__ macro/directive were implemented _for debuggers_ when originally created. They were made to be handed over to the debugger.

If you simply compile and run, the debugger won't have __LINE__, no. But it also won't have line numbers, at all. So you might have missed a bit of context to this discussion - how are line numbers implemented in a debugger that does so, without access to the source?

Post reply on HN