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

60x speed-up of Linux “perf”

eighty-twenty.org

Post reply on HN
Print view View original

61–70 of 224 posts

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

#61

Post by for1nner »

dvdkhlng wrote: post #9
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?

IMO it's not "GPL virality" that is at the root of the issue here. The authors' decision to license theis works this way causes the problem. You can still ask both libraries' authors for relicensing their work in a less restricted / more compatible way. If they don't want to do that, then being authors and owning their copyrights, that's their right to do. That's nothing I would blame on the GPL. I mean we should be…

> The authors' decision to license theis works this way causes the problem.

I'm not sure how you can rationally make an argument for a framework that literally limits the use of improved or more performant code/technology/understanding simply because it does not share a philosophical view of IP/ownership/sharing.

This is the core of the problem with IP in the real world as well, and I find it mind-boggling that we don't look at the SYSTEM and see it as problematic.

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

#62

Post by nonbirithm »

It is a tough feeling to see someone else's design for a library that would be literally perfect for my needs, but I'm unable to use it because of the license, so I have to spend weeks implementing my own inferior version while carefully avoiding making the code too similar to what I happen to remember.

I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution for all my needs by myself every time. But copyright still has to be respected.

When I'm forced into that situation from licensing issues, it really makes me feel like my skillset primarily revolves around gluing together other people's well-designed code, and being left to my own devices exposes my weakness in implementing something from scratch.

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

#63

Post by thayne »

faho wrote: post #56
saagarjha wrote: post #52

Earlier quoted context omitted.

What is Clang using it for? I thought it had its own suite of that.

This... is some weirdness in Arch's clang package. It depends on gcc, for some reason, and that depends on binutils? (and I have no idea if anything here uses libbfd, since it's just a part of the binutils package and not split out)

Maybe it depends on gcc so it can use gcc's assebler for inline assembly?

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

#64

Post by nickitolas »

dvdkhlng wrote: post #9
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?

IMO it's not "GPL virality" that is at the root of the issue here. The authors' decision to license theis works this way causes the problem. You can still ask both libraries' authors for relicensing their work in a less restricted / more compatible way. If they don't want to do that, then being authors and owning their copyrights, that's their right to do. That's nothing I would blame on the GPL. I mean we should be…

As I understand it relicensing in many open source projects can be a very complicated matter, since in some cases it requires getting permission from all past contributors (Which could number in the hundreds)

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

#65

Post by adsche »

nonbirithm wrote: post #62

It is a tough feeling to see someone else's design for a library that would be literally perfect for my needs, but I'm unable to use it because of the license, so I have to spend weeks implementing my own inferior version while carefully avoiding making the code too similar to what I happen to remember. I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution…

Curious, what license(s) prevented you from using a library?

Or maybe rather, what does "use" mean here?

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

#66

Post by tverbeure »

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.

I’ve wondered about similar situations.

Take Yosys, an open source synthesis platform that allows external commands by adding shred libraries. It’s MIT licensed.

There is the Yosys-GHDL plug-in that allows using VHDL instead of Verilog compilation. It’s an independent open source project that can’t be merged into the main Yosys tree because GHDL itself is GPL 2.0.

Is the author of that plug-in violating the GHDL license? The plug-in glue code is GPL2 as well.

Can the GHDL authors ask the plug-in authors to take down their code (which has been forked many times on GitHub, of course.)

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

#67

Post by vlovich123 »

vient wrote: post #51
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…

Looks interesting. I've encountered some annoying bugs with latest addr2line when trying to get symbols for addresses, wonder how gimli performs in that sense. Also, it seems that addr2line 2.37 has some performance regressions compared to 2.36.1 which I didn't look at yet.

In my experience gimli also symbolicated things addr2line couldn't.

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

#68

Post by fiddlerwoaroof »

tverbeure wrote: post #66
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.

I’ve wondered about similar situations. Take Yosys, an open source synthesis platform that allows external commands by adding shred libraries. It’s MIT licensed. There is the Yosys-GHDL plug-in that allows using VHDL instead of Verilog compilation. It’s an independent open source project that can’t be merged into the main Yosys tree because GHDL itself is GPL 2.0. Is the author of that plug-in violating the GHDL lice…

My understanding is that there’s only a problem if the distributor combines the two things: if the main application is one license and the plug-in a different one, it’s not a license violation for the end-user to combine the two (unless they turn around and become a distributor in some way).

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

#69

Post by matheusmoreira »

nonbirithm wrote: post #62

It is a tough feeling to see someone else's design for a library that would be literally perfect for my needs, but I'm unable to use it because of the license, so I have to spend weeks implementing my own inferior version while carefully avoiding making the code too similar to what I happen to remember. I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution…

> carefully avoiding making the code too similar to what I happen to remember

Is this really necessary? The GPL allows you to read and study the software. Is it really copyright infringement if you take your understanding and make your own program? Are people really forced to come up with convoluted new ways to solve the same problem just to avoid any similarity to existing work?

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

#70

Post by geofft »

tverbeure wrote: post #66
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.

I’ve wondered about similar situations. Take Yosys, an open source synthesis platform that allows external commands by adding shred libraries. It’s MIT licensed. There is the Yosys-GHDL plug-in that allows using VHDL instead of Verilog compilation. It’s an independent open source project that can’t be merged into the main Yosys tree because GHDL itself is GPL 2.0. Is the author of that plug-in violating the GHDL lice…

The plugin is potentially a derivative work of both Yosys and GHDL, but that's fine - it's possible to comply with the requirements of both the MIT license and the GPLv2 at the same time. The resulting work is GPLv2-licensed. (To be precise, you also need to preserve any copyright notices from the MIT-licensed project and the text of the MIT license. The MIT license has only one condition, but you do need to follow it, same as if you were building proprietary software with an MIT-licensed component.) If anyone distributes Yosys with the plugin, the combined work must also be distributed under GPLv2, which is also fine.

In this case, perf is (like the Linux kernel, in whose git tree it lives) GPLv2-only, and modern versions of libbfd are GPLv3-or-later, and it's not possible to comply with both at the same time. The GPLv2 has a "no additional restrictions" clause, and the GPLv3 asks for things the GPLv2 does not. So a distributor of a combined system including perf built against libbfd (like a Linux distro) cannot comply with the licenses.

(I suppose perf was written against the libbfd API back when libbfd was GPLv2, avoiding the question of whether perf is an illegal derivative work of libbfd. Or the backtracing API is de minimis, which means the source is fine but a compiled binary as par of a distro that also includes a modern libbfd is not.)

One possible answer here is to ask the perf authors to relicense under GPLv2 or later. Many years ago, at a startup that no longer exists, I wanted to reuse code from the Linux kernel "dm-verity" module in GRUB, which had moved to GPLv3, and I got a pretty quick answer from Red Hat (who was the only copyright holder for those files) saying that would be fine.

Post reply on HN