From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2896 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [PATCH] Added ARM optimised memcpy implementation Date: Fri, 8 Mar 2013 09:24:18 +0100 Message-ID: <20130308082418.GT6181@port70.net> References: <1362101090-8525-1-git-send-email-andre@bluewatersys.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1362731075 16559 80.91.229.3 (8 Mar 2013 08:24:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 08:24:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2897-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 08 09:24:56 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UDsbn-0000Nu-7O for gllmg-musl@plane.gmane.org; Fri, 08 Mar 2013 09:24:56 +0100 Original-Received: (qmail 24390 invoked by uid 550); 8 Mar 2013 08:24:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24382 invoked from network); 8 Mar 2013 08:24:30 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2896 Archived-At: * Andre Renaud [2013-03-08 10:48:47 +1300]: > Was there any form of consensus over whether it was possible to get > some version of these ARM optimisations merged? eventually it will be merged i think, but we have seen string optimizations go very wrong (glibc sse mess..) so it should be verified to work properly in cornercases we did not see much measurement data (x% speedup is not measurement data, the speedup will depend on alignment and size, i guess small and aligned memcpy will actually be slower than the current c) most string functions are compiler builtins, so in some cases the compiler will know better what to do than libc and it's extra code to maintain, bugfixes get into musl much easier than arch specific optimizations but if there is a strong cause for the change then i dont think anyone is opposed to it