Comment On The Speed-up Loop

“So what do you think about the opportunity,” Ben’s recruiting agent asked. He thought about it for a few moments. It wasn’t exactly what he was looking for, but then again, he had been out of work since November of 1989 – nearly three whole months – and figured he should probably get back in to the swing of things. He told the recruiter that he’d like to talk to the client and asked to schedule an interview for the following week. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Re: The Speed-up Loop

2008-01-24 10:05 • by savar
i done worked with inline assembly all my life, yessir

i tell you what

Re: The Speed-up Loop

2008-01-24 10:07 • by Tom (unregistered)
It's......it's brilliant.

Re: The Speed-up Loop

2008-01-24 10:07 • by anonymous_coder() (unregistered)
<head-desk>
Sounds like some of the mechanics I knew, who would break things that were almost broke to keep from having to do hard jobs - windshield wipers, mirrors, etc.

On the other hand, it's a great way to keep a PHB happy...

Re: The Speed-up Loop

2008-01-24 10:10 • by dlikhten
Speed Loops... BRILLIANT!

I guess that's what happens when you need to "fill the void"

Re: The Speed-up Loop

2008-01-24 10:12 • by 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.

Re: The Speed-up Loop

2008-01-24 10:13 • by Tyler (unregistered)
Wayne is a goddamn genius.

I do something similar at by giving out really long timelines for development and then consistently beating them by huge margins. This also gives me the benefit of extra time if something needs more work than I planned.

Re: The Speed-up Loop

2008-01-24 10:13 • by The MAZZTer
I feel dumb. I can't find the integer overflow. :(

char *p only goes up to 0x0010423F which is far below the maximum of 0xFFFFFFFF.

and int i only goes up to 0x000F423F which is also below the maximum of 0x7FFFFFFF.

The only WTFs I see are a hardcoded memory address, which I suppose could be acceptable depending on what hardware and operating system the code is run under, and the setting of 1000000 bytes to 0 when there's probably a better way to do it (memset is one) although what improvements can be made depends on how the set memory is used (if it is later read without setting and the program depends on 0 for initial values then there's probably no way around it).

[Edit: Wait... it makes more sense if those were int16s... were they?]

Re: The Speed-up Loop

2008-01-24 10:15 • by Alex G. (unregistered)
That is brilliant.

Really. I'm in awe, this guy is a genius.

Re: The Speed-up Loop

2008-01-24 10:16 • by Crash Magnet (unregistered)
I thought the 80/20 rule was: The first 80% of the project take 20% of your time, the last 20% of the project takes 80% of the time. But I remember it as the 90/10 rule.

Re: The Speed-up Loop

2008-01-24 10:20 • by Rene (unregistered)
172958 in reply to 172954

I feel dumb. I can't find the integer overflow. :(


In more or less every DOS compiler you'll find, int defaults to short, aka a 16-bit integer. 0x000F423F > 0xFFFF

Re: The Speed-up Loop

2008-01-24 10:21 • by gabba
Building in future optimizations is a pretty standard technique. In certain organizations you simply have to prepare for defending yourself.

Very similar to hardware engineers who purposely design in expensive components, knowing they'll be asked to go through a cost reduction phase later.

No WTF here; just sensible self-defense.

Re: The Speed-up Loop

2008-01-24 10:21 • by smooth menthol flavor (unregistered)
172960 in reply to 172954
ints were probably only two-byte words back in 1989. int i could only have gone up to 32767.

Re: The Speed-up Loop

2008-01-24 10:21 • by Benjamin Normoyle (unregistered)
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."

Re: The Speed-up Loop

2008-01-24 10:21 • by Tiver (unregistered)
172962 in reply to 172954
The MAZZTer:
I feel dumb. I can't find the integer overflow. :(
<snip>
[Edit: Wait... it makes more sense if those were int16s... were they?]


Correct, which in the days of Windows 2, they most definitely were.

Re: The Speed-up Loop

2008-01-24 10:22 • by sweavo (unregistered)
172963 in reply to 172958
Rene:

I feel dumb. I can't find the integer overflow. :(


In more or less every DOS compiler you'll find, int defaults to short, aka a 16-bit integer. 0x000F423F > 0xFFFF


Don't forget it's 1987.

Wayne is a Genius. Where is he working now? Can I apply?

