<d​imalinux:monero.social> Can anyone confirm what @xmrack wrote?

<d​imalinux:monero.social> I don't see an update on the official webpage (github.com/j-berman/fcmp-plus-plus-optimization-competition).

<d​imalinux:monero.social> I submitted my Helioselene entry 5 days early. Berman answered a question that I put into the PR. No feedback or requests for changes were given in the PR or here in Matrix chat. I'm happy make any changes needed or required even if they are outside the scope of the contest, but I'd need to know what was invalid if that's truely the case. I'd like to make the repo public, but sinc<clipped message>

<d​imalinux:monero.social> e there is a chance that the competition is ongoing, here's a Gist with the benchmarks that I was getting:

<d​imalinux:monero.social> gist.github.com/dimalinux/fef1a6f70df3f6924e22c45f50b1cc3b

<3​21bob321:monero.social> Are you in monero research lab ?

<3​21bob321:monero.social> Was posted there

<d​imalinux:monero.social> I'll join it (thanks!). If you read the README for the competition, this is the official channel.

woopsidaisy

<d​imalinux:monero.social> Wow. After spending many, many man hours on the Helioselene contest, the last thing I expected as the result was to be accused off plagiarism and writing code that breaks US Copyright law (see the research channel). I know kayabanerve can be passionate and I'm very grateful for all the work he does, so I'm not going to hold it against him. That said, to counter these accusations,<clipped message>

<d​imalinux:monero.social> I'm opening the repository permissions for my submission:

<d​imalinux:monero.social> dimalinux/fcmp-plus-plus-optimization-competition #1

<d​imalinux:monero.social> All my code is in the branch called `contest`. I submitted my entry 5 days early and explicitly asked in the PR on how to do attribution for the `crypto-bigint` code. If I had received a request, I would have already made it. The contest is using the MIT license, just as the `crypto-bigint` library, and the `cypto-bigint` library was already doing the vast majority of the liftin<clipped message>

<d​imalinux:monero.social> g in the competition's reference code.

<d​imalinux:monero.social> The rules for the contest stated:

<d​imalinux:monero.social> > helioselene uses crypto-bigint for its arithmetic. Replacing its field arithmetic with a tailored implementation will likely provide significant savings.

<d​imalinux:monero.social> I stripped the library down to the nuts and bolts and created a tailored U256 implementation with const modular arithmetic.

<d​imalinux:monero.social> Here is what the reference code was using (and the code base that I started with):

<d​imalinux:monero.social> github.com/RustCrypto/crypto-bigint…ustCrypto/crypto-bigint/tree/v0.5.5

