|
|
|
This thread is locked; no one can reply to it.
|
| Dev-C++ Optimizations |
|
Damian Grove
Member #6,758
January 2006
|
I guess this would be the forum for this. It's not specifically a code-oriented question, but just programming more in general. I noticed something that really surprised me. I was playing around with Dev-C++'s optimizations and such because I've never used them before. My game is not running as fast as I'd like it, and I was curious to see if any of Dev-C++'s optimizations could give it a couple extra FPS at the least. Where it gives you a choice of processor-base instructions -- i386, i486, Pentium, Pentium MMX, etc... if I leave it blank, my game runs at about 56 fps. I figured maybe selecting Pentium III might give it a boost with the use of the SSE instructions... nope. Only one gave it a boost -- the i386! It boosted my game to 58 fps, which isn't a huge improvement but still nice to have anyhow. Now, am I crazy or does Dev-C++ (or is it MingW that does this?) optimize poorly? I mean I would have figured if I selected anything ABOVE an i386, it would at LEAST perform the same. I'm stunned that everything above it performs worse. BTW: Not that I plan on setting it to "Pentium 4", but I tried it out of my curiousity and it won't even build the program... I get several "suffix or operands invalid for 'movsd'" messages. I haven't even used any of my own assembly code in the game. Get into awesome with Saxman! |
|
Joel Pettersson
Member #4,187
January 2004
|
It is MinGW that does everything as far as compiling is concerned. When using CPU-specific tuning (the -mtune option; no idea how these things are handled in the Dev-C++ GUI), don't expect anything unless you are using a processor of the specific family you are optimizing for, and even then, the regular optimzation options are the most important, having the greatest impact. However, optimizing for i386 will often reduce code size somewhat, which can often result in small performance improvements unless something ends up significantly less effective on your CPU (how likely this is depends on the CPU in question) in the process. Optimizing for the actual CPU you use will probably still be better, though. Also note that there are two kinds of CPU-specific optimizations that can be specified independently; instruction sets (-march) and code layout (-mtune). Specifying -march alone will have the result of setting -mtune to the same option as well, but you can override this, making it possible to optimize for an older processor using newer instruction set extensions. (which obviously doesn't work for the older processor in question, but can sometimes be advantageous) To begin with, try setting -march to allow more instructions to be used, and then setting -mtune to your CPU or to i386, and see what happens.
|
|
HoHo
Member #4,534
April 2004
 |
Usually CPU specific optimizations will give you only a couple of percent of speed. Not worth it usually. I'd just go with -O2 and improve the algorithms to get way better improvements. Also, have you heard of a thing called "profiling"? __________ |
|
nonnus29
Member #2,606
August 2002
 |
That's not surprising at all. There are so many different systems that the cpu interacts with in a game that alot of performance is out of the cpu's control: ie the video hardware. Now if you were doing some computationally intensive like multiplying two 100x100 matrices then you'd see some speed up because it would all occur on the cpu and the cache. |
|
Damian Grove
Member #6,758
January 2006
|
Thanks for the info! I suspect you're all right because I tried optimizing for PII and ran that on my PII machine, and it was a performance improvement, whereas it would produce a performance drop on this (P4) machine. Although it still makes me curious why it won't allow me to optimize for a P4. Again I don't plan to use the P4 optimization in my program -- I might not use any because as was said, it's really the code and algorithms that I should try modifying to speed up my program. But I don't know why it gives me those assembly error messages with the P4 optimization. It also does it if I simply select 'SSE 2'. Anyone have any ideas? Also, I tried the -O2 suggestion and when I compile it and run it, the game freezes. I can't do anything, it just sits there doing nothing. I press Ctrl+Alt+Delete and it automatically closes itself. Any ideas why this might happen? EDIT: I just tried the profiler option, and it won't compile the program now. I get these assembler messages: 'movl $LP173,%edx' It fails to build the program. I have a feeling maybe I'm having these problems because of something the compiler doesn't like that's in my code. I have no clue what that would be because it's obviously not giving me any hints I can really put to use. Should I upload my source somewhere and have it looked at? Get into awesome with Saxman! |
|
Joel Pettersson
Member #4,187
January 2004
|
Quote: Also, I tried the -O2 suggestion and when I compile it and run it, the game freezes. I can't do anything, it just sits there doing nothing. I press Ctrl+Alt+Delete and it automatically closes itself. Any ideas why this might happen? Most likely, it's a problem in the code that, depending on how it is compiled, might be next to or completely unnoticeable or cause severe problems. Generally, the latter result becomes more likely when you use more optimizations. A common example of things that can cause such problems are arrays being written to outside their bounds. The result can range from crashes to more or less subtle glitches. It closing immedietly upon Ctrl+Alt+Delete being pressed is caused by Allegro. (assuming you use one of the many versions with that little problem - check if it happens otherwise as well; if so, it is the case)
|
|
|
