[Mesa-dev] A few NIR compile time optimisations

[Eero Tamminen]

Hi,

On 20.2.2019 17.32, Marek Olšák wrote:
> On Wed, Feb 20, 2019 at 2:31 AM Connor Abbott <cwabbott0 at gmail.com 
>     On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák <maraeo at gmail.com
...
>         That's a harsh reaction to a relatively good benchmarking setup.
>         I use debugoptimized with -DDEBUG. My performance is probably
>         more affected by -fno-omit-frame-pointer than -DDEBUG.
> 
>     Why would you enable DEBUG in a profiling build? AFAIK it's supposed
>     to enable validation more expensive than simple asserts, which you
>     probably don't want in a benchmarking setup, although from grepping
>     the source it's not used much. It might be a good idea to move
>     running NIR validation behind DEBUG instead of !NDEBUG. In the
>     meantime, unless you really want to benchmark things with assertions
>     enabled in which case NIR_VALIDATE=0 works (but why would you?), you
>     can set -Db_ndebug=false in Meson. I just saw today that they're
>     enabled by default in debugoptimized builds (whoops, better go fix
>     that and re-profile...).
> 
> Assertions and other debug code really don't cost much, so I don't see a 
> reason to undef DEBUG.

At least on other projects I've seen cases where:
* assert or debug code has been added to places where it's expensive, or 
some of those places become expensive later
* one sees low cost code in profiles and assume it to be specific to 
DEBUG build, although somebody had forgotten to ifdef it properly
* debug build (or part of it) is compiled with other optimization flags 
than release build [1]
* added debug code causes important code not anymore to fit into smaller 
cache level (this is very specific to cache sizes on given machine and 
code GCC generates though)

[1] Unexpected things happen.  Recently I e.g. saw switching
     between Meson & Autotools causing Mesa URB allocation changes:
	https://bugs.freedesktop.org/show_bug.cgi?id=108787


-> It would help if you could verify what's the perf gap between release 
and debug builds, and provide numbers for both (preferably each time 
there are significant code changes).

Just using release builds should be simpler though (unless your 
intention actually is investigating why debug code is slow).


	- Eero