Re: [patch, mips] Improved memset for MIPS

["Carlos O'Donell" <carlos@redhat.com>]

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.