Re: The Speed-up Loop

2008-01-24 10:25 • by sweavo (unregistered)
172964 in reply to 172963

Don't forget it's 1987.


oh wait, that would be three months after 1986 not 1989, hang on...

Don't forget it's 198L

Re: The Speed-up Loop

2008-01-24 10:29 • by Keith (unregistered)
At last!

Finally, an explanation of why Lotus Notes is so *&^%*@&$ SLOW!!!

Re: The Speed-up Loop

2008-01-24 10:35 • by 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.

Re: The Speed-up Loop

2008-01-24 10:35 • by Justin (unregistered)
Wow. What a BOFH, or perhaps a BPFH.

Re: The Speed-up Loop

2008-01-24 10:38 • by Anon Coward (unregistered)
I worked on a large consumer application that's on at least version 12 now. The code is sprinkled with sleep(10000) everywhere. Some were hold-overs from past days when you were waiting for a supposed synchronous hardware operation to complete, other times it was because the original programmer didn't understand multi-threading and IPC, so the sleep was to let another thread finish an operation or avoid hammering on a shared resource. Our 'Architect' would regularly go back and reduce the numbers and claim wonderful improvements in how fast the program now ran. Alas, his name wasn't Wayne.

Re: The Speed-up Loop

2008-01-24 10:41 • by Jay (unregistered)
I thought the 80/20 rule was: The first 20% of the project takes 80% of the allotted time, while the remaining 80% of the project takes another 80% of the allotted time.

The big flaw I see to their speed-up loops is that they should have made the ending value a parameter read in from a config file or something of the sort. Then you wouldn't have to recompile to change the delay. Also, it really should check the system clock rather than just counting. That way you'd get consistent performance savings regardless of the speed of the processor.

Re: The Speed-up Loop

2008-01-24 10:45 • by Battra (unregistered)
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.

Re: The Speed-up Loop

2008-01-24 10:51 • by gcc4ef3r (unregistered)
uh, wouldn't the compiler optimize that away? i mean, depending on the intelligence of the compiler...

Re: The Speed-up Loop

2008-01-24 10:54 • by T $
Can't quite figure out why the last contractor "just left all of a sudden." Did he decide he wanted a real job instead?

Re: The Speed-up Loop

2008-01-24 10:59 • by hallo.amt
172976 in reply to 172973
not back then, optimization is a quite new field

Re: The Speed-up Loop

2008-01-24 11:00 • by Zylon
Wayne and Wane really need to work out their split personality issues.

Re: The Speed-up Loop

2008-01-24 11:01 • by Alcari (unregistered)
Oh, i've done that.
Someone complained that sometimes, saving a file was to fast, so he didn't know if it was succesfull, since the statusbar popped in and out to fast.

Solution:
If filesize < 2mb
open FakeSaveAnimation.gif
end

Re: The Speed-up Loop

2008-01-24 11:05 • by VolodyA! V A (unregistered)
The funny for me was the google ad on this exact page:

"Slow computer? Speed it up by cleaning your registry..." maybe there is some NumberOfZerosInSpeedupLoop in Windows registry?

Re: The Speed-up Loop

2008-01-24 11:07 • by Mick (unregistered)
172980 in reply to 172973
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.



Re: The Speed-up Loop

2008-01-24 11:14 • by jon (unregistered)
Isn't the 80/20 rule... 80% of the work is done by 20% of the people? No wait, I'm thinking of the 90/10 rule.

Re: The Speed-up Loop

2008-01-24 11:14 • by SomeCoder (unregistered)
172982 in reply to 172980
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.






It will optimize it away. If you just set to Release mode in Visual Studio, that isn't full optimizations. You need to tell it that you want it to run as fast as possible too.

One time, I tried something like this:

while (true);

Set the mode to Release and the optimizations to "Speed" and voila, program runs, no infinite loop.

Back in the late 80s though, there probably weren't optimizations like this so that for loop would have happily done nothing... 1000000 times.

Re: The Speed-up Loop

2008-01-24 11:18 • by mallard
172986 in reply to 172980
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.



The C# compiler in VS2008 certainly doesn't. Built in release mode with optimisation:
Source:

static void Main(string[] args)
{
for (int i = 0; i < 100000; i++) ;
Console.WriteLine("Hello World!");
}


