[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optimize glyph row clearing and copying routines
From: |
Eli Zaretskii |
Subject: |
Re: Optimize glyph row clearing and copying routines |
Date: |
Tue, 24 Sep 2013 14:50:40 +0300 |
> Date: Tue, 24 Sep 2013 14:10:07 +0400
> From: Dmitry Antipov <address@hidden>
> CC: address@hidden
>
> On 09/24/2013 10:35 AM, Eli Zaretskii wrote:
>
> > Does this change really speed up the code?
>
> YMMV, as usual with benchmarks. Time is in CPU cycles, smaller is better:
>
> It was:
>
> gcc 4.8.1 gcc 4.8.1 Intel C 13.1.3
> clang 3.3
> -O2 -g3 -O3 -march=native -O3 -xHOST -O3
> -march=native
> ------------------------------------------------------------------------------------------
> clear_glyph_row 100 140 90 40
> copy_row_except_pointers 90 160 80 100
>
>
> Now it is:
>
> gcc 4.8.1 gcc 4.8.1 Intel C 13.1.3
> clang 3.3
> -O2 -g3 -O3 -march=native -O3 -xHOST -O3
> -march=native
> ------------------------------------------------------------------------------------------
> clear_glyph_row 75 60 35 35
> copy_row_except_pointers 95 150 50 70
>
> (Intel C and clang makes heavy use of SSE, but gcc isn't).
>
> It would be interesting to add MSVC to this table :-).
>
> In short, I believe that a good compiler should get more optimization
> opportunities from
> new code rather than from old. For this particular case, Intel C is
> "definitely good",
> and gcc, hm...looks controversial at least.
I think -O3 is not interesting in this case. For -O2 with GCC, which
is the most important case (as Emacs is normally built like that), you
get net loss, because AFAIR copy_row_except_pointers is called much
more often than clear_glyph_row. The important comparison is, of
course, as part of some redisplay scenario, not just cycle comparison.