does integral literals affect efficiency?

The compiler has to convert it to a binary literal at compile time, no matter what format you use.

My god, you're prematurely optimizing so horribly that you're attempting to optimize something that's not even an optimization!!!

I suggest worring nothing about optimizations until you have the program working first - and then, and only then, if it runs too slow (just because it's mobile dosn't mean it's going to run too slow) do you ever worry about small efficiency gains from micro-optimizations, especially if they're going to be at the expense of mantainability.

edited for clarification. Choosing between an O(x^2) and an O(1) algorithm for, say, sorting, is something I'd consider more of a design decision - something I would easily choose rather than worry incessently about.

[Edited by - MaulingMonkey on January 16, 2005 12:55:22 PM]

Quote:

Original post by MaulingMonkey My god, you're prematurely optimizing so horribly that you're attempting to optimize something that's not even an optimization!!! I suggest worring nothing about optimizations until you have the program working first - and then, and only then, if it runs too slow (just because it's mobile dosn't mean it's going to run too slow) do you ever worry about efficiency.

dont presume im prematurely optimizing. im only asking so maybe i could optimize my application well. and one thing, i have completed what im suppose to make and everything works already. i think im ready to optimize now in hoping that i could make it run much better. you say things like i dont know about optimizations. i may not know everything, but i do know how to optimize things in certain aspects.

"prematurely optimizing", dont ever say that to me because i dont.

Oh god, I could get upset each and every time I hear the words "premature optimization [is the root of all evil]". Let me rephrase that: "the lack of optimization is the root of today's inefficient and horribly bloated software".

Anyway, davenirline, it is a very good idea to get a general overview over performance aware programming practices. But you should understand the difference between compile time and run time operations. Only the latter ones are relevant to the performance of your program. And numeric literal conversion is done at compile time, so there won't be any difference at all, the result will always be the same for either representation.

Quote:

Original post by Yann L Oh god, I could get upset each and every time I hear the words "premature optimization [is the root of all evil]". Let me rephrase that: "the lack of optimization is the root of today's inefficient and horribly bloated software".

my sig:

OP: It is not the format in which you write the data in the code that is important. It will be transformed into the same binary representation in the end by the compiler.

What is important is the type of literal constants you use.

For instance, if I remember correctly, RISC PocketPC processors have a nifty optimization that allows you to build constants directly in the processor instead of having to go fetch them in a table. If a given constant can be generated by applying a barrel shift to an 8-bit variable, then it will be generated in one operation, as opposed to a fetch from memory.

Yann L: there's an area between optimizing too much and not optimizing enough (or at all). That no optimization is bad does not affect the fact that premature optimization is bad as well, because it can result in waste of time that would have been better spent on more important optimizations or on getting out a program that is reasonably fast and bug-free. With deadlines, the key is to optimize what needs to be optimized most, and while some are able to "smell" where a bottleneck is, profiling is the only general bit of a solution to the problem.

Actually, there's 2 things that make programs be more bloated and work slower:
1:Premature optimization. It usually doesn't make code run any faster. If somebody would be replacing literals, it would be very good example.

Numbers in program are converted to binary form at compile time if he are using compiler. With compiler, no matter how you write your constants, resulting executable code is *exactly* the same. That is, compile your program, replace 15 by 0xf and compile again. Then check for differences between executables. There shouldn't be any.

If he are coding in &#106avascript or other interpreted language, so things is processed at runtime, smaller code will be interpreted better by half-assed interpreters. For that, there is code optimizers/obfuscators, that remove all comments and rename everything so code size is decreased. Such things can be used in place of compiler, to generate somewhat compressed code that will be executed. Them will convert constants to hex if it is faster.<br/><br/>2:Premature "we don't optimize because we are mature, compilers are uber-super-duper-smart these days" - same result(bloat and slowdown), and it also does not increase coding efficiency. (because of more bloat). They tend to use wrong tools for the job if it could make program run slower . Zealots of 2 are common on teh web, they never reply anything in threads like this one, they reply only to threads where somebody makes some useful optimization.<br/><br/><!--EDIT--><span class="editedby"><!--/EDIT-->[Edited by - Dmytry on January 15, 2005 8:20:06 AM]<!--EDIT--></span><!--/EDIT-->

Quote:

Original post by ToohrVyk Yann L: there's an area between optimizing too much and not optimizing enough (or at all). That no optimization is bad does not affect the fact that premature optimization is bad as well, because it can result in waste of time that would have been better spent on more important optimizations or on getting out a program that is reasonably fast and bug-free. With deadlines, the key is to optimize what needs to be optimized most, and while some are able to "smell" where a bottleneck is, profiling is the only general bit of a solution to the problem.

I have to disagree. While a profiler is a very important (read: invaluable) tool in performance tuning your code, there is another type of profiler that gets often neglected nowadays: the human brain. I've often come across this situation while working with third party production code: it is slow, but there is no real bottleneck. There are literally thousands of small bottlenecks throughout the entire code, that sum up. This is often the case with modern code, especially application code (like GUIs). It isn't something that makes the software unusable, it just makes it sluggy. The "90% of the execution time is spend in 5% of the code" is an ideal, and it doesn't always apply. Often, there is no single bottleneck you can magically fix. Often, fundamentally wrong design decisions (from a performance point of view) are burried so deeply within the very structure of the code, that the only solution is an entire rewrite.

