Anon (no@email.com) on 7/19/10 wrote:
---------------------------
>Linus Torvalds (torvalds@linux-foundation.org) on 7/19/10 wrote:
>---------------------------
>>Anon (no@email.com) on 7/19/10 wrote:
>>>
>>>Not mention media codecs, which I would suggest consume
>>>more of the world CPU cycles that many other more 'common'
>>>codes these days (if only because they dont just idle the
>>>cpu most of the time).
>>
>>Well, the well-behaved parts of media decoding are often
>>done largely by accelerators, because it's much more power-
>>efficient that way. And yes, those accelerators are often
>>fixed-function and largely in-order.
>>
>>But it does mean that there's much less nice core codec
>>kernels for the CPU, when things like scaling and YUV-RGB
>>conversion is done by the graphics pipeline. The higher
>>level decoding etc tends to be written in C, and is not
>>necessarily hand-tuned to the same degree.
>>
>>And because it runs on different micro-architectures, I
>>bet it all ends up preferring OoO execution cores. It's not
>>like things like the Atom made a good name for itself in
>>media decoding - quite the reverse.
>>
>>There's no question that you can't try to optimize media
>>codecs to hell and back on an in-order core. But it's a lot
>>of work, and the end result will definitely not run better
>>than on an OoO one.
>>
>>So I don't think media codecs are a good argument against
>>OoO. Except perhaps in the sense that you do want that
>>specialized graphics accelerator core (which tends to be
>>in-order and often have some fixed functions too).
>
>
>Sorry, I should have pointed out...
>I dont at all agree with the 'non-OoO is better for tight optimisation', I think thats rubbish.
>
>I was pointing at media kernels as places where very tight and careful optimisation
>is often done, and also where a good amount of real-world CPU cycles end up being spent.
>
>I suspect without OoO hiding a lot of latencies writing such kernels would be a
>lot harder (and require quite a few more magic pre-fetch and cache access instructions..).

The point is probably that with regular or quite well known memory access patterns, known cache structure, and minimal invalidations from outside sources, and at least a few instructions to do some prefetching. and a lot of time, then it _is_ possible to basically schedule instructions and fetches on an in-order core such that OOOE would not help much.

As soon as you start changing any of these parameters, the house of cards can get wobbly.

Profile driven optimizations and really good compilers can probably get a lot of the way there too, but they still fail when things change dynamically. Dynamic optimizing is really interesting and could get closer again, but I think at the low level when behaviour changes dynamically you can't beat OOOE.

Dynamic optimizing could probably be quite a big gain on OOOE CPUs as well though, by reducing icache footprint, function calls, branch mispredicts and so on.

>
>I've written enough DSP code to know that SSE, etal is a lot 'easier' for a target
>performance level, if not a lot easier to understand.
>
>I would say GPU code is easier that either, but ONLY because you can afford to
>make things VERY wide and leave quite a lot of cycles on the floor - and only if
>your application actually allows you to go that wide.... the good old horses for courses..
>
>I would say though that a LOT of people these days confuse low overhead (OS) and
>IO bound (database, a lot of webserver) code for compute code... its not EASY to
>saturate a modern CPU in a useful and efficient way.. it used to be a lot easier ;)
>
>Of course interpreted languages and deeply layered software stacks help with the
>job of soaking up CPU cycles nicely these days ;)
>