60x speed-up of Linux “perf” • Hacker News Board

Re: 60x speed-up of Linux “perf”

#21

Post by tonyg » Thu, Sep 09, 2021, 2:35 PM UTC

vlovich123 wrote: post #14

I haven't blogged about this yet, but we saw a 1000x fold speed-up doing several things around symbolication. The more optimal approach we found was to use the gimli crate[1] directly & carefully optimize it to read in the data structures for the executable(s) you are symbolicating upfront & then issuing in-process queries. They also have a drop-in replacement of addr2line that outperforms it (both in symbolication s…

Steinar Gunderson (who suggested [1] the talk-through-a-pipe approach) just now compared [2] the `libbfd` variant to the pipe-to-`addr2line` version, and found them to take similar amounts of time.

This agrees with what I saw in `top` while testing: with the patch, I see `perf` using ~95% CPU, with `addr2line` using the remaining ~5%.

So speeding up `addr2line` probably wouldn't result in very much of an overall improvement for this workload.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#28 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38

Re: 60x speed-up of Linux “perf”

#22

Post by lnxg33k1 » Thu, Sep 09, 2021, 2:35 PM UTC

junon wrote: post #2

Yet another case of GPL virality causing more issues than it solves. E: Downvoters, have you read the article? The program started a new process for each address lookup instead of using a library because that library is GPL. Shall we have a discussion?

I guess MIT and Apache would be better, so that company can make billions on the code and contributors would still be poor (see AAPL -> FreeBSD)

Re: 60x speed-up of Linux “perf”

#23

Post by globular-toast » Thu, Sep 09, 2021, 2:35 PM UTC

yakubin wrote: post #7

AstralStorm wrote: post #6

Earlier quoted context omitted.

No. That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons. The incompatibility is caused by "lack of restrictions" clause. Without that, GPL becomes essentially BSD with all the corporate thievery that entails.

The "or later" clause is a backdoor. Not wanting backdoors in your license doesn't seem like a bad reason to me.

So what's the solution? You can use a permissive licence which has a huge "backdoor" allowing derivatives to turn up under any licence, including GPLv3 (or v4). Or you can use GPLv2 with no "or later" clause which means you get situations like this.

Re: 60x speed-up of Linux “perf”

#24

Post by faho » Thu, Sep 09, 2021, 2:37 PM UTC

aaomidi wrote: post #19

ziml77 wrote: post #17

Earlier quoted context omitted.

It's fixable with a license change, but in practice that's impossible for large projects. Without a CLA, every individual who's contributed is a copyright owner. If you can't get every single one of them to agree to change it, then the license is stuck. And it doesn't matter if the reason you can't get them to agree is because they've become uncontactable or died.

If they're dead then they're not going to stop you from changing the license. What are they gonna do? Sue you from beyond the grave?

Inheritance exists.

Re: 60x speed-up of Linux “perf”

#25

Post by CodeWriter23 » Thu, Sep 09, 2021, 2:37 PM UTC

aaomidi wrote: post #19

ziml77 wrote: post #17

Earlier quoted context omitted.

It's fixable with a license change, but in practice that's impossible for large projects. Without a CLA, every individual who's contributed is a copyright owner. If you can't get every single one of them to agree to change it, then the license is stuck. And it doesn't matter if the reason you can't get them to agree is because they've become uncontactable or died.

If they're dead then they're not going to stop you from changing the license. What are they gonna do? Sue you from beyond the grave?

Their heirs could do precisely that.

Re: 60x speed-up of Linux “perf”

#26

Post by captainmuon » Thu, Sep 09, 2021, 2:38 PM UTC

faho wrote: post #3

> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't . Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.

If we are nitpicking, they can, there is nothing material stopping them. It is "just" at odds with copyright law.

In a society with different laws, there would be no problem. I wonder what would be greater - the productivity gain when we would not have to make workarounds due to licensing, and when we could just legally access the source code of everything. Or the loss, because people might have less incentive to innovate, or they would just keep the source hidden.

Re: 60x speed-up of Linux “perf”

#27

Post by ziml77 » Thu, Sep 09, 2021, 2:38 PM UTC

faho wrote: post #3

> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't . Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.

Is it just me or is the incompatibility especially absurd given that perf is currently using libbfd, just 1 step removed via addr2line?

I wonder if a patch to addr2line would be accepted which allows the executable to stay running to accept multiple requests through stdin.

Re: 60x speed-up of Linux “perf”

#28

Post by junon » Thu, Sep 09, 2021, 2:40 PM UTC

aaomidi wrote: post #19

ziml77 wrote: post #17

Earlier quoted context omitted.

It's fixable with a license change, but in practice that's impossible for large projects. Without a CLA, every individual who's contributed is a copyright owner. If you can't get every single one of them to agree to change it, then the license is stuck. And it doesn't matter if the reason you can't get them to agree is because they've become uncontactable or died.

If they're dead then they're not going to stop you from changing the license. What are they gonna do? Sue you from beyond the grave?

IANAL but I believe a Qui Tam could take place by surviving family. Or inherited copyrights, etc.

Re: 60x speed-up of Linux “perf”

#29

Post by tonyg » Thu, Sep 09, 2021, 2:40 PM UTC

ziml77 wrote: post #27

faho wrote: post #3

> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't . Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.

Is it just me or is the incompatibility especially absurd given that perf is currently using libbfd, just 1 step removed via addr2line? I wonder if a patch to addr2line would be accepted which allows the executable to stay running to accept multiple requests through stdin.

addr2line already does this, and it's exactly what TFA is making use of to get the speedup.

Re: 60x speed-up of Linux “perf”

#30

Post by dvdkhlng » Thu, Sep 09, 2021, 2:40 PM UTC

aaomidi wrote: post #19

ziml77 wrote: post #17

Earlier quoted context omitted.

It's fixable with a license change, but in practice that's impossible for large projects. Without a CLA, every individual who's contributed is a copyright owner. If you can't get every single one of them to agree to change it, then the license is stuck. And it doesn't matter if the reason you can't get them to agree is because they've become uncontactable or died.

If they're dead then they're not going to stop you from changing the license. What are they gonna do? Sue you from beyond the grave?

I think copyright is inherited by the heirs (in most cases relatives of the deceased) and carries on quite a long time after death. So the relatives may actually sue you, and any discussion WRT relicensing would have to be addressed to them.

I actually consider putting something into my will that states that all my open-source contributions are relicensed to "public domain" (CC0 [1]) once I die.

[1] https://creativecommons.org/share-your-work/public-domain/cc...