2024-12-25 01:38:47 yes, that's true about pipe organs 2024-12-25 01:40:10 KipIngram: the pipes are also long enough that it takes a significant time for the resonance to build up 2024-12-25 01:42:34 as for local echo, some terminals did support local echo and even local editing, while others didn't. The VT100 lineage we mostly emulate these days did not. But, for example, the IBM 3270 family would locally edit a whole form full of information, and then send the whole screenful of editable fields when you hit SEND, like a web browser 2024-12-25 01:43:58 the Datapoint 2200 was marketed as a terminal but ran arbitrary programs locally. HP also had some "terminals" like that in the later 70s 2024-12-25 01:45:48 whether and where to echo keystrokes was a huge issue throughout the 60s and 70s. one of the big advantages of the SDS 940 timesharing system for QED was that the connection was full duplex and so it was possible to disable local echo 2024-12-25 01:47:09 I should say the VT100 lineage *normally* did not. most terminals supported a half-duplex mode in which it was necessary to echo locally 2024-12-25 01:47:47 Tymnet in some sense dedicated most of their hardware to local echo if we count by transistors :) 2024-12-25 05:03:03 Yeah, I remember seeing old 3270 systems where your "enter" action basically would send a whole screen full of form data. 2024-12-25 08:51:59 Merry Christmas 2024-12-25 08:55:21 If your application is I/O-bound then the polyforth system is instant, as it did allow interrupts and would have been particularly low latency waiting for I/O 2024-12-25 08:56:20 It just seemed like it really underperformed with compute tasks, they were sleeping tasks willy nilly to get the latency down, so compute was much worse than it would have been with only one task 2024-12-25 08:57:02 Obviously this is down to the programmer, they can choose to have less sleeps and worse latency, and sometimes that's appropriate 2024-12-25 08:57:23 Not surprising that it was essentially down to the programmer, typical for Forth resource management! 2024-12-25 08:57:55 10ms latency in the 70's or 80's would be more like 10us today 2024-12-25 08:58:10 if that 2024-12-25 09:01:35 And also now we don't usually share a computer for gaming or music between many people 2024-12-25 10:30:54 Merry Christms veltas, and all you guys. How did polyForth handle multiple cores? 2024-12-25 10:32:06 I get impression they didn't 2024-12-25 10:32:34 I would consider extra cores a compute resource, and let you run dedicated stuff on different cores, because it's easiest implementation 2024-12-25 10:32:45 Although it doesn't match the I/O throughput of latest processors 2024-12-25 11:06:56 That would be my leaning as well, though I suppose I'd arrange SOME kind of default utilization that was just easy for the programmer to take control over if they wished. 2024-12-25 11:11:23 Regarding cooperative vs. interupt-based switching, I lean toward stradding the fence. I'd put a counter-based switch trigger in DOCOL. So while it would still ultimately be cooperative, that cooperation would be wired in so that it occurred "under the hood." I'd probably still offer a word that let the programmer invoke it explicitly if desired. 2024-12-25 11:11:53 I also considered having that in NEXT, but the code turns out to be more graceful if you put it in DOCOL. 2024-12-25 11:13:56 It would just march you around a circular list of threads; items would get moved into and out of that list as appropriate. Then a separate list for each core. 2024-12-25 20:26:28 KipIngram: I would call that mostly preemptive 2024-12-25 20:27:40 merry stackmas 2024-12-25 23:02:55 veltas: getting reliably low latency out of cooperative multitasking becomes difficult when systems get big 2024-12-25 23:03:43 latency hasn't gone down neatly as much since the 80s as throughput has gone up 2024-12-25 23:04:19 I don't think anybody ever ran polyForth on multiple cores 2024-12-25 23:06:03 KipIngram: what you are describing is preemptive multitasking, just implemented by having the interpreter check for a timer "interrupt" instead of having the hardware do it 2024-12-25 23:07:55 worst-case latency has acquired lots of new dimensions. code running slowly after a task switch because of cold instruction and data caches, cold branch predictors, etc. 2024-12-25 23:08:42 and even SDRAM worst-case latency is still almost 100ns. DRAM latency in the 80s was 300ns 2024-12-25 23:08:46 IIRC 2024-12-25 23:12:06 veltas: basically with cooperative multitasking any loop anywhere in the system whose number of iterations depends on the input becomes a threat to response time unless you can insert a yield into it, which introduces concurrency bugs 2024-12-25 23:24:03 What KipIngram suggested isn't fully preemptive because it's not entirely fool-proof, you can get in loops that won't ever be preempted 2024-12-25 23:25:21 You know an interesting counter-point, is cooperative is very sensitive to latency issues, but also makes it extremely easy to track down such issues 2024-12-25 23:26:05 Rather than going for a catch-all solution, I'm always interested in simpler versions that do 90-100% of what I actually want/need 2024-12-25 23:26:58 I'm not even sure cooperative threads is what I want, I've got an even simpler model in mind at the moment 2024-12-25 23:30:54 that's an interesting point 2024-12-25 23:57:58 mac os classic used to freeze a lot, but it also lacked memory protection