From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.devel Subject: Re: Removing assumption of unsigned long pixel values for colours Date: Mon, 6 May 2019 10:13:04 -0400 Message-ID: References: <87v9yqjdnh.fsf@gmail.com> <83a7g2kqsi.fsf@gnu.org> <87lfzlkeic.fsf@gmail.com> <83zho0khdu.fsf@gnu.org> <87h8a8k84a.fsf@gmail.com> <83pnowjo63.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000010fad4058838b5ac" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="185478"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Alex Gramiak , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 06 16:13:59 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNeNT-000m8O-5t for ged-emacs-devel@m.gmane.org; Mon, 06 May 2019 16:13:59 +0200 Original-Received: from localhost ([127.0.0.1]:57097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNeNS-0005Qt-67 for ged-emacs-devel@m.gmane.org; Mon, 06 May 2019 10:13:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNeNM-0005Qo-QO for emacs-devel@gnu.org; Mon, 06 May 2019 10:13:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNeNK-0006vB-TG for emacs-devel@gnu.org; Mon, 06 May 2019 10:13:52 -0400 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:40518) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNeNI-0006qq-Rr for emacs-devel@gnu.org; Mon, 06 May 2019 10:13:50 -0400 Original-Received: by mail-lj1-x232.google.com with SMTP id d15so11214478ljc.7 for ; Mon, 06 May 2019 07:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TO8sf4/ljIFpdzOWcExfY/h4R7ovFhNQ2jnpeFIe9/I=; b=mUBP8whjduJ6CculG0JMR9+HYxgs+fAst7FQCfl/KElSwmn70x0+BXIUgph1/iZaP1 oUgxZQpO9JvS6QiSQm2tzd9aRu9sDc/kBDINrVfVeVLoV2Qj5CmQfLfELAaBYlcwzXGJ NLsqp4O8g8Eij0TUhKqzj1N1knY92DGOLubJNT8efqvFRp3SbfjQdN8VzOWeKMK9zbr4 SH46jpHY210b/8hP7c3EaotGELNBnCepfbkaC0M4tr221uYuKHk/yLosbjvUHj2PL1cV pnjOpCI/oXut7bGW/MWdaXEhNIfhQrCTHy+AY8QbiAdUG1+Kvmc7rYPVM7RBnw4LZWDY M7Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TO8sf4/ljIFpdzOWcExfY/h4R7ovFhNQ2jnpeFIe9/I=; b=fVEogfl9gQnf2cq9eJ9aEEZUEm3b+INDvARFCZ+KzIeRPPnXxw4WOocOT6dVtrQjKL mFqAocFFHEbBEaD/LazP9hV5d2T0lJKnwzzSoppS4kIAxxyQIwDeNC/jeVsghrQVhBep oZNQ1LLJ3yxvnNr4dOup/Lw0Va2B55AT1vk2QmiJxpyGBDtezHUXe5jYUZm47d1rGP0z mDrdkevgKlcz0S+hcu4z6fxjDbfh8rtto6k3mNV8LuHHwDDfDPIH/il1H4ZzaK2wRTAz +EWNGMQnT1wtgBmSYNBUvmJpAte2VQsddaGDzfgNXFIy0E6IGAhUDHRkEfhTkcsMFP1c smFg== X-Gm-Message-State: APjAAAVYHDduy8JaWzME480j3B+z46hiHfcCrjlpEQcRw1bpNRmZBewz WRMobOTyhQ1xt0zgLAYgogyVGGnQlgvQcZHNrpN3fA== X-Google-Smtp-Source: APXvYqywhoZIapl5dbjK2IXM5fZEK6layfBMTkRnNSaxp/3AyrUpUrMWp46BOsC4EmIJwUuX4kUecCPOxrQz4fvH0B0= X-Received: by 2002:a2e:5b18:: with SMTP id p24mr199983ljb.50.1557152020862; Mon, 06 May 2019 07:13:40 -0700 (PDT) In-Reply-To: <83pnowjo63.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:236193 Archived-At: --00000000000010fad4058838b5ac Content-Type: text/plain; charset="UTF-8" > > > > It's certainly possible that I'm overestimating the cost of the > > conversions. It just doesn't seem good to have to do this conversion for > > every draw operation. > > > > Perhaps I should follow the old adage and just use unsigned long with > > conversions first and benchmark after. > > Yes, please. > If you wanted to explore the optimization (and because I was curious, personally): https://godbolt.org/z/vC_yOg You can change the width of the representation, and possibly even use signed int color values (untested), to see the effect it has. spoiler alert, pretty much none, even with a 64-bit integer for each color value. Even using a relatively old compilers, gcc 4.1.2 from February 13, 2007, the compiled results are quite efficient. See the LLVM-MCA analysis, but your costs seem well within reasonable limits to me. I don't think I'd cache it either: at around 14 cycles per conversion, it is around 5.3ns to run, and fetching from in the L1 cache is around 9ns, so your best case scenario is that you took 60 percent longer to fetch it than to convert it, excluding CPU stalls from other activity. So, benchmark if you want, but I'm pretty sure you can't win much back by doing the conversion only once, rather than inline at execution time. --00000000000010fad4058838b5ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> It's certainly possible that I= 9;m overestimating the cost of the
> conversions. It just doesn't seem good to have to do this conversi= on for
> every draw operation.
>
> Perhaps I should follow the old adage and just use unsigned long with<= br> > conversions first and benchmark after.

Yes, please.

If you wanted to explore t= he optimization (and because I was curious, personally):
https://godbolt.org/z/vC_yOg

You can change the width of the representation, and po= ssibly even use signed int color values (untested), to see the effect it ha= s.=C2=A0 spoiler alert, pretty much none, even with a 64-bit integer for ea= ch color value.

Even using a relatively old compil= ers, gcc 4.1.2 from February 13, 2007, the compiled results are quite effic= ient.
See the LLVM-MCA analysis, but your costs seem well within = reasonable limits to me.

I don't think I'd= cache it either: at around=C2=A014 cycles per conversion, it is around 5.3= ns to run, and fetching from in the L1 cache is around 9ns, so your best ca= se scenario is that you took 60 percent longer to fetch it than to convert = it, excluding CPU stalls from other activity.

So, = benchmark if you want, but I'm pretty sure you can't win much back = by doing the conversion only once, rather than inline at execution time.

--00000000000010fad4058838b5ac--