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

201–210 of 224 posts

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

#201

Post by Dylan16807 »

dasyatidprime wrote: post #193
Dylan16807 wrote: post #173

Earlier quoted context omitted.

> very reasonably relabels SaaSS (Service as a Software Substitute) Heck no. "as a" already means that. Rewriting the acronym is far more petty than reasonable.

They both contain both elements, but the point is to sharply alter the emphasis. “Software as a Service” is a reasonable description in the salience model of the mainstream software industry, because it is something that you choose and integrate and use like software, except it just so happens to be a service, coming with various costs like subscription fees and very direct vulnerability to upstream changes, and vari…

I do care about it. That doesn't make it less petty, the same way M$ is petty.

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

#202

Post by tlamponi »

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?

  > 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?
Yeah no, they simply had a bad alternative implementation which could have been just as fast as the licence incompatible library call:

  >  non-bfd, without patch:  7m59s
  >  non-bfd, with patch:       15s
  >  bfd:                       15s
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38

The same could have happened due to other reasons for alternative implementation, that range from availability of more than one implementation with different advantages and disadvantages, different OS the code needs to run on, or simply preference.

Blaming the license in this case is just short-sighted and with the wording used it just shows a bias of yours against the GPL, but not actual will to participate in a meaningful discussion on the linked thematic.

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

#203

Post by yakubin »

globular-toast wrote: post #116
yakubin wrote: post #59

Earlier quoted context omitted.

This incompatibility is a unique feature of GPL. Wherever it goes, it's incompatible with something (in this case, with itself). You could use MPL or CDDL and, as long as GPL isn't involved, you won't have problems with license compatibility. However, in the case of the Linux kernel (which "perf" is distributed with) changing the license is not an option --- no CLA and, even if it was practical to ask so many people…

It's not a feature of GPL, it's an unfortunate side-effect of copyleft. If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.

MPL and CDDL are copyleft licenses as well. It is a feature of GPL.

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

#204

Post by Kliment »

gautamcgoel wrote: post #163
jcranmer wrote: post #35

Earlier quoted context omitted.

Here's a brief summary of major licenses: MIT, X11, BSD (2- or 3-clause), and more similar ones I can't name off the top of my head: these are the basic do-what-you-want license, the only requirements are things that every (good) license already has, such as standard limitation-of-warranty clauses and retention of copyright notice requirements. Apache (v2): This is the next stage up, which means that the text is leng…

> The patent clause here includes a provision that any patent licenses are revoked if you sue the authors for patent infringement. I don't understand this part. Why is this useful?

Facebook uses your code. Facebook wants to sue you for patent infringement. Doing that makes them no longer have the right to use your code, so they're deterred from suing you.

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

#205

Post by saagarjha »

fiddlerwoaroof wrote: post #68
tverbeure wrote: post #66

Earlier quoted context omitted.

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).

I am pretty sure that depends on the intent of your distribution. If your software is useless with the plugin and you go "wink wink nudge nudge use this plugin to make this work" this would probably be infringement. If your software is functional without this, and you just happen to have the ability to load plugins of which this is one of them, then it's much better.

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

#206

Post by zaarn »

scottlamb wrote: post #138
anticristi wrote: post #74

Earlier quoted context omitted.

Kind of ironic that RMS campained against proprietary software to allow reuse of code. Now we have two islands of open source code ... .

At least you can legally build it locally, just not distribute the result. That's still better than what's possible with proprietary software. As drran mentioned, I'm sure RMS would say the problem here is that Linux is licensed under v2 only. Linus of course would disagree.

There is proprietary "source available" software that I can compile locally but not distribute the result either. The GPLv2/3 disaster is not an improvement.

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

#207

Post by tonyg »

dabreegster wrote: post #153

Does anybody have working instructions to build a patched perf for Ubuntu 20.04? I built from kernel.org following https://michcioperz.com/post/slow-perf-script/ , but somehow flamegraph pointed at the new build breaks totally -- after exiting the app, there's no "perf record: Woken up 181 times to write data" message; it just hangs.

Note that the patch does something other than what Michał's post ends up doing: instead of linking libbfd, it replaces lots of calls to addr2line with a single long-running call to addr2line.

If you want to try the patch on Ubuntu, I recommend using the Debianish technique of "apt source linux-perf-5.10" (or whichever version of the kernel you're running) and applying the patch. Then "make" in the tools/perf directory, and it should work...

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

#208

Post by tonyg »

a-dub wrote: post #145

is it the fork/exec overhead or the overhead of re-parsing the dwarf data that is responsible for the slowdown? process spawn thrash is obviously bad, but i'm curious how much it contributes to the issue here? forks are pretty cheap these days as i understand, and i think an exec may also be pretty cheap since the program image is already going to be sitting in the buffer cache. reading/parsing dwarf data, on the oth…

I suspect it's both. But I didn't measure, because the patch does away with both sources of overhead at the same time :-)

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

#210

Post by account42 »

whoknowswhat11 wrote: post #167
csdreamer7 wrote: post #95

Earlier quoted context omitted.

This is the comment that points out the issue. perf is licensed under GPL v2 only and libbfd is a GNU tool that is licensed GPL v3 and higher. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815 Really wish the Linux kernel would start mandating new patches to be GPL v2 and higher and get buy in from the largest contributors. A decade later new code would like replace the smaller contributors code and we could c…

No chance of that. GPLv3 wasn't just an update, it was a major change from GPLv2. Importantly, it limited developers own rights to use code of projects they contribute to how they want (including in devices that are locked or secured in various ways). Plenty of people even outside of Linux are not going to be going to GPLv3. The GPLv3 split also damaged the more copyleft side of things as I think some kernel devs pre…

> GPLv3 wasn't just an update, it was a major change from GPLv2. Importantly, it limited developers own rights to use code of projects they contribute to how they want (including in devices that are locked or secured in various ways).

This is FUD.

- The developer's own rights to their own code are never limited. What is limited is the rights they get to other people's code.

- GPL does not limit use in any way, it limits distribution.

The limit placed by the GPL on distribution is that the recipient must also be given source code and the same legal rights to the code. The GPL-3 fixes a technical loophole where the recipient is given rights to the code but prevented by technical means of using their modifications to that code on the device it is intended for. And yes, tivoization is absolutely a loophole in the GPL2, i.e. against the spirit of the license - the FSF has always been about empowering users to modify their software.

Post reply on HN