Efficiency/Optimization
Author
as a new programmer i'm having trouble grasping some aspects of the bigger picture. from what i've read, the most 'efficient' method of manipulation would be ASM. (that is a goal of mine, but for now am focusing on C++...) i've read that OOP is convenient, but clumsy compared to procedural coding, ie is easier to follow, and saves typing time, but when it comes to memory management, and CPU load consideration, isn't quite as good. any insights??
[Edited by - auric on January 31, 2007 4:25:04 PM]
Quote:Original post by auricI think you're worrying about the wrong things. I think you also may be reading the wrong things :-)
as a new programmer i'm having trouble grasping some aspects of the bigger picture. from what i've read, the most 'efficient' method of manipulation would be ASM. (that is a goal of mine, but for now am focusing on C++...) i've read that OOP is convenient, but clumsy compared to procedural coding, ie is easier to follow, and saves typing time, but when it comes to memory management, and CPU load consideration, isn't quite as good. any insights??
Perhaps you could tell us exactly what you want to do. Game programming? Systems programming? What's the target platform? PC? Console? If it's games you're interested in, what types/genres? Casual games? 2D arcade games? 3D games?
Once we know the answers to these questions, we'll probably be able to give you advice that's more meaningful and/or useful.
Author
my goal is adeptness neccessary for scientific simulation, R&D tools. as i'm devoloping i'd like to see myself following this curve: 2D sprite shooter with tweakable handling and level editor, then a 3d game engine, and maybe music creation software (focus on digital synthesis of really awesome and scary sounds, possibly a sequencer). i guess i might be alitte overconcerned with good coding practices and efficient methods.
[Edited by - auric on January 31, 2007 4:17:44 PM]
[Edited by - auric on January 31, 2007 4:17:44 PM]
Quote:Original post by auric
stitching one on this for sure...
i'm looking to gain the prowess neccessary for scientific simulation, R&D tools. as i'm devoloping i see myself following this curve: 2D sprite shooter with tweakable handling and level editor, then a 3d game engine, and maybe music creation software (focus on digital synthesis of really awesome and scary sounds, possibly a sequencer). pretty easy to follow why i'm might be alitte overconcerned with good coding practices and efficient methods. i guess a feel really nice being able to ask a question and get an experienced response, just a little nicer than racking brains over tutorials 100 percent of the time.
Good programming practices and efficiency have very little to do with each other. I mean "good programming practices" in the sense of maintainable, flexible code. You can make highly readable code that is poorly optimized, and you can make lean, fast code that is unreadable.
Is this what you meant by "good practices", or could you clarify for me?
Author
quote: templewulf
"Good programming practices and efficiency have very little to do with each other. I mean "good programming practices" in the sense of maintainable, flexible code."
Are you saying that generally... flexible code is a bit 'fat around the edges'? from what i've read, OOP is really good for the ability to replace small sections of code without effecting the entire program. I guess what I'm asking for is opinions of whether or not this model of coding (or any other)inevitably effects the programs ability to manage system resources in the most efficient way. (i.e. i'm trying, as early as possible, to solidify my development criterion when deciding how exactly i want to flick those damn electrons around)
[Edited by - auric on January 31, 2007 4:09:05 PM]
"Good programming practices and efficiency have very little to do with each other. I mean "good programming practices" in the sense of maintainable, flexible code."
Are you saying that generally... flexible code is a bit 'fat around the edges'? from what i've read, OOP is really good for the ability to replace small sections of code without effecting the entire program. I guess what I'm asking for is opinions of whether or not this model of coding (or any other)inevitably effects the programs ability to manage system resources in the most efficient way. (i.e. i'm trying, as early as possible, to solidify my development criterion when deciding how exactly i want to flick those damn electrons around)
[Edited by - auric on January 31, 2007 4:09:05 PM]
Unless you have a very good reason to do otherwise, you should put 100% of your concentration on good coding practice, wherever it doesn't clash with macro-performance. You should aim to optimise your algorithm, as it appears in pseudocode, but not the implementation, as it appears in C++.
We programmers have a strange relationship with 'optimisation'. There's no way to learn it but through experience, but you can save yourself a lot of effort by just doing things according to what you're told (and will have to accept) is 'the right way'. At every level, it is tempting to over-optimise, and it's never good. The problem is that most programmers don't tend to grok just what needs optimising, and often end up optimising the wrong bits. The rule of thumb, I guess, is 'if it costs you readability, don't optimise'. Years down the line you'll realise when you can get away with cutting a corner or two, but that's only once you've understood that the bits that looks like they want optimising aren't really the bits that need it.
Admiral
We programmers have a strange relationship with 'optimisation'. There's no way to learn it but through experience, but you can save yourself a lot of effort by just doing things according to what you're told (and will have to accept) is 'the right way'. At every level, it is tempting to over-optimise, and it's never good. The problem is that most programmers don't tend to grok just what needs optimising, and often end up optimising the wrong bits. The rule of thumb, I guess, is 'if it costs you readability, don't optimise'. Years down the line you'll realise when you can get away with cutting a corner or two, but that's only once you've understood that the bits that looks like they want optimising aren't really the bits that need it.
Admiral
As a beginner, you should be concerned with programming concepts, data structures, good coding practices, and how to use the tools. You should not worry about efficiency and optimization other than when choosing algorithms.
OOP is the most appropriate technique for most of the programming you will do, therefore that should be you main focus, regardless of any tradeoffs you may have read about.
OOP is the most appropriate technique for most of the programming you will do, therefore that should be you main focus, regardless of any tradeoffs you may have read about.
If you are worrying about optimization then you probably aren't capable of it.
This may seem strange but well-written code tends to perform better than poorly written code. This is because if you understand what you are trying to make and the tools that you are using you will be naturally inclined to choose algorithms that are less complex in the big-O sense.
This may seem strange but well-written code tends to perform better than poorly written code. This is because if you understand what you are trying to make and the tools that you are using you will be naturally inclined to choose algorithms that are less complex in the big-O sense.
Quote: by auric
from what i've read, the most 'efficient' method of manipulation would be ASM. (that is a goal of mine, but for now am focusing on C++...)
Assembler isn't necessarely more efficient; if you don't know what your doing you may make the performance worse and besides, a good c++ compiler will take into consideration the target processor and produce very optimised code. You can make the compiler produce assembler output listings which you can learn from.
Quote: by auric
i've read that OOP is convenient, but clumsy compared to procedural coding, ie is easier to follow, and saves typing time, but when it comes to memory management, and CPU load consideration, isn't quite as good. any insights??
Actually you can make quite efficient resource managers using OOP. I think the CPU load between procedural programs and OOP programs would be very small.
There is fundemental tension between code reuse and performance.
For example reusable code may do things which you know you don't need in a specific scenerio.
HOWEVER - code reuse is super-duper-mega important. It mostly reduces development time (easier to write debug and maintain) which is what you should be most concerned about.
In general there is no problem if a function takes 0.1ms or 4ms if you call it just once in a while. Even if you write performance critical code you still need to optimize just the code path that is activated 99% of the time which is usually less than 10% of the code. The rest of the code is rarely activated and there is no problem with it being "slow". What you do is write everything without considering optimizations too much and then if there is timing problem you run a profiler to see what is the code that takes the most time, and then optimize just that code.
Note: writing slow code is usually wrong data structures or wrong algorithm, read about those subjects first.
Unless you really must squize every bit of performance I suggest you stay away from assembly. You can write very efficient code in C++ if you know what you are doing, and the result will be much easier to reuse and develop.
What I suggest is you learn C++ and learn it good enough to know what happens "under the hood" so you'd know how to write effecient code in it.
There are things which are easy optimizations:
- fix: unnessecary temp vars, pass-by-value, unnessacary construction
- use templates instead of inheritence for code reuse + efficiency.
- use memory pooling
- more...
Iftah
For example reusable code may do things which you know you don't need in a specific scenerio.
HOWEVER - code reuse is super-duper-mega important. It mostly reduces development time (easier to write debug and maintain) which is what you should be most concerned about.
In general there is no problem if a function takes 0.1ms or 4ms if you call it just once in a while. Even if you write performance critical code you still need to optimize just the code path that is activated 99% of the time which is usually less than 10% of the code. The rest of the code is rarely activated and there is no problem with it being "slow". What you do is write everything without considering optimizations too much and then if there is timing problem you run a profiler to see what is the code that takes the most time, and then optimize just that code.
Note: writing slow code is usually wrong data structures or wrong algorithm, read about those subjects first.
Unless you really must squize every bit of performance I suggest you stay away from assembly. You can write very efficient code in C++ if you know what you are doing, and the result will be much easier to reuse and develop.
What I suggest is you learn C++ and learn it good enough to know what happens "under the hood" so you'd know how to write effecient code in it.
There are things which are easy optimizations:
- fix: unnessecary temp vars, pass-by-value, unnessacary construction
- use templates instead of inheritence for code reuse + efficiency.
- use memory pooling
- more...
Iftah
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
