The Daily WTF: Curious Perversions in Information Technology

Chris Butler · 2004-12-09 Reply Admin

Holy hell...

I hope you're joking too.............

JoeNotCharles · 2004-12-09 Reply Admin

KoFFiE:
Damn - I _really_ hop you're joking... the original stunned me a bit - but this is really fucked up... The comment "No reason to waste time initializing this again every time we're called" really is the finishing touch... You're only wasting thousands and thousands of times the cpu-power necessary.... Oh boy...

Actually, I think I good compiler would notice that the function always begins with a write to the static, and that there's no way to read to it from outside the function, so it can be optimized to a register. If it were really smart, it would conclude that the programmer is on crack and throw the static away, but more likely it'd make space in memory for it but never use it. So that line wouldn't be too harmful - mostly it'd just be pointless. To really muck this up, you need to use "volatile".

(Why yes, I was reading about liveness analysis just last night. Why do you ask?)

JoeNotCharles · 2004-12-09 Reply Admin

JoeNotCharles:
Actually, I think I good compiler...

I good compiler and I good at grammar too!

redtetrahedron · 2004-12-09 Reply Admin

icelava:

[image] Alex Papadimoulis wrote:

Note the elite use of hexidecimal.
Everybody knows "real programmers code in binary".

And know how to spell hexadecimal.

2004-12-09 Reply Admin

Actually, I think the language in which the function was written was C or C++, in which statics are initialized exactly once. Therefore, the function does not "always begin with a write to the static". Since int is a primitive type, I'd expect the compiler to have that set up in the image already. Remember, it's not on the stack. See Stroustrup, The C++ Programming Language 3rd edition, Section 7.1.2 (p145). I don't have K&R2 here at the office; sorry. It'll tell you the same thing.

Throwing the static away would be an odd thing for a compiler to do, because it's used (it's the loop counter variable). For the same reason, not using it at all would also be very odd indeed.

The punchline on that static declaration is something else entirely: Think about my first paragraph above. Walk through the logic in the function. What happens the second time the function is called? "Harmless" would not be my first choice of words.

