Stephen Waits wrote:
> 
> However, my first problem is getting a compiler to emit PS3 code.  :)

Does GCC target Cell yet?


Sean

Sean Kelly wrote:
> 
> Does GCC target Cell yet?

Yah.  The official toolchain is based on gcc and there's one in the wild too, used on PS3 Linux.

--Steve

Stephen Waits wrote:
> [...]
> I agree with you.. portability is preferred here, considering the non-existent performance difference.
> 
> I'd even go as far as saying that using bit twiddling in this specific case is the "junior mistake".
> 
> Why?  Because it assumes that the compiler isn't already taking care of this for you.
> [...]

To highlight this point, I interviewed a candidate the other day that agonized over the best way to return a vector from a C++ function in an efficient manner.  He considered heap-allocating it and returning a pointer (apparently, he thinks 'new' is fast), passing an out reference, and a few other things.  And yet, he didn't once mention the fact that he was passing *in* two vectors *by value*.  When I asked him the most efficient way to pass in the input vectors, I asked if he should do it by value, by reference, or by pointer.  He said: "By pointer".  Oy vai!  Apparently, he wasn't familiar with [N]RVO, and was optimizing the wrong thing.  90% of any given program contributes only 10% to its overall performance, typically.  That's why C.A.R. Hoare warned against the dangers of premature optimization (and making sure you optimize the *right* thing).

Dave

David B. Held wrote:
> Stephen Waits wrote:
>> [...]
>> I agree with you.. portability is preferred here, considering the
>> non-existent performance difference.
>>
>> I'd even go as far as saying that using bit twiddling in this specific case is the "junior mistake".
>>
>> Why?  Because it assumes that the compiler isn't already taking care
>> of this for you.
>> [...]
> 
> To highlight this point, I interviewed a candidate the other day that
> agonized over the best way to return a vector from a C++ function in an
> efficient manner.  He considered heap-allocating it and returning a
> pointer (apparently, he thinks 'new' is fast), passing an out reference,
> and a few other things.  And yet, he didn't once mention the fact that
> he was passing *in* two vectors *by value*.  When I asked him the most
> efficient way to pass in the input vectors, I asked if he should do it
> by value, by reference, or by pointer.  He said: "By pointer".  Oy vai!
>  Apparently, he wasn't familiar with [N]RVO, and was optimizing the
> wrong thing.  90% of any given program contributes only 10% to its
> overall performance, typically.  That's why C.A.R. Hoare warned against
> the dangers of premature optimization (and making sure you optimize the
> *right* thing).
> 
> Dave

This is one thing I really lament about my uni education thus far.  Two topics that basically have *never* been covered in even minimal detail have been optimisation and debugging.

To be honest, I wouldn't know the most efficient way to return or pass out a vector because I've never had any kind of grounding in the effects of the various ways of doing it.  For instance: at what point does passing by reference become faster than by value?

Wish I knew :)

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> [...]
> This is one thing I really lament about my uni education thus far.  Two
> topics that basically have *never* been covered in even minimal detail
> have been optimisation and debugging.
> 
> To be honest, I wouldn't know the most efficient way to return or pass
> out a vector because I've never had any kind of grounding in the effects
> of the various ways of doing it.  For instance: at what point does
> passing by reference become faster than by value?

This is where it really helps to have some understanding of what a compiler actually does.  The "Java Syndrome" helps students treat the compiler like a magical black box where text goes in and executables come out.  While this is useful for cranking out thousands of entry-level programmers that assiduously follow design specs, it's not very good for creating engineers who are also artists.

If you want to understand pass-by-value vs. pass-by-reference, it helps to understand how C works, and then how assembly works.  Only when you get an idea for the actual instructions involved and how much time they take, relatively speaking, does it become practical to estimate these things.  You can never be 100% sure what code a compiler is going to generate without looking at the output, but after you learn a few languages, you can make pretty good guesses.

