From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Optimize glyph row clearing and copying routines Date: Tue, 24 Sep 2013 11:03:32 -0700 Organization: UCLA Computer Science Department Message-ID: <5241D3F4.7060407@cs.ucla.edu> References: <83a9j2iv6o.fsf@gnu.org> <83wqm6gnhv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380045834 12049 80.91.229.3 (24 Sep 2013 18:03:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Sep 2013 18:03:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 24 20:03:56 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VOWxo-0001FB-Jl for ged-emacs-devel@m.gmane.org; Tue, 24 Sep 2013 20:03:56 +0200 Original-Received: from localhost ([::1]:47381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOWxo-0007UK-6N for ged-emacs-devel@m.gmane.org; Tue, 24 Sep 2013 14:03:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOWxe-0007Tw-Nz for emacs-devel@gnu.org; Tue, 24 Sep 2013 14:03:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOWxV-0004eG-Bn for emacs-devel@gnu.org; Tue, 24 Sep 2013 14:03:46 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:48446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOWxV-0004eC-5f for emacs-devel@gnu.org; Tue, 24 Sep 2013 14:03:37 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 3F57F39E8109 for ; Tue, 24 Sep 2013 11:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnU2SnIS1r6z for ; Tue, 24 Sep 2013 11:03:35 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id CB86639E80FF for ; Tue, 24 Sep 2013 11:03:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 In-Reply-To: <83wqm6gnhv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163618 Archived-At: On 09/24/13 10:04, Eli Zaretskii wrote: > The issue here is a _partial_ copy of a struct, starting with some > offset. That offset can be aligned less favorably than the struct > itself, which will cause memcpy be less efficient. Yes, I can verify that this is indeed an issue on my platform (Fedora 19 x86-64, bundled GCC 4.8.1). On my platform, this code: enum { off = offsetof (struct glyph_row, x) }; memcpy (&to->x, &from->x, sizeof *to - off); generates a complicated sequence of 176 instructions, whereas this: *to = *from; generates just two: mov 0x20,%ecx rep movsq %ds:(%rsi),%es:(%rdi) I don't know whether this is faster, but it sure is simpler. One possible way to get the simplification at the assembly level, might be to package the part of the structure that one wants to copy inside another structure designed just for that purpose, so that one could write (to->substruct = from->substruct). The new code does have an advantage of clarity. The old code squirreled away some stuff in a temporary copy and then copied it back, which was hard to follow, whereas the new code simply copies from source to destination. This may be worth any minor performance loss.