About CAT

[mystran]

but i tend to think, the timing was appropriate to bump this thread for other reasons

Also just in case there's confusion:

I have ZERO interest in trying to maintain any plugin API. I wrote a quick draft back then to see if it was just a problem of everybody being scared of being the first one to do something concrete, but that doesn't seem to be the case and it seems nobody actually wants to do anything concrete at all.

So let's keep discussing branding and irrelevant minutiae. That's the important part, right?

[Music Engineer]

I have ZERO interest in trying to maintain any plugin API.

sure, i don't mean to place that burden on you. i just think that in the context of that other thread, it's good to raise the overall awareness of the existence of your draft. especially in light of Urs' latest comments about creating a new standard. i think your draft is a good starting point for such a thing.

I wrote a quick draft back then to see if it was just a problem of everybody being scared of being the first one to do something concrete, but that doesn't seem to be the case and it seems nobody actually wants to do anything concrete at all.

i can only speak for myself and i can only say, that i didn't really feel qualified enough to do such a thing and was indeed a bit scared to embarrass myself. in fact, i was happy to see you to be the one to do it because i think, you are one of the best qualified people around here.

i also don't really have the impression, that no one wants to do anything. it rather seems to be the case that many people are pessimistic about the chances of success. and it seems to me that the lack of success could very well be a self-fulfilling prophecy. at least it's a sort of feedback loop. no one believes it to take off and therefore it doesn't take off and therefore no one believes... you get it. ...but the pressure seems to be mounting, so maybe that vicious cycle can finally be broken.

So let's keep discussing branding and irrelevant minutiae. That's the important part, right?

yeah...no! i was also a bit surprised how quickly the original thread was derailing into discussing gui and graphics stuff. this is supposed to be an audio api. first things first.

[mystran]

i can only speak for myself and i can only say, that i didn't really feel qualified enough to do such a thing and was indeed a bit scared to embarrass myself. in fact, i was happy to see you to be the one to do it because i think, you are one of the best qualified people around here.

That's the thing: I'm not qualified either. Nobody is. That's why you need different people with different fields of expertise to share their wisdom of how to handle different things, even if they don't know anything about some other thing.

[camsr]

Any real performance improvement over the current state of APIs is going to require tremendous effort. The more I think about it, the best solution is a generic, somewhat abstract, interface, which doesn't even assume implementation details. But as far as functionality goes, there is plenty to offer immediately.

[camsr]

About backwards compatibility, I do not embrace this idea. If it could be done, that's fine. Low priority as far as I'm concerned.

[camsr]

The data layout argument doesn't really fly. Random memory access is bad, sure.. but streaming for two buffers as opposed to just one doesn't make much of a practical difference, since the access pattern is still just as nice, straight through the memory.

Where it matters is when the value of one channel is being used to operate on a value in another channel. Interleaving could help speeds if that's the case. If there is just a collection of channels which don't interact, the best access pattern is usually sequential by samples in channel.

[Music Engineer]

The data layout argument doesn't really fly. Random memory access is bad, sure.. but streaming for two buffers as opposed to just one doesn't make much of a practical difference, since the access pattern is still just as nice, straight through the memory.

Where it matters is when the value of one channel is being used to operate on a value in another channel.

does it? i thought, we have just established that it doesn't

[Music Engineer]

About backwards compatibility, I do not embrace this idea. If it could be done, that's fine. Low priority as far as I'm concerned.

what do you mean? that a host compiled against a newer version of the api can load plugins that were compiled against and older version and vice versa? i think, that's super important! and a dispatcher/opcode system with return values indicating support of a particular feature/opcode would naturally provide that

[Music Engineer]

That's the thing: I'm not qualified either. Nobody is. That's why you need different people with different fields of expertise to share their wisdom of how to handle different things, even if they don't know anything about some other thing.

i think that's what civilization is all about. and that's why we are discussing these and other things here and elsewhere. nevertheless, someone has to make the first move. it was supposed to be a starting point, not the final thing. and as such, i think it's good and deserves serious consideration...although i can't really tell - again, because i'm not qualified enough. it's more a gut feeling. and i really like the no-frills, lightweight spirit of it. similar to vst 1 and 2 - and maybe even more so

[BertKoor]

Was there any mention already of xkcd 927?

[camsr]

The data layout argument doesn't really fly. Random memory access is bad, sure.. but streaming for two buffers as opposed to just one doesn't make much of a practical difference, since the access pattern is still just as nice, straight through the memory.

Where it matters is when the value of one channel is being used to operate on a value in another channel.

does it? i thought, we have just established that it doesn't

Yeah but most buffers are more than 1 cacheline. A fast piece of code will work with the same cacheline as much as possible, avoiding access to others as much as possible until the operations complete.

[mystran]

The data layout argument doesn't really fly. Random memory access is bad, sure.. but streaming for two buffers as opposed to just one doesn't make much of a practical difference, since the access pattern is still just as nice, straight through the memory.

Where it matters is when the value of one channel is being used to operate on a value in another channel.

does it? i thought, we have just established that it doesn't

Yeah but most buffers are more than 1 cacheline. A fast piece of code will work with the same cacheline as much as possible, avoiding access to others as much as possible until the operations complete.

No. Just no. You have at least a couple of kilobytes worth of L1 data cache, I guess around 16kB is typical, but it's kilobytes in any case. Fetching cache lines into L1 is the expensive part, but once it's there the access pattern doesn't matter anymore, until you touch enough other memory that your precious cache line gets thrown out of L1.

So if you have two buffers, you typically need to fetch 2 cache lines to read the first sample from each, but then you can read the full 64 bytes from each buffer in any order without additional penalty. So you spend twice as much time waiting for the data, but now you have twice as much data in the cache. Reading through each of these in sequential fashion might help the prefetch logic to figure out it should fetch the next cache lines in advance, but that's about it.

Seriously, it's complete waste of time to stress about a small number of buffers. What matters is that whatever you fetch into L1 is actually used completely (preferably before touching so much other memory that the cache lines get thrown out), so you don't waste time fetching 64 bytes just to read one byte out of it.

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.

[camsr]

Don't assume buffers are small, and channel counts are small There's also a stack using cachelines. And instructions.

[2DaT]

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.

[Urs]

Was there any mention already of xkcd 927?

I have sleepless nights over it

But the good thing is: VST2 is going away for good, leaving a sore gap for a format that is agreeable. So, while one standard is on its way out, another might put a foot in the door.