Hrmm, I guess VS8 sets the defines for character encoding internally, unlike previous versions to set the character encoding.
You probably should have posted it in the "Visual C++ General" (or Language) forum, but it will probably be moved =-)
native char* slower on VS2005?
Quote:Original post by PromitWeird, could have sworn it was in VS General =-/
It IS in the Visual C++ General forum.
This is interesting, both GCC doesn't seem to be able to remove dead loops either. I'd say it's some kind of safety "feature" to preserve delay loops and performance tests like these, except that sounds exceedingly retarded given todays heavily templated code.
Here's what the best I could do (by enabling loop unrolling and setting the maximum number of iterations) without spending an enternity fiddling with all of GCC's optimization settings:
Here's what the best I could do (by enabling loop unrolling and setting the maximum number of iterations) without spending an enternity fiddling with all of GCC's optimization settings:
mov eax,4999999.loop: sub eax,32 jns .loop
An MS guy has graciously explained:
Quote:Post by Jonathan Caves [MSFT]
Hi: I've talked to the optimizer guys here and they explained why this code is being generated.
1) If you remove the statement:
cout << temp2;
then by applying the dead-store elimination the opimizer can remove all the proceeding code as there is not real use of temp2
2) The reason why the loop is not being completely removed is that for most of the optimization process the compiler does not know what strcpy does: it cannot assume that you are calling the Standard version of strcpy (after all at the link phase you may provide your own version of strcpy with completely different semantics). It is only when the compiler is generating the assembly code for the target platform that it replaces the call to strcpy with a platform specific intrinsic and at this stage it is too late to go back and re-run the global opimizer over the generate x86 (or x64, or IPF) assembly code.
We agree that this is situation is not ideal and the optimizer team is currently working on a new architecture which they hope will enable them to fix issues like this.
Author
Yes this seems pretty logical to me. I am glad this topic raised such positive discussion.
But what about the speed difference I am getting with VS2005 vs VS6. Shouldn't the performance be equal or better than previous version ? Or I am missing some compiler option ? 882 is not faster then 573 I am getting with VS6 for sure.
But what about the speed difference I am getting with VS2005 vs VS6. Shouldn't the performance be equal or better than previous version ? Or I am missing some compiler option ? 882 is not faster then 573 I am getting with VS6 for sure.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
