freenode/#sicl - IRC Chatlog
Search
9:10:53
beach
So from looking around a bit, I see that a context switch for a traditional kernel-based operating system takes around a μs (order of magnitude).
9:13:23
beach
But recent Linux definitely can't do it without special kernel modules and other settings.
9:15:02
no-defun-allowed
I don't think Linux will immediately switch from the sound emitter to the mixer to the driver though.
9:16:08
no-defun-allowed
If a kernel/switching-based kernel could trace message passes like that and try to schedule the involved programs sequentially, it might be more lucky though.
9:17:08
no-defun-allowed
I think so, because the context switch might not immidiately run the message recipient.
9:18:20
no-defun-allowed
So, prioritising messages sent to mixers (which PulseAudio does, it has a nice level of -11) and/or jumping immediately into running the recipient process could lower latency.
9:18:57
no-defun-allowed
I imagine the second option might decrease throughput since the sender may have more to say, though.
9:20:59
beach
I am not sure that in a system like CLOSOS sender and receiver would have to be in different processor nor even threads.
9:21:48
no-defun-allowed
No, I don't think that would be needed either -- except for mixing sources though, yes.
9:22:39
no-defun-allowed
But the mixer->driver path could be eliminated, and the source->mixer path could be handled specially by the system hypothetically.
9:23:25
beach
... the scheduler in a traditional OS like Linux, would need to give each process hundreds of μs in order to minimize overhead due to context switches.
9:25:57
beach
So that kind of time slice already has a negative impact on sound synthesis. If there are several ready processes, then we are talking milliseconds, and that is dangerously near the tolerance level for sound.
9:27:18
beach
So each "process" (or rather "thread" in CLOSOS) could be given shorter time slices, thereby lowering response time.
9:27:56
no-defun-allowed
Yes, you could easily get more switches in if only normal registers have to be replaced.
9:28:23
beach
Therefore, even with a dumb scheduler, if there are few enough ready threads, there would be no problem with delays for sound synthesis.
9:29:23
|3b|
i think there are also issues with drivers blocking things in kernel for longer than you might want
9:29:43
no-defun-allowed
I remember there being a comparison of the speeds of various parts of context switches on osdev.org, but I can't find it now.
9:30:24
beach
And do we have reasons to believe that this problem would be less of one in a system like CLOSOS?
9:31:54
|3b|
i think a some of it is being fixed already, so wouldn't have to apply to closos, and some more is due to supporting lots of old/flaky hardware
9:34:53
beach
In half an hour, my lunch guests will arrive and I have to cook for them. So unfortunately, I need to suspend this discussion for several hours. :( Interesting stuff though.
10:58:41
luis
beach: right, Cleavir might be too heavy handed at this point. I'm not looking to have all editing commands operate on the CST/AST or anything like that. But definitely something to consider in the future. Shinmera's Staple seems promising.
11:04:24
Shinmera
Or rather: I leave it up to the user to install the apropriate extensions to Staple do work with it correctly.
11:05:41
Shinmera
Using an Eclector readtable that delegates to CL's current one on unknown reader macros could maybe, perhaps, work somewhat but I can see lots of ways for that to go wrong too.
11:06:46
luis
Shinmera: well, my first intuition was to copy user reader macros into the Eclector readable. That wouldn't very well once the reader macro calls CL:READ, for instance
11:07:42
Shinmera
You could work around that by just discarding the result or wrapping it in a way that marks it as ignored for the rest of the machinery.
11:11:35
luis
But, we might be able to instrument the cl:*readable* to delegate everything to Eclector.
11:14:52
luis
OK, I've got a rough plan, now all I need is some quality computer time. (I'm trying this on my phone right now. *sigh*) Thanks Shinmera and beach for the discussion.
11:54:27
|3b|
ACTION seems to need actual regalloc/lifetime/etc stuff in my android compiler now :( too easy to run out of 16 registers without any
12:06:46
|3b|
ACTION currently has a register allocator that just increments a counter when it sees a new variable, which worked for some trivial things, but starts to not be enough
12:07:24
|3b|
i theoretically have 64k 'registers', but some instructions can only use the first 16 or 256 of them
12:12:37
|3b|
maybe i can get away with just reserving some low registers for function calls and such that are limited to 16, and copy as needed