<div dir="ltr">What did you do (besides verifying that the tests pass) to ensure that the generated result is equivalent to the previous generator?  Have you verified that they generate basically the same code?<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 3:45 PM, Dylan Baker <span dir="ltr"><<a href="mailto:baker.dylan.c@gmail.com" target="_blank">baker.dylan.c@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This rather lengthy series takes a strong stab at cleaning up the python<br>
generators, particularly the OpenGL generators, with the exception of<br>
the generators that rely on the builtin_function.py and<br>
builtin_funciton_fp64.py (I have another series underway to deal with<br>
those, but one thing at a time).<br>
<br>
There are 4 goals for each generator in this series:<br>
1) Use mako:<br>
   There on generator (gen_interpolation_tests) that didn't use mako<br>
   before this series. There are also several generators that nominally<br>
   use mako, but don't take advantage of it's features, instead relying<br>
   on python functions and blocks when mako is better equipped to handle<br>
   the problem itself<br>
2) Make it fast:<br>
   Mako is faster than string concatenation, but there are also some<br>
   really stupid things going on in these generators. For example Some<br>
   of them loop over the same very large container several times when<br>
   they could be combined.<br>
3) Make it clean:<br>
   The style of these ranges from pretty good, to pretty bad. There is a<br>
   lot of C-in-python code here, and a lot of use of sub-optimal<br>
   functions, like range instead of xrange, dict.items() instead of<br>
   dict.iteritems(), etc<br>
4) Split the templates:<br>
   This both helps with speed and cleanliness. It makes it clean because<br>
   the templates don't clutter the python scripts, in some cases the<br>
   templates are as long as the script itself. It also means we can use<br>
   a module_directory, which will speed up rebuilds significantly.<br>
<br>
Finally, as a bonus, the last patch splits the generators targets for<br>
the generators so that the OpenGL and OpenCL generators aren't linked by<br>
default. This allows OpenGL developers and OpenCL developers to save<br>
time with generated tests they aren't going to run.<br>
<br>
Despite all of the work this ends up being a was for LOC, in 45 patches<br>
we gain ~100 lines.<br>
<br>
I noticed on my system ~2 second decrease for OpenGL test generation,<br>
and about a ~5 second decrease for OpenGL test regeneration (using<br>
cached templates)<br>
<br>
This is available at my github:<br>
<a href="https://github.com/dcbaker/piglit" target="_blank">https://github.com/dcbaker/piglit</a> submit/generator-cleanups<br>
<br>
_______________________________________________<br>
Piglit mailing list<br>
<a href="mailto:Piglit@lists.freedesktop.org">Piglit@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/piglit" target="_blank">http://lists.freedesktop.org/mailman/listinfo/piglit</a><br>
</blockquote></div><br></div></div></div></div>