For function call performance, you need to understand registers, memory, stacks, call frames, and calling conventions.  You also need to understand that references are just pointers that get automagically dereferenced on use.  Once you put these things together, it starts to become fairly clear when one is preferred over the other (though there is definitely a gray area where it depends on the actual code generation and hardware characteristics).

If you really want to be a good programmer, you need to take your education into your own hands.  I would venture to claim that the majority of experts in the world learned most of what they know from self-study, and not from classroom lectures and textbooks.  You are particularly lucky to be alive at this point in time because you have ridiculously more free information available to you than I did when I was growing up.  I would have killed to have as much of the internet to access as you do.

If you are really serious about your education, you will soon find your classes boring, because most of your learning will be self-directed. But you have to be fairly motivated to engage in that kind of learning, and everyone has different personalities.  In the end, a diploma only proves that you will jump through hoops for The Man (which is important for getting a job in the corporate world, where docility is rewarded and innovation is discouraged).

Dave

David B. Held wrote:
> Daniel Keep wrote:
>> [...]
>> This is one thing I really lament about my uni education thus far.  Two
>> topics that basically have *never* been covered in even minimal detail
>> have been optimisation and debugging.

I took a university course on software testing a while back and found it to be fairly useful.  It opened with proofs of correctness and went from there.  Not directly related to debugging, but close enough to bear mentioning.

> If you really want to be a good programmer, you need to take your education into your own hands.  I would venture to claim that the majority of experts in the world learned most of what they know from self-study, and not from classroom lectures and textbooks.

Definitely.

> If you are really serious about your education, you will soon find your classes boring, because most of your learning will be self-directed. But you have to be fairly motivated to engage in that kind of learning, and everyone has different personalities.  In the end, a diploma only proves that you will jump through hoops for The Man (which is important for getting a job in the corporate world, where docility is rewarded and innovation is discouraged).

True enough, but a lot of importance is placed on degrees nevertheless.    My advice would be not to go to college until you're ready to take it seriously, because there's no point in paying for a service you're not going to use.  But don't look to formal education as the beginning and end of the learning process.  In the professional sector, credentials might get you an interview but they won't get you a job.


Sean

David B. Held wrote:
> Daniel Keep wrote:
>> [...]
>> This is one thing I really lament about my uni education thus far.  Two
>> topics that basically have *never* been covered in even minimal detail
>> have been optimisation and debugging.
>>
>> To be honest, I wouldn't know the most efficient way to return or pass out a vector because I've never had any kind of grounding in the effects of the various ways of doing it.  For instance: at what point does passing by reference become faster than by value?
> 
> This is where it really helps to have some understanding of what a compiler actually does.  The "Java Syndrome" helps students treat the compiler like a magical black box where text goes in and executables come out.  While this is useful for cranking out thousands of entry-level programmers that assiduously follow design specs, it's not very good for creating engineers who are also artists.

Well, it's a good thing that I loathe Java, then ;)

> If you want to understand pass-by-value vs. pass-by-reference, it helps to understand how C works, and then how assembly works.  Only when you get an idea for the actual instructions involved and how much time they take, relatively speaking, does it become practical to estimate these things.  You can never be 100% sure what code a compiler is going to generate without looking at the output, but after you learn a few languages, you can make pretty good guesses.

I think I've got a fairly good understanding of *how* things work at the instruction level.  My current failing is, I believe, the part about understanding their relative speed under different circumstances.

The example I gave in my previous posting was in regards to my vector struct; I don't understand the relative speeds of copying the vectors onto the stack and dereferencing pointers to them to be able to comfortably make a decision on which to use.

