[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v1 12/14] hostfloat: support float32/64 square r
From: |
Emilio G. Cota |
Subject: |
Re: [Qemu-devel] [PATCH v1 12/14] hostfloat: support float32/64 square root |
Date: |
Thu, 22 Mar 2018 00:02:15 -0400 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Mar 22, 2018 at 01:29:23 +0000, Alex Bennée wrote:
> Emilio G. Cota <address@hidden> writes:
>
> > Performance results for fp-bench run under aarch64-linux-user
> > on an Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz host:
> >
> > - before:
> > sqrt-single: 13.23 MFlops
> > sqrt-double: 13.24 MFlops
> >
> > - after:
> > sqrt-single: 15.02 MFlops
> > sqrt-double: 15.07 MFlops
> >
> > Note that sqrt in soft-ft is relatively fast, which means
> > that fp-bench is not very sensitive to changes to sqrt's
> > emulation speed.
>
> Weird, I thought we had slowed it down quite a bit in the re-factor as
> we eschewed the estimate step for an easier to read but slower iterative
> process. That's why I chose sqrt for my hostfp hack experiment.
Yes, my first statement ("soft-ft is relatively fast") is
wrong. Sorry about that, I thought I had deleted it but it
slipped through.
What I should have said (but decided against to keep the commit log
short) is that fp-bench doesn't do a good job in being sensitive
to the performance of the sqrt instruction, so even if got it
to take 0 time we'd still get a small speedup.
Just realised that this happens because ~50% of the inputs are
negative, which will go through some very slow paths. This ends
up showing in perf like this:
# Overhead Command Shared Object Symbol
# ........ ........ ................. ...........................
#
61.74% fp-bench fp-bench [.] main
22.58% fp-bench libm-2.23.so [.] __kernel_standard
6.22% fp-bench libm-2.23.so [.] __kernel_standard_f
5.21% fp-bench libm-2.23.so [.] __sqrtf
2.17% fp-bench fp-bench [.] _init
1.91% fp-bench [kernel.kallsyms] [k] __call_rcu.constprop.70
0.18% fp-bench [kernel.kallsyms] [k] cpumask_any_but
0.01% perf [kernel.kallsyms] [k] native_iret
0.00% perf [kernel.kallsyms] [k] native_write_msr_safe
__sqrtf (which does 'sqrtss %xmm0,%xmm0') only takes 5% of the time!
I just fixed fp-bench to discard negative inputs. This looks
much better: (Note that this is fp-test-x86_64 instead of -aarch64,
which explains why the "before" throughput is different than
the one reported above)
[...]
+fma: (patch 11, i.e. sqrt still in soft-fp)
sqrt-single: 27.11 MFlops
sqrt-double: 27.17 MFlops
+sqrt: (12)
sqrt-single: 66.67 MFlops
sqrt-double: 66.79 MFlops
+cmp: (13)
sqrt-single: 126.46 MFlops
sqrt-double: 126.06 MFlops
+f32f64: (patch 14)
sqrt-single: 122.75 MFlops
sqrt-double: 126.57 MFlops
We get a >2x speedup, which is consistent with the fact
that now perf shows that sqrt takes ~60% of execution time.
Compare does matter here as well because libm is checking
sqrt's result against NaN.
I'll include this fix to fp-bench in v2.
Thanks,
E.
- Re: [Qemu-devel] [PATCH v1 08/14] hostfloat: support float32/64 addition and subtraction, (continued)
[Qemu-devel] [PATCH v1 09/14] hostfloat: support float32/64 multiplication, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 01/14] tests: add fp-bench, a collection of simple floating-point microbenchmarks, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 11/14] hostfloat: support float32/64 fused multiply-add, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 10/14] hostfloat: support float32/64 division, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 12/14] hostfloat: support float32/64 square root, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 05/14] softfloat: add float32_is_normal and float64_is_normal, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 13/14] hostfloat: support float32/64 comparison, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 14/14] hostfloat: support float32_to_float64, Emilio G. Cota, 2018/03/21
[Qemu-devel] [PATCH v1 02/14] tests: add fp-test, a floating point test suite, Emilio G. Cota, 2018/03/21