This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [patch, mips] Improved memset for MIPS
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: libc-ports at sourceware dot org
- Date: Fri, 06 Sep 2013 22:38:15 -0400
- Subject: Re: [patch, mips] Improved memset for MIPS
- Authentication-results: sourceware.org; auth=none
- References: <93a232b5-9d0b-4a27-bbb5-16e3ae7c4b89 at BAMAIL02 dot ba dot imgtec dot org> <522957A4 dot 2030400 at redhat dot com> <1378483403 dot 5770 dot 307 dot camel at ubuntu-sellcey> <522A0CF8 dot 8040008 at redhat dot com> <1378510388 dot 5770 dot 346 dot camel at ubuntu-sellcey>
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.