• Jim (unregistered) in reply to big picture thinker
    big picture thinker:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    Perhaps the loop was assembly, but just changed to c for ease of reading. The article did say there was some in-line assembly.

    Managers aren't always as stupid as you think and one of them would surely notice that the same, easy-to-read line of c code gets changed on a weekly basis but never removed. It was probably assembly to obfuscate it more.

    Managers actually looka t what was changed now?

  • Andran (unregistered) in reply to Abso
    Abso:
    eric76:
    SuperBK:
    I once encountered code like that for timing delays. Not very portable. On my local system I noticed "wow this code is taking forever", so I took it upon myself to optimize it. It went to the cusomter who had a faster computer and promptly failed.

    I used to have some kind of game on one of the old original IBM PCs that depended on processor speed for timing.

    When I got an 80286, I put the game on it and found it to be completely unplayable because human reaction times weren't fast enough to do anything before your game character was knocked off.

    I remember having the same problem. I also remember having a utility that "fixed" it, by consuming most of the CPU time.
    This was a pretty common problem, which is why there were plenty of "slowdown" utilities. MoSlo and Throttle are some that come to mind, but there were many more.

    Many if not most DOS oldies had timing loops, which meant they ran poorly in newer computers. In fact, this problem was so common than it was a noteworthy occasion when an old DOS game was properly coded, such as Alley Cat (which ran fine in faster computers, see http://www.mobygames.com/game/alley-cat ).

  • Microsoft (unregistered)

    http://support.microsoft.com/kb/192841/en-us

    (This irrelevant line is added to speed up posting because without this irrelevant line TDWTF said this was spam.)

  • (cs) in reply to nonpartisan
    nonpartisan:
    deezil:
    I love how all the typos are still presant in the reposted version.

    CAPTCHA: vindico - Latin for vindicated.

    You can't edit the classics. If you did, then it would be an edited classic and not a classic.

    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Flippin eck. Can't even say it.

  • (cs) in reply to Kef Schecter
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    A little bit. You ought to be okay with the fact that most programmers are ignorant fuckers who just think they're smart.

  • (cs) in reply to Andran
    Andran:
    Abso:
    eric76:
    SuperBK:
    I once encountered code like that for timing delays. Not very portable. On my local system I noticed "wow this code is taking forever", so I took it upon myself to optimize it. It went to the cusomter who had a faster computer and promptly failed.

    I used to have some kind of game on one of the old original IBM PCs that depended on processor speed for timing.

    When I got an 80286, I put the game on it and found it to be completely unplayable because human reaction times weren't fast enough to do anything before your game character was knocked off.

    I remember having the same problem. I also remember having a utility that "fixed" it, by consuming most of the CPU time.
    This was a pretty common problem, which is why there were plenty of "slowdown" utilities. MoSlo and Throttle are some that come to mind, but there were many more.
    Ah, MoSlo. I remember that tool fondly.

    Reminds me of probably my first experience with debugging - as a kid, I quite enjoyed playing Nibbles, which you may recall was distributed in source form (specifically, QBasic source). It actually did have code to check how fast your computer was, and modify its internal speed based on the result of the check... too bad computers quickly got so fast that that check threw a divide by 0 error sometimes. Just running too quickly would probably have been preferable to a divzor. On the plus side, yay open source!

  • jenn (unregistered) in reply to Kef Schecter
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    Was thinking the same thing... At risk of continuing ever more off-topic, Juliet is not asking Romeo where he is, but why he is who he is.

  • (cs) in reply to MeesterTurner
    MeesterTurner:
    I once (very briefly) worked with a guy who told me he'd put loops like this all over some industrial resource calculator program because the calcs took under a second to run, but he wanted to delay it to "make it look like it was working hard doing something"

    It happened once at my first job, but only during an installation routine (and it did eventually get eliminated).

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    A little bit. You ought to be okay with the fact that most programmers are ignorant fuckers who just think they're smart.

    Damn network engineers are worse.

  • Dave (unregistered) in reply to Per
    Per:
    Is there really an "obvious integer overflow"? Isn't the max value of the int-type 2147483647?

    Wow, it's nearly 2012 and all the world's still a VAX.

    (Hint: The post mentions Windows 2.x).

  • foo (unregistered) in reply to eric76
    eric76:
    Back in the 70s, a couple of friends of mine worked as projectionists in an adult movie theater.

    They had a speedup loop of their own.

    Whenever they got a new movie in, they would watch it looking for scenes where they could cut to the next reel of film. On the last showing of the night, they would cut the movie short.

    On a good night, they could reduce an hour of film to about 20 minutes. I've always wondered what the customers thought or if they even noticed.

    Amateurs! They should have cut short all shows and schedule twice as many. Of course, so nobody would notice, alternating in two auditoriums which are actually just two entries to the same one.

  • Borland (unregistered) in reply to Microsoft
    Microsoft:
    http://support.microsoft.com/kb/192841/en-us

    (This irrelevant line is added to speed up posting because without this irrelevant line TDWTF said this was spam.)

    Turbo Pascal had the same problem (http://en.wikipedia.org/wiki/Borland_pascal#Issue_with_CRT_unit_on_fast_processors), though they never even bothered to release a fix. (Others made unofficial patches.)

    Remarkable how the same big corporations that basically require Moore's Law for their ever-more bloated frameworks to remain usable, are ignorant about the effects of this law on their own code just a few years hence.

  • (cs) in reply to nonpartisan
    nonpartisan:
    deezil:
    I love how all the typos are still presant in the reposted version.

    CAPTCHA: vindico - Latin for vindicated.

    You can't edit the classics. If you did, then it would be an edited classic and not a classic.

    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Well it went over pretty well when it was
    WTF AER U ROMEO
    WHY R U A MONTAGUE THATS SUCKS.

  • Lone Marauder (unregistered) in reply to Microsoft
    Microsoft:
    http://support.microsoft.com/kb/192841/en-us

    (This irrelevant line is added to speed up posting because without this irrelevant line TDWTF said this was spam.)

    Dear God, I had forgotten all about that error. Thanks for undoing months of expensive therapy.

  • mmarrero (unregistered) in reply to Andran
    Andran:
    Many if not most DOS oldies had timing loops, which meant they ran poorly in newer computers. In fact, this problem was so common than it was a noteworthy occasion when an old DOS game was properly coded, such as Alley Cat (which ran fine in faster computers, see http://www.mobygames.com/game/alley-cat ).

    Agreed, but, the IBM PC and XT had no hardware interrupts for hsync nor vsync. It's possible to sync the timer interrupt to vsync but it affects the system clock (no RTC), games using this usually didn't return to DOS.

    Taking about WTF speed-up loops, most old PC/XT software had to always wait before writing text! The original IBM CGA card displayed "snow" on the entire display unless video RAM was written during the hync or vsync periods.

  • Rudy (unregistered) in reply to nonpartisan
    nonpartisan:

    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Pretty damn badly, I'd imagine. Seeing as "Wherefore" means "Why", not "Where".

    Yeah. I need to get out more.

  • (cs) in reply to mmarrero
    mmarrero:
    Andran:
    Many if not most DOS oldies had timing loops, which meant they ran poorly in newer computers. In fact, this problem was so common than it was a noteworthy occasion when an old DOS game was properly coded, such as Alley Cat (which ran fine in faster computers, see http://www.mobygames.com/game/alley-cat ).

    Agreed, but, the IBM PC and XT had no hardware interrupts for hsync nor vsync. It's possible to sync the timer interrupt to vsync but it affects the system clock (no RTC), games using this usually didn't return to DOS.

    Taking about WTF speed-up loops, most old PC/XT software had to always wait before writing text! The original IBM CGA card displayed "snow" on the entire display unless video RAM was written during the hync or vsync periods.

    Being able to access VRAM only during h/vblank is a very common limitation on older machines (other times, the GPU is using it, and there's only one bus), but not having interrupts for these? Nevermind the article, this is TRWTF.

  • the beholder (unregistered) in reply to Andran
    Andran:
    Abso:
    eric76:
    SuperBK:
    I once encountered code like that for timing delays. Not very portable. On my local system I noticed "wow this code is taking forever", so I took it upon myself to optimize it. It went to the cusomter who had a faster computer and promptly failed.

    I used to have some kind of game on one of the old original IBM PCs that depended on processor speed for timing.

    When I got an 80286, I put the game on it and found it to be completely unplayable because human reaction times weren't fast enough to do anything before your game character was knocked off.

    I remember having the same problem. I also remember having a utility that "fixed" it, by consuming most of the CPU time.
    This was a pretty common problem, which is why there were plenty of "slowdown" utilities. MoSlo and Throttle are some that come to mind, but there were many more.

    Many if not most DOS oldies had timing loops, which meant they ran poorly in newer computers. In fact, this problem was so common than it was a noteworthy occasion when an old DOS game was properly coded, such as Alley Cat (which ran fine in faster computers, see http://www.mobygames.com/game/alley-cat ).

    And who could forget the Turbo button that was so common on those old PCs?

    I remember when I was a kid I had a 386DX2 and got a Simpsons arcade port. Twice in the game there were bonus stages that asked you to press two alternating keys the faster you could. Unfortunately The Computer Is A Cheating Bastard {url=http://tvtropes.org/pmwiki/pmwiki.php/Main/TheComputerIsACheatingBastard}™{/url}* and your enemies would end the same task as you under 2 seconds. It was humanly impossible to defeat them, but pressing Turbo slowed them to a crawl and I ended up winning without breaking a sweat.


    Akismet's creator is guilty of crimes against humanity. How the hell do we put up with this monstrosity?

    *Intentionally broken tag, or my comment wouldn't get through.

  • Sten (unregistered) in reply to dpm

    For GCC:

    gcc -O0

    or

    #pragma GCC optimize "O0"

    should do the trick

  • (cs) in reply to Jim
    Jim:
    big picture thinker:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    Perhaps the loop was assembly, but just changed to c for ease of reading. The article did say there was some in-line assembly.

    Managers aren't always as stupid as you think and one of them would surely notice that the same, easy-to-read line of c code gets changed on a weekly basis but never removed. It was probably assembly to obfuscate it more.

    Managers actually looka t what was changed now?
    Who are these managers who have that kinda time?

  • (cs) in reply to darkmattar
    darkmattar:
    1048575 - 65536 = 983039 memory spaces available to zero out before overflow... and the loop goes 1000000 times. I assumed this was the "obvious overflow", not the int declaration.

    Don't mind thinking about memory. That code will try to iterate the int untill it reaches 1000000.

    As that int doesn't reach 1000000, you can see the problem.

  • (cs) in reply to anon5
    anon5:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    In case you can't just turn the optimization off (perhaps it would alert the flying monkeys), the trick is to include something inside the loop so that it has some effect in the program's state, then the compiler wouldn't feel confident about removing it.
    It is not that simple to put something there that doesn't change the calculation outcome but still fools the optimizer. The math behind that kind of optimization is quite strong.

    Everything I can think about depends on the number of times the loop runs. Thus would insert bugs on the application if you put the wrong maximum in there.

  • (cs) in reply to Kef Schecter
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    "Yo, Ro, why dey be callin you dat."
  • the beholder (unregistered) in reply to hoodaticus
    hoodaticus:
    Jim:
    big picture thinker:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    Perhaps the loop was assembly, but just changed to c for ease of reading. The article did say there was some in-line assembly.

    Managers aren't always as stupid as you think and one of them would surely notice that the same, easy-to-read line of c code gets changed on a weekly basis but never removed. It was probably assembly to obfuscate it more.

    Managers actually looka t what was changed now?
    Who are these managers who have that kinda time?
    Are you kidding? Time is not the real issue here. I've seen dozens of managers that have time enough for this stuff. The only reasons they don't do it is are laziness and ignorance.

  • (cs) in reply to neminem
    neminem:
    Andran:
    Abso:
    eric76:
    SuperBK:
    I once encountered code like that for timing delays. Not very portable. On my local system I noticed "wow this code is taking forever", so I took it upon myself to optimize it. It went to the cusomter who had a faster computer and promptly failed.

    I used to have some kind of game on one of the old original IBM PCs that depended on processor speed for timing.

    When I got an 80286, I put the game on it and found it to be completely unplayable because human reaction times weren't fast enough to do anything before your game character was knocked off.

    I remember having the same problem. I also remember having a utility that "fixed" it, by consuming most of the CPU time.
    This was a pretty common problem, which is why there were plenty of "slowdown" utilities. MoSlo and Throttle are some that come to mind, but there were many more.
    Ah, MoSlo. I remember that tool fondly.

    Reminds me of probably my first experience with debugging - as a kid, I quite enjoyed playing Nibbles, which you may recall was distributed in source form (specifically, QBasic source). It actually did have code to check how fast your computer was, and modify its internal speed based on the result of the check... too bad computers quickly got so fast that that check threw a divide by 0 error sometimes. Just running too quickly would probably have been preferable to a divzor. On the plus side, yay open source!

    This too: http://support.microsoft.com/kb/312108

  • (cs)

    Back when I worked on image processing software, there was more than one customer who believed we put in these very sort of loops.....

  • (cs) in reply to boog
    boog:
    “The idea is,” Wayne continued, “whenever we have those really slow weeks ... we just drop one of the zeros on the loop. And then we just tell the manager ... we were able to speed things up significantly...”
    Ben should have removed the speed-up loop and taken credit for optimizing the hell out of the application.
    That's all fine and well, but what does he work on tomorrow?
  • (cs)

    Is Alex still in-laws place eating Christmas stuff?

  • Homer J. (unregistered) in reply to the beholder
    the beholder:
    I remember when I was a kid I had a 386DX2 and got a Simpsons arcade port.
    D'oh, I feel old now!
  • foo (unregistered) in reply to Mcoder
    Mcoder:
    anon5:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    In case you can't just turn the optimization off (perhaps it would alert the flying monkeys), the trick is to include something inside the loop so that it has some effect in the program's state, then the compiler wouldn't feel confident about removing it.
    It is not that simple to put something there that doesn't change the calculation outcome but still fools the optimizer.
    Sure, "volatile".
  • (cs) in reply to G W C
    G W C:
    Back when I worked on image processing software, there was more than one customer who believed we put in these very sort of loops.....
    .....AND?
  • (cs) in reply to the beholder
    the beholder:
    hoodaticus:
    Jim:
    big picture thinker:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    Perhaps the loop was assembly, but just changed to c for ease of reading. The article did say there was some in-line assembly.

    Managers aren't always as stupid as you think and one of them would surely notice that the same, easy-to-read line of c code gets changed on a weekly basis but never removed. It was probably assembly to obfuscate it more.

    Managers actually looka t what was changed now?
    Who are these managers who have that kinda time?
    Are you kidding? Time is not the real issue here. I've seen dozens of managers that have time enough for this stuff. The only reasons they don't do it is are laziness and ignorance.
    You successfully decoded my management speak. Bravo.

  • (cs) in reply to foo
    foo:
    Mcoder:
    anon5:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    In case you can't just turn the optimization off (perhaps it would alert the flying monkeys), the trick is to include something inside the loop so that it has some effect in the program's state, then the compiler wouldn't feel confident about removing it.
    It is not that simple to put something there that doesn't change the calculation outcome but still fools the optimizer.
    Sure, "volatile".

    Any updating of shared state should do it.

  • (cs)

    Windows 2.11? I don't remember that one.

  • Blackchip (unregistered) in reply to DWalker59

    From 1989. See http://en.wikipedia.org/wiki/Windows_2.1x#Windows_2.11

  • Tud (unregistered)

    “The idea is,” Alex continued, “whenever we have those really slow weeks – you know, the kind where don’t actually have any WTFs any other stories – we just re-post an old WTF. And then we just tell the readers that we ran into some issues with the latest story, but after a whole lot of deep-juju searching, we were able to come up with a WTF that's still interesting and should be able to find a few new ones the next week.”

  • foo (unregistered) in reply to Tud
    Tud:
    “The idea is,” Alex continued, “whenever we have those really slow weeks – you know, the kind where don’t actually have any WTFs any other stories – we just re-post an old WTF.
    And the next day, just nothing at all.

    Suggestion for tomorrow: null

  • FuBar (unregistered) in reply to Kef Schecter
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"
    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?
    In other words, 'wherefore' means 'where' just as much as 'therefore' means 'there'.

    (Another one I like is: 'fulsome' means 'full' just as much as 'noisome' means 'noise'. Etymylogically, 'noisome' is related to 'annoy' and 'fulsome' is related to 'foul'.)

  • d (unregistered) in reply to Per
    Per:
    Is there really an "obvious integer overflow"? Isn't the max value of the
    int
    -type 2147483647?

    And can you really use ++ on a

    char
    -type?

    Sorry for my questions, but I'm still a beginner at programming.

    (Or am I missing the sarcasm in the text? :-p)

    The size of int depends on what compiler you use (or rather - what the compiler thinks it should do). For instance, avr-gcc (for 8 bit AVRs) will interpret int as 16 bit.

  • Shakin' Bill (unregistered) in reply to nonpartisan
    nonpartisan:
    deezil:
    I love how all the typos are still presant in the reposted version.

    CAPTCHA: vindico - Latin for vindicated.

    You can't edit the classics. If you did, then it would be an edited classic and not a classic.

    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Actually, a more correct interpretation would be:

    "Dang, Ro! How's come you hafta be a black hat?"

  • (cs) in reply to Per
    Per:
    Is there really an "obvious integer overflow"? Isn't the max value of the
    int
    -type 2147483647?

    Not everything is Java ;) The purported loop is in C-like pseudocode, and that should give you a hint ;)

    In C and C++ the size of an int is platform (hardware+OS) dependent. The C standard guarantees that a signed or unsigned int will be at least 16 bits long. In some platforms it could be 32 bits, in others it could be 16. Heck there is nothing preventing it to be, say 24 or 28 bits.

    So if you want an int type that is guaranteed to be of a certain size, you need to use one of the typedefs in stdint.h/cstdint.h . For example, you want a 32 bit int, you use int32_t, or uint32_t for an unsigned 32 bit int, or int16_t/uint16_t, or uint8_t/int8_t...

    Per:
    And can you really use ++ on a
    char
    -type?

    That's an standard capability of most (if not all) languages that follow a C-like syntax. And a char is nothing more than a 8-bit (or 16 or 32-bit) numeric value. Take 'i' for instance. Its ascii value is 105 decimal. If you increase it by one, then you get 106 decimal, which is simply the successor of 'i', which is 'j'. So doing 'i'++ simply yields 'j'.

    Per:
    Sorry for my questions, but I'm still a beginner at programming.

    (Or am I missing the sarcasm in the text? :-p)

    Asking questions is how we learn ;)

  • (cs) in reply to jenn
    jenn:
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    Was thinking the same thing... At risk of continuing ever more off-topic, Juliet is not asking Romeo where he is, but why he is who he is.

    Or: "Romeo, Romeo, the real WTF is that you're a frigging Montague, FFS."

  • (cs) in reply to Shakin' Bill
    Shakin' Bill:
    nonpartisan:
    deezil:
    I love how all the typos are still presant in the reposted version.

    CAPTCHA: vindico - Latin for vindicated.

    You can't edit the classics. If you did, then it would be an edited classic and not a classic.

    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Actually, a more correct interpretation would be:

    "Dang, Ro! How's come you hafta be a black hat?"

    Indeed.

    I'm thinking this deceased equine has been thoroughly flogged and the remains should be inhumed approximately 1.8288m below ground level. This being TDWTF, the remainder of the audience will go out and procure whips, chains, rods, Tiki torches (local story), and the like in order to continue the flagellation for the simple purpose of participation with no discernible value.

  • (cs) in reply to Jim
    Jim:
    big picture thinker:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    Perhaps the loop was assembly, but just changed to c for ease of reading. The article did say there was some in-line assembly.

    Managers aren't always as stupid as you think and one of them would surely notice that the same, easy-to-read line of c code gets changed on a weekly basis but never removed. It was probably assembly to obfuscate it more.

    Managers actually looka t what was changed now?

    Fuckinell yes we do. It's called "code reviews". If any of the monkeys try and get something like that past me then I'll need a hefty bribe and a cut of their bonuses or their out on their arses.

  • The Capricious Meteorologist (unregistered) in reply to Nag-Geoff
    Nag-Geoff:
    frozen requirements?

    I'm naming my Silicon Valley Sno-cone shop that (or maybe my cryogenic storage facility (heck why not a combo?)). It'll be a wonderful inside joke.

  • (cs) in reply to Microsoft
    Microsoft:
    http://support.microsoft.com/kb/192841/en-us

    (This irrelevant line is added to speed up posting because without this irrelevant line TDWTF said this was spam.)

    Correct me if i'm wrong, but doesn't that actually make that line relevent? Or is it as useless as the speedup loop?

  • (cs) in reply to Per
    Per:
    Thank you all for explaining the int and pointer for me. I didn't know what the * meant in the code, and didn't realize that once upon a time in the 80's a int wasn't the same as a int in the 21th century.

    Thank you all for enlightening me. :-)

    It's not that int used to be different, it's that in C++, the max value for int, char, long int, etc are "implementation dependent." That means it's up to the compiler writer to define those things, possibly based on the system it's running on. There are some requirements -- for example a lowest possible max value for each type and guarantees that some types are larger than others.

    But actual values may differ, and might be more likely to be different today than in the 80s. There might be some embedded systems with limited resources that use smaller data types than what you would find on a PC or server.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Jim:
    big picture thinker:
    dpm:
    How did Wayne keep the compiler from simply skipping that code altogether? In 1985, I had a boss who tried to do exactly the same thing for the same reason, but was foiled by the optimizer and never figured out why.
    Perhaps the loop was assembly, but just changed to c for ease of reading. The article did say there was some in-line assembly.

    Managers aren't always as stupid as you think and one of them would surely notice that the same, easy-to-read line of c code gets changed on a weekly basis but never removed. It was probably assembly to obfuscate it more.

    Managers actually looka t what was changed now?

    Fuckinell yes we do. It's called "code reviews". If any of the monkeys try and get something like that past me then I'll need a hefty bribe and a cut of their bonuses or their out on their arses.

    We fire monkeys - we don't employ them. Unless, of course, they work for bananas... but with that productivity level, I'd feel like I was stealing from the company by keeping them on my team.

    We tend to hire programmers instead of monkeys. You have to pay them - and it isn't cheap, but I've learned that working with monkeys slowly dissolves your soul. The same goes for being treated as a monkey (unless you are a monkey, of course).

    I sneak in and review code behind my people's backs and then have them terminated if they force me to submit their code here. That's my process. It's Darwinian: they're the species, and I'm natural selection eliminating the unfit.

    Addendum (2011-12-28 22:58): And yes, agile would be much better, but I don't have a team that works well together or sufficient proof of incompetence (yet) to have them terminated.

  • (cs) in reply to jenn
    jenn:
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    Was thinking the same thing... At risk of continuing ever more off-topic, Juliet is not asking Romeo where he is, but why he is who he is.

    She's really just whining at the universe that her lover had to be on opposite sides of an inter-clan blood feud. It has nothing to do with the metaphysical question of who Romeo is.

  • (cs) in reply to nonpartisan
    nonpartisan:
    Matt Westwood:
    Kef Schecter:
    nonpartisan:
    How well do you think it'd go over if Juliet asked, "Yo Ro, where y'at?"

    Is it weird that I'm bothered less by the modern slang and more by the fact that "wherefore" does not mean "where"?

    A little bit. You ought to be okay with the fact that most programmers are ignorant fuckers who just think they're smart.

    Damn network engineers are worse.

    This.

    I actually have a real life case where I can determine their worth.

    The WAN has two LANs linked by MPLS - a thousand miles between domains in the forest. They were joined a year ago as part of a merger.

    My network has never gone down. My Exchange always works, my DC's are always up, my databases are always running.

    The other network has a dedicated network engineer. His Exchange works about two weeks between crashes. His SQL processes fail 50% of the time. Yes, we replaced both - hardware and software. There is a 15 second latency before the fastest query returns. The OLAP cubes take up to 5 minutes to return results (and as said before, half the time, the cubes didn't get updated anyway). He has yet to get kerberos to work.

    I know what you're thinking: half of that crap shouldn't even be in his lap. But it isn't. This shit happens because (besides outsourced Indian quarter-million dollar OLAP boondoggle of a monstrosity and 1.5 megaloc COBOL fossil) the problem is caused by the network. It's so freaking slow, all technology that connects to it randomly goes on strike as if to protest abusive working conditions.

    Is their job description really, "Show Up, The End"? Shouldn't they figure out what's causing the slowness and give us a proposal to fix it, then do it?

    Network engineer really doesn't mean anything other than knowing what can be learned on the job through google or technet, yes?

Leave a comment on “Classic WTF: The Speed-up Loop”

Log In or post as a guest

Replying to comment #:

« Return to Article