• Hat (unregistered)

    Which would be what the 'volatile' keyword is for.

  • (cs) in reply to Tann San
    Tann San:
    I had a uni lecturer explain how we should do things like this. He said it was great as a contractor as he'd get calls back from past clients asking if he could update their system to run faster, he'd do the same thing as the OP said; shorten some un-necessary purposefully placed loop, say it took 6+ hours doing it and voila, instant pay day.

    Wow. See, this is why computer science needs a professional "engineering" association, which includes ethics in the prerequisites. It exists in other fields, why not in computer programming?

  • Mike (unregistered)

    Err, maybe I'm missing something--but given the 16-bit overflow, wouldn't the "speed-up loop" be infinite? Or is that the real WTF?

  • Teh Optermizar (unregistered) in reply to AdT
    Ben:
    Probably because that loop actually does something?

    Ben, read each character on the 'for' loop line very carefully... the trailing semi-colon is the catch.

    Failing that... curly brace matching on the reflected code FTW!!

  • ac (unregistered)

    A lot of optimising compilers probably have specific code for recognising a completely empty loop and not removing it on the grounds that it's a common (albeit broken) idiom for a delay, and people would grumble if their software stopped working.

  • Nulla (unregistered) in reply to Matthew
    Matthew:
    Integer overflow!? How is that the "obvious" error? He had me at *p = 0x10000;. I'm sorry, but if you're picking an arbitrary memory address and writing 1 million zeros starting at that point, the LEAST of your problems will be the integer overflow of i. Hell, in a system like DOS, you may not even make it to the point of overflowing i before the system hangs because you wrote over some video buffer or something.
    Clever remark, however writing over the video buffer is perfectly valid in DOS, and will certainly not hang the system. In fact, that's exactly how you would change what is displayed.
  • Teh Optermizar (unregistered) in reply to notromda
    notromda:
    Tann San:
    I had a uni lecturer explain how we should do things like this. He said it was great as a contractor as he'd get calls back from past clients asking if he could update their system to run faster, he'd do the same thing as the OP said; shorten some un-necessary purposefully placed loop, say it took 6+ hours doing it and voila, instant pay day.

    Wow. See, this is why computer science needs a professional "engineering" association, which includes ethics in the prerequisites. It exists in other fields, why not in computer programming?

    This may be a very naive point of view, but I agree with your sentiment... intentionally crippling a solution for the purposes of future reward is a bit too morally corrupt for my tastes... transparency and honesty are my watchwords as a contractor, and it has never steered me wrong

  • Micirio (unregistered) in reply to Mike

    Maybe i isn't an int.

  • Teh Optermizar (unregistered) in reply to derula
    derula:
    TRWTF is that the article has 2^10 words.

    You are truly evil... I couldn't resist the urge to paste this into Word to see if you were serious... curse ye!

  • Matthew (unregistered) in reply to AdT
    AdT:
    What? I've done some video programming under DOS and if there was a memory area with fixed address that you wanted to overwrite with zeroes, it was the video RAM. And no, the system would not hang if you did this.

    Sorry, I just picked some random thing that could happen if you wrote to arbitrary areas of memory in a system without memory protection. You're right, of course. Writing to a video buffer won't crash the system. It might, however, make it difficult to see the results of overflowing the integer though.

    Genius programmer: "Damn it! Every time I run this program the video goes blank and I can't read the error message. Oh! I know, I'll just log the error it to a file!

    picks random sector of disk and writes debugging information before and after the loop

    My point is that the OBVIOUS error in that code sample was picking a seemingly arbitrary point in memory to write zeros. The integer overflow was actually rather subtle.

  • (cs)
    After giving a brief tour of the MTWS and the logistics application, Ben left for the day...

    His first day and he's already giving tours?!

  • B (unregistered) in reply to Teh Optermizar
    Teh Optermizar:
    Ben:
    Probably because that loop actually does something?

    Ben, read each character on the 'for' loop line very carefully... the trailing semi-colon is the catch.

    Failing that... curly brace matching on the reflected code FTW!!

    Yeah, I was a bit hasty on that one. At least I wasn't the only one though :)

  • Chris (unregistered)

    Re: the 80/20 rule... that reminds me of the worst project I've ever worked on. The whole thing was designed in two weeks by the management, and then they gave the design to we programmers. I should have run for the hills right then...

    So anyway, when we said that there was no way we could build the system in their time-frame (about six months), they invoked the 80/20 rule. They said, 80% of our users will only need 20% of the functionality, so build that first. When we pointed out that the system would be a total disaster unless we accounted for the other, complicated, 20% of users from the start, they said "don't worry about that, just build the code for the easy users first, then add on the extra stuff later".

    The project was a total disaster. Version 1.0 was released, but the users were told not to use it. The managers got their bonuses - ker-ching. The whole thing was scrapped a few months later.

  • JonC (unregistered) in reply to Teh Optermizar
    Teh Optermizar:
    derula:
    TRWTF is that the article has 2^10 words.

    You are truly evil... I couldn't resist the urge to paste this into Word to see if you were serious... curse ye!

    It tells you that it's 1024 words on the front page

  • Anon (unregistered) in reply to Benjamin Normoyle
    Benjamin Normoyle:
    I thought 80/20 was how to completely bullshit situations: when you need a percentage, use either 80 or 20 percent as your number. E.g. : "80 % of this department is slacking off," "20% of companies give free soda to their employees," "20% of experts say YO MAMA."

    I think only 80% of people define it that way...or was it 20%?

  • Richard Sargent (unregistered) in reply to hallo.amt
    hallo.amt:
    not back then, optimization is a quite new field

    I hope you are kidding! Check out the article date on http://portal.acm.org/citation.cfm?id=365000.

    I agree substantial advances have occurred in optimizations since 1989, but it was hardly "new".

  • tezoatlipoca (unregistered) in reply to JonC
    JonC:
    Teh Optermizar:
    derula:
    TRWTF is that the article has 2^10 words.

    You are truly evil... I couldn't resist the urge to paste this into Word to see if you were serious... curse ye!

    It tells you that it's 1024 words on the front page

    Where? Have I been staring at code too long or can I blame IE for rendering WTF poorly?

  • (cs)

    I always looked at the 80/20 rule as Scotty's Law...

    Scotty: How long did you tell the captain the deflector work would take us? LaForge: Two hours and we have barely more than that till the Borg cube arrives. Scotty: And how long will it actually take us? LaForge: Two hours-like I told him. Scotty: Geordi, ye've got a lot to learn. You never tell captains how long it will really take. How do you expect to earn a reputation as a miracle worker that way?

  • (cs)

    Since nobody has actually posted the correct definition of the 80/20 rule yet--

    The Pareto principle (also known as the 80-20 rule, the law of the vital few and the principle of factor sparsity) states that, for many events, 80% of the effects comes from 20% of the causes. Business management thinker Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who observed that 80% of income in Italy went to 20% of the population. It is a common rule of thumb in business; e.g., "80% of your sales comes from 20% of your clients."
    So for example, in any given programming shop, 80% of the usable work might be generated by only 20% of the programmers.

    The example that "Wayne" gives appears to be a mangling of Westheimer's Rule:

    To estimate the time it takes to do a task: estimate the time you think it should take, multiply by 2, and change the unit of measure to the next highest unit. Thus we allocate 2 days for a one hour task.
  • Teh Optermizar (unregistered) in reply to JonC
    JonC:
    Teh Optermizar:
    derula:
    TRWTF is that the article has 2^10 words.

    You are truly evil... I couldn't resist the urge to paste this into Word to see if you were serious... curse ye!

    It tells you that it's 1024 words on the front page

    Aha... I came in via a direct link in the RSS feed, so I didn't see that... its only 892 according to Word (904 if you include the title and by-line gubbins)

    Obviously this is an indication that Microsoft is short-changing me on words... bastards... :P

  • Lobster (unregistered) in reply to tezoatlipoca
    tezoatlipoca:
    JonC:
    Teh Optermizar:
    derula:
    TRWTF is that the article has 2^10 words.

    You are truly evil... I couldn't resist the urge to paste this into Word to see if you were serious... curse ye!

    It tells you that it's 1024 words on the front page

    Where? Have I been staring at code too long or can I blame IE for rendering WTF poorly?

    Blaming IE is always a good idea.

    But seriously the word-count is located right of the "Full Article" link on the FRONTpage (not the article page)

  • joe (unregistered) in reply to Benjamin Normoyle

    The traditional 80/20 rule is: 80% of the coding is done in 20% of the time, and the last 20% is done in 80% of the time (or more).

  • Da Koochman (unregistered)

    Honestly, thats brilliant!

  • foo (unregistered) in reply to Mike
    Mike:
    Err, maybe I'm missing something--but given the 16-bit overflow, wouldn't the "speed-up loop" be infinite? Or is that the real WTF?

    On a 16-bit machine the loop should run 16960 times.

  • fist-poster (unregistered)

    Ok, if there's an int overflow, how would the loop even compile or how many times it would run if it compiled?

    for(i=0;i<1000000;i++) {;}

    So the fix would be to use nested speed-up loops?

    Could you post the codes because I need too many iterations to speed up my programs.

  • elias (unregistered) in reply to notromda
    notromda:
    Tann San:
    I had a uni lecturer explain how we should do things like this. He said it was great as a contractor as he'd get calls back from past clients asking if he could update their system to run faster, he'd do the same thing as the OP said; shorten some un-necessary purposefully placed loop, say it took 6+ hours doing it and voila, instant pay day.

    Wow. See, this is why computer science needs a professional "engineering" association, which includes ethics in the prerequisites. It exists in other fields, why not in computer programming?

    I have a BS in Software Engineering and we had a class that was prerequisite for pretty much everything which had computer science ethics as a good chunk of its curriculum.

  • (cs) in reply to joe
    joe:
    The traditional 80/20 rule is: 80% of the coding is done in 20% of the time, and the last 20% is done in 80% of the time (or more).
    Also wrong. Your "80/20" rule is a mangling of the 90-90 rule--
    Tom Cargill:
    The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
    Ninety-ninety rule
  • Steve (unregistered) in reply to SomeCoder 
    someThreadVariable = 400;
