Female Programmers Unite!

On behalf of my good friend Kendall, here is her compiler/interpreter tutorial just uploaded hours ago:

http://www.youtube.com/v/1XZoKXJpbVg&hl=en_US&fs=1&;

Enjoy!

I'll rip you a new asshole with my evaluator, baby.

>>39
On common C compilers for x86:

You do know that that doesn't measure much, except for your CPU's speed and if it's compiled to 32bit or 64bit code. Most compilers will allocate an entire register's size for a variable. So you end up with a stackallocated char/short/int taking a whole int for 32bit archs. For long long's, they'll use either 2 registers or one 64bit register if it was targetted for x86_64. Also note that various delays can be introduced because of context switches and other tasks running too.

If you really want to find out if something really matters, just fire up your favorite disassembler or have your C compiler generate an ASM listing, and the listing will explain why you got those numbers.

>>42
Right, that's why 1 byte datatypes and 4 byte datatypes were faster when allocated outside of a loop. Because it's using 2 registers for 8 byte datatypes.

The measurement was obviously not to indicate the speed, but rather, the difference in speed. Unless you're arguing that your precious context switches account for an almost uniformly 30,000ms difference in only specific datatypes, in which case, IHBT.

The test was by no means strictly scientific, but I wasn't doing anything else at the time. It's sufficient to illustrate the difference in speed. Because the only thing that changed was the positioning of the variable declaration, it's a safe assumption that the stack allocation makes a difference even in primitives. This difference becomes MUCH larger when you factor complex objects in Sepples.

Your entire argument was that it keeps the variables on the stack for the entire loop execution anyway, which is obviously not the case in at least some situations with primitives.

Just in case there is still confusion, the content of >>16:
and the declaration of loop variables makes no difference at all; they are just references to stack space which are the same whether they are in the loop or outside the loop

That's the original argument. That the declaration of loop variables makes no difference at all. Clearly it does!

>>43
Of course there will be a slight performance difference if the compiler chooses to stack allocate/deallocate a variable within a loop (in your case this happens a lot, which illustrates the penalty). It is however nothing more than adjusting the stack pointer on loop entry and exit, or if the compiler is smarter, it might be able to (in some cases) completly preallocate the needed space in the function prologue (no add/sub stack pointer instructions needed). Of course it's possible to make educated guesses on the compiler's behaviour depending on the code you wrote and the arch you're targetting and of course the compiler you're using, the only way to know for sure is to check the assembly listing. I don't think it's something to worry about unless you're doing it in a truly speed-critical loop, but in that case, if performance is so important for that function and the compiler isn't performing that well(after you profile), you might as well write the function in assembler.

>>22

No. That "tutorial" was the level of browsing Wikipedia for five minutes.

Lol bitch

>>32
>I love to play video games, watch anime, and read. I also try my hand at creative writing occasionally, and linguistics is an amusing passtime. But in the end, programming is my one true love, and I work very hard to improve myself at it by studying code, experimenting with new ideas, teaching others so that I can gain a more complete understanding, and of course, reading everything I can get my hands on. It's fun, it's educational, and when I tell my grandkids how I spent my youth, I can say I did productive things.
There is no way that is real. No way.

>>43

It's interesting that it would make that much a difference. Technically, in the style of a for loop that you posted, the variable local to the loop should be allocated once when the loop begins, and then deallocated once when the loop eventually exits, and I don't see why it would be any different inside or outside of the loop in that case, as even with the variable outside of the loop, the variable is allocated once when the function starts, and is deallocated once when the function returns. So there should be the same amount of work in both cases. But in general, when you have loops inside of loops and all that, I can see why having all of your variables allocated once at the beginning of the function and deallocated once at the end of the function could save a lot of time, especially if the loops run a lot. If the function has many many loops with lots of local variables within each of them, then it would save memory to allocate them on the stack during their independent executions, and that benefit would surely come at the cost of time. In general, any program that uses the stack to allocate variables could instead use static allocation for all values, and manipulate the memory directly in a more hard coded fashion. While using more memory (potentially unbounded if the growth of the stack can't be bounded), the program will run faster.

>>49
It's a tranny.

>>51
Just like the cudder.

>>32

I'd wed that.

Females do not program computers, they program kitchens and children.
[/thread]

>>40
Video games and anime is shit.

Wow yeah, since streams of characters are always parsed into streams of tokens, and never directly into immediately usable data.