This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 00/27] S390: Optimize string, wcsmbs and memory functions.

On 08/13/2015 06:14 PM, OndÅej BÃlka wrote:
On Thu, Aug 13, 2015 at 04:58:48PM +0200, Stefan Liebler wrote:
On 08/11/2015 01:16 PM, OndÅej BÃlka wrote:
On Wed, Aug 05, 2015 at 12:41:34PM +0200, Stefan Liebler wrote:
ping after release 2.22.

ok to commit?
Regarding to the wide-string enhancements for tests/benchtests

 From performance side I don't have more comments, it looks like nice
instruction set. However I couldn't review this on correctness side so
who could check assembly for that?
Thanks for your review.
Andreas Krebbel will do this.
Is the enhancement of the tests/benchtests okay?

As benchmarks I will shortly post link to next iteration of dryrun
framework on this list. It allows to collect call traces and replay
functions with same arguments. While not as accurate directly measuring
timing information of new implementations it gives good approximation of
what improvement you will actually get. So could you after I post it
also run it?

Yes, of course. I'll give it a try, but I'm not allowed to post the
results. Are there any traces of workload available?

And could you at least tell what speedup you got or not?

I didn't publish workloads for all functions yet, only some special
cases. I need to write utilities to limit record size, now it generates
gigabyte large files for strcmp after short while as strcmp is called
that much. Also I didn't add conversions between little/big endian and
alignments could be different.

I would prefer if you did recording for example compiling glibc(or
anything else that interests you), you need to only write following

mkdir glibcdir
$GLIBC_SOURCE/configure --prefix/usr
cd glibcdir
# end shell

I recorded the building of binutils/glibc and produced some GB of record data. Afterwards I called bench_<function> via from no-vector/vector glibc-build as mentioned in your separate dryrun-post. Comparison showed speedup and no function was slower with the vector-glibc-build.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]