Re: Fast Assignment of POD Struct Whose Members Have Copy Constructors
On Dec 4, 10:16 pm, "Nevin :-] Liber" <ne...@eviloverlord.com> wrote:
In article
<115454d1-1019-4fd0-a172-eff3cfbc7...@c3g2000yqd.googlegroups.com>,
Le Chaud Lapin <jaibudu...@gmail.com> wrote:
I would like to verify if the following [undoubtedly common] trick for
deliberately circumventing compiler copy/assignment assistance is
legal.
What makes you believe this is common? Sounds more like a bad premature
optimisation to me.
I am near the end of my project, so one might say that the moment of
evil has arrived. ;)
I can't imagine any modern compiler where your hack generates any better
code than the compiler does in this case. What compiler (and
optimisation level) is generating suboptimal code for you in this case?
I'm using the Microsoft's Visual Studio 2008 stock C++ compiler in
Release mode with all "regular" optimizations turned on, but with
debug information included. "Suboptimal" in this case is function
calls to memcpy, even though truly inline code would be shorter and
faster than the prolog/epilogue code of the memcpy function.
And if you have a user defined copy constructor or copy assignment
operator, either:
A. It is mimicking the compiler generated one, in which case you don't
need it (private/protected notwithstanding)
B. Your hack has broken semantics.
Well, it looks like it is about to become even more broken. I am ready
to use _asm on x86 at least. The compiler requires platform-specific
__forceinline to force inlining of constructors whether they were
declared-inline-explicitly+defined-in-class-declaration or not. I
realize that inline is only a hint to the compiler. I was hoping that
Microsoft's compiler would forgive the 10 or so instructions for a
memory move and not go to memcpy, which is bigger and slower.
For example, in the following code, class Frame has no .cpp file,
only .hpp, with copy constructor/assignment using the trick that I
wrote about in my OP. As can be seen, without programmer help at the
command line, the compiler ignores implicit inlining of the
constructor, not taking into consideration how trivial construction
would be if truly inlinde, which would be a simple move of 9KB of
information:
Frame frame1, frame2, frame3;
004B175E lea ecx,[ebp-62E4h]
004B1764 call Frame::Frame (4A6E37h)
004B1769 lea ecx,[ebp-85A4h]
004B176F call Frame::Frame (4A6E37h)
004B1774 lea ecx,[ebp-0A864h]
004B177A call Frame::Frame (4A6E37h)
Now for assigment, which is equally trivial using the technique that I
mentioned in my OP, the compiler still makes a call to memcpy:
frame1 = frame2;
004B177F push 22B8h
004B1784 lea eax,[ebp-85A4h]
004B178A push eax
004B178B lea ecx,[ebp-62E4h]
004B1791 push ecx
004B1792 call @ILT+4040(_memcpy) (4A5FCDh)
004B1797 add esp,0Ch
And for copy construction, again it makes a call to memcpy:
Frame frame4(frame3);
004B179A push 22B8h
004B179F lea eax,[ebp-0A864h]
004B17A5 push eax
004B17A6 lea ecx,[ebp-0CB24h]
004B17AC push ecx
004B17AD call @ILT+4040(_memcpy) (4A5FCDh)
004B17B2 add esp,0Ch
return 0;
So in all these cases, there are pushes, invocations of memcpy [which
is suprisingly large, btw], and stack cleanup.
This is a bit to much for this particular area of my project, so I
plan to use __asm, __declspec(naked) and __forceinline on all three
functions:
1. constructor
2. copy constructor
3. assignment operator
....to get the performance that I need.
Certain x86 memory movement instructions are much faster than calls to
memcpy, which simply employs those same instructions internally along
with unnecessary overhead.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]