Proof of the hardware/software company conspiracy

[brew]

I love how everyone attempted to attack me in this topic. First off:
TheMinistered, I have updated my code so that it checks for any flags first.
What I tried to do was simple, utilize break-through so that it would execute however many temp++s there are (at the time it looked attractive to me-- inc eax takes one byte), and IMO it looked silly for sequential cases to return sequential static values.
It didn't work out like that however.
What I was outraged about this was how the compiler places two movs after every case. I was hoping it would see what I am doing, and use eax in lieu of that variable. Because I've always taken for granted that the compiler writes the optimal code for the situation, I was shellshocked to discover this when checking out what it compiled to.
I tried writing my own equivalent in assembly, and using my break-through method, it actually takes 33% longer to execute then it would if I returned static values (the compiler ends up changing it to push 8bit, pop eax). Sure, the code ends up being 2 bytes bigger for every case there is, but in my opinion, speed is much more valuable then memory usage here.
And frozen: Why would i want to be parsing the client/flags by refrence? Do you understand what you're talking about? Do you get what passing something by refrence actually means? Do you know how the compiler accomplishes that?

[Warrior]

Everyone attacked you in hopes you'd realize how silly you're being.

[FrOzeN]

And frozen: Why would i want to be parsing the client/flags by refrence? Do you understand what you're talking about? Do you get what passing something by refrence actually means? Do you know how the compiler accomplishes that?

So, I've only been learning C++ less than two weeks and I figured parsing something by it's address is faster than creating a new value and copying the data across. A fairly logical assumption in my opinion.

Anyway, I decided to run some benchmarks to see the difference in speed. It wasn't until I ran it through 100 million iterations before I started noticing a reasonable difference (ie. 50 milliseconds). Seriously, you're wasting so much time optimizing code that already runs at the speed of light.

[brew]

So, I've only been learning C++ less than two weeks and I figured parsing something by it's address is faster than creating a new value and copying the data across. A fairly logical assumption in my opinion.

Protip: it's not. You figured wrong.
What if i wanted to make it fastcall? I'd be forcing the compiler to make the flags and ping actual variables on the stack if it already weren't a variable (note: the stack is slow when compared to registers) in order to lea the address into the variable, then it'd have to use mov eax, dword ptr [eax] anyways in order to do the cmp, where i could've just left it as eax. end of story. All of that adds up to take many more instructions then you'd think.
Sure, it may seem like such a small improvement on performance, but what you have said, right here, is the REASON why computers never got faster. We take for granted that our processors can handle extra instructions like nothing, ignorant to the fact that all of this builds up over time, and our once lightning-fast programs become more akin to turtles then rabbits, with no real change in stability or productivity.

Here is the evolution of microsoft windows:

Code Select Expand


Recommended specs-
Version                 Speed   | Ram    | Disk space
Windows 95              25 MHz  | 8   MB | ~50       MB
Windows 98              66 MHz  | 24  MB | 140 – 255 MB
Windows Me              150 MHz | 32  MB | 320       MB
Windows 2000 Server     133 MHz | 64  MB | 1         GB
Windows XP              300 MHz | 128 MB | 1.5       GB
Windows Vista           1 GHz   | 1   GB | 15        GB

Have our ways of computing really changed since windows 2k? Yet look at that, it takes 16 times less RAM to run then vista, and 15 times less disk space. That is not only the result of more features, but because of bad programming practices as well. Back in the '70s if frozen said that, he would've been guilotined. Now today's world of software companies believe that it's product's success lies within the time it takes to produce and the number of useless features, further promoting high level programming languages and a slower end product. What fools.

[Leaky]

Have our ways of computing really changed since windows 2k? Yet look at that, it takes 16 times less RAM to run then vista, and 15 times less disk space. That is not only the result of more features, but because of bad programming practices as well. Back in the '70s if frozen said that, he would've been guilotined. Now today's world of software companies believe that it's product's success lies within the time it takes to produce and the number of useless features, further promoting high level programming languages and a slower end product. What fools.

WHAT??? you mean it's not a good success strategy to make my bots able to grate cheese?

[Banana fanna fo fanna]

You guys are both retarded.

- brew is being silly in order to prove how awesome he is
- passing a long by reference is silly. at least on my machine, a long is a processor word and therefore fits in a register. the compiler would probably pass it in a register. if you're passing it by reference, it has to be stored in memory and can't be stored in a register which is much faster. if a long was NOT a machine word, however, it would be faster to pass by reference as you'd only pass the memory address rather than copying the memory on to the stack.

In essence, frozen was almost correct. brew, I agree in the hardware software conspiracy, but I think you're just being an asshole.

[brew]

if a long was NOT a machine word, however, it would be faster to pass by reference as you'd only pass the memory address rather than copying the memory on to the stack.

if a long was NOT a machine word, however, it would be faster to pass by reference

if a long was NOT a machine word

Suprise, it is! Say the machine word was 64 bits. What's that going to change? Is it faster to push the 64-bit address onto the stack or pass the 32 bit number by value? cough*zero extend*cough. If the case here would be opposite, (apparently you're using a 16 bit machine?) then yeah, i can see where you're going, but this code isn't MADE for dos. sorry. And before anyone attacks me about the size of a long, look here: http://en.wikipedia.org/wiki/Long_integer
It's always 4 bytes, in the C programming language. Always. And before anyone says something about the size of a byte, it's ASSUMED TO BE 8 BITS. IF IT IS NOT 8 BITS, YOU AND YOUR COMPUTER MUST BE FROM CIRCA 1950. so shut up and don't try to get technical.

[l2k-Shadow]

