|
Elementary, my dear Watson!
|
|
|
|
|
Hello all. When I debug a Visual C++ 9 application and want to see a CString variable's value in the watch tab, it only displays a memory address. If I wish to see the string, I have to select CString's m_pszData member.
I remember that one could customize Intellisense so that it would show some specific value of a certain class. I've been googling for a while but haven't found something useful: I only get references to DebuggerDisplayAttribute class, but since that's a managed class I can't use it.
So, does anybody have a clue on how to configure Intellisense?
Thanks in advance.
|
|
|
|
|
| Maybe you can edit the autoexp.dat file (somewhere in the VS folder) to do that ? (just google for that). Watched code never compiles.
|
|
|
|
|
Yep, that did the trick. I found this article[^] that explains how to do it. And although it references VC6 it works quite well in VC9, the only difference being that autoexp.dat file is located at C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger (in my machine, at least).
Thanks for the help!
|
|
|
|
|
Hi,
After making arbitrary decisiones for a long time, I've decide to ask it once and for all.
Suppose you have a bool value (WasFooEverCalled), that indicates whether some function Foo() was ever called or not. Suppose 'Foo()' is going to be called millions of times. What is more efficient:
1. Simply assigning 'WasFooEverCalled = true;' whenever Foo is called().
2. Whenever 'Foo()' is called, check whether 'WasFooEverCalled' is currently false, and if it is, assign 'WasFooEverCalled = true;'.
What I'm actualy asking is what is more CPU expensive, assigning a bool value, or checking if a bool value is something.
// Here's the code:
bool WasFooEverCalled = false;
void Foo()
{
WasFooEverCalled = true;
if ( ! WasFooEverCalled )
WasFooEverCalled = true;
}
Thanks!
|
|
|
|
|
void f()
{
...
}
class CF
{
public:
CF() { f(); };
};
void usage()
{
static CF onlyOnce();
}
I have no answer for your last question, sorry  Check your definition of Irrationality[ ^]
1 - Avicenna
5 - Hubbard
3 - Own definition
|
|
|
|
|
I think both should use the same time. In general reading is faster then writing,
but both calls should be around 2-4 cycles on the cpu. So even if
reading would be faster then writing (assume 1 cpu cycle), you have to call this
function around ~2.5-3 billion times to have a differ of one second.
-> Conclusion:
If you really need that performance than you are using the wrong language and not
the wrong option.
At least:
Use option b, because if this function is called very often, the cpu also should have
a higher cache hit rate for this and the cpu doesn't have to do a memory access.Greetings
Covean
|
|
|
|
|
Ofer Gross wrote: What I'm actualy asking is what is more CPU expensive, assigning a bool value, or checking if a bool value is something.
If you'll look as the assembly code, you likely find that the latter takes one more instruction."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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
As David already suggested, option A, namely
mov BYTE PTR ?WasFooEverCalled@@3_NA, 1 ; WasFooEverCalled
looks more efficient than option B
cmp BYTE PTR ?WasFooEverCalled@@3_NA, 0 ; WasFooEverCalled
jne SHORT $LN4@Foo
; Line 702
mov BYTE PTR ?WasFooEverCalled@@3_NA, 1 ; WasFooEverCalled
$LN4@Foo:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
You both should be right if you just look at the count of commands the cpu has to execute.
But as I mentioned before, there are more things that can effect the efficiency.
- cache hits
- (maybe) no write-back phase
- instruction order to process
...
At least:
I think this optimization stands in no relation to the time spend thinking about it.Greetings
Covean
|
|
|
|
|
Yes there are a lot of thing to consider, anyway it is very hard to figure out how 'option B' may outperform 'option A'.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
But it seems that I'm right, after I made some performance tests (1 billion loop).
with Check:
bool bTest = false;
LARGE_INTEGER lFreq;
LARGE_INTEGER lStart;
LARGE_INTEGER lEnd;
QueryPerformanceFrequency(&lFreq);
QueryPerformanceCounter(&lStart);
_asm
{
push ecx
mov ecx, 1000000000
_loop:
cmp bTest, 0
je _set
sub ecx, 1
jnz _loop
jmp _end
_set:
mov bTest, 1
sub ecx, 1
jnz _loop
_end:
pop ecx
}
QueryPerformanceCounter(&lEnd);
without Check:
bool bTest = false;
LARGE_INTEGER lFreq;
LARGE_INTEGER lStart;
LARGE_INTEGER lEnd;
QueryPerformanceFrequency(&lFreq);
QueryPerformanceCounter(&lStart);
_asm
{
push ecx
mov ecx, 1000000000
_loop:
mov bTest, 1
sub ecx, 1
jnz _loop
pop ecx
}
QueryPerformanceCounter(&lEnd);
Here are the results of the test:
with Check:
1270916680 ns
1263151000 ns
1266200680 ns
1263518040 ns
1261185600 ns
average: 1264994400 ns for an one billion loop
without Check:
1268685200 ns
1264999280 ns
1268999120 ns
1263301960 ns
1263604200 ns
average: 1265917952 ns for an one billion loop
So writing it every time is a little bit slower than checking the value (on my cpu).Greetings
Covean
|
|
|
|
|
Your test on on my machine:
With check (average of 8 runs): 1138972011 ns
Without check (average of 8 runs): 579320876 ns
BTW it looks like my machine is a bit faster than yours... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
|
Dual Core 1.8 GHz, 2 GB, 32 bit OS, Release Build with default optimizations (Visual Studio 2005).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Now I got a clue why its so slow on my cpu.
On an 64 bit machine 32 bit application are not that fast (can't test it with x64 because this allows no inline assembly). This also explains why both tests didn't perform at the maximum speed they could do and also 16/32 bit instructions are slower on an 64 bit cpu then the 64 bit instructions.
Thanks for the time you took to test it on your machine  .Greetings
Covean
|
|
|
|
|
and even more should the byte code show the differences.
I guess checking needs some commands  Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
My usual way:
static bool _bWasFooEverCalled = false;
inline bool WasFooEverCalled()
{
return _bWasFooEverCalled;
}
cheers,
ARWhen the wise person points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
Option A is more efficient. The main reason is that the 'if' statement changes the program flow, which can interfere with the CPU's pipelined execution.
Modern CPUs typically have several consecutive instructions in various stages of execution. For a linear instruction sequence, N stages will process N times as fast as a single stage. When there's a branch, however, this efficient arrangement is messed up, and can result in flushing the instruction cache, losing the speed advantage from pipelining.
Bottom line: For maximum efficiency, avoid branches (both conditional and unconditional) as much as possible in the critical sections.
|
|
|
|
|
There you are completely right. But if you take a deeper look you will see that, there
will only be 1 branch (at the first call) and after that it never will flush the instruction cacheGreetings
Covean
|
|
|
|
|
But if the function call is compiled inline (which is reasonable, since it's called frequently and needs to be efficient), that branch may be in the middle of an otherwise linear instruction sequence. In this case the option without the branch would be more efficient.
|
|
|
|
|
'Option B' was not compiled inline while 'Option A' was: I had to make the function 'fatter' to obtain a standard, i.e. not-inline one (VS2005 Release Build with default optimization options).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
a really clever compiler would know that option B can be thought of as an equivalent to option A. the end result is always: WasFooEverCalled = true
if WasFooEverCalled is false, it will be set to true. if it's already true, setting it to true again changes nothing. might as well just set it to true, always.
|
|
|
|
|
In many cases, it will be faster to blindly write to a variable than to do so conditionally, though the difference is unlikely to be great. The only time that conditional writing would be faster be in multi-CPU architectures which require pre-arbitration of memory writes (which is how I understand some of them work). In that scenario, if two CPU's were repeatedly trying to write 1 to the same variable, performance may be quite poor as the CPU's would spend considerable time acquiring and releasing control of the cache page holding the variable in question. If instead the variable was only written once and the CPU's simply had to read it repeatedly, the variable could be held in both CPU's caches with zero time wasted on arbitration.
|
|
|
|
|
Option C:
(but its only reasonable if you can't inline the foo function)
In this example you just have to call foo() (what will be "inlined" be the compiler)
At the first call it calls _FooFuncAndSetBool. There it sets the bool value bWasFooEverCalled
and after that it set the function pointer to the function _FooFuncWithoutSetBool.
Every later "inlined" call to foo() will just call you funtion without setting or checking
a value.
But as I mentioned before its only reasonable if your foo() funtion itself can't be inlined,
because there will always be a call statement in assembler and call statements are
always slower then "inlining" a function.
And now the CODE: (I hope its not that cruel )
typedef void FooFunc();
void _FooFuncAndSetBool();
void _FooFuncWithoutSetBool();
bool bWasFooEverCalled = false;
FooFunc* pFooFunctionToCall = &_FooFuncAndSetBool;
void _FooFuncAndSetBool()
{
bWasFooEverCalled = true;
pFooFunctionToCall = &_FooFuncWithoutSetBool;
_FooFuncWithoutSetBool();
}
void _FooFuncWithoutSetBool()
{
}
inline void Foo()
{
(*pFooFunctionToCall)();
}
Maybe this is an alternative for you.
[edit] Added the call _FooFuncWithoutSetBool() to _FooFuncAndSetBool().Greetings
Covean
modified on Thursday, March 4, 2010 6:48 AM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