> For function call performance, you need to understand registers, memory, stacks, call frames, and calling conventions.  You also need to understand that references are just pointers that get automagically dereferenced on use.  Once you put these things together, it starts to become fairly clear when one is preferred over the other (though there is definitely a gray area where it depends on the actual code generation and hardware characteristics).
> 
> If you really want to be a good programmer, you need to take your education into your own hands.  I would venture to claim that the majority of experts in the world learned most of what they know from self-study, and not from classroom lectures and textbooks.  You are particularly lucky to be alive at this point in time because you have ridiculously more free information available to you than I did when I was growing up.  I would have killed to have as much of the internet to access as you do.
> 
> If you are really serious about your education, you will soon find your classes boring, because most of your learning will be self-directed. But you have to be fairly motivated to engage in that kind of learning, and everyone has different personalities.  In the end, a diploma only proves that you will jump through hoops for The Man (which is important for getting a job in the corporate world, where docility is rewarded and innovation is discouraged).
> 
> Dave

Well, I basically taught myself to program from books and online tutorials.  Sadly, my first languages were all BASICs (GWBASIC, QBASIC and then Visual Basic 5 & 6), although I hope I've made up for that by taking an interest in a wider variety of languages.  My comp.sci. degree was boring until about the third year when it finally started to get interesting :)

That said, I don't think I'll ever really be able to learn enough... all I can do is continue to read and experiment, hopefully bettering myself in the process.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

David B. Held wrote:
> 
> compiler actually does.  The "Java Syndrome" helps students treat the 

Ahh, thanks for giving it a name.  I'll add that to our vocabulary here.

We've been seeing this get worse and worse in the past 5 years.  It's to the point now where entry-level candidates we interview, from some high-profile schools, cannot write a basic recursive function (factorial) or demonstrate any knowledge about pointers, memory, or anything to do with bits.

That's been my experience anyway.

Basically, seems like the students aren't learning much about the machine any more.  Were they ever?  Or were us "old-timers" (I'm 35, not quite an old timer, but whatever) just so excited about the whole thing that we all spent way too much time learning stuff on our own?  (I also quit college so I could learn more)

I fear for some of the guys coming through here, that some day they may find themselves inside a paper bag.

--Steve

Daniel Keep wrote:
> 
> To be honest, I wouldn't know the most efficient way to return or pass
> out a vector because I've never had any kind of grounding in the effects
> of the various ways of doing it.  For instance: at what point does
> passing by reference become faster than by value?

10 second lesson on optimization:

* Memory access is slow.  Both reading and writing.  It's generally been that way for a long time, and appears to be staying that way.

* Optimize what is slowest.

* Know what's slowest by profiling.

* The largest gains generally come from larger algorithmic changes.

--Steve

Stephen Waits Wrote:
> * Memory access is slow.  Both reading and writing.  It's generally been that way for a long time, and appears to be staying that way.
> 
> * Optimize what is slowest.

Optimize what consumes the most time when the user needs it most.  Having a slow idle process that consumes the cpu time doesn't imply you need to make the idle process more effiicient.  : )

> * Know what's slowest by profiling.

This involves more than invoking a program.  It involves some heuristics.

> * The largest gains generally come from larger algorithmic changes.

I find trivial things like aligning heavily used structs and using in/out/inout parameters in the right places make a big difference and don't even require significant thought.

~~~

To answer his question;

A reference is typically a void**, which essentially means a pair of 32-bit (on a 32 bit system) values stored somewhere.  Those values are used as indexes into the massive array that is your program's memory space (a.k.a: pointers).  If both pointers are already loaded into cache by virtue of being on the same memory page as previously executed data, then dereferencing can take as few as 4 cycles.  In the event of a cache miss, it can take several hundred.  Typically they're kept on the stack, so you almost always get towards the low end.

Passing by value tends to involve moving the data itself, either through registers or the stack (at 1 mov instruction each 32-bit dword).  If the data is less than 128-bits, it tends to be cheaper to pass by value than by reference; and with SSE2, that can be true with data up to 512-bits.

Additionally, once the data has been passed by value, you can manipulate it on the spot; using inout parameters for direct manipulation and in parameters when you only want to touch a copy of the data (copies are as cheap as the original, unlike when passed by reference)

I may have missed some things.  Regardless, those are my thoughts on it atm.

Sincerely,
Dan