Live data from Hacker News

60x speed-up of Linux “perf”

eighty-twenty.org

41–50 of 224 posts

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

#41

Earlier quoted context omitted.

You understand there's nothing in the GPL that prevents companies from making billions on the code without compensating the contributors?

The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable so…

But companies wouldn't use it anyway since it's GPL.

Enter MPLv2, with the best of both worlds:

- not viral copyleft

- but users DO have to contribute back

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

#42

Earlier quoted context omitted.

You understand there's nothing in the GPL that prevents companies from making billions on the code without compensating the contributors?

The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable so…

The most recent exploitation of opensource code comes from Amazon & friends making their own paid, hosted versions of redis, elastic search, mongodb, and so on. And not making any sort of proportionate contribution to the developers - whose free work their profits entirely rely on.

And in this case I’m not sure how gpl helps. With gpl2 you only need to distribute source code if you distribute binaries - so they have no legal obligations there. And Amazon isn’t really making meaningful changes to elasticsearch and friends anyway, so having the license require them to opensource their changes is a bit moot.

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

#43
post #21

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 impr…

The piping is a good chunk of the gain but the gimli library is still much faster than addr2line & uses less memory if used correctly. Since libbfd shows similar results, I'm thinking there might be a speed bump from switching to use it (some care has to be taken to preserve 0-copy semantics across FFI).

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

#44

Earlier quoted context omitted.

You understand there's nothing in the GPL that prevents companies from making billions on the code without compensating the contributors?

The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable so…

The GPL doesn't require “contributing back”.

You can't just give out binaries without source, but you can choose not to release anything. The thing is, as usage models shift to include a lot of what the FSF very reasonably relabels SaaSS (Service as a Software Substitute), you can release nothing but provide the functionality over the network and reasonably expect people to use it that way. Since you haven't distributed the software itself to anyone, the GPL doesn't put you out of compliance for not showing them your code or letting them distribute it further.

This is the situation the Affero GPL (AGPL) was intended to address—it requires (or tries to require) that source code also be accessible to anyone who is given access to the software over a network. (Imprecisely speaking, that is; do check the license text if you want the specifics.)

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

#45
post #21

Earlier quoted context omitted.

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 impr…

The piping is a good chunk of the gain but the gimli library is still much faster than addr2line & uses less memory if used correctly. Since libbfd shows similar results, I'm thinking there might be a speed bump from switching to use it (some care has to be taken to preserve 0-copy semantics across FFI).

It'd definitely be interesting to find out!

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

#46
post #27
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.

This is kind of the crux of a long history of these licensing arguments. That dynamic linking is problematic because it potentially creates a derived work. And then you might distribute that derived work.

But shelling out to something or in some cases having an automated script create or download the derived work automatically is sometimes acceptable.

It’s a bit of a silly line in some ways. But it’s a long story.

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

#47
post #42

Earlier quoted context omitted.

The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable so…

The most recent exploitation of opensource code comes from Amazon & friends making their own paid, hosted versions of redis, elastic search, mongodb, and so on. And not making any sort of proportionate contribution to the developers - whose free work their profits entirely rely on. And in this case I’m not sure how gpl helps. With gpl2 you only need to distribute source code if you distribute binaries - so they have…

That’s a shortcoming of the GPL: it doesn’t consider interactions over the network “distribution”. It’s the reason the AGPL exists. IMHO, GPL software that could be expected to run in SaaS form should be AGPL.

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

#48
post #19

Earlier quoted context omitted.

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.

Yep. It’s how the Marvin Gaye lawsuits these past few years have been able to happen (despite him being dead). His estate is suing.

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

#49

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.

> That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons. Linus does not think GPLv3 is a good or fitting license for the Linux-kernel and that it changes too much things to be considered a new version of the same license as GPLv2. So he refuses to add the “or later” backdoor which would effectively relicense “his” kernel with a license he does not approve of. Is that no…

It is, but we can still be petty about it.

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

#50
post #40

Earlier quoted context omitted.

> more issues than it solves. Can you explain how you reach this conclusion? Assuming the GPL did not exist and the author would have made stuff proprietary, would that be better ? Some people like me would share code with GPL3 or later, why the f* should we give it to you as BSD? are you running on your devices only BSD code or MIT code ? or are you running proprietary software but for some reason making all stuff B…

> Assuming the GPL did not exist and the author would have made stuff proprietary, would that be better ? That's a false dichotomy – there are many more open source licenses which wouldn't have led to the problem described in the article.

But respect the author decision, maybe the "problem" is what the author desired to happen.
Post reply on HN