From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master def6fa4246 2/2: Speed up string-lessp for multibyte strings Date: Sat, 08 Oct 2022 13:40:07 -0400 Message-ID: References: <837d1bmo66.fsf@gnu.org> <069A384D-4D27-4787-B6BE-84B43FBDF952@acm.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17888"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel To: Mattias =?windows-1252?Q?Engdeg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 08 19:42:27 2022 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 1ohDqE-0004Vg-Sj for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Oct 2022 19:42:27 +0200 Original-Received: from localhost ([::1]:59634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohDqD-000124-BC for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Oct 2022 13:42:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohDoD-0000D8-7B for emacs-devel@gnu.org; Sat, 08 Oct 2022 13:40:21 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52167) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohDo9-00081s-H9; Sat, 08 Oct 2022 13:40:19 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E9703100189; Sat, 8 Oct 2022 13:40:14 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2E331100084; Sat, 8 Oct 2022 13:40:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665250809; bh=GE+RLiWuJnJks+Z4YGyjxHor/8/M7LXjJottSZEFrLA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nwLuRNctRtYw89Arm3fqUOxJZ6fsqgp++++hoLXDsf5F9npRILvF8bF0CwUAqT4oM BJ7XTBli+QEhLo46G8BepYpUwIhJMdRXQ9EYCHpettFLrkHKp2VgkWqnas7Fw1XWNv hZ4bHIxR3ym9cFFPZvb2fi4ccynohSkxAvH0o8PnGblRt+nMmxwDbfxSbMDdWFXmBA 8z9LvyPX36wI3EvE4MD7oUCiIPO4CfVgEWwCPMRk6zPZV/2L65JVzat6SRd27IsGGa 5IpmVo79NNPjBMo7iVB2wO1RDfHSuyr+7+IfRnDmUrsAcRDqDapS8pumDaBCy+xrJo 0/NzQFL6b5NNQ== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F31891203FE; Sat, 8 Oct 2022 13:40:08 -0400 (EDT) In-Reply-To: <069A384D-4D27-4787-B6BE-84B43FBDF952@acm.org> ("Mattias =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 8 Oct 2022 18:49:11 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:297215 Archived-At: > Of course I was wrong! String data from purespace can be unaligned even for > multibyte. Thanks for making me take another look. (Of course, angry SPARC > users would have let me know eventually.) [ Cue the "kill the purespace" song. ] > Rather than attempting to find and plug all cases where unaligned strings > are produced, this part of the optimisation has now been restricted to > platforms where unaligned accesses are safe using a architecture whitelist. I haven't looked in detail at this code, but this reminds me of the code I wrote to compute the hash of a string (`hash_string` in fns.c), where I similarly want to use word operations rather than manipulate individual bytes. I ended up using `memcpy` which the compiler helpfully turns into plain word-sized loads. So we get code without alignment or architecture assumptions and efficient code (even on architectures that don't allow unaligned loads since the compiler can still produce more efficient code than a byte-by-byte loop). > It may still be a good idea to ensure aligned allocation since it allows for > more vectorisation of string operations but then again, most commonly used > architectures handle unaligned accesses well. [ Over on comp.arch the general mood is that not supporting unaligned loads natively is a ridiculous mistake because it's so cheap to implement (and the software workarounds are much more costly in comparison). ] Stefan