From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: macOS metal rendering engine in mac port Date: Sun, 23 May 2021 12:47:46 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28711"; mail-complaints-to="usenet@ciao.gmane.io" Cc: YAMAMOTO Mitsuharu , emacs-devel@gnu.org To: Aaron Jensen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 23 13:50:20 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lkmce-0007Mp-Gd for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 13:50:20 +0200 Original-Received: from localhost ([::1]:47536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkmcd-00054V-HJ for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 07:50:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkmbD-000437-13 for emacs-devel@gnu.org; Sun, 23 May 2021 07:48:51 -0400 Original-Received: from [217.169.17.33] (port=57248 helo=breton.holly.idiocy.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkmbB-0003bB-28 for emacs-devel@gnu.org; Sun, 23 May 2021 07:48:50 -0400 Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id B5946202C1C0CD; Sun, 23 May 2021 12:47:46 +0100 (BST) Mail-Followup-To: Alan Third , Aaron Jensen , emacs-devel@gnu.org, YAMAMOTO Mitsuharu Content-Disposition: inline In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 217.169.17.33 (failed) Received-SPF: none client-ip=217.169.17.33; envelope-from=alan@breton.holly.idiocy.org; helo=breton.holly.idiocy.org X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269663 Archived-At: On Sat, May 22, 2021 at 02:20:34PM -0700, Aaron Jensen wrote: > > How can the Mac port only see a change of 0.6s while the NS port sees > > a change of 1.3s, when the only change is turning line numbers on or > > off? Line numbers performance should surely be mostly independent of > > the UI toolkit? > > No idea. It seems to be percentage based more than fixed for whatever > reason. I built emacs 27 w/ -g3 -O2 Me too. I checked the Mac port flags too in case it was doing something sneaky, but nope, looks the same. > > You know, my benchmarking is all over the place. I literally just did > > two runs at 11s and another two at 8.6s. Nothing changed. And I > > regularly see a code change produce an improvement, then undoing the > > change retaining the improvement. It's like rebuilding the exact same > > code base produces a completely different performance result. > > > > I suspect my Mac rides the CPU frequency continuously or something. > > Mine are fairly consistent. I imagine hitting thermal would hurt > though and Intel macs love to do that. Yeah, I wonder if that's what's happening. I have to say that I don't think this Mac has ever been what I'd consider fast. My ancient first gen i7 absolutely wipes the floor with it in compilation speed despite being at least 7 years older. I guess Moores law really did run out of steam. ;) > What isn't consistent is typing experience. There are times when it's > just like molasses but I can't necessarily reproduce that with > benchmarks. I wonder if the separate threaded IO from the mac port > helps make things feel more consistent in some way. Probably, the threading also seems to be used to do the buffer copies and things. AFAICT it also offloads the copy to Metal when it's enabled, although I imagine that then involves copying the buffer back down to system RAM from VRAM for updating, so I don't know how much of a win it really is. On a fast graphics card it maybe really is a big win. > It'd be great to try an emacs-28 with the 27+flicker patch rendering. > I'd be curious how that'd feel w/ native comp. Maybe that'd make > enough of a difference for me on this screen. It's a lot of work. I'd have to be sure that the patch actually stops the flashing and blanking before I tried that. I'm not hopeful, tbh. Anyway, the last thing I want to try to improve lag is to move the buffer copy to as soon after the layer update as possible, so that when you hit a key we don't have to wait for it before we can start drawing. I've pushed a change to the surface-stuff branch, so can you please give it a go and see if there's any improvement. -- Alan Third