From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1753 invoked by alias); 7 Sep 2013 02:38:21 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 1742 invoked by uid 89); 7 Sep 2013 02:38:20 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 07 Sep 2013 02:38:20 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r872cHov012107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Sep 2013 22:38:17 -0400 Received: from [10.3.113.8] ([10.3.113.8]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r872cFD4005992; Fri, 6 Sep 2013 22:38:16 -0400 Message-ID: <522A9197.9000601@redhat.com> Date: Sat, 07 Sep 2013 02:38:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Steve Ellcey CC: libc-ports@sourceware.org Subject: Re: [patch, mips] Improved memset for MIPS References: <93a232b5-9d0b-4a27-bbb5-16e3ae7c4b89@BAMAIL02.ba.imgtec.org> <522957A4.2030400@redhat.com> <1378483403.5770.307.camel@ubuntu-sellcey> <522A0CF8.8040008@redhat.com> <1378510388.5770.346.camel@ubuntu-sellcey> In-Reply-To: <1378510388.5770.346.camel@ubuntu-sellcey> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00066.txt.bz2 On 09/06/2013 07:33 PM, Steve Ellcey wrote: > On Fri, 2013-09-06 at 13:12 -0400, Carlos O'Donell wrote: > >> Are you able to post this test program for posterity along with >> your patches? > > I have attached it to this email. I compile with -UVERIFY when doing > benchmarks and with -DVERIFY when I am doing correctness testing. On > one of my 74k boards the old memset took 63.409 seconds and the new one > took 45.577 seconds. I played with different prefetch hints too while > benchmarking but the prepare-to-store one is the fastest. Thanks for sharing that. >> Just run `make bench', wait a while, and compare results before and after. >> >> Look at bench/README for more details. > > I tried running it but all the tests failed with messages like this: > > Running /home/sellcey/gcc/memset/obj-mipsisa32r2el-linux-gnu/glibc/obj_default/benchtests/bench-bcopy > /home/sellcey/gcc/memset/obj-mipsisa32r2el-linux-gnu/glibc/obj_default/elf/ld.so.1: 1: /home/sellcey/gcc/memset/obj-mipsisa32r2el-linux-gnu/glibc/obj_default/elf/ld.so.1: ^?ELF^A^A^A^C^H^A�^O4~\�: not found > /home/sellcey/gcc/memset/obj-mipsisa32r2el-linux-gnu/glibc/obj_default/elf/ld.so.1: 2: /home/sellcey/gcc/memset/obj-mipsisa32r2el-linux-gnu/glibc/obj_default/elf/ld.so.1: Syntax error: "(" unexpected That's really quite odd. Have the Makefile print what it's going to run and then re-run it by hand? e.g. diff --git a/benchtests/Makefile b/benchtests/Makefile index 4d4b909..b0f0716 100644 --- a/benchtests/Makefile +++ b/benchtests/Makefile @@ -146,7 +146,7 @@ bench: bench-set bench-func bench-set: $(binaries-benchset) for run in $^; do \ - echo "Running $${run}"; \ + echo "Running $(run-bench)"; \ $(run-bench) > $${run}.out; \ done --- > I am not quite sure what to make of this, it seems to be using the right > ld.so.1 but I am not sure what it is that is 'not found' Could this be > related to the issue of installing the latest libgcc and libstdc++ in > default locations? (glibc 2.18 wiki section 5.1.1) I built glibc with a > GCC from a non-standard location so the libgcc and libstdc++ for that > compiler are not in the standard locations. No, libgcc won't matter unless you do cancellation, and libstdc++ doesn't matter because it's not a C++ application. You'll just get glibc using the versions of those from the related prefix directories. I don't think it should be making any difference here. You've certainly got your share of weird environment issues :-) Cheers, Carlos.