Unfortunately, C++, C# and Java all make it very easy to write good looking, very elegant, and horribly inefficient code. A copy ctor that triggers an exponential copy ctor cascade within the class members, things like object[a], where object is a linked list, postincrement operators on non-trivial types that suck out CPU cycles in thousands of for() loops throughout the entire code, etc.

Yes, micro-optimization can be bad (but isn't necessarily). Going ASM isn't the ultimate solution to all performance problems either (but it can sometimes be). The profiler comes in handy for such decisions. But the profiler isn't some magical tool, that will make up for bad coding and bad design. More often than not, this dreaded saying about premature optimization is used as an excuse for lazyness. And even the ones trying to learn performance aware coding practices will quickly drop them, after being screamed on by everyone around, how what they're doing is the root of all evil.

So in conclusion: premature optimization is not the root of all evil. Bad premature optimization is - when optimization gets in the way of code maintenability, stability and requires the investment of more time than it is worth. But keeping optimization in mind from the beginning on will guarantee slick and fast code, and i think we agree that this is a good thing, don't you think ?

Edit: oh yes, sorry for going offtopic here, but I think the OPs question has been answered.

Are you sure he are using compiler? Maybe his code is interpreted? In this case, you might need to get some tool that makes code be smaller by removing all comments, unnecessary spaces, renaming variables, and possibly converting everything, and make special "optimized" version...

Quote:

Original post by Dmytry Are you sure he are using compiler? Maybe his code is interpreted?

Hmm, true, he didn't mention the language. But even on interpreted code, the base of a constant numeric value shouldn't make a noticeable difference in speed (well, unless it's binary, and the parser has to read a mile-long stream of 0's and 1's ;)

Quote:

Oh god, I could get upset each and every time I hear the words "premature optimization [is the root of all evil]". Let me rephrase that: "the lack of optimization is the root of today's inefficient and horribly bloated software".

Amen. The theory itself isn't so much what gets to me, it's that what some people seem to consider an optimisation, I consider to be simply thinking about good design. I've seen people try and use this quote to justify not thinking about any performance related questions during the design phase. It's much easier to consider performance when doing the initial design, than it is to come back and rework the whole thing later.

That said, this thread isn't an example of this.

Quote:

Original post by Yann L Oh god, I could get upset each and every time I hear the words "premature optimization [is the root of all evil]". Let me rephrase that: "the lack of optimization is the root of today's inefficient and horribly bloated software".

I have to disagree. There is no way that I have planetside, an FPS ranging in at 3.40GB, and the contents of my steam directory, measuring in at 3.52GB, be that size simply due to lack of optimization. Considering that FPSes can be made at sizes of 96kb (this infamous demo), I find it mind boggling that someone can create 3.399904 GB of code bloat (a 3,541,566% increase) just by not optimizing.

It's about features, and content. Features that are left on by default, features that are "integral" to the program wheither or not they're used. Sure, some of the bloat comes from not being anal over every assembly instruction of a program - but I find living in a world where MMOs and XML and Java exist much favorable to living in 1995 - wheither or not programs are somewhat bloated due to missed opportunities in optimization.

Let's take a quick look at my PlanetSide directory. Let's take a quick look at the size of all the EXE and DLL files in there (as well as that ocx file - ActiveX plugin), and total their size...

...

14.9MB. Well gosh darn, that's only what, 0.4% of the directory? Not a whole lot of room for optimization reducing sizes there, compared to the entire directory. I would rather have the programmers work on squashing some of the bugs at the expense of a few hundred megs, even, rather than be slower in their fixing of them by being "super-optimizing-genius"esque.

Lack of code reuse is one problem. For horribly crazy example, planetside and steam use almost no common components besides basic APIs such as OpenGL and DirectX, and the windows API for file i/o and socket connections. These are issues of trade secrets in this case - but I suspect a lot of cases in programming where you have similar situations could have their code size reduced by reusing components - and were most likely not for the sake of "optimization".

Quote:

Original post by davenirline Quote: Original post by MaulingMonkey My god, you're prematurely optimizing so horribly that you're attempting to optimize something that's not even an optimization!!! I suggest worring nothing about optimizations until you have the program working first - and then, and only then, if it runs too slow (just because it's mobile dosn't mean it's going to run too slow) do you ever worry about efficiency. dont presume im prematurely optimizing. im only asking so maybe i could optimize my application well. and one thing, i have completed what im suppose to make and everything works already. i think im ready to optimize now in hoping that i could make it run much better. you say things like i dont know about optimizations. i may not know everything, but i do know how to optimize things in certain aspects. "prematurely optimizing", dont ever say that to me because i dont.

Sorry, I just have to assume because 99.99% (okay, probably more like 95%) of the posters here, with posts like yours, are prematurely optimizing. I also didn't say you "dont know about optimizations". Don't put words in my mouth and I'll do my best to refrain from accusing you of premature optimization - well, once established that you're not, anyways.

It seems that most of the members of this forum are working on hobby projects to help them learn about game development and the surrounding issues. I know that's why I signed up, although my priorities are different now. I would start working on a project to learn about some specific thing (or things), and then when I felt I'd got the hang of it and had my eye on something else, I'd stop and go work on that other thing. I wonder how many of the projects that people here are working on ever get to the stage at which asking optimisation questions would meet widescale approval.

Yann - Hoare's statement is still quite legitimate. Part of the problem is that many people don't seem to understand what 'premature' means, much less 'premature optimization'.
As you put it, "performance-aware coding practices" are perfectly fine: they're idioms and algorithms you have learned and can use matter-of-factly; you know the pitfalls, so you just avoid them. It can, however, cause confusion in people who won't recognize the difference between, say, avoiding unnecessary data copying and with randomly restructuring a loop while the function it is in hasn't even been completely written.

We do see way too much blind groping for cycles from the part of people who do think that a linked-list is the one and only data structure. Or performance questions from people who do not provide context nor even bother to run their own tests...

Quote:

Original post by Fruny Yann - Hoare's statement is still quite legitimate. Part of the problem is that many people don't seem to understand what 'premature' means, much less 'premature optimization'. As you put it, "performance-aware coding practices" are perfectly fine: they're idioms and algorithms you have learned and can use matter-of-factly; you know the pitfalls, so you just avoid them. It can, however, cause confusion in people who won't recognize the difference between, say, avoiding unnecessary data copying and with randomly restructuring a loop while the function it is in hasn't even been completely written.

Couldn't have said it better. I've edited my post to clarify that I'm not bashing all attempts at speedier code in general, I'm bashing premature micro-optimizations. Choosing between an O(1) and O(x^2) algorithm is fine and quick - not something I'd be worrying about (the subtle keyword from my original post which I realize wasn't clear).

