-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Add Benchmark for rawloader #82
Conversation
Rust statically links, so anything depending on LGPL must itself be LGPL licensed.
From the readme:
|
My non-lawyer understanding is that all 8 of the dependencies are LGPL compatible due to dual licensing under MIT. (Unfortunately Apache 2.0 is not LGPL 2 compatible.) As a result, any user who builds this benchmark can implicitly choose MIT for the dependencies, and then be forced by the library to opt into the LGPL for that particular executable (as per Section 3, Paragraph 6). Other binaries and code are unaffected. Given the warning about licensing in the README, and the general use case for these benchmarks, I understood this to be acceptable.
Oh. I didn't read that as, "this is the only way to run the tests," but rather as "don't do this unless you own a giant box and are ready for significant resource use." Thanks for the clarification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks! To inform expectations, you should probably know that the bots for this project haven't been running for a bit (#68) and I'm currently very slowly moving the CI over to something that works today (#72). Landing might take a little while 😅 .
Re: LGPL, I agree that the specific benchmark binaries statically linking the code need to be LGPL as well, I think it's set up correctly for this PR. AIUI, there's nothing about LGPL that would suggest that lolbench_support
would need to be relicensed to be linked into the same benchmark binary. When it comes down to it, the provenance is important but redistributing this many binaries with code cribbed from this many sources is always going to be fraught (which is fine because we mostly need data, not runnable programs to download).
If you would prefer I commit the 18 MB file to the repo, I can.
I think that's probably the right call, left a review comment.
I am hoping the Cargo.lock additions will not break anything, and will pin its dependency version numbers. If I am wrong, how do I fix that?
Don't worry too much about that right now, because the bots aren't running we can consider this an extended maintenance window :P.
lolbench_support = { path = "../../support" } | ||
|
||
[dependencies.rawloader] | ||
version = "*" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you leave a comment here explaining what you said in your PR description about a mismatch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
This dependency is precisely pinned to rawloader
, based on the git commit I tested. That is fine.
However, what about the library's dependencies? They are:
[dependencies]
toml = "0.5"
enumn = "0.1"
lazy_static = "1"
byteorder = "1"
rayon = "1"
itertools = "0.9"
serde = "1"
serde_derive = "1"
To my surprise, when I added this and did a fetch, it only added new things to Cargo.lock, but I am not sure if this situation will continue.
I know there is an open issue for this, #64. But I was wondering if I should do something to make the pinning tighter and avoid worsening things? Like overriding itertools to =0.9.1
for example? Or is that not necessary?
Understood. ... Although I would say, progress looks pretty good. The only failing check on that PR is the (dead for a while) website. Perhaps it would be possible to find a "good enough" CI for the time being, just to accept PRs again? I do see this referred to in Rust issues at times, so I can't be the only one who is interested in it.
Indeed. The "source only" nature of this project -- where redistributing any binaries someone built would mostly defeat the purpose -- is the reason I didn't consider the licensing issue a showstopper.
Since the website died due to the size of the repo, I thought I'd be conservative and ask before bloating the repo significantly with one commit! 😄 A separate, stupider question, @anp: when I run
The warm-up actually took 3 seconds, but the process burned 100% of a single CPU core on that second message for 45 minutes before I killed it. Dumping the assembly shows a hot and tight recursive function, that, well, looks like Fibonacci. But I can't seem to see it ever changing stack frame sizes. Worse yet, I can't even figure out how to remove it. Even after deleting the rayon benchmarks -- where there are functions with matching names -- and doing This was with both Rustc 1.36 (which the project wanted me to download) and current stable (1.51). What am I missing? |
Closes #46.
I am hoping for an early review, @anp. Some notes:
main()
function that did its own iteration, and had noblack_box
. Therefore, I am hoping this version does not need a call toblack_box
either.cargo bench
does nothing, andcargo test --release
does not give me any numbers. Is this expected?I imagine I left something out, so please let me know what. 😄