Disassembly (from Lutz Roeder's .NET Reflector):

private static void Main(string[] args)
{
for (int i = 0; i < 0x186a0; i++)
{
}
Console.WriteLine("Hello World!");
}

Re: The Speed-up Loop

2008-01-24 11:23 • by jtl (unregistered)
172988 in reply to 172978
Alcari:
Oh, i've done that.
Someone complained that sometimes, saving a file was to fast, so he didn't know if it was succesfull, since the statusbar popped in and out to fast.

Solution:
If filesize < 2mb
open FakeSaveAnimation.gif
end


Apparently giving the user a 'save complete' message was too much hassle?

Re: The Speed-up Loop

2008-01-24 11:23 • by AdT (unregistered)
172989 in reply to 172982
SomeCoder:
One time, I tried something like this:

while (true);

Set the mode to Release and the optimizations to "Speed" and voila, program runs, no infinite loop.

Back in the late 80s though, there probably weren't optimizations like this so that for loop would have happily done nothing... 1000000 times.


What you mentioned is not an optimization, it's a breaking change. Removing an infinite loop is not a speed-up, it's a major semantic change. Just imagine you had put "DeleteAllFilesInUsersHomeDir();" after the loop.

Visual C++ is notorious for "optimizing" code in ways that break it. I encountered such cases myself and have seen co-workers run into similar issues where the Debug code ran fine and the Release version screwed up big time and disabling some optimizations resolved these issues.

Re: The Speed-up Loop

2008-01-24 11:24 • by GettinSadda
172991 in reply to 172980
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.


WRONG!!!

// OptTest.cpp : Defines the entry point for the console application.

//

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
const char *Before = "Before\n";
const char *After = "After\n";

printf(Before);
00401000 push offset string "Before\n" (406104h)
00401005 call printf (40101Ah)

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

printf(After);
0040100A push offset string "After\n" (4060FCh)
0040100F call printf (40101Ah)
00401014 add esp,8

return 0;
00401017 xor eax,eax
}
00401019 ret

Re: The Speed-up Loop

2008-01-24 11:27 • by ChiefCrazyTalk (unregistered)
172992 in reply to 172971
Jay:
I thought the 80/20 rule was: The first 20% of the project takes 80% of the allotted time, while the remaining 80% of the project takes another 80% of the allotted time.

The big flaw I see to their speed-up loops is that they should have made the ending value a parameter read in from a config file or something of the sort. Then you wouldn't have to recompile to change the delay. Also, it really should check the system clock rather than just counting. That way you'd get consistent performance savings regardless of the speed of the processor.



Ummm its the other way around.

Re: The Speed-up Loop

2008-01-24 11:28 • by Ozz (unregistered)
172993 in reply to 172956
Crash Magnet:
I thought the 80/20 rule was: The first 80% of the project take 20% of your time, the last 20% of the project takes 80% of the time. But I remember it as the 90/10 rule.

It's actually the 90/90 rule. The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time.

Re: The Speed-up Loop

2008-01-24 11:31 • by SuperousOxide
172994 in reply to 172986
mallard:

The C# compiler in VS2008 certainly doesn't. Built in release mode with optimisation:
<snip>


There's no optimization the compiler could do there. Removing the for loop would change the behavior of the program (by not printing out the "Hello World!"). If you removed the WriteLine, then it should remove the loop.

Re: The Speed-up Loop

2008-01-24 11:32 • by Matthew (unregistered)
172995 in reply to 172947
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.

Re: The Speed-up Loop

2008-01-24 11:33 • by derula (unregistered)
TRWTF is that the article has 2^10 words.

Re: The Speed-up Loop

2008-01-24 11:34 • by AdT (unregistered)
172997 in reply to 172994
SuperousOxide:
There's no optimization the compiler could do there. Removing the for loop would change the behavior of the program (by not printing out the "Hello World!").


No, it wouldn't. In either case, "Hello World!" is printed exactly once.

Re: The Speed-up Loop

2008-01-24 11:35 • by Ben (unregistered)
172998 in reply to 172986
mallard:
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.



The C# compiler in VS2008 certainly doesn't. Built in release mode with optimisation:
Source:

static void Main(string[] args)
{
for (int i = 0; i < 100000; i++) ;
Console.WriteLine("Hello World!");
}