How can it be premature optimization to simply ask which is faster? Of course this particular question makes no difference whatsoever, but if it did (and which the OP assumed it did), then it'd be a valid question to ask. If writing numbers in hex was significantly faster, then making a habit of writing all numbers in hex might be a good idea. At least there'd be no harm in it. And when you don't *know* whether it makes a difference, then I'd say asking about it is about the best you can do. It's certainly much better than saying "This is a premature optimization, so I won't even think about it".

Of course premature optimization is bad. But trying to understand performance issues before and while coding is good, isn't it? I'd say so, but maybe I'm just prematurely optimizing... :P

To add extra information to the OP's original questions:

First, so that my post doesn't confuse anyone. The already stated answer is that (assuming a C/C++/Java like compiled langauge) the conversion of 15, 017, 0xF etc all happen at compile time, and yeild the exact same code to be inserted into the compiled program - so there is absolutely no possible runtime difference between them.

My addition, not only is there no possible runtime difference between them, but the compile time situation is not what you (the original poster) think it is. The source of your program is in ASCII encoding, and is parsed that way, using character-by-character parsing / matching algorithms. So no matter what you write, when you see the "decimal" number 15, the compiler sees the ascii characters '1' and '0', and in the other version is sees '0' '1' '7' and '0' 'x' 'F' respecively. In all (likely) cases it builds a token (effective a string) out of the recognized sequence of letters, and then passes them to an algorithm which converts them to their internal (int, short, float, whatever - int in this case) representation.

The internal representation is always effectively binary, but writing the number in a longhand binary ascii (something like 0b1111) would not necessarily be faster than the other formats (because it is more characters, taking longer to match and copy).

In theory the most efficient native string representation for converting to binary would be the hex one - because it has the highest base (so requires the least number of characters) and is a base which is a power of 2 (so therefore the conversion algorithm is extremely small), in fact the conversion algorithm from a string of base 2, 4, 8, 16, 32, or 64 would all be nearly identical in size and speed. Decimal is a slightly less efficient conversion algorithm, but not enough so that anyone ever writes in another base for efficiency (I have never heard of source code constants being stored in a different base for efficieny, even back in C in the 1970s - so I'm guessing they are so close it has never mattered). Another thing against the hex version is the 2 extra characters on the front '0x'.

In the real world, people write constants in the base which makes since for their domain or usage. ALL BIT PATTERNS should be written in hex. All normal numbers meant to be thought of as such by the programmer should be written in decimal. All numbers converted from other systems should be writen as they are in the other system (for example when writing the ASCII code, hex is more common than decimal, because it partitions the characters into groups 30-39 hex are 0-9, 41-5? hex are A-Z, 61-7? hex are a-z) (for another example, codes from old mainframe computers are often written in octal - which is the only time I've seen octal used).

well, it quite made a long thread when i came back. thanks for the arguments and answers. the way i understand it, premature optimization is thinking of sucking in efficiency from the start of the coding phase compromising any other aspect on the way (maintainability, readability). if this is what premature optimization means to you, then i don't think it's bad as long as it makes it run faster. but i don't do this though. i do it after coding phase.