Comments on: Think low level, write high level [...] Think low level, write high level by Chris Kosanovich [...] [...] Think low level, write high level by Chris Kosanovich [...]

]]>
By: James Podesta/2011/01/18/think-low-level-write-high-level/#comment-689 James Podesta Mon, 24 Jan 2011 02:05:28 +0000 ./altdevblogaday.org/2011/01/18/think-low-level-write-high-level/#comment-689 Hey there Glenn. How goes it?<o:p></o:p> Yeah, I think it’s safe to never assume you know exactly what a compiler is going to do... and what it can and can’t optimise... <o:p></o:p> Although if your focussed on one specific platform, it’s not so bad.  I remember working with the lead emulation programmer (Manu) on Microsoft’s Game Room trying to track down LoadStore issues and you could pretty much do it from restructuring the C code because all the optimising was doing exactly what you expected it to...  ie. If it was loading a variable from memory where you thought it didn’t need to,  sure enough their might be a “continue” in your loop so the compiler couldn’t make an assumption of what the variable held...   Mind you, we really had to look at the assembly for the hits,  and then look back into the C code to see what might be causing it.<o:p></o:p> From: Posterous [mailto:comment-fhBulHkzcsgycto=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Monday, 24 January 2011 11:50 AM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Think low level, write high level"<o:p></o:p> Hey there Glenn. How goes it?<o:p></o:p> Yeah, I think it’s safe to never assume you know exactly what a compiler is going to do… and what it can and can’t optimise… <o:p></o:p> Although if your focussed on one specific platform, it’s not so bad.  I remember working with the lead emulation programmer (Manu) on Microsoft’s Game Room trying to track down LoadStore issues and you could pretty much do it from restructuring the C code because all the optimising was doing exactly what you expected it to…  ie. If it was loading a variable from memory where you thought it didn’t need to,  sure enough their might be a “continue” in your loop so the compiler couldn’t make an assumption of what the variable held…   Mind you, we really had to look at the assembly for the hits,  and then look back into the C code to see what might be causing it.<o:p></o:p> From: Posterous [mailto:comment-fhBulHkzcsgycto=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Monday, 24 January 2011 11:50 AM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Think low level, write high level"<o:p></o:p>

]]>
By: Glenn Watson/2011/01/18/think-low-level-write-high-level/#comment-688 Glenn Watson Mon, 24 Jan 2011 01:50:23 +0000 This reminds me of an interview I had, where the interviewer worried about excessive memory transfers causing memory modules to overheat and fault, while at the same time basing their entire product on PostgreSQL, which wastes performance everywhere.In other words, I think optimizing is a top-down affair that is totally context dependent. Don't try to shave 40% of 1% when at the top level you could shave 10% of 100%. This reminds me of an interview I had, where the interviewer worried about excessive memory transfers causing memory modules to overheat and fault, while at the same time basing their entire product on PostgreSQL, which wastes performance everywhere.In other words, I think optimizing is a top-down affair that is totally context dependent. Don’t try to shave 40% of 1% when at the top level you could shave 10% of 100%.

]]>
By: Chester Hsieh/2011/01/18/think-low-level-write-high-level/#comment-686 Chester Hsieh Wed, 19 Jan 2011 18:42:16 +0000 I don't think the OP ever referred to only writing strictly low level code. I think his point is that it's fine to write in "any level," as long as you are consciously and knowingly making that choice given your circumstances. Just like how (most likely) it's pointless to write low level code for a simple 2D game on current PC hardware, it's also backwards to use interpreted JavaScript (pertaining to your "the higher level the better") in an every-cycle-counts AAA 3D console game's ocean simulation. While I can't speak for that lead programmer as to what his concerns are, but I can guess that for such a constrained device like the Nintendo DS with only 4MB of RAM and two slow processors, every bit counts. If one allocates a "uint8_t" for every trinary state they have (it's definitely easier to read "foo_state" than "(aggregate_bits & FOO_STATE) >> FOO_SHIFT"), that programmer will soon run out of memory if that kind of state exists many times for large arrays of "objects." As for the argument about not knowing your platforms for commercial projects, is that really the case? I mean, if you write a fully-featured game for the PC, do you really expect that code to run on a low-end Android device? When was the last time in the past 5 years that you had to consider running your modern commercial code on a 80286 machine? Bottom line is, there's no single rule of thumb other than: the more questions you ask, the more you know; and the more you know, the better choices you can make. This is my takeaway from the OP. I don't think the OP ever referred to only writing strictly low level code. I think his point is that it's fine to write in "any level," as long as you are consciously and knowingly making that choice given your circumstances. Just like how (most likely) it's pointless to write low level code for a simple 2D game on current PC hardware, it's also backwards to use interpreted JavaScript (pertaining to your "the higher level the better") in an every-cycle-counts AAA 3D console game's ocean simulation. While I can't speak for that lead programmer as to what his concerns are, but I can guess that for such a constrained device like the Nintendo DS with only 4MB of RAM and two slow processors, every bit counts. If one allocates a "uint8_t" for every trinary state they have (it's definitely easier to read "foo_state" than "(aggregate_bits & FOO_STATE) >> FOO_SHIFT"), that programmer will soon run out of memory if that kind of state exists many times for large arrays of "objects." As for the argument about not knowing your platforms for commercial projects, is that really the case? I mean, if you write a fully-featured game for the PC, do you really expect that code to run on a low-end Android device? When was the last time in the past 5 years that you had to consider running your modern commercial code on a 80286 machine? Bottom line is, there's no single rule of thumb other than: the more questions you ask, the more you know; and the more you know, the better choices you can make. This is my takeaway from the OP.

]]>
By: Rex Guo/2011/01/18/think-low-level-write-high-level/#comment-684 Rex Guo Wed, 19 Jan 2011 15:33:33 +0000 I was interviewing for a programming job at a video game company. It was a project for the Nintendo DS. The lead programmer asked me if I preferred high level or low level programming. I sayed "high level" because it makes the code look so much better. Now I didn't get the job because of that. He throught that I didn't know well enough low level and feared that his game would not be as optimised as a consequence. > You will never be targeting some unknown number of platforms so we need to drop that mind set. Usually, for non commercial projects, when you start coding, you don't know yet the whole lifecycle of the application and the platforms it will run on.tldr: You are wrong, the more high level, the better. I was interviewing for a programming job at a video game company. It was a project for the Nintendo DS. The lead programmer asked me if I preferred high level or low level programming. I sayed “high level” because it makes the code look so much better. Now I didn’t get the job because of that. He throught that I didn’t know well enough low level and feared that his game would not be as optimised as a consequence. > You will never be targeting some unknown number of platforms so we need to drop that mind set. Usually, for non commercial projects, when you start coding, you don’t know yet the whole lifecycle of the application and the platforms it will run on.tldr: You are wrong, the more high level, the better.

]]>
By: James Podesta/2011/01/18/think-low-level-write-high-level/#comment-682 James Podesta Wed, 19 Jan 2011 14:11:36 +0000 This is one of my pet hates. Why use more force than necessary? Use the least expensive operator you can. Greedy local optimizations like this add up in the long run!@Arseny: x % 2 yields bad code especially when x is signed, since then the result could be (-1,0,1). Some compilers may be smart enough to determine when the result is used to compare for equality with zero but in practice I've seen plenty of compilers generate division instructions in these cases as well. So might as well use x & 1! This is one of my pet hates. Why use more force than necessary? Use the least expensive operator you can. Greedy local optimizations like this add up in the long run!@Arseny: x % 2 yields bad code especially when x is signed, since then the result could be (-1,0,1). Some compilers may be smart enough to determine when the result is used to compare for equality with zero but in practice I’ve seen plenty of compilers generate division instructions in these cases as well. So might as well use x & 1!

]]>
By: Fabrice Lété/2011/01/18/think-low-level-write-high-level/#comment-680 Fabrice Lété Wed, 19 Jan 2011 13:19:01 +0000 Cycles are even more important. It's mostly known that 80% percent of time is spent in 20 % of the code ( or 90-10 ).It doesn't mean you don't have to care about the next 20%. It still impacts the overall performance. Writing correct and "performant" code at first is a win. Cycles are even more important. It's mostly known that 80% percent of time is spent in 20 % of the code ( or 90-10 ).It doesn't mean you don't have to care about the next 20%. It still impacts the overall performance. Writing correct and "performant" code at first is a win.

]]>
By: Julien Hamaide/2011/01/18/think-low-level-write-high-level/#comment-678 Julien Hamaide Wed, 19 Jan 2011 12:50:04 +0000 Can I ask what could sound like a dumb question?Disclaimer : I'm a tech artist and self taught coder so I'm sorry if this sounds stupid.How dumb is it to do something like this[code]bool IsEven(int num){ return (num % 2 == 0);}if(IsEven(42)) Blah();[/code]am I foolish in thinking that putting that test into it's own function is good way to do later optimization? Assuming of course that you are going to be checking evens and odds a lot. Or does the overhead of calling the function just outweigh the benifit? Can I ask what could sound like a dumb question?Disclaimer : I’m a tech artist and self taught coder so I’m sorry if this sounds stupid.How dumb is it to do something like this[code]bool IsEven(int num){ return (num % 2 == 0);}if(IsEven(42)) Blah();[/code]am I foolish in thinking that putting that test into it’s own function is good way to do later optimization? Assuming of course that you are going to be checking evens and odds a lot. Or does the overhead of calling the function just outweigh the benifit?

]]>
By: Brett Douville/2011/01/18/think-low-level-write-high-level/#comment-676 Brett Douville Wed, 19 Jan 2011 11:27:10 +0000 If automatic tests are run against that code across different target platforms then you are alerted immediately if a bug exists in one architecture versus the other.  The test would also documents what the method is expected to do, further aiding diagnosis for anyone, not just the original developer.  Then a developer has the choice of making the code more generic for both, or forking off a version for the new target platform.   So as long as you have tests that have got your back, I do not see any problem using the optimal solution especially if there are no plans to port to that architecture that would cause problems.  You may as well make the code as good as you can for what you need it for *now* rather than things that may never be asked of it.   If a coder does not understand the optimal solution, then it is a perfect excuse for an interesting conversation anyway and for spreading that kind of expertise.    If automatic tests are run against that code across different target platforms then you are alerted immediately if a bug exists in one architecture versus the other.  The test would also documents what the method is expected to do, further aiding diagnosis for anyone, not just the original developer.  Then a developer has the choice of making the code more generic for both, or forking off a version for the new target platform.   So as long as you have tests that have got your back, I do not see any problem using the optimal solution especially if there are no plans to port to that architecture that would cause problems.  You may as well make the code as good as you can for what you need it for *now* rather than things that may never be asked of it.   If a coder does not understand the optimal solution, then it is a perfect excuse for an interesting conversation anyway and for spreading that kind of expertise.   

]]>
By: mosaic_school/2011/01/18/think-low-level-write-high-level/#comment-674 mosaic_school Wed, 19 Jan 2011 10:07:38 +0000 If you are coding for big AAA console games, then I guess you are right about the importance of performance of small details. However, for anything smaller than that, I think that simplicity and understandability are way more important that this kind of detailed performance stuff. We never worry about these details at Ronimo and we do develop console downloadable games without big problems. When we need to optimise, we usually find enough large, structural improvements to reach 60fps without having to look into these instruction specific details. If you are coding for big AAA console games, then I guess you are right about the importance of performance of small details. However, for anything smaller than that, I think that simplicity and understandability are way more important that this kind of detailed performance stuff. We never worry about these details at Ronimo and we do develop console downloadable games without big problems. When we need to optimise, we usually find enough large, structural improvements to reach 60fps without having to look into these instruction specific details.

]]>
By: Arseny Kapoulkine/2011/01/18/think-low-level-write-high-level/#comment-672 Arseny Kapoulkine Wed, 19 Jan 2011 06:24:34 +0000