From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Optimize glyph row clearing and copying routines Date: Tue, 24 Sep 2013 16:42:57 +0400 Message-ID: <524188D1.1050500@yandex.ru> References: <83a9j2iv6o.fsf@gnu.org> <524164FF.10407@yandex.ru> <837ge6igkv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380026602 14353 80.91.229.3 (24 Sep 2013 12:43:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Sep 2013 12:43:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 24 14:43:26 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 1VORxd-0007FH-Ha for ged-emacs-devel@m.gmane.org; Tue, 24 Sep 2013 14:43:25 +0200 Original-Received: from localhost ([::1]:45685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VORxd-0006YD-65 for ged-emacs-devel@m.gmane.org; Tue, 24 Sep 2013 08:43:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VORxU-0006Vf-3X for emacs-devel@gnu.org; Tue, 24 Sep 2013 08:43:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VORxN-0003q9-1s for emacs-devel@gnu.org; Tue, 24 Sep 2013 08:43:16 -0400 Original-Received: from forward9l.mail.yandex.net ([84.201.143.142]:60996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VORxF-0003p0-Cm; Tue, 24 Sep 2013 08:43:01 -0400 Original-Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward9l.mail.yandex.net (Yandex) with ESMTP id ECEDEE60DD5; Tue, 24 Sep 2013 16:42:57 +0400 (MSK) Original-Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 9545A2C1995; Tue, 24 Sep 2013 16:42:57 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id TzTmCItDp2-gvdG9qKU; Tue, 24 Sep 2013 16:42:57 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1380026577; bh=JKvhTs7JS4uDIAT6zwl8eT2/K3WwvZzd+eecOmRNv/g=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GV9NfxBkrnF7RzX/AmBQH6GVASZa87g6sfooKwQuHwGR0S59ZvG9WQxKJoRNVUSUh 3pvckwBNu6QI8FhRUSyiXBjVwrnBwIOLgJMGEOsiOXJDytllYdBY6EPKQRLxsenfZI mw5mZgFH/IR25JHmz68+a+E2AFwd5aawR8ltysT8= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <837ge6igkv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.142 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:163599 Archived-At: On 09/24/2013 03:50 PM, Eli Zaretskii wrote: > I think -O3 is not interesting in this case. For -O2 with GCC, which > is the most important case (as Emacs is normally built like that), you > get net loss, because AFAIR copy_row_except_pointers is called much > more often than clear_glyph_row. The important comparison is, of > course, as part of some redisplay scenario, not just cycle comparison. 1) I do not believe in 5 CPU cycles difference too much. This is just ~5%, which may be explained by some irregular inaccuracy. 2) I'm talking about GCC 4.8.1, but people from this list still uses 4.2.x. or even older. Unfortunately GCC is known to have some serious regressions from time to time. 3) As it's proven by icc/clang, good compiler _really_ gets more optimization opportunities from new code rather than from old. IMHO we should provide workaround if it's known that gcc-X.Y.Z has serious bug; but we should not reject generally better code if we have just an unconvincing suspicion that gcc-P.Q.R introduces some miserable regression. Dmitry