It's always 4 bytes, in the C programming language. Always. And before anyone says something about the size of a byte, it's ASSUMED TO BE 8 BITS. IF IT IS NOT 8 BITS, YOU AND YOUR COMPUTER MUST BE FROM CIRCA 1950. so shut up and don't try to get technical.

the data type sizes depend on the compiler and the data model of that compiler, so shut up and stop trying to say that you know everything when you don't.
http://en.wikipedia.org/wiki/64_bit#64-bit_data_models

[Banana fanna fo fanna]

if a long was NOT a machine word, however, it would be faster to pass by reference as you'd only pass the memory address rather than copying the memory on to the stack.

if a long was NOT a machine word, however, it would be faster to pass by reference

if a long was NOT a machine word

Suprise, it is! Say the machine word was 64 bits. What's that going to change? Is it faster to push the 64-bit address onto the stack or pass the 32 bit number by value? cough*zero extend*cough. If the case here would be opposite, (apparently you're using a 16 bit machine?) then yeah, i can see where you're going, but this code isn't MADE for dos. sorry. And before anyone attacks me about the size of a long, look here: http://en.wikipedia.org/wiki/Long_integer
It's always 4 bytes, in the C programming language. Always. And before anyone says something about the size of a byte, it's ASSUMED TO BE 8 BITS. IF IT IS NOT 8 BITS, YOU AND YOUR COMPUTER MUST BE FROM CIRCA 1950. so shut up and don't try to get technical.

no shit, pledge. i hope you aren't critiquing me. i was saying that i think frozen was confused about the size of a unsigned long.

[brew]

It's always 4 bytes, in the C programming language. Always. And before anyone says something about the size of a byte, it's ASSUMED TO BE 8 BITS. IF IT IS NOT 8 BITS, YOU AND YOUR COMPUTER MUST BE FROM CIRCA 1950. so shut up and don't try to get technical.

the data type sizes depend on the compiler and the data model of that compiler, so shut up and stop trying to say that you know everything when you don't.
http://en.wikipedia.org/wiki/64_bit#64-bit_data_models

I didn't say I know everything. I'm just saying that I'm tired of people picking out small stupid little details and making a huge deal out of it. This exact thing happened to me at least 3 times this week. I'm physically TIRED of arguing about the size of data types. I'm sorry, I misread that wiki article. My point was that frozen really was wrong, banana tried to back him up though saying he wasn't entirely wrong. No, he wasn't. But the case that banana presented where frozen wouldn't be wrong is just hardly ever seen in practice. I was just pointing that out.
and wtf is with me being the pledge, i'm not the pledge. okay???

[MyndFyre]

[Protip:

LOL Please.

So, I've only been learning C++ less than two weeks and I figured parsing something by it's address is faster than creating a new value and copying the data across. A fairly logical assumption in my opinion.

You're incorrect in this case.

Here's what happens when you call a function:
Local stack variables being passed by value are copied onto the stack, usually padded to 4 or 8 bytes depending on the architecture.  For example:

Code Select Expand


int a = 10;
func(a);

Local stack variables being passed by reference have their addresses copied onto the stack, always 4 or 8 bytes depending on the architecture.  Example:

Code Select Expand


int a = 10;
func(&a);

Local heap variables being passed by value are copied onto the stack, always 4 or 8 bytes depending on the architecture.  Example:

Code Select Expand


CString* str = new CString;
str("Blaaaaarrgh");
func(str);  // changes made to the parameter affect the object pointed-to by the str pointer.

Local heap variables being passed by reference (for instance, to change the address of a pointer inside of a function) have their addresses in the local function passed to the callee.  Example:

Code Select Expand


CString* str = new CString;
str("Blaaaaaaaaaaaaaaaaaarrgh!");
func(&str);


In the second and fourth examples, passing by reference allows you to modify the variable internal to the calling function - the actual pointer will be different in the fourth example.  

Passing variables by reference is really only faster when it involves copying a value larger than the machine pointer size.

[brew]

Protip:

LOL Please.

wat? it's a 4chan meme that was just all too easy to insert ITT. for those of you who don't know, here is the original image:

[Mystical]

i think my IQ just dropped.

[FrOzeN]

It's always 4 bytes, in the C programming language. Always. And before anyone says something about the size of a byte, it's ASSUMED TO BE 8 BITS. IF IT IS NOT 8 BITS, YOU AND YOUR COMPUTER MUST BE FROM CIRCA 1950. so shut up and don't try to get technical.

the data type sizes depend on the compiler and the data model of that compiler, so shut up and stop trying to say that you know everything when you don't.
http://en.wikipedia.org/wiki/64_bit#64-bit_data_models

Shouldn't data types be independent of the compiler? Instead, follow the rules of the language? (At least if you're using Stardard C++)

From the way I've seen it so far, it goes like this: Short and long aren't data types, they are data type modifiers. A short is actually shorthand for short int which should force an integer to be 16-bit. A long is short for a long int which forces it to be 32-bit. An int without a data type modifier should be either 16 or 32 bits depending on the system. Also, ISO C++ 99 introduces the use of long long int which forces a 64-bit integer.

---
Coming to think of how it all works, it does make sense now that parsing a value smaller or equal to the size of an address would be faster. You can thank VB6 for indoctrinating me with "ByRef is always faster than ByVal" shit. Maybe the way VB6 handles data types that statement would be true for the most part, unfortunately I brought the concept with me to C++ without much of a thought.

[Kp]

As I recall, the rules of the language are somewhat vague on that point.  A short int is not larger than an int and a long int is not smaller than an int.  The standard does not declare that a long int must be 32 bits.  Further, the standard does not declare that an int must be the size of a short int or the size of a long int.  On an AMD64 platform, gcc implements int as 32 bits and long int as 64 bits.  See the description of -m32 and -m64 in info gcc for details.