Slashdot Mirror


Ask Slashdot: What's the Most Often-Run Piece of Code -- Ever?

Hugo Villeneuve writes "What piece of code, in a non-assembler format, has been run the most often, ever, on this planet? By 'most often,' I mean the highest number of executions, regardless of CPU type. For the code in question, let's set a lower limit of 3 consecutive lines. For example, is it:
  • A UNIX kernel context switch?
  • A SHA2 algorithm for Bitcoin mining on an ASIC?
  • A scientific calculation running on a supercomputer?
  • A 'for-loop' inside on an obscure microcontroller that runs on all GE appliance since the '60s?"

5 of 533 comments (clear)

  1. Re:Bios code? by Anonymous Coward · · Score: 5, Interesting

    I would probably have to say whatever is the inner loop on the system idle process in windows.

  2. IEFBR14 - Mainframe Null Program by Anonymous Coward · · Score: 5, Interesting

    http://en.wikipedia.org/wiki/IEFBR14

    Any time a mainframe does anything with a dataset in a batch job (i.e. allocate, delete, whatever) it runs IEFBR14, a null program, as a target program to satisfy a requirement in how jobs are created.

    This means that banks, retailers, governments, you name it--when they process the back-end records that make modern life functional, IEFBR14 usually gets invoked somewhere.

    1. Re:IEFBR14 - Mainframe Null Program by sk999 · · Score: 5, Interesting

      This gets my vote. Ran it many times myself.

      As an aside, this program, (which did absolutely nothing and, in binary format, was originally only 2 bytes long) had the dubious reputation of being the shortest program with a bug. It failed to clear the register that returned the error code. Oops.

  3. Re:Bios code? by Rockoon · · Score: 5, Interesting

    You are right about the hardware/bios aspect, but arent on the right device.

    (nearly) Every computer has a video device which has a loop running over the frame buffer, outputting pixels to the display output port. Even in the days of regular CGA 320x200 graphics on 60hz monitors that amounted to 3,840,000 iterations per second. We are talking over 3 decades of this going on, on nearly every desktop and laptop computer build during that time (vector displays worked differently) and even in those early days of CGA most of the time those machines were in a text mode with a pixel resolution of 720x240 and still putting out a 60hz of video signal (10,368,000 pixels per second.)

    A single CGA desktop machine in text mode left on since January 1984 would have output 9,816,000,000,000,000 pixels to its display port so far. Thats nearly 10 quadrillion pixels. Even if the average number of running desktop computers over the period were only 1 million (a severe lowball) and used that shitty low resolution at only 60 hz, thats still over a sextillion iterations of that simple pixel outputting loop.

    I would say the average number of running desktops over the period since 1984 is more like 50 million and the average resolution over the period was 1024x768, and the average monitor refresh is 70 hz. My guestimate is about 2.606E+24 iterations of the framebuffer loop, over 2 septillion iterations.

    --
    "His name was James Damore."
  4. Re: For / While in C by Zmobie · · Score: 5, Interesting

    I work with a ton of electrical/controls engineers. Yes it is still probably true, mostly because it is still even cheaper/easier to do this through ladder logic. I forget the context of what we were talking about one day, but one day while talking to one of our SENIOR (30+ years) controls engineers I was explaining some logic that if we had to implement it in C# would take probably 300 lines of code. His reply was simply, psh, I could do that in 3 rungs, don't bother.