[MPlayer-dev-eng] Adding threaded functionality to mplayer NODAEMON

[D Richard Felker III]

On Mon, Sep 13, 2004 at 03:43:19PM +0200, Roberto Ragusa wrote:
> > And dont forget that RAM is slow compared to L2 cache.
> 
> Maybe words like speed and slow are ambigous, because they can refer to
> latency or bandwidth.
> I'd say that memory is very (latency)slow but not too (bandwidth)slow.
> 
> Reading 262144 bytes in random order from a hot 512KiB cache is a lot
> faster than doing that directly from memory, but maybe reading 262144
> bytes in sequence order from memory is not excessively slow compared
> to a read from cache.

this is utter nonsense. memory is slow in both senses. are you trying
to say a 100 mhz bus is as fast as a 500 mhz one? nowadays p4 and ath
have 266 mhz memory bus or something i think, but that's nowhere near
as fast as the cache which runs at cpu speed or sometimes half cpu
speed (think 2 ghz!).

> As a DVD frame is 622kB, at 25 fps we have 15MB/s which is not a
> significant part of the available RAM bandwidth.
> Estimating 15MB/s of writes from the decoder, 15MB/s of reads and 15MB/s
> of writes of one filter and 15 MB/s of reads to go to the video card
> we have "only" 60MB/s of highly sequential traffic. Today the RAM peak
> performance is measured in GB/s, right?

you can estimate all you want, but the performance impact is huge. why
don't you go run tests rather than making up theoretical numbers?
trying to guess based on bus bandwidth and cycle counts hasn't worked
since the 386...

> L2 cache is important for mpeg quantization tables and similar things,
> sure, but for raw streaming data?

yes, the _data_ is what it's important for!!

> Didn't hardware designers come up with instructions to read/write memory
> directly bypassing the cache, explicit prefetching...? It was said

rotfl! yes. we use them for writing the final picture to video memory,
but nothing else. in any other case, the picture will be read again so
it's very very stupid to bypass the cache.

> that it's better to keep code and tables in the cache than thrashing
> everything with pixels from a frame that will not fit entirely in the
> cache at last.

nonsense, that's not the choice you're making. the code and tables
will always stay there as long as they're used often enough, and even
if not, these are the _small_ parts that are inexpensive to reload.
the image data is _big_ and _expensive_ to reload from memory.

> A similar issue is debated on the kernel level; why should be try to
> cache gigabytes from VOB files during playing and discard all the
> things which can be useful in the future (libraries, config files,
> tmp files,...). See madvise(MADV_DONTNEED)

yes but alas the kernel developers are too stupid to make this
automatic (any linear read with no seeks should be considered for
"dontneed" status).

rich