Are there any Avisynth filters that would benefit from a large L3 cache?

[JohnMK]

Hi there,

I am curious if there are any avisynth filters that would show an appreciable boost to performance with the presence of a large L3 cache such as present in the P4 Extreme Edition. If you know of any that don't cleanly fit within the L1 and L2 data caches of the Pentium 4, and that would probably fit well within the L1+L2+L3 caches of the P4 EE, please let me know, or feel at ease to theorize on any other tangential issues of this topic.

Thanks!

[kassandro]

A full resolution yv12 frame is about 600 kb. Thus even for a single frame filter with more than one pass a L2 cache of 512 kb is already insufficient. Now the unique advantage of Avisynth over other filter techniques is that it can operate on multiple frames. Any good deinterlacer needs at least two input frames and one output frame. Thus it needs already almost 2 Mb to avoid reloading. My RemoveDirt filter needs even 3 input frames and 1 output frame and has 3 passes. Thus a big cache would be quite useful. Also, if you use input frame n-1 and n for deinterlacing frame n you would like to keep input frame n in the cache also for deinterlacing frame n+1. Unfortunately, even if you would have a 2 Mb cache you must be very lucky to achieve this, because between deinterlacing frame n and n+1 other filters and the encoder will pollute the cache.
On the other hand, I thank that an optimal cache logic for the L1 cache is usúally much more important.

[vinks]

i was always under the impression that the L1 cache on the p4's were not real L1 as such, its just 8kb of trace cache, which isnt very useful compared to the L1 on the amd chips? unless intel decided to put some real L1 onto the p4 ee chip.

[JohnMK]

Every L1 cache since at least the 386 has two functions: data caching and instruction caching. The P4 has 8kb of L1 data cache, and a 12k micro-op instruction cache (which is something entirely new, I'm not sure of its merits or demerits). Thus the P4 does indeed have data cache in the same fashion as other CPUs; it's very tiny, but very efficient by virtue of its low latency, and other reasons that I'm not aware of.

[bill_baroud]

The trace-cache is here to reduce the effect of an unpredicted branching in the large p4 pipeline. It stocks here decoded instructions in case of if it need them, it doesn't have to re-fetch and re-decode them.

And for the tiny data cache, it's because p4 cache are inclusive type (L2 contain L1 data) so if it's big, you loose some time to copy data to keep them in synch, but at the advantage that is not a complex operation, unlike exclusive cache type (AMD one). So p4 keep his L1 cache very tiny but damn fast (about 60Gb/s)

[vinks]

the inclusive design of the p4's L1 and L2 is a good idea alright, its probably a good idea for most applications, but it's not as useful for computationally intensive apps with large data sets, well it makes it a little bit more work to write code to take advantage of the "fast" L1 on the p4.

i dont have much experience in video processing programming, but in scientific applications, you'd take the approach of moving just enough data into L1/L2 and work on the data as much as possible before throwing the answer out, so having a larger L1 would help alot. i presume the same approach is taken in most avisynth filters, perhaps looking at some dgemm code would be of interest, and things like the straussen multiply algorithm might interest people reading this thread.

[JohnMK]

If I'm not mistaken, shouldn't the compiler do that automatically, for the programmer?

[vinks]

unfortunately when you do something like this


/* the matrix operation c = c - a*b */
for (i = 0; i < M; i++) {
for (j = 0; j < N; j++) {
for (k = 0; k < K; k++) {
c[i][j] -= a[i][k] * b[k][j];
}
}
}


which most people would probably do naturally, is just plain inefficient. a compiler would give a modest speed boost, but code like this is typically less than 1% efficient for a modest matrix size 256x256 in size, actually you'd be lucky to get even half a percent efficiency with the above code on any cpu.