About CAT

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

2DaT wrote: Sat Apr 24, 2021 9:06 am
mystran wrote: Sat Apr 24, 2021 7:53 am edit: Well, the only other thing is that caches are set-associative (eg. 4-way or something) so if you have a large power-of-two stride then you might not be able to effectively utilize your whole L1 if all the cachelines you fetch map to the same set, but I don't really see how even this would matter when it comes to an API pushing around a few small buffers for an even smaller number of channels.
Even if data does not fit in L1, L2 is often fast enough to not bottleneck anything. Only a fraction of workloads can utilize the L1 bandwidth such as matrix multiplication or direct convolution - only in these workloads it makes sense to do L1 tiling (with appropriate SIMD). In any other case L2->L1 prefetch would get data faster than you can process it.
Well, the main point of the post was that cache efficiency is not about whether or not your access pattern is totally linear, but rather about whether or not you're making effective use of the bandwidth by utilizing full cache lines when fetch them to whatever level of cache.

One thing to take home about the set-associativity though is that if you have two aligned 64 byte (or whatever the cacheline size is) chunks of memory next to each other (eg. a single buffer of 128 bytes) then these two cachelines will never compete against each other, because being next to each other they map to different sets.

That said, tiling for a specific cache size can be dangerous anyway, because if the code then runs on a different CPU with a different specific cache layout and you rely on the layout too heavily you can get very poor performance as the result. Basically this only really makes sense if you're willing to tune for every different CPU separately (eg. FFTW style).

I'm personally more of a fan of "cache oblivious" design whenever possible, where you assume that the exact cache layout is unknown and try to build your code to be cache friendly for essentially any reasonable layout.. but even then it's not about having perfectly linear access patterns, but rather just about dense access patterns and good locality of reference.

Post

Whatever access pattern is used, at the limit of cacheline optimization is L1/L2/L3/L4 cache sizes. Prefetching, I don't know how well it works IF the memory is coming from RAM, but in all cases shouldn't it be the best case to be able to prefetch everything buffer related?

Just for example, a NxN matrix convolution, with acceptably large channel count, will absolutely kill almost any cacheline scheme due to buffer size. Prefetching is the only thing left to do when the dataset grows larger. That's why it's important to hold a cacheline as long as possible, it gives time for the prefetch to complete.

Temporal locality supersedes spacial, when the set outsizes the cache, but only because of prefetch.

Post

Hi Guys

I'd love to see it happen so here's my thoughts on this.

The files
Only one Header.h file is a good idea.
Header.h must be in pure C for maximum portability.
Ports to other languages that adhere to the standard can be done at a later time.

The Chicken and the egg :!:
The Host DAW and plugin code should be in the same Header.h.
Plug and host functions should be intimately related in the same file.
A plugin developer can probably just ignore the host functions.
A host developer can access both.
The final standard should include the Header.h and folders containing a simple example host. A simple example plugin and some very simple and clear documentation to get started.

Getting it organised :idea:
Set up a developer forum.

Users...
Anyone can be a casual viewer/commenter.
Moderators can ban members who post flaming or malicious comments designed to derail development.
Anyone can propose a suggestion as to what should be included in the standard.
Anyone can vote on a suggestion.
The most popular suggestions bubble to the top :wink:

Developers...
Any company or individual can join up to become a core Header.h developer.
Any suggestion >= say 75% in votes because you can't please everyone gets ratified by the core developers.
Once ratified the suggested code in the Header.h file is added by the core group of developers.
After some time the Header.h will stabilise into a viable standard.


...and finally, just for fun.
I nominate we call it CATS 'Community Audio Technology Standard'.
Because we all know that Cat's and Synths go together like carrots and peas.

Kirsty :)

Post

FYI there are a few promising projects out there as well - I know at least one that's pretty far. Curious to see what's happening :)

Post

Woah, what? I definitely missed something here! Is this an effort to make an open plugin format?

I scanned a couple of pages and didn't see any links, googling "Community Audio Technology github" didn't bring anything either?

Post

Mayae wrote: Thu Apr 29, 2021 4:00 pm Woah, what? I definitely missed something here! Is this an effort to make an open plugin format?

I scanned a couple of pages and didn't see any links, googling "Community Audio Technology github" didn't bring anything either?
i think, this should now be viewed in the context of this thread:

viewtopic.php?f=33&t=561545

on page 3, i have put a couple of links to this thread and its prequel and its sequel. they should probably be read/skimmed in the order i posted them there because that's the correct historical order (except for the first link). the gist of it is: lengthy discussions of the why and why not, and if so, how (which is actually an adequate thing to dicuss), eventually mystran posted a draft for an api header but now things are moving more into the direction of creating momentum for adoption of lv2, which i think, is the more realistic option anyway
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Music Engineer wrote: Thu Apr 29, 2021 11:12 pm
Mayae wrote: Thu Apr 29, 2021 4:00 pm Woah, what? I definitely missed something here! Is this an effort to make an open plugin format?

I scanned a couple of pages and didn't see any links, googling "Community Audio Technology github" didn't bring anything either?
i think, this should now be viewed in the context of this thread:

viewtopic.php?f=33&t=561545

on page 3, i have put a couple of links to this thread and its prequel and its sequel. they should probably be read/skimmed in the order i posted them there because that's the correct historical order (except for the first link). the gist of it is: lengthy discussions of the why and why not, and if so, how (which is actually an adequate thing to dicuss), eventually mystran posted a draft for an api header but now things are moving more into the direction of creating momentum for adoption of lv2, which i think, is the more realistic option anyway
Cheers, I'll have a look!

Post Reply

Return to “DSP and Plugin Development”