Disassembly (from Lutz Roeder's .NET Reflector):

private static void Main(string[] args)
{
for (int i = 0; i < 0x186a0; i++)
{
}
Console.WriteLine("Hello World!");
}


Probably because that loop actually does something?

Re: The Speed-up Loop

2008-01-24 11:38 • by GettinSadda
173000 in reply to 172991
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.


WRONG TAKE 2!!!

Same code compiled in Visual C++ 6
00401000   push        406038h

00401005 call 00401020
0040100A push 406030h
0040100F call 00401020
00401014 add esp,8
00401017 xor eax,eax
00401019 ret
0040101A nop
0040101B nop
0040101C nop
0040101D nop
0040101E nop
0040101F nop

Re: The Speed-up Loop

2008-01-24 11:38 • by Ben (unregistered)
That is a WTF? No

That's a GREAT IDEA

Re: The Speed-up Loop

2008-01-24 11:39 • by mallard
173002 in reply to 172994
SuperousOxide:
mallard:

The C# compiler in VS2008 certainly doesn't. Built in release mode with optimisation:
<snip>


There's no optimization the compiler could do there. Removing the for loop would change the behavior of the program (by not printing out the "Hello World!"). If you removed the WriteLine, then it should remove the loop.


No, the program only prints out "Hello World!" once, after the loop. Notice the ";" at the end of "for (int i = 0; i < 100000; i++) ;", that is, as the disassembly showed, an empty loop body, equivalent to "{ }".

Besides, even with the "Console.WriteLine("Hello World!");" removed (commented out), the disassembly becomes:

private static void Main(string[] args)
{
for (int i = 0; i < 0x186a0; i++)
{
}
}


The loop still remains.

Re: The Speed-up Loop

2008-01-24 11:40 • by clively
173003 in reply to 173001
Ben:
That is a WTF? No

That's a GREAT IDEA


I really hope none of you guys work for Microsoft.

Re: The Speed-up Loop

2008-01-24 11:41 • by AdT (unregistered)
173004 in reply to 172995
Matthew:
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.


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.

The system would rather hang (or probably crash in a more spectacular way) if you overwrote some hardware interrupt handler or some code/data structures used by such a handler. You could prevent that by executing CLI before the loop. Of course that would only make any sense if you wanted to kick DOS from memory altogether, for example to load your own OS instead.

Re: The Speed-up Loop

2008-01-24 11:46 • by AdT (unregistered)
173005 in reply to 172998
Ben:
Probably because that loop actually does something?


It's amazing how many people don't understand the C# syntax although in the case of this loop, it's absolutely identical to that of C or C++.

This is a loop whose body consists of the empty statement. It has no effect on program semantics.

Re: The Speed-up Loop

2008-01-24 11:47 • by SomeCoder (unregistered)
173006 in reply to 172989
AdT:
SomeCoder:
One time, I tried something like this:

while (true);

Set the mode to Release and the optimizations to "Speed" and voila, program runs, no infinite loop.

Back in the late 80s though, there probably weren't optimizations like this so that for loop would have happily done nothing... 1000000 times.


What you mentioned is not an optimization, it's a breaking change. Removing an infinite loop is not a speed-up, it's a major semantic change. Just imagine you had put "DeleteAllFilesInUsersHomeDir();" after the loop.

Visual C++ is notorious for "optimizing" code in ways that break it. I encountered such cases myself and have seen co-workers run into similar issues where the Debug code ran fine and the Release version screwed up big time and disabling some optimizations resolved these issues.



The point was not that the loop was infinite; it was that the loop did nothing. Consider:


someThreadVariable = 400;

while (someThreadVariable != 500);

DeleteAllFilesInUsersHomeDir();


If we aren't careful with threading, someThreadVariable could be changed by another thread. So the current thread should "pause" until the other thread changes the variable to 500.

If you run this in debug mode, it will work as you would expect. If you turn on optimizations, Visual Studio will see this as a loop that does nothing and remove it and the "pause" that we would expect is gone.

NOTE: I am not saying that this type of coding is a good idea! It's just an example!!

Re: The Speed-up Loop

2008-01-24 11:54 • by Intelligent Layman (unregistered)
173007 in reply to 172964
> Don't forget it's 1987.

It's not pretend-to-be-a-time-traveler day. You must really be a time traveller.
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Add Comment