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?"
for(;;){
}
OR
while(1){
}
Starts all main control loops and all kernels.
Every Ask Slashdot gets a comment pointing out that it's the dumbest Ask Slashdot ever, I know.
This time, it's really, really the case.
CLI paste? paste.pr0.tips!
Indeed.
Must be the SlashCode "asciifier" which removes all non-ASCII characters in summaries and posts, thus mangling a lot of names, locations and math formulas.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
Question: 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.
Answer: Genetic code.
How could this ever be more than a guess? How could it ever be determined, documented, or verified?
And for that matter, what is the definition of whether something is "the same" piece of code? For example, if the same source code compiles to different instructions on two platforms, are they running the same code?
How about if one of them actually compiles code that gets executed, and the other optimizes it out?
"How to Do Nothing," kids activities, back in print!
I would probably have to say whatever is the inner loop on the system idle process in windows.
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.
for(int i=0; iSOME_LENGTH; i++){
array[i] = 0;
}
Run 100s of times per program, for almost all programs
I still have more fans than freaks. WTF is wrong with you people?
eg. Call timer code in the 5ESS switch. Countless millions of times a day for over 30 years now. Probably the oldest code that we all depend on every day.
"To those who are overly cautious, everything is impossible. "
on anything {
displayHWinPtrAddrPtrScreen( {492EC5F8-477F-438E}.color.const::BLUE status:{492EC5F8-477F-438E}.const.DEATH } )
}
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
If it's not yet, it will be soon. At the moment the SHA-256 algorithm is being run in the neighborhood of 15,000,000,000,000,000 times per second by miners.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
Lets approach this analytically.
What platform has the most computation power (number of CPUs x speed)?
Due to the increase in speed, we can disregard any CPUs built before 2000.
In number, mobile phones are the largest platform. So I would reckon, some GSM codec/cipher.
I think, for now, microcontrollers can be ignored, because they have much lower computational power.
Desktops and supercomputers have more power, but are they excessing the mobile phones? If they are a relevant portion, then across mobile phones and desktops, perhaps some code related to network access is the most-run.
I doubt it would be something kernel-related (like bootup, context-switching), because the kernel usually does not (or should not) take up a lot of the computing time. If we go by number of entries only, then perhaps some networking code.
If so, I'm not sure which layer to look into though. The lower ones are called more often, but media is not the same across use cases.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I would probably have to say whatever is the inner loop on the system idle process in windows.
Ding, we have a winner. Not supercomputer code. Sure, supercomputers are... super and all, but the biggest one only has around 1 million processing cores. How many windoze machines are out there, idling away?
A squid eating dough in a polyethylene bag is fast and bulbous, got me?
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."
Actually, it's likely not executed that many times - the CPU goes into HALT when idle, and wakes up when there's work to do. Gone are the days of endlessly spinning....
The Idle Process may be more book-keeping artifact than actual code.
That is also wrong.
HALT for the CPU means furtherhin it will do nothing.
Perhaps you ment a different opcode?
Halt means it does nothing... until the next interrupt. Which will happen when there's something useful to do.
It's not compiled, it's interpreted. If you had a single gigantic mRNA consisting of all your genes, that would be compilation.
You can think of DNA as source (in an extremely low-level language), mRNA as machine code, and ribosomes as microcontrollers. DNA transcriptase interprets DNA into RNA. In eukaryotes, SNRPs are optimizers (written by a lunatic, but no analogy is perfect) that rearrange the RNA; ribosomes interpret the RNA.
You've got lots of ribosomes in each cell, so think of each cell as a massively multi-core architecture running a totally asynchronous program.
So what's the most frequently interpreted gene? Most likely something used by bacteria, since those are the most numerous cells on the planet. Or maybe a routine that's common to all cells. Something that regulates cell division?
Note that a lot of the stuff that cells do most frequently (say, transport a hydrogen ion across a membrane) does not require DNA synthesis each time. The instructions in DNA are in large part "build a machine out of protein"; there are also a lot of genes involved in *managing* the machine but not much involved in *operating* the machine, if you see what I'm driving at. Obviously, after cell division you need to synthesize more stuff to replace what you've lost (otherwise you'd shrink away to nothing after surprisingly few divisions), but you basically need to sythesize everything; I'm not sure one gene would stand out.
There are specialized cases where a cell needs to synthesize LOTS of something; salivary glands in insects for example make lots of extra copies of the genes for certain enzymes; some plants do something similar to synthesize various chemicals. But these cases are probably outnumbered by bacteria.
I would have to guess any error handling code I have ever written. It may not be the most oft-run code, but for me it sure seems like it is..
I don't trust atoms -- they make up stuff.