|
Hans Dietrich wrote: Whole Program Optimization: No
Why do you have this option set to "No"?
Steve
|
|
|
|
|
Mainly due to personal experience. I was trying to track down an intermittent crash that seemingly moved from one area of the app to another. A co-worker suggested removing /GL because it had caused him a similar problem. At this point I was grabbing for anything, so I removed /GL, and that was the last I saw of that crash. I wish I had a better justification, but I don't. There didn't seem to be any noticeable speed slowdown when /GL was removed, so I didn't pursue it.
|
|
|
|
|
I would suggest you save the PDB files generated by the compiler and also save the crash dump after the crash.
You could then debug and get to the root cause of the crash.
|
|
|
|
|
In the kernel I like to turn them all off. That way you get exactly the code you wanted. I have had optimisations take out bits of code I intended to be in their (particulary dead loop timing stuff. Yes, the windows timer has NOT got a low enough granularity. 
You have to write tight code, no function calls in conditions in loops for example, but another benefit is that release code looks like your source, so it is easier to debug release build bugs.
==============================
Nothing to say.
|
|
|
|
|
Optimization: Minimize Size
Inline Function Expansion: Only those explicitly marked
Enable Intrinsic Functions: Yes
Favor Size or Speed: Favor small code
Omit Frame Pointers: No
Enable Fiber-safe Optimizations: Yes
Whole Program Optimization: Yes
Favour size or speed is a result of previous issues with speed optimizations causing problems. Also, smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
I had also done a compare of a number of apps compiled both ways. I was rarely able to find significant differences in speed, but often in size - the size opt had more effect.
Inline expansion 'Any' has caused significant module bloating for me before. This usually happens with template code. I like this part to be deterministic.
Fiber/whole optimizations, never had a reason to turn them off.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
cmk wrote: the size opt had more effect
I assume you mean the size opt yielded faster speed than the speed opt?
cmk wrote: smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
What was the exe size in this case?
|
|
|
|
|
Hans Dietrich wrote: What was the exe size in this case?
The total size of the executable is meaningless in relation to the favor small code optimization. What this does is favor optimizing each function/loop with a very small instruction count. Which may actually reduce the overall exectable size but thats not really the goal. The Favor fast code optimization optimizes for instruction execution throughput... and it may even make code larger because aligned instructions generally prefetch/execute faster. I don't want to give any specific numbers because I am not programming in asm as much these days and plus my expertise is mostly with the older Intel Pentium class processors. Some 32 bit generalizations that may still hold true:
Favor small code:
1.) Could result in more branches but possibly fewer instructions.
2.) Makes an extra effort to keep functions/loops as small possible.
3.) May favor single-byte instructions utilizing the accumulator.
4.) May implement some jumps as sign-extended 8-bit shorts jumps resulting in smaller instruction size.
Favor fast code:
1.) Attempts to keep unconditional branches to a minimum resulting in faster execution speed.
2.) May unroll loops resulting in higher instruction count.
3.) May attempt to align the loops to 16/32/64 byte blocks even at the cost of using more instructions. (Possibly even padding with NOPS!)
Anyway what cmk is implying is that favor fast code will sometimes cause the function or loop to be much larger than a cache line resulting in slower execution and possibly a cache miss.
All of the information I just gave you is speculative and relative to the older compiler code generation algorithms. Modern compilers such as VS2010 generate extremely efficient code in nearly all cases. I spent over a decade hand optimizing much of my C++ code sprinkled with with assembler and could nearly always optimize better than the MS compilers. Beginning with VS2005 I noticed that the compiler was optimizing equal or greater to what I could do by hand. To be perfectly honest... it doesn't make much of a difference these days. The Microsoft compiler is smart enough to know when it is generating inefficient code and sometimes will switch between fast/small code generation algorithms regardless of the engineers choice. The same goes for __inline and __forceinline where the compiler will completely ignore what the engineer wants in many cases.
Btw, I would recommend that you start using whole program optimization. I would be willing to bet that the prior experience you mentioned was due to either VC7.0/VC7.1 or VC8. There were some /LTCG problems on those compilers. Also... for some reason all of those compilers would optimize out calls to memset/ZeroMemory on one of my projects causing an access violation. I ended up using the inlined SecureZeroMemory to get around the optimizing bug. When I moved to VC9 the issues went away entirely and holds true for VC10.
P.S. I essentially use the same optimization settings as cmk with the exception of sometimes omitting the frame pointers to free the ESP register if I am not using exception handlers.
Best Wishes,
-David Delaune
|
|
|
|
|
Good summary.
As you mention, the fast code option can can cause a cache miss. Additionally, earlier versions at least, could result in enough bloat to create extra pages. Related code, that under 'small' sits in the same page, could be split into different pages under 'fast'. This can result in more page faults. The performance impact due to page faults can exceed the speed improvements made from 'fast'.
So, based on past experience, and that these days the difference in optimization strategies is generally minor, I still use 'small'.
I haven't experienced the compiler ignoring my inline settings yet, have to check that, thanks.
The memset issue ... I ran into the same things years ago and found the following:
http://msdn2.microsoft.com/en-us/library/ms972826.aspx[^]
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Excel automation. How to save as *.xls with Excel 2010?
The default extension is *.xlsx, which is uncompatible with Excel 2003.
I want to save as *.xls.
Any one can help?
|
|
|
|
|
Falconapollo wrote: How to save as *.xls with Excel 2010?
Have you looked at the first and second arguments to the SaveAs() method? By specifying an extension of "xls", it should use a v11 or v12 file format (rather than a v14 file format having a "xlsx" extension)?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I build MFC project "czsj", and put some source files out of the project folder. I have specify the "additional includes" of the project, but I still get the error message:
fatal error C1083: Cannot open include file: 'e:\work\t\czsj\excel.cpp': No such file or directory
I have also tried to set the global VC includes, but failed.
I think I can resolve the problem by specifying the search path of MS compiler.
Any one can help?
Thank you in advance!
|
|
|
|
|
Tools->Options->Projects and Solutions->VC++Directories
Choose: "Show directories for: Include Files"
Add your directories here.
Independent ACN Business Owner- Check out the possibilities for your future!
- Financial independance
- Full time or Part time
- In more than 20 countries through North America, Europe, Asia and the Pacific
- Featuring the ACN IRIS 5000 video phone. See the person you are talking to.
Within you lies the power for good - Use it!
|
|
|
|
|
It doesn't work. I have tried. I think I shoud specify the search path for compiler.
|
|
|
|
|
If it is the implementation files you're missing, you could just drag the missing cpp-files from windows explorer and drop them in your project tree, and they will be built from wherever they are stored.
|
|
|
|
|
Falconapollo wrote: Cannot open include file: 'e:\work\t\czsj\excel.cpp': No such file or directory
The text of the error message is perfectly clear and tells you that the file excel.cpp cannot be found at that path. Why are you trying to include a source (.cpp) file in this way; you should add the file to your project (directly or indirectly) and build it as normal.
|
|
|
|
|
The compiler will never search for cpp files, you have to add them explicitly to your project, see the solution pane. Either create them inside your project, or add them ("Add Existing Item") if they already exist.
The one thing that gets looked for is header files (*.h), that is what all the "include" commands and directives are for.
|
|
|
|
|
Hi everybody
How can I send/receive SMS in c++(with PC) with a GSM Modem?
Is it possible?
Can I use MAPI for this?
www.logicsims.ir
|
|
|
|
|
|
Thanks a lot
I've read most of them already
I hope I can find a way with windows API, not sending AT command.
Regards
www.logicsims.ir
|
|
|
|
|
If you use a terminal such as hyper teminal you can practise with the AT commands you need to send SMSs. Once you have got these tuned, then you can put those strings into a C++ app (all it is going to do is send these strings to an opened COM port, as hyperterminsl does).
I wrote a driver some years back that does this, it isnt terribly difficult once you get the AT commands sorted out.
By the way, you must terminate the string in some kind of a carriage return, '\r' or '\n'. It is this that tells the AT processing engine in the modem to actually send the string, this could be what you are missing.
==============================
Nothing to say.
modified 10-Oct-11 3:03am.
|
|
|
|
|
Hi
Thank you,I will try it
Regards
www.logicsims.ir
|
|
|
|
|
hello guys... I have got a project online. Now this project contains a function whose return type is LRESULT. Function's prototype and body are given as under.
afx_msg LRESULT FunctionName(WPARAM wParam, LPARAM lParam);
LRESULT ClassName::FunctionName(WPARAM wParam, LPARAM lParam)
{
}
But the problem is, I dont know how to add these sort of functions in application? Thanx for any help.
modified 8-Oct-11 2:42am.
|
|
|
|
|
overloaded Name wrote: I dont know how to add these sort of functions in application?
Just add the code into one of your source files where you need to use it. In the case of class functions you would add the prototype to the class definition in the header file and the body to the class source file. The sample code from any Visual C++ project will show you how to do it.
|
|
|
|
|
Hi all,
I want to make a priviewer in my application. i have also found a article on code project to preview files but it only priview files which have priview handler installed in registry, so it only preview word, excel files(i.e office Files). i want to priview all other files which are able to generate their priviews in windows priviewer pane. How can i do it.
Thanks in advance
|
|
|
|
|
If the files do not have an attached/attachable previewer then you will have to write your own, by creating some sort of view of the file content and rendering it to a bitmap which you can then display at whatever scaling you wish.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
