Slow Code Competition

[kevinskii]

Given the totally arbitrary choice between writing fast vs. slow code, it seems that developers unfairly discriminate against slowness every time. It's time to rectify this situation with a slow code competition. Let's see who can write a code snippet that will take the longest amount of time to print the numbers one through ten.

These are the only rules: - You can use any language you choose, including pseudocode. - Your code snippet must be ten lines of code or less. Preprocessor directives and such may be omitted. - It must complete in some finite amount of time. - Sleep (and similar) statements are not allowed. - You can't stay awake until 4:00am trying to think of a way to "win."

Yes, I realize this is a stupid competition with lots of loopholes in the rules. I'm mainly curious to see how people who are much smarter than me might approach the problem. Without further ado, here's my submission:

/* Variables / unsigned long counter1 = 0, counter2 = 0, counter3 = 0, counter4 = 0, currentNumber = 0; time_t markTime = time(NULL);

while(++currentNumber <= 10) {

    /* Wait until the system time wraps.
     * This should take a few hundred billion years on a 64-bit system. */
    while(time(NULL) > markTime) { /* do nothing */ } 

    /* Update the time reference so the above WHILE loop doesn't immediately fall through
     * the next time around. */
    markTime = time(NULL); 
    
    /* If every counter has wrapped back to zero */
    if(++counter1 == 0) {
        if(++counter2 == 0) {
            if(++counter3 == 0) {
                if(++counter4 == 0) {
                    
                    /* Print the number */
                    printf("%d", (int)currentNumber);
    } } } }
}

[dalke]

Why is this interesting? Here's Python code which will take longer than your code:

    i = 0
    while i < 9999**9999:
        i += 1
    print range(10)

Assuming 10 billion loops per second that's about 10^40000 years before it finishes. Want longer? Put some extra digits on the exponent.

[kevinskii → dalke]

Actually that is really interesting to me. In the languages I'm familiar with, processing something such as 9999^9999 would require additional logic to avoid overflowing a fixed-size storage unit. I haven't worked with Python at all, and after looking at your reply I did a little bit of research and learned that its long integer type will automatically allocate as many bytes as necessary to get the job done. Very cool. I was thinking that someone would probably show me a better way in another language. Thanks for sharing.

[fmora]

Isn't the line:

while(time(NULL) > markTime) { /* do nothing */ }

some sort of sleep mechanism? What's the point again?

[kevinskii → fmora]

The "no sleep statement" rule is just there to prevent a pseudocode solution from being too easy.

The point is to see if someone will submit something that makes me think, "Oh wow, I would have never considered doing it that way." Thus expanding my software horizons forevermore. It's a simple problem with potentially several creative solutions.

[mooism2 → kevinskii]

Busy waiting isn't any more interesting than calling sleep(). Spectacularly convoluted ways of generating a particular output, yes, that could be interesting.