Log in

View Full Version : question regarding x264 integer operations


deadrats
19th November 2012, 04:58
this is a question for one of the x264 developers, i recall DS stating in another thread that x264 doesn't use 32 bit int operations, that most of the ints are 8 bit and 16 bit at the most, with the rational being that pixels are 8 bit entities to begin with.

i ran across the following optimization guide from amd with regards to writing code to maximize performance on bulldozer cpu's and under section 3.19 "integral data types" it says the following:

*******************
Optimization

Use 32-bit integers instead of smaller sized integers (16-bit or 8-bit).

Application

This optimization applies to:

• 32-bit software

• 64-bit software

Rationale

When choosing between 32-bit, 16-bit and 8-bit data types in cases where memory footprint is not a concern, using 32-bit integer types in 32-bit software (32-bit or 64-bit integer types in 64-bit software) avoids possible register-merging false dependencies due to partial register writes. See
section 5.5, "Partial-Register Writes" on page 84 for details.

http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf
****************************

i was just interested in seeing what the x264 developers think of amd's suggestion, in another section amd suggests:

3.2 Using Arrays and Pointers

Optimization

Use array notation instead of pointer notation when working with arrays.

Application

This optimization applies to:

• 32-bit software

• 64-bit software

Rationale

C allows the use of either the array operator ( []) or pointers to access the elements of an array. However, the use of pointers in C makes work difficult for optimizers in C compilers. Without
detailed and aggressive pointer analysis, the compiler has to assume that writes through a pointer can write to any location in memory, including storage allocated to other variables. (For example, *p and *q can refer to the same memory location, while x[0] and x[2] cannot.) Pointers make it difficult for
compilers to detect the presence or absence of aliasing—with possible ambiguous access to a block of memory. The compiler sometimes must assume aliasing in the presence of pointers, which limits the opportunities for optimization. Array notation makes the task of the optimizer easier by reducing
possible aliasing.

i guess i was just wondering if you avoid these pitfalls by use of hand coded assembler, were you guys aware that amd makes these suggestions or does it not even apply to x264?

lil'jerry
19th November 2012, 05:14
It doesn't apply at all to the SIMD optimizations that x264 uses.

All that hint is saying is that unless you have a good reason not to that it is usually better to just use the native int width of the system. In the case of image processing it is better to use what matches the pixel data's size to pack more data in for the SIMD operations.

littlepox
26th November 2012, 12:34
AMD is always creating their own preference of optimization which differs from the Intel's and their old models' , especially for their new Bulldozer architecture. Developers do trouble a lot with optimization for Bulldozer: Do they really wish to change the basic level of implementation just for a supposedly failed Bulldozer architecture?

Nevertheless my own test suggests that x264 is doing quite well on the Bulldozer CPUs. A cheap FX8120p can run as quick as a i7 2600K, which only cost you a similar price to i5 3450