

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.<p>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."<p>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:<p>/* Variables <i>/
unsigned long counter1 = 0, counter2 = 0, counter3 = 0, counter4 = 0, currentNumber = 0;
time_t markTime = time(NULL);<p>while(++currentNumber &#60;= 10) {<p><pre><code>    /* Wait until the system time wraps.
     * This should take a few hundred billion years on a 64-bit system. */
    while(time(NULL) &#62; 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);
    } } } }
}</code></pre>
======
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
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
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
Busy waiting isn't any more interesting than calling sleep(). Spectacularly
convoluted ways of generating a particular output, yes, that could be
interesting.

