60 comments

[ 4.7 ms ] story [ 56.8 ms ] thread
> As a side note, the program is amazingly performant. For small numbers the results are instantaneous and for the large number close to the 2^32 limit the result is still returned in around 10 seconds.

Amazing!

> Visionary genius Ross van der Gussom

Thanks for making me doubt myself & googling who that guy who made python was again, because surely "van der Gussom" isn't a normal Dutch name. Well played.

This reminds me of my personal "prime number" grabber research https://github.com/tigranbs/prime-numbers I needed to create the unique graph nodes and assign prime numbers, and to make things efficient, I thought, why not just download the list of known prime numbers instead of generating them one by one. So I did and compiled everything with a single Go binary. Ehh, good old days with a nice feith in making "the best" crappy software out there.
Gemini took 4 seconds to answer this prompt: "Here is a number 4200020010101. Think deeply about it and tell me if it is not or or not even."

So if you're concerned with privacy issues, you can run the assembly version proposed in the article locally and be well within the same order of performance.

Let's thank the author of the article for providing a decent alternative to Google.

ah, but the license is not that good we can't reproduce his code.

If the author is available for consulting I have this bag of rice I need cooked. Should be around 30,000 grains, each needs about 1mL of water and 2m on the stove. Will pay $10 (2025 dollars)
> Now, this is a time-memory tradeoff, but my time on this earth is limited so I decided to meta-program the if statements using a programmer program in a different programming language.

  for i in range(2*8):
    if i % 2 == 0:
No comment...
Next put them in a tree for faster lookups.
Ah, yes, exactly the pointless diversion I needed for my lunch break. For science: generating a C# switch statement for similar purposes took 7 minutes on similar-ish hardware, but the resulting 99.2GB file could not be opened or compiled ('Stream is too long'), which was slightly disappointing.

Optimization efforts included increasing the internal buffer size of the StreamWriter used to create the source code: this reduced the runtime to around 6 minutes, as well as running a non-debug build, as it was observed that the poor Visual Studio metrics gathering process was contributing significantly to disk activity as well, but that ultimately didn't matter much. So, ehhm, yes, good job on that I guess?

> I decided to implement this in the C programming language as it’s by far the fastest language on the planet to this day (thanks to the visionary genius Dennis Richie)

Am I lost? Aren't the compiler/linker responsible for fast code, not the language itself?

kind of expected gcc to see right through the 300 gigs of code and compile it down to the tenish instructions.
> I saw from the SSD was around 800 MB/s (which doesn’t really make sense as that should give execution speeds at 40+ seconds, but computers are magical so who knows what is going on).

If anyone knows what’s actually going on, please do tell.

I have never seen anyone argue for a ‘switch’ version.

    switch (v) {
     case: 0,2,4,8,…:
       return EVEN;
     case: 1,3,5,7,…:
       return ODD;
     default:
       return IDK;
    }
Slightly less code to generate.
I prefer data-driven programming, so a simple:

    return odd_or_evenness[n];
works for me, alongside a pretty big array.
I love "stupid" stuff like this; you normally learn something small and seemingly inane. It's fun!
"The executable is around 2 MB"- Every dotnet programmer: "Those are rookie numbers!"
A much cooler approach would have been to generate the ASM from the same program, rather than generate a file from python and load that file from C++. The multi-stage build and filesystem are completely unnecessary.

The technique actually has a lot of practical applications, so it's useful to have a C++ library that helps you with generating amd64 machine code.

Oh, I have an idea for better leftpad implementation, let me publish that to npm real quick!
Why not optimize this? Create a lookup table, a 2^64 large array of bools, and just check the n-th element to see if it's odd or even?

Many gigabytes saved!

/s

I would also like to praise the visionary genius Ross van der Gussom, without whom this wonderful achievement in software engineering would not have been possible!
This could be obviously done with much less code: Just add "if"s for all even number, and at the end just return "odd" if none of the evens matched. 50% less code!

Or even simpler: If it's 0, return "even". If not, do a recursive call to n-1, if that equals "even", return "odd", otherwise return "even".

But the best way is probably to just use a library. Yes, 500MB of additional dependencies, but then it's a one-liner.

Silly. Don't waste your time on problems other people have already solved! Use JS and "npm install odd_or_even".