<d​imalinux:monero.social> The code in question that started from the `cypto-bigint` (but doesn't have a ton in common with it now) is all under this folder (no where else):

<d​imalinux:monero.social> github.com/dimalinux/fcmp-plus-plus…st/helioselene-contest-src/src/u256

From what I read in the research-lab channel, the main problem with this is that it's a dependency inlined in the source tree of this solution, which adds a burden of maintaining it (who will pull and integrate all the fixes and changes from the parent lib?). Also, there is not comments in files with attributions and/or reference of where the files

were taken from. No matter if it's a MIT license (free for any use), authors of that code should be mentioned in the top comment in each file ("copyright" comment). And their original LICENSE file should also be there. Another problem with this solution was that it wasn't fast enough if the original crypto-bigint lib was used.

<d​imalinux:monero.social> @sech1 The `crypto-bigint` is a ginormous monster. Look at how much code is in that `u256` module:

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> helioselene-contest-src$ wc -l $(find src/u256 -name '*.rs') | tail -1

<d​imalinux:monero.social> 1659 total

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> @sech1 The `crypto-bigint` library is a ginormous monster. Look at how much code is in that `u256` module:

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> helioselene-contest-src$ wc -l $(find src/u256 -name '*.rs') | tail -1

<d​imalinux:monero.social> 1659 total

<d​imalinux:monero.social> ```

1659 line is a monster? That's a small library, if you ask me. You haven't seen BIG libraries yet.

<d​imalinux:monero.social> Also note that I didn't strip any copyrights from the code (that project only does its license at the top of the repo), and I nicely asked how to best add attribution here on June 25th:

<d​imalinux:monero.social> dimalinux/fcmp-plus-plus-optimization-competition #1#discussion_r2167611866

Ah, 1659 files, not lines. Still not very big. grpc C++ library with all its dependencies is 13223 files, for example

<d​imalinux:monero.social> 1659 is *my* code for U256. The `crypto-bigint` library is much larger. And it's a monster in terms of readability, as it is trying to solve a much bigger problem than U256. My version eliminates a lot of templating.

Still, the best practice is to use the original library as it is much easier for maintainability. And another point about your code not being fast enough with the original library, still stands. But I'm not the judge in that competition.

<d​imalinux:monero.social> 1659 is _my_ code for U256 (that's lines, there are 20 files). The `crypto-bigint` library is much larger. And it's a monster in terms of readability, as it is trying to solve a much bigger problem than U256. My version eliminates a lot of templating.

<d​imalinux:monero.social> Optimizing the U256 code was where I spent the majority of the time and how I got the performance improvements. The contest rules explicitly suggested removing its use with a tailored solution, so that is what I ran with.

I took a quick look at github.com/RustCrypto/crypto-bigint…/tree/master/src/modular/monty_form (this library, right?), and I don't see any mess in the code. Yes, the code is complex and has this feel of long-time developed library that handles all the possible uses, but it's not a mess and not a monster code

<d​imalinux:monero.social> Optimizing the U256 code was where I spent the majority of the time and how I got the performance improvements. The contest rules explicitly suggested removing crypto-bigint's use with a tailored solution, so that is what I ran with.

Like I said, I'm not the judge in that competition. They had their reasons, probably.

<d​imalinux:monero.social> For what it is trying to accomplish, it is not a mess. It is just trying to accomplish a hell of a lot more. Note that it is big enough that you did not pick the right directory. You wanted `src/modular/const_monty_form`.

<r​brunner7:monero.social> Looks to me as if "being faster" and "using the original library" are mutually exclusive. Bring the original library in again -> there is no more contest entry, because nothing is any faster than before.

Good point. The contest was about helioselene, not bigint optimization

<r​brunner7:monero.social> (I am speaking in the context of dimalinux 's contest entry, and I tend to support their viewpoint that what they did should be permitted, given the circumstances.)

The contest rules weren't clear enough then

<r​brunner7:monero.social> Yeah, right :) Hindsight, I heard about it

<r​brunner7:monero.social> But well, if it turns out that BitInt optimizations *is* on the way to make Helioselene faster ...?

I considered taking part in the contest, but Rust stopped me. I also read that heliosene entries were expected to have some Crandall prime optimization (?) that would really speed them up. And I agree, algorithmic optimizations are always better than hand-tuning the code to get a few %

<d​imalinux:monero.social> @rbrunner7:monero.social: I just don't feel like there was any way I could have known these requirements. I'll quote the contest suggestion again as it is getting buried here:

<d​imalinux:monero.social> > helioselene uses crypto-bigint for its arithmetic. Replacing its field arithmetic with a tailored implementation will likely provide significant savings.

<d​imalinux:monero.social> My u256 module is a tailored implementation of the math for the field arithmetic. On top of that, I'm being accused of plagiarism and breaking copyright law. So I opened up the repo permissions so that everyone can see that this is plainly not the case.

And this submission didn't do it

In fact, both submissions didn't do it

<r​brunner7:monero.social> And the contest rules didn't ask for it ...

<r​brunner7:monero.social> Only perhaps hinted at it to be a good way

<d​imalinux:monero.social> Does anyone have good references for Crandall prime optimization? Especially references tailored for implementing it in code? (They were hinted at on the top page. Putting it in the helioselene specific page could have helped people a little.)

<r​brunner7:monero.social> No idea :) In a few hours some people in the know, located in the Americas, will wake up and might help. Could be a good idea to also ask in the MRL room.

I guess the answer is somewhere in this book amazon.com/Prime-Numbers-Computational-Richard-Crandall/dp/0387947779

<d​imalinux:monero.social> Anyways, I'm going to bed. By any reasonable interpretation of the contest rules, I should be awarded the prize and I will gladly modify the code until it makes everyone happy. I'm even happy to forgo the prize until J Berman and Jeffro are happy with it assuming they have time to communicate in the PR or chat about the changes to make. The cuprate group wanted lots of changes whe<clipped message>

<d​imalinux:monero.social> n I implemented the legacy cryptonight hash in Rust for them. They'll vouch for me. I made sure that everyone was happy before that code got merged. My contest entry is open now, so no one can seriously accuse me of breaking copyright law (or even not wanting to give attribution for the roots of the `u256` module).

<s​yntheticbird:monero.social> good night

<s​yntheticbird:monero.social> sweet dream