while (someThreadVariable != 500);
DeleteAllFilesInUsersHomeDir();

    The compiler is quite right to optimise the loop test away in this case. If you don't want it too you have to declare someThreadVariable volatile. A common misconception about C is that it's just a slightly advanced assembler, whereas the compiler is actually allowed to rearrange the code to it's hearts content. So long as it still appears to do what the code says, and all accesses to volatile variables and extern functions occur in the precise places they do in the code.

  • Ben Tremblay (unregistered)

    What pains me is that so very very few folk know how Byzantine some work situations really are. I mean, you have to have been there at least once in your life ... straight out of Kafka's "The Kastle." This is a great story.

    I've been pimping it as an alt interpretation of 80/20, but here's my alt: you get 80% of the buzz by doing 20% of the heavy lifting; or putting it otherwise, with 20% of the effort you can cobble something together that provides 80% service to 80% of the users in 80% of situation. So where's the incentive to actually finish anything?

    My sympathy to anybody with actual needs and requirements, I mean more than the need for plausible deniability. Most software I'm seeing seems designed as entertainment ... "constant partial attention" and "social objects", the stuff of mass delusion.

    --bentrem

    p.s.1 "The corruption of the best is the worst." p.s.2 "Incompetence is the thin edge of a wedge called corruption."

  • Mirko (unregistered) in reply to Rene

    Don't forget about the sign bit so you only get half the range.

  • Sean (unregistered)

    An int is 32 bits on a 32bit machine. The 386 came out in 1985, it's very likely that in 1990 they were using 386s and not 286s... therefore it's not an overflow caused by a 16bit int.

  • Patrick (unregistered)

    One coworker suggested the following way to estimate projects (I'm not sure if he was serious or not!)

    Take your best guess, multiply by 2, add 1, and move to the next higher unit of measurement.

    So, if you think it's two hours, estimate 5 days.

  • Andrew (unregistered) in reply to ssprencel
    ssprencel:
    That's...pretty crummy. If they would have put as much effort into creating the GUI as they did avoiding work, then we might have had a real alternative to Microsoft.

    Apple Macintosh, X-Windows, & SmallTalk all had mature GUI systems by 1989 (or 1987 as some comments mark the story). Microsoft Windows is, by far, the latest entry to the GUI world.*

    People bought Microsoft Windows because, like MS-DOS, it was cheaply bundled with PCs. VHS beat out Betamax on a similar price issue. Sometimes shit floats to the top.

    • NOTE: Although NextStep and Mac OSX are newer than MS Windows, they are really offshoots of Apple Macintosh.
  • Patrick (unregistered) in reply to Mick
    Mick:
    gcc4ef3r:
    uh, wouldn't the compiler optimize that away? i mean, depending on the intelligence of the compiler...

    I read statements like this again and again, but I'll be damned if I've ever seen a compiler do that. Ok, ok, I've only used the compiler that comes with (various versions of) Visual C++ but it is supposed to optimize some and even with full optimizations on in a release build it's never optimized anything like this away that I've found.

    Let's assume it did. I fyou made the variable volatile, it would guarantee that it has to be compiled.

  • optimized away? (unregistered)

    for(i=0;i<1000000;i++) {;}

    Not sure how much much impact this would have on the processing time though. I guess a modern compiler would kind of optimize this it away?

    -{II}-

  • jd (unregistered) in reply to Benjamin Normoyle

    Yes, but it's like any other rule-of-thumb: useful to know, but if that kind of thing is all you know, then you're just bullshitting.

  • Office Space (unregistered)

    Isn't Initech the name of the company in the movie Office Space?

  • (cs) in reply to Rene
    In more or less every DOS compiler you'll find, int defaults to short, aka a 16-bit integer. 0x000F423F > 0xFFFF

    So it's kind of unfortunate that the pointer 0x10000 wouldn't fit in a 16-bit pointer address (which DOS compilers also have to suffer under) either... 0x1:0 maybe, if it's compiled Huge.

  • me too (unregistered) in reply to Office Space

    IAWTC.

  • Jason (unregistered) in reply to Battra
    Battra:
    I've done that myself, and it's still in production. The client complained that he couldn't see the little animated widget I'd put in for the AJAX call, so I added a .5 second delay on the server side of the AJAX call. Result, happy (but stupid) client.

    Actually, in terms of usability, this is a fairly common technique and there is some psychology behind it. When performing an AJAX operation that saves data, for example, users tends to disbelieve that it could have possibly saved in such a short amount of time. The calls tend to be almost instant. Thus, they'll click several times just "to make sure."

    Users are (and I'm generalizing hardcore here) still conditioned to believe that the form they just spent a full minute filling out needs at least a few seconds to save. They want to see something happening. So, a half second pause to display a "Saving.." animation always does the trick. It soothes the users preconceived notion about how this stuff should work and actually looks nice by giving the visual queue. So, I wouldn't quite call that a WTF.

    Besides, as per Wayne, when your happy (but conditioned) client gets annoyed that it takes too long to save, you can boast major speed improvements with ease!

  • MadeItUp (unregistered) in reply to Zylon
    Zylon:
    Since nobody has actually posted the correct definition of the 80/20 rule yet--
    The Pareto principle (also known as the 80-20 rule, the law of the vital few and the principle of factor sparsity) states that, for many events, 80% of the effects comes from 20% of the causes. Business management thinker Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who observed that 80% of income in Italy went to 20% of the population. It is a common rule of thumb in business; e.g., "80% of your sales comes from 20% of your clients."
    So for example, in any given programming shop, 80% of the usable work might be generated by only 20% of the programmers.

    The example that "Wayne" gives appears to be a mangling of Westheimer's Rule:

    To estimate the time it takes to do a task: estimate the time you think it should take, multiply by 2, and change the unit of measure to the next highest unit. Thus we allocate 2 days for a one hour task.

    And I thought the 80/20 rule was that 80% of users only use 20% of the features, but a different 20%

  • Charles (unregistered) 
        int i;
    char *p = 0x10000;
    for (i = 0; i < 1000000;i++) 
    {
       *p++ = 0;
    }

    I thought the bug was that it writes into unallocated memory.

  • (cs) in reply to Hat
    Hat:
    Which would be what the 'volatile' keyword is for.

    Nobody says it was unused.

    fist-poster:
    Ok, if there's an int overflow, how would the loop even compile or how many times it would run if it compiled?

    for(i=0;i<1000000;i++) {;}

    So the fix would be to use nested speed-up loops?

    Nobody says it was an int, either. The fix would obviously to use long.

    Sean:
    An int is 32 bits on a 32bit machine. The 386 came out in 1985, it's very likely that in 1990 they were using 386s and not 286s... therefore it's not an overflow caused by a 16bit int.

    An int is what the compiler defines it to be. The only guarantee is that int can represent numbers from -32767 to +32767.

  • lenny (unregistered)

    int i; char *p = 0x10000; for (i = 0; i < 1000000;i++) { *p++ = 0; }

    uhmm, maybe i'm missing something, or back in the 80's the program could just set zeroes to a megabyte of memory it didn't allocate?

  • (cs) in reply to gcc4ef3r
    gcc4ef3r:
    uh, wouldn't the compiler optimize that away? i mean, depending on the intelligence of the compiler...
    1. Optimizing compilers were just barely better than non-optimizing ones, and far worse than hand-optimization.
  • (cs) in reply to lenny
    lenny:
    int i; char *p = 0x10000; for (i = 0; i < 1000000;i++) { *p++ = 0; }

    uhmm, maybe i'm missing something, or back in the 80's the program could just set zeroes to a megabyte of memory it didn't allocate?

    MS-DOS has absolutely no memory protection, and memory allocation is just a courtesy.

  • (cs) in reply to Spectre
    Spectre:
    An int is what the compiler defines it to be. The only guarantee is that int can represent numbers from -32767 to +32767.

    Only if you're using C++ or a recent version of the C standard. The original guarantee is that:

    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

    with additional guarantees of

    sizeof(void *) == sizeof(int) sizeof(unsigned x) == sizeof(signed x)

    and that a char is large enough to store a single text character in the platform's preferred text encoding. On a machine using 7-bit ASCII, you could theoretically have an int with a range of -64 to 63.

  • swei (unregistered) in reply to Benjamin Normoyle

    The 80/20 rule is a hypothesis (or idiom, not sure what to call it) that 20% of your software bug will take up 80% of your time. Or something like that.

  • Old fart (unregistered)

    Reminds me of the days of IBM mainframe programming with CICS back in the '70s. The CICS programmers would introduce a throttle in new applications to increase response time to a few seconds on each transaction. As the CICS region became more overloaded during the subsequent months with the increase in traffic and additional applications, the response time would degrade. So they would just reduce the throttle to maintain the expected response time.

    This would go on until the system was saturated and no more reductions were available. Then they would upgrade the hardware and start all over again.

  • (cs)
    swei:
    The 80/20 rule is a hypothesis (or idiom, not sure what to call it) that 20% of your software bug will take up 80% of your time. Or something like that.
    I swear to god, I must be posting in INVISIBLE MODE or something.

Leave a comment on “The Speed-up Loop”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article