[cairo] [PATCH, pixman] Eliminate fast path flags

[Soeren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> > Yeah, we should probably at have at least two CRC32 values, one for
> > the 2 million case, and one for a 100 million case that could run
> > overnight.
> >
> > It might also be interesting to have many more than two values, and
> > store them in a table where each row would contain both CRC and seed
> > for 2 million iterations, for 4 million, for 6 million and so on.
> >
> > The test could then pick a range to run at random, which would
> > substantially increase the coverage.
> 
> The problem is that performance of different systems may vary a lot, so 100
> millions may be fine for one system, but too much for the other. 

I am saying that there would be a table like this:

        { <seed>, <crc value> },      /* after 1000000 iterations */
        { <seed>, <crc value> },      /* after 2000000 iterations */
        { <seed>, <crc value> },      /* after 3000000 iterations */
        { <seed>, <crc value> },      /* after 4000000 iterations */
        { ... },

and so on. The test suite could then do these things:

(1) It could pick a random number k between 0 and 99 (with a seed of
current time), then run that range of tests, using the seed and CRC
from row[k-1] as the starting seeds and CRCs.

After running those 1000000 iterations it would compare the crc value
to the one in in row[k] and fail the test if they didn't match. (It
could also compare the seed values and complain that the test table
itself was broken).

(2) It could repeat (1) until you stopped it

(3) It could run all 100 tests.

I think this would substantially increase the coverage from the
test. Of course, maybe 100 is not the right number.

> For modern systems it probably also makes sense to add multithreading
> support to the test so that it can utilize all the available CPU
> cores.

Agreed.



Soren