The Fastest FizzBuzz Implementation

Relevant: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29031488" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29031488</a>

&gt; The developer behind the Assembler version goes by the handle &quot;ais523&quot;.<p>Alex Smith [1] is also known for winning the Wolfram 2,3 Turing Machine Research Prize [2].<p>[1] <a href="https:&#x2F;&#x2F;www.cs.bham.ac.uk&#x2F;~ais523&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cs.bham.ac.uk&#x2F;~ais523&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;writings.stephenwolfram.com&#x2F;2007&#x2F;10&#x2F;the-prize-is-won-the-simplest-universal-turing-machine-is-proved&#x2F;" rel="nofollow">https:&#x2F;&#x2F;writings.stephenwolfram.com&#x2F;2007&#x2F;10&#x2F;the-prize-is-won...</a>

The simplest change for performance even in Python, JavaScript, etc is to avoid the modulo function.<p>All of the top contenders on <a href="https:&#x2F;&#x2F;codegolf.stackexchange.com&#x2F;questions&#x2F;215216&#x2F;high-throughput-fizz-buzz&#x2F;" rel="nofollow">https:&#x2F;&#x2F;codegolf.stackexchange.com&#x2F;questions&#x2F;215216&#x2F;high-thr...</a> do exactly this.<p>Yes there is a lot of optimization specific to languages, OS, CPU... but the takeaway for me isn&#x27;t that you have to go that extent to build an order of magnitude improvement, you can still achieve many order of magnitudes of improvement by understanding what is happening when you use something like the modulo function and that if you have requirements where you can avoid using it then that&#x27;s the win.<p>For FizzBuzz you are told it &quot;iterates from 1 to &lt;some number&gt;&quot;... and modulo would be perfect for &quot;take a single number and produce Fizz, Buzz or FizzBuzz if it&#x27;s divisable by 3, 5, or both 3 and 5&quot;... but as we&#x27;re iterating, counters are better suited to the task.<p>I love seeing epic code golf (and the solution outlined in the article is it), but the takeaway for the majority of engineers is that significant improvements can be made with a readable and maintainable solution just by understanding the requirements and comp sci fundamentals.

&gt; Before running the code, make sure your CPU does support AVX2. ... You should see &quot;sse2&quot; at a minimum.<p>AVX2 is not SSE2 - SSE2 is much, much older.<p>You want to check for the avx2 flag itself.

When I saw this a few weeks ago it set off a lot of thinking about compilers and ML.<p>Even the unoptimized C version is 10x slower than the one that is painstakingly optimized.<p>Some of this performance gain will certain be achievable by ML&#x2F;AI assisted compilers and translators. In that case, even a 2x speedup would be game changing. Is anyone using ML in compilers yet? The part where you verify the code still does what you wanted it to do seems trickiest.

It seems there&#x27;s a huge gap between what machine code compilers can generate and hand written optimized assembler. There&#x27;s a lot of room left for compilers to be improved.

I think the original author said that it was harder to make this than his masters thesis.

The most interesting thing is the C version is almost as fast as assembler version.

Asm 56 GB&#x2F;s (you are reading Sanskrit) C 41 GB&#x2F;s (you are reading US Tax Code) Rust 30 GB&#x2F;s (you are reading English) Python (why bother) (you are speed reading ) So many tools, so many languages, life is great.

Imagine writing this asm-implementation to the 22 y&#x2F;o google recruiter and fail the interview. :D

This looks like a pretty rubbish blogspam regurgitation of the original SE answer.

I played with FizzBuzz when this was mentioned here a month ago, focusing on the algorithm not optimizations.<p>I stopped once I could do it in simple code with no math except addition, 15 numbers at a time.<p><pre><code> for (int x = 0 ; x &lt; 1000000 ; x+= 15) { printf(&quot;%d\n%d\nfizz\n%d\nbuzz\nfizz\n%d\n%d\nfizz\nbuzz\n%d\nfizz\n%d\n%d\nfizzbuzz\n&quot;, 1 + x, 2 + x, 4 + x, 7 + x, 8 + x, 11 + x, 13 + x, 14 + x); } </code></pre> That is simple enough and fast enough for me.

I dont understand the FizzBuzz thingy. I mean isnt it just about who has the fastest print method? Correct me please, but this problem has period 15, so if you just write:<p>for (i=1;i&lt;n;i+=15) { print i; print i+1; print &#x27;fizz&#x27; print i+3 ... } You have the fastest , dont you? (if the ending n is important then one can just write 15 of such loops&#x2F;endgame depending on the modulus). Since there is no &#x27;if&#x27; the branch predictor should be on your side.

YAWFB: Yet another wrong fizzbuzz.<p>“fizz” % 3, “buzz” % 5, what is the % 15 for?<p>You can blow a interviewee’s mind by saying, great, now “bang” % 7… and (hopefully!) watch the light dawn.<p>&#x2F;&#x2F; why so serious? :-)

I wonder how an M1 Max assembly version would fare.

Hold my beer. Now were is that OpenCL programming book when I need it?

I wonder about FPGA and io_uring implementations performances

How do you learn about this? Does anyone have any good recommendation on books, where you learn how to do these kind of very low level optimizations?

I would like to propose (or remind) that for this type of problem the fastest implementation is paper.

How did they tested it? Is the data actually being delivered, and read, in order?

No machine code implementation? I wonder how much faster than assembler it could be.

<i>581 lines of Assembler</i><p>Interesting, but not very practical.

&gt; As of this writing, the 3rd fastest submission is written in Rust and produces out at a rate of 3 GB&#x2F;s, 2nd is written in C and produces at a rate of 41 GB&#x2F;s and the fastest is written in Assembler and produces at a rate of 56 GB&#x2F;s.<p>This makes me happy. The order is exactly as it should be, much to the disappointment of the Rustaceans.<p>It&#x27;s a nice reminder that for the ultimate performance, there is no substitute for knowing exactly what the assembler is doing.<p>It&#x27;s also a nice reminder that most of us will never want to do that.<p>EDIT: Whoa. It&#x27;s late, and I thought Rust was at 30 GB&#x2F;s instead of 3, i.e. roughly neck and neck with C. I meant to make a good-natured joke. There must be something wrong with the Rust implementation to be 10x slower; I wonder what it is.<p>As I mentioned further down in the comments, I&#x27;ll donate $500 to Watsi if someone manages to displace the C implementation in Rust or any other language besides C&#x2F;C++&#x2F;ASM. Be sure to DM me on Twitter (<a href="https:&#x2F;&#x2F;twitter.com&#x2F;theshawwn" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;theshawwn</a>) if you do, both so I&#x27;ll see it and so that I can congratulate you. I&#x27;m sure it&#x27;s possible, but it&#x27;s sort of interesting that the activation energy is so high.

interesting for me was the fact, that the author talks about themselves in the third person. Very unusual for some content like this :D

Come on now, are we really using fizzbuzz as a performance benchmark? Seriously, don&#x27;t base a real-world decisions on this.<p>PS. The Rust implementation is also not very optimal, for example, the stdout is not locked so... what are we even trying to show :-).

Pfft. No machine learning was used?