|
how the proper image of the dice can be generated properly??
one image is not replaced by the other image
|
|
|
|
|
Why didn't you report also the initgraphics function (you provided only the prototype)?
Is the compiler happy with two implementations of the same function (gen_dice) that differ just for the return value type?
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]
|
|
|
|
|
hey man
just see the code carefully
and tell either u can solve the problem or not
i just got problem in generating the dice of image
so kindly tell me either u can do any thing r not
|
|
|
|
|
swtlibra wrote: hey man
just see the code carefully
Hey man I've seen again your code and the initgraphics function definition is still missing.
swtlibra wrote: and tell either u can solve the problem or not
Yes, I can. However, when the request is nice like yours, my rate is 150 euro/hour: can you kindly tell me if you're going to pay such a rate?
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]
|
|
|
|
|
The weirdest thing :
compiling the following C code with gcc (no options) on linux64 :
int main ()<br />
{<br />
unsigned int i,j ;<br />
printf("start");<br />
for (i=j=0;i < UINT_MAX ;i++);<br />
printf("end");<br />
}<br />
<br />
produces a faster binary than this next (leaner) code :
int main ()<br />
{<br />
unsigned int i ;<br />
printf("start");<br />
for (i=0;i < UINT_MAX ;i++);<br />
printf("end");<br />
}
Can someone explain ??
The first code takes around 13-14 seconds on average to run on my machine (dual core AMD64)
the second code takes 14-15 seconds ,on average between 1-2 seconds slower 
why would the addition of an extra int (namely j) produce faster code ?
Can you reproduce on your machine ? 
|
|
|
|
|
With multiple runs, are the difference in times consistent? I would imagine the compiler would optimize the j variable out since it is not used. You might pose this question to Dr. Newcomer (www.flounder.com), an SME on compilers and optimizers.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
The runs are consistently faster with j included .
What I noticed when printing the pointer adresses of both ints i and j is that they were aligned and differing 4 bytes (the size of an unsigned int) :
fi. i at adres 0x7fff095efa0c , j at adres 0x7fff095efa08
My machine being a 64 bit processor , might it be that both adresses occupy precisely a single machine-word and therefore optimize the assembly ? Instead of just one int taking half of the registers ?
|
|
|
|
|
I do not have an answer but if I was interested in the question, I would compile with the -S option
which will show me the generated assemble code. By comparing the two assemble language listings,
you should be able to figure out what the differences are.
Bob
|
|
|
|
|
Thanks for your suggestion :
running a diff on the results gave me :
27c27,29
< movl $0, -4(%rbp)
---
> movl $0, -8(%rbp)
> movl -8(%rbp), %eax
> movl %eax, -4(%rbp)
, where the bottom half is the faster code (with an extra declared int )
Perhaps it is so that 8 aligned bytes (4+4) are transferred more rapidly than just the 4 bytes (?+4) using these registers and 64 bit words
|
|
|
|
|
On OS X with a 2.4GHz Core 2 Duo, they give the expected result - i.e. repeatably the same time to within < 0.1% (6ms in 12s). gcc = i686-apple-darwin9 4.0.1.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Look at the assembly.
Sometimes, an extra variable changes what registry is selected or how the loop is constructed is more amenable to the CPU loop prediction. (I've seen counterintuitive results of code changes that boiled down to both.) You may also be seeing artifacts of load times. Larger code may cause segmentation.
(VC++ will optimize the loop out of existence. Thus any alleged differences in speed are errors in the benchmarking utility.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Hi,
I did a lot of performance analysis on different processors (mostly for embedded systems) including Intel's x86, but not AMD, and lots of C compilers.
My overall conclusion is there are a lot of factors some of which are difficult to control; one of them is code alignment (the address of the first instruction in a loop being at a multiple of 8 or 16 bytes).
Furthermore there is the issue of instruction scheduling: the CPU has different functional units, some in multiple quantities, and depending on minor details, the instructions get dispatched to some or other units, yielding better or worse performance. Adding an instruction may well lead to a faster piece of code.
The bigger issues however are inside the compiler itself; with standard optimization it should:
1. keep values in registers when there are very few involved (here only i and j);
2. figure out the loop does nothing useful and can be discarded;
3. if the net result of the loop would be some final value (i=UINT_MAX), then it should just assign that, but not in the current case since i and j are dead, their value is not used when the loop is done.
4. and for a real loop, with some body, it should consider "loop unroll".
So my advice is:
- start looking at the compiler switches, make sure you use a normal level of optimization (most of the time I apply several switches, the defaults aren't well chosen if you ask me);
- compare compilers for the kind of code that is most relevant to your app;
- only then start looking at the microscopic level. And get ready for a long learning curve.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Hello, I'm writing a MFC application to move a picture control when i press the "Next" button. (Please see screen-captures at following links)
http://i238.photobucket.com/albums/ff191/pumbaboy/before-move.jpg[^]
http://i238.photobucket.com/albums/ff191/pumbaboy/after-move.jpg[^]
There is a dialog box on which there are 2 picture controls. When I press the Next button, the left picture control should move on top of the right picture control.
You can see I kept the code for moving the picture control in a for loop because I wanted a sort of animation effect.
As you can see from the attachments, after I move the image there are some vertical lines appearing. How do I make them go away?
Thank you.
void CShabbirDlg::OnBnClickedButton2()
{
if (pageNum <= 10) {
pageNum++;
CRect RRect, LRect;
picPreview2.GetWindowRect(&RRect);
picPreview.GetWindowRect(&LRect);
for (long int i = LRect.left; i > RRect.left; i -= 20) {
picPreview.MoveWindow(i , LRect.top, LRect.Width(), LRect.Height());
}
}
}
|
|
|
|
|
we need 4 class for an sdi application why we need that application class ??and what is the program flow in a doc view program for an sdi appliction??
|
|
|
|
|
See here.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
if u can't don't make any rubbish ..i hope u got it
|
|
|
|
|
Bisua wrote: if u can't don't make any rubbish ..i hope u got it
Well, this perfeclty applies to you also: if you can't make a valid question and do not bother reading the posting guidelines, don't make any rubbish post like you just did.
|
|
|
|
|
Bisua wrote: .i hope u got it
While you clearly haven't got it.
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 guys, perhaps we should be nice and answer the questions...
Question 1
Bisua wrote: we need 4 class for an sdi application why we need that application class ??
Answer:
Guess WE really don't need it (you might) - there are many other ways to write a program (although you may have been told to use it).
Question 2
Bisua wrote: and what is the program flow in a doc view program for an sdi appliction??
Answer:
That all depends on how you write the program.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
You are not just an idiot, you also have a history of abusive behaviour towards people who actually want to help you but you're too stupid to realize that.
Go away and stop polluting this forum.
|
|
|
|
|
Genius!
|
|
|
|
|
Bisua wrote: we need 4 class
You are kidding right?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
Help humanity, join the CodeProject grid computing team here
|
|
|
|
|
I am trying to understand how to write an efficient OnPaint routine. That is, I want my routine
to only update the part of the screen that needs to be updated. Therefore I wrote a simple program
that creates a window and displays three lines. Below is the OnPaint routine for that program:
void<br />
CMainWindow::OnPaint()<br />
{<br />
CPaintDC dc(this);<br />
<br />
RECT rect1;<br />
BOOL retValue = GetUpdateRect( &rect1 );<br />
if ( retValue != 0 ) {<br />
char *ptr = 0;<br />
*ptr = 23;<br />
}<br />
dc.BitBlt( 0, 0, maxX, maxY, &m_memDC, 0, 0, SRCCOPY );<br />
}
The code works but the routine GetUpdateRect always returns 0. I am wondering if the only way to
get GetUpdateRect to return non-zero is if the program sends (via something like SendMessage)
the WM_PAINT message.
You should also observe that in the current code, if GetUpdateRect does return a non-zero value
then the program crashes. Currently, the program never crashes.
Bob
|
|
|
|
|
BobInNJ wrote: CPaintDC dc(this);
RECT rect1;
BOOL retValue = GetUpdateRect( &rect1 );
try the statement sequence in the following order:
RECT rect1;
BOOL retValue = GetUpdateRect( &rect1 );
CPaintDC dc(this);
Because, from documentation [^]:
BeginPaint automatically validates the update region, so any call to GetUpdateRect made immediately after the call to BeginPaint retrieves an empty update region.
(CPaintDC constructor eventually calls BeginPaint).
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]
|
|
|
|
|
Thanks for your response. I now understand what is going on.
Bob
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
