libtorsion VS cloc

Most of the crypto is from my more general crypto library libtorsion: https://github.com/bcoin-org/libtorsion

I originally wanted to vendor my libtorsion code and link to it, but it felt clunky since libtorsion pulls in a ton of crypto that bitcoin doesn't need. Also, since I was focusing on just a few algorithms, it gave me the opportunity to optimize a lot of them (in particular, the ECC backend was optimized for secp256k1 whereas in libtorsion it supports all kinds of curves).

Because of all of this, there's probably some leftover comments. That comment isn't true anymore. rand.c is definitely used internally for libmako, just not libtorsion.

edit: fixed link.

The 2-by-1 and 3-by-2 division functions described in the paper result in a very measurable speedup in my code. I think you're confusing those with the reciprocal calculation itself (which can be computed with a lookup table). I agree that part doesn't really lend itself to any significant performance benefit and is probably better calculated with a single hardware division instead.

I feel it necessary to point out that the 3-by-2 division actually has multiple benefits which are easy to miss:

1. The quotient loop can be skipped as I mentioned.

2. The "Add back" step is less likely to be triggered.

3. Since a 2-word remainder is computed with the division, you can skip 2 iterations on the multiply+subtract step.

My reimplementation of GMP documents both the 2-by-1 and 3-by-2 divisions pretty thoroughly[1][2].

[1] https://github.com/bcoin-org/libtorsion/blob/master/src/mpi....

[2] https://github.com/bcoin-org/libtorsion/blob/master/src/mpi....

Cloc - https://github.com/AlDanial/cloc

and get the results on the cli.

Let me know what you think. :)

0: https://github.com/AlDanial/cloc

Awesome stuff, thank you! I‘d love some flags/options for cloc integration if it can be detected, maybe a summary of the top N languages for directories (67% Rust, 13% Html, 9% Bash) or something. Just a suggestion/idea. Gonna install it anyway, it‘s shiny!

The solution I am using is currently comprised of 145 projects, 141k+ lines of C#, and 37k+ lines of Razor, courtesy of cloc:

Just out of curiosity, I downloaded the latest version of GNU coreutils and compared the line count between a few source files and the resulting disassembled object files (using cloc to exclude blank lines and comments). It looks like the ratio is very approximately 2 assembly instructions per line of C code. Obviously, that will depend a lot on what the code is doing and the coding style.

When I started making a game [0] last year, first thing I did was write a little Unity script that takes a screenshot of the opening scene, counts current lines of code using CLOC [1] (for fun, not as a true measure of anything), and occasionally renders it all out to an image file.

With that I'm able to create some pretty fun time lapses of progress. I've been doing this at an arbitrary milestone, whenever my Luau [2] LOC surpasses C++ by another factor. This post reminded me I'm overdue for another now that Luau > 3x C++ LOC.

I find it rewarding to look back at my progress. I'll share in case it's interesting for you too [3].

[0] https://store.steampowered.com/app/2168330/Helmscape/

[1] https://github.com/AlDanial/cloc

[2] https://luau-lang.org

[3] https://twitter.com/kineticpoet/status/1619508466212831232

My manager just asked me about this a few days ago (sigh) cloc is good for this - you can pass it a hash or two hashes and it will give you counts accordingly. https://github.com/AlDanial/cloc

Finally, since I'm limited on the character-length of this post, I'll post an individual comment for each year with a table of data. The "All Rank" column will rank the problem by difficulty (measured by leaderboard close time) across all years, with 1 being longest. The "Yr Rank" column will be similar, but ranked only within that year. The "P1 LOC" and "P2 LOC" columns show the numbers of lines of code in my solutions for each part as measured by cloc (each part is stand-alone so there will be some duplication, especially for Intcode). Other columns should be self-explanatory.