I'm making some assumptions here, obviously, about your intent. When you say "throw away the static", I'm guessing that you mean "throw away that variable". I may be wrong; it could be that you mean "keep the variable, but make it automatic instead". If that's what you mean, forget it: An automatic can't possibly do what that variable is doing (what it's doing is insane, of course, but the compiler can't know that) -- though I'll concede that a really clever compiler could copy the variable's value to a register, use that for the actual loop counter while the loop is executing, then copy the ending value to the static after the loop exits (assuming that the compiler can be certain the code needn't be re-entrant or thread-safe). If that's what you mean, you're right, that would be pretty cool. But all the register thing would do is save a pittance in cycles on roughly 2^31 unnecessary iterations, each of which spends an enormous amount of time doing perfectly senseless busywork. An alert optimizing compiler, with a keen sense of what its own standard library is all about (and great trust in the linker), might in theory actually optimize out most of that busywork. I should compile the code with /Fa (MSVC) and all optimizations turned on and see what happens.

2004-12-09 Reply Admin

In the above, "2^31" was meant to indicate "two to the thirty-first power", not "2 bitwise-xor 31".

JoeNotCharles · 2004-12-09 Reply Admin

:
Actually, I think the language in which the function was written was C or C++, in which statics are initialized exactly once. Therefore, the function does not "always begin with a write to the static".

What I mean is that the first statement it would actually execute was the "for" statement, which wrote to i, so the liveness analysis would notice that it didn't actually matter what was stored in the static memory area and would skip the memory-to-register move.

...except I just noticed the for loop doesn't actually write to i. I'm too used to looking at normal code.

Since int is a primitive type, I'd expect the compiler to have that set up in the image already. Remember, it's not on the stack.

Exactly - I figured the inefficiency that was mentioned was the requirement to copy i to and from memory every time the function is called.

The punchline on that static declaration is something else entirely: Think about my first paragraph above. Walk through the logic in the function. What happens the second time the function is called? "Harmless" would not be my first choice of words.

Yeah, I completely missed the fact that the loop was missing the initializer - I figured the point of the static was a misguided attempt to avoid allocating local variables and thus get a smaller stack frame. Clearly, I'm overthinking things.

This would almost make sense if the strtol calls were outside the loop, so that he initializes an array on the first call and then each call just looks for the nValue parameter in the array. And if he weren't reusing buf. And if... Argh! It's so close to actually using recognizable patterns, but it's just so wrong! A masterpiece of devilry.

I'm making some assumptions here, obviously, about your intent. When you say "throw away the static", I'm guessing that you mean "throw away that variable". I may be wrong; it could be that you mean "keep the variable, but make it automatic instead".

Yeah, that's what I meant.

-- though I'll concede that a really clever compiler could copy the variable's value to a register, use that for the actual loop counter while the loop is executing, then copy the ending value to the static after the loop exits (assuming that the compiler can be certain the code needn't be re-entrant or thread-safe).

I assumed that's what it always did - having to go back to memory for every access to a static seems insanely slow. If you need the variable to be unoptimized, use "volatile".

Not that I've looked at how any real compilers are implemented - I only know the theory.

2004-12-09 Reply Admin

Geez, can you say "paid for each line of code they write?"

2004-12-10 Reply Admin

JoeNotCharles:
[image] wrote:
Actually, I think the language in which the function was written was C or C++, in which statics are initialized exactly once. Therefore, the function does not "always begin with a write to the static".

What I mean is that the first statement it would actually execute was the "for" statement, which wrote to i, so the liveness analysis would notice that it didn't actually matter what was stored in the static memory area and would skip the memory-to-register move.

...except I just noticed the for loop doesn't actually write to i. I'm too used to looking at normal code.

Since int is a primitive type, I'd expect the compiler to have that set up in the image already. Remember, it's not on the stack.

Exactly - I figured the inefficiency that was mentioned was the requirement to copy i to and from memory every time the function is called.

The punchline on that static declaration is something else entirely: Think about my first paragraph above. Walk through the logic in the function. What happens the second time the function is called? "Harmless" would not be my first choice of words.

Yeah, I completely missed the fact that the loop was missing the initializer - I figured the point of the static was a misguided attempt to avoid allocating local variables and thus get a smaller stack frame. Clearly, I'm overthinking things.

This would almost make sense if the strtol calls were outside the loop, so that he initializes an array on the first call and then each call just looks for the nValue parameter in the array. And if he weren't reusing buf. And if... Argh! It's so close to actually using recognizable patterns, but it's just so wrong! A masterpiece of devilry.

I'm making some assumptions here, obviously, about your intent. When you say "throw away the static", I'm guessing that you mean "throw away that variable". I may be wrong; it could be that you mean "keep the variable, but make it automatic instead".

Yeah, that's what I meant.

-- though I'll concede that a really clever compiler could copy the variable's value to a register, use that for the actual loop counter while the loop is executing, then copy the ending value to the static after the loop exits (assuming that the compiler can be certain the code needn't be re-entrant or thread-safe).

I assumed that's what it always did - having to go back to memory for every access to a static seems insanely slow. If you need the variable to be unoptimized, use "volatile".

Not that I've looked at how any real compilers are implemented - I only know the theory.

2004-12-10 Reply Admin

JoeNotCharles,

This new comment software is indescribably rotten. In the immediately preceding post, I removed everything but the one line, then added a reply -- so the server restored the entire quoted post and ditched my addition. No doubt it was user error, but it's hard for me to imagine how I should've removed the text if simply removing the text didn't do the job. That's on top of the microscopic font, the blizzard of utterly useless visual "noise", and yada yada yada. Horrible. Truly horrible.

Anyway...

...except I just noticed the for loop doesn't actually write to i. I'm too used to looking at normal code.

But it does write to i. There's a ++i in the for loop header.

2004-12-12 Reply Admin

There are only 10 types of people in the world: Those who understand binary and those who don't [;)] wuuuuuuu!!!!!

kellyleahy · 2004-12-14 Reply Admin

JoeNotCharles:

[image] wrote:

Actually, I think the language in which the function was written was C or C++, in which statics are initialized exactly once. Therefore, the function does not "always begin with a write to the static".

What I mean is that the first statement it would actually execute was the "for" statement, which wrote to i, so the liveness analysis would notice that it didn't actually matter what was stored in the static memory area and would skip the memory-to-register move.

...except I just noticed the for loop doesn't actually write to i. I'm too used to looking at normal code.

Actually, its much worse that that. The for loop does write to i, but it doesn't initialize i. Also, the static =0 initializer is only at compile time, which means that i will continue to grow each time the function is called (except that the for simply won't execute the next time around as the guard is not satisified for entering the loop). I think you may have been getting at this problem in your post...

However, what about the character array? It is stackalloced each time the call is made - and costs a hell of a lot more to do than i = 0 does! If one is going to try to make something more efficient, one should at least concentrate on the changes that reap the most benefits -hehehe.

All I can say is WOW - it's a good thing most of these posters are anonymous. Sometimes their replies are worse than the original code!

Kelly

2005-02-13 Reply Admin

Wouldn't this effectively do what the guy is trying to do?
[code language="c#"]
void m_SetYear ( CTime &Time ) 
{ 
   m_TagDate.Year = (Time.GetYear() - 2000);
} 

void m_SetMonth ( CTime &Time ) 
{
   int month = Time.GetMonth();
   if (month >= 1 && month <= 12)
   {
      m_TagDate.Month = Time.GetMonth();
   }
}

void m_SetDay ( CTime &Time ) 
{
   int day = Time.GetDay;
   if (day >= 1 && day <= 31)
   {
      m_TagDate.Day = Time.GetDay();
   }
} 

void m_SetHour ( CTime &Time) 
{ 
   int hour = Time.GetHour();
   if (hour >= 0 && hour <= 24)
   {
      m_TagTime.Hour = hour;
   }
} 

void m_SetMinute( CTime &Time ) 
{ 
   int minute = Time.GetMinute();
   if (minute >= 0 && minute <= 60)
   {
      m_TagTime.Minute = time;
   } 

} 

void m_SetSecond( CTime &Time ) 
{ 
   int second = Time.GetSecond();
   if (second >= 0 && second <= 60)
   {
      m_TagTime.Second = second;
   } 
} 
[/code]

2005-02-17 Reply Admin

NO !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

void m_SetYear ( cTime &Time )
(
int nYear = cTime.GetYear();
m_TagDate.Year = 0;
if (nYear >= 2000 && nYear <= 2006)
{
m_TagDate.Year = (nYear - 2000);
}
}

void m_SetMonth ( cTime &Time )
{
m_TagDate.Month = cTime.GetMonth();
}

void m_SetDay ( cTime &Time )
{
m_TagDate.Day = cTime.GetDay();
}

void m_SetHour ( cTime &Time)
{
m_TagTime.Hour = cTime.GetHour();
}

void m_SetMinute( cTime &Time )
{
m_TagTime.Minute = cTime.GetMinute();
}

void m_SetSecond( cTime &Time )
{
m_TagTime.Second = cTime.GetSecond();
}

And this assumes seconds are integers and not real (abit like this thread!)

Although you would probably set m_TagTime.Time to cTime then call mSet_Year(cTime) only, but we don't know if .Time exists....

2008-01-11 Reply Admin

There're also apparently 25 hours in a day. Impressive.

Stand Back, I've got Hexidecimal

Leave a comment on “Stand Back, I've got Hexidecimal”