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!

>>1
Compulsive semicolon much?

Female Programmers
No such thing exists.

>>1
Look at that revealing dress. What a filthy whore.

>>3
Wow, you take denial to a whole new level.

>>4
Look at those eyebrows. It's a man.

>>3
Here's a fun fact: At my university, 85% of computer science freshmen are male. 43% of computer science seniors are female. In other words, men drop/fail/switch majors away from CS WAY more frequently.

Whats even better is the average GPA of male senior CS students is 3.06 and female senior students is a staggering 3.45

>>6
I'm a chick and I have thicker eyebrows than that...

>>7
anyone who's any good at programming stays far away from CS.

>>8
prove it.

>>9
Thats crazy talk.

>>5
no

>>8
no

>>10
which part?

>>11
i loled

>>12
anyone who's any good at programming stays far away from CS.

>>14
it's true. all the good programmers choose real majors, like mathematics or physics.

>>1
Wtf. I started watching this because she's hot and I'm drunk. Go to 4:05. Check out the examples of optimization she gives:

- A preprocessor define being inlined
- Declaration of loop variables moved outside the loop

Wtf? These are not optimization at all! The preprocessor constant should be substituted BEFORE lexical analysis (according to the standard, though some compilers combine it with lexical analysis) which is long before optimization, 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.

In all honesty though it's really great to see an intelligent female programmer. As a career programmer, the Steve rule is incredibly depressing to me.

she's hot and I'm drunk.
Moar liek "he's hot because I'm drunk." amirite?

>>16
Just do add on to this:

She says intepreted languages skip the optimization step (at least at compile time). This is wrong. Interpreted languages do optimize the code quite a lot at compile time (especially for embedded VMs). For example, with J2ME and Android, the compiler will do a lot of static analysis (called the pre-verification step) to remove stuff like bounds checks where it's unnecessary from the compiled bytecode. Compilation for BlackBerry in particular can actually be quite slow for these reasons.

There is this recurring assumption that interpreters run slower just because they have to do more runtime work. This is not necessarily true. Some JIT VMs can actually end up with faster code in a lot of scenarios because they can exhibit much better cache locality. They profile the code to figure out what functions are hotspots, compile them, then mash them together into one cache line so the thing runs super fast. Most compilers are extremely dumb in this respect; profile-guided optimization isn't that good, and some compiled languages bloat the outputted code heavily having devastating effects on cache performance (I'm looking at you, C++). Compiled languages can't re-organize the machine code at runtime.

Also, the platform independence of interpreted languages is kind of a joke at this point. Java VMs are starting to get their own bytecode formats for crying out loud, so J2SE != MIDP != BlackBerry != Android. Even for the desktop stuff, the rule is now write once, test everywhere.

>>1

Yay, middle school level programming!

just to give you bitches a hand, if you want to contact someone who is female and really makes C/C++ compilers for a living, I recommend you contact Julienne Walker, here is her website which has a lot of good articles: http://www.eternallyconfuzzled.com/jsw_home.aspx
she is also a forum moderator at cprogramming.com and daniweb.com

>>18
How the heck do JIT vms figure in a discussion on interpreters? Are we conflating bytecode interpreters and regular ones because, fuck, I don't know?

>>19
Middle school? Yeah right. 3503 System Software. Thats upper division undergraduate level.

Thats upper division undergraduate level.
maybe in some shitty third-world country.

>>20
is she hot?

>>24
yes she is, blond, looks like someone who would work in a bank or something

>>25
pics please

>>26
she took it off her website and I cant find it on web search

>>27
google cache?

>>28
all I know about her is:
shes 31 has a kid, not married, lives in Atlanta, likes rock climbing and goes to a rock climbing place called "Atlanta Rocks" and she posts under the name "Prelude" at cprogramming.com

bitches and hoes

makes C/C++ compilers for a living
jsw_home.aspx
Nice try.

>>28
http://web.archive.org/web/20060207060354/www.eternallyconfuzzled.com/about.html

yes she is, blond, looks like someone who would work in a bank or something
No. She is uglier than a red headed anus.

>>32
You are wrong, she is definitely more attractive than Patrick Collision.

>>29
Apparently she left when she couldn't change her avatar.^[1]

1: http://cboard.cprogramming.com/brief-history-cprogramming-com/56162-so-what-ever-really-happened-prelude.html

[code]Dislikes: humidity, speeding tickets, the emo look, C Shell[\code]

Oh god.

Sorry for my BBCode failure.

Dislikes: humidity, speeding tickets, the emo look, C Shell

>>16
References to stack space
...Which are then destroyed when they go out of scope at the end of a loop execution and then recreated when the loop begins again. For every iteration. IHBT

>>37
Loop variables are kept because the compiler knows it's a loop and it knows exactly what you described would happen if they weren't.

>>38
in loop:
unsigned long long:    Took 239016ms to do 46116860184 loops.
unsigned int:        Took 205063ms to do 46116860184 loops.
unsigned short:        Took 222547ms to do 46116860184 loops.
unsigned char:        Took 206047ms to do 46116860184 loops.
signed long long:    Took 238610ms to do 46116860184 loops.
signed int:        Took 205485ms to do 46116860184 loops.
signed short:        Took 221063ms to do 46116860184 loops.
signed char:        Took 205891ms to do 46116860184 loops.

out of loop:
unsigned long long:    Took 239094ms to do 46116860184 loops.
unsigned int:        Took 171109ms to do 46116860184 loops.
unsigned short:        Took 223219ms to do 46116860184 loops.
unsigned char:        Took 171547ms to do 46116860184 loops.
signed long long:    Took 238985ms to do 46116860184 loops.
signed int:        Took 171406ms to do 46116860184 loops.
signed short:        Took 222610ms to do 46116860184 loops.
signed char:        Took 171406ms to do 46116860184 loops.

/*
    const unsigned long long loopiters = 46116860184;
    clock_t b = clock();
    signed char blah2;
    for (unsigned long long c = 0; c <= loopiters; c++) {
        blah2 = 0;
    }
    cout << "Took " << clock() - b << "ms to do " << loopiters << " loops." << endl;
*/

And that's with primitives, chum.

>>32
I love to play video games, watch anime

I'M IN LOVE

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.