4 ms·

Sorry for the super layman question, but can someone explain why is this so amazing?

BenjiWiebe 5y ago
Because it's super CRAZY fast.
jodrellblank 5y ago
A typical desktp computer processor runs at 3Ghz, or 3 billion cycles per second. It has 64-bit registers, which is 8x8 bytes. If it moves one register of results per clock cycle that's up to 24 billion bytes per second, 24GB/s if it does nothing else and never stalls or trips up[1]. Less than half the speed this answer is moving data. In a typical desktop computer from a few years back the connection between CPU and main memory tops out at 25GB/sec throughput[2], often less. There's delay when a user program requests that the Linux kernel does things such as allocate memory or open input/output. Printing text to a console is really quite slow. That means lots of stalls and trips waiting for IO related things and context switching as the same processor runs both the FizzBuzz printer and the PV counter and the Linux kernel and pipes connecting them together and has to keep task-switching between them. From the opening question on that page "A naive implementation written in C gets you about 170MiB/s on an average machine" and that C code is typical, there's nothing drastically bad about it. C already has a reputation as a fast, low level language. This answer is running over 320x faster than the straightforward C answer on the same hardware. If you asked people "how much faster can it possibly get without moving to specialist hardware", I doubt they'd guess that high. It's difficult to get higher speed by using more CPU cores because calculating FizzBuzz is much faster than printing it so they'd just fill up a queue and then stall waiting. To get faster, people are leaning on what exactly is happening internally, adjusting buffer sizes and how to generate the text "FizzBuzz" and get it into the right place to be printed at the right time, and which system calls can be done with less overhead, and lining up more work which can happen during the pauses, and unrolling loops to give the CPU a pattern of instructions it can execute quicker, this is getting answers into the GB/sec ranges. This answer is like the Bugatti Veyron of answers; so finely tuned it's surely getting close to the limits of what the hardware can do. Making use of AVX2 registers which can hold 32 bytes instead of 8, and can be vectorised so one instruction processes many pieces of data, which means less overhead of instructions for the CPU to decode and process per piece of data, and deeper magic, a lot of skill and knowledge required to put all of it together. And of course, someone spending months trying to send "Fizz" and "Buzz" into a counter at tens of billions of bytes per second for no good reason, is amazing in a different way. [1] A nonsense back of an envelope estimate, but good enough for context. [2] https://www.softwareok.com/?seite=faq-Beginners&faq=25 https://www.softwareok.com/?seite=faq-Beginners&faq=25

Because it's super CRAZY fast.

A typical desktp computer processor runs at 3Ghz, or 3 billion cycles per second. It has 64-bit registers, which is 8x8 bytes. If it moves one register of results per clock cycle that's up to 24 billion bytes per second, 24GB/s if it does nothing else and never stalls or trips up[1]. Less than half the speed this answer is moving data. In a typical desktop computer from a few years back the connection between CPU and main memory tops out at 25GB/sec throughput[2], often less. There's delay when a user program requests that the Linux kernel does things such as allocate memory or open input/output. Printing text to a console is really quite slow. That means lots of stalls and trips waiting for IO related things and context switching as the same processor runs both the FizzBuzz printer and the PV counter and the Linux kernel and pipes connecting them together and has to keep task-switching between them. From the opening question on that page "A naive implementation written in C gets you about 170MiB/s on an average machine" and that C code is typical, there's nothing drastically bad about it. C already has a reputation as a fast, low level language. This answer is running over 320x faster than the straightforward C answer on the same hardware. If you asked people "how much faster can it possibly get without moving to specialist hardware", I doubt they'd guess that high. It's difficult to get higher speed by using more CPU cores because calculating FizzBuzz is much faster than printing it so they'd just fill up a queue and then stall waiting. To get faster, people are leaning on what exactly is happening internally, adjusting buffer sizes and how to generate the text "FizzBuzz" and get it into the right place to be printed at the right time, and which system calls can be done with less overhead, and lining up more work which can happen during the pauses, and unrolling loops to give the CPU a pattern of instructions it can execute quicker, this is getting answers into the GB/sec ranges. This answer is like the Bugatti Veyron of answers; so finely tuned it's surely getting close to the limits of what the hardware can do. Making use of AVX2 registers which can hold 32 bytes instead of 8, and can be vectorised so one instruction processes many pieces of data, which means less overhead of instructions for the CPU to decode and process per piece of data, and deeper magic, a lot of skill and knowledge required to put all of it together. And of course, someone spending months trying to send "Fizz" and "Buzz" into a counter at tens of billions of bytes per second for no good reason, is amazing in a different way. [1] A nonsense back of an envelope estimate, but good enough for context. [2] https://www.softwareok.com/?seite=faq-Beginners&faq=25 https://www.softwareok.com/?seite=faq-Beginners&faq=25