03:19 <siraben> Stacks and monoids on HN front page https://raphlinus.github.io/gpu/2020/09/05/stack-monoid.html

03:31 <siraben> Looks like there's a relevant paper too; https://dl.acm.org/doi/pdf/10.1145/3018882.3018891 . The idea seems to be turning imperative, sequential code into a map/reduce type of computation that can be parallelized.

03:32 <siraben> If you know that the partial results can be combined in a monoidial way (i.e. with an operation that is associative), then it makes sense that the order in which the partial results happen is independent.

03:36 <siraben> Oh, the paper is so much clearer than the blog post.

05:18 <proteusguy> siraben, definitely speaks in favor of stack oriented devices. Interesting. Have to dig into it and see if its something we can apply.

06:43 <proteusguy> siraben, seems like the biggest issue (which it often is) is getting the data segmented where it can actually be accessed in parallel faster than just sequentially going through it in a single process.

06:44 <siraben> proteusguy: Right. Hence the importance of the monoidial decomposition.

06:46 <proteusguy> How does that help you segment the data? I see if you can segment the data then you can apply this decomposition to it but it seems that segmenting the data is a pre-requisite.

06:50 <siraben> It's a precondition. The paper is about taking imperative sequential programs and rewriting them in an equivalent way of map/reduce form.

06:52 <siraben> I think the approach is more general than splitting data. Entire control structures can be rewritten as well.

06:52 <proteusguy> yes i understand what the paper is about - and it's an interesting approach. Now I'm talking about the challenges in being able to apply the paper in a real world situation.

06:57 <siraben> Sure. What challenges are you referring to?

07:00 <proteusguy> OK you have a large file on a drive in a computer. If you're critical path is the IO bus transfer speed of the drive, how do you use parallel processing to process the data any faster than a single process just iterating over the file? So the challenge is to identify scenarios where you can have the data in a format/location that allows you to apply the solution.

07:05 <siraben> Well parallel processing won't help you read the file faster so here you're I/O bound.

07:05 <siraben> If a large database is split across multiple servers, parallel processing would be very useful.

14:20 <WilhelmVonWeiner> Oh it's siraben

14:20 <siraben> hi WilhelmVonWeiner

14:20 <WilhelmVonWeiner> Long time no see, how's KnightOS

14:21 <siraben> You're on the KnightOS channel?

14:21 <WilhelmVonWeiner> I'm on the KnightOS channel?

14:21 <siraben> Haha, I mean what was I doing the last time we met?

14:21 <siraben> Because I happen to be doing some KnightOS related things now as well

14:22 <WilhelmVonWeiner> Not very sure. Last I remember you'd met a Forther at their office and you were sounding well smart. I thought KnightOS was your thing.

14:22 <siraben> Ah, not KnightOS but yeah I was tinkering with my TI-84+ calculator.

14:22 <siraben> Wrote a Forth on it that started up at boot

14:22 <siraben> github.com/siraben/zkeme80

14:22 <WilhelmVonWeiner> zkeme80

14:22 <WilhelmVonWeiner> that's what I was thinking of

14:22 <WilhelmVonWeiner> got them confused

14:23 <WilhelmVonWeiner> I went to put it on my TI but found it didn't work

14:23 <siraben> zkeme80?

14:23 <WilhelmVonWeiner> as in, the calculator, not the OS

14:23 <siraben> Oh the calculator

14:24 <siraben> Aww, batteries?

14:24 <WilhelmVonWeiner> Nope, I think it'd been dropped on it's head too many times

14:24 <siraben> That's unfortunate. There's an online emulator: https://www.cemetech.net/projects/jstified/

14:24 <siraben> I still haven't implemented a REPL yet, which was one of my plans. Maybe sometime this year or next I'll get to it.

14:25 <WilhelmVonWeiner> Haven't had much opportunity for Forth since finishing university.

14:26 <WilhelmVonWeiner> The only Forth-related idea I have is SIP processing hardware which loads configuration from flash, written in Forth.

14:33 <siraben> I think Forth will just remain a hobby for me, for systems programming definitely something like C++ or Rust with tooling will be better.

14:34 <WilhelmVonWeiner> Yes, I like Zig

15:37 <MrMobius> hmm, maybe I have shot myself in the foot

15:38 <MrMobius> I decided to put make a flag byte for each word that marks minimum number of stack items and whether it will add to the stack

15:39 <MrMobius> the dispatcher looks at the byte and does the checks to save space so each word doesnt waste space on checks

15:40 <MrMobius> now how do you implement ' ? you can return the address of the code but then there is no checking since that only happens in the token dispatcher

15:48 <MrMobius> so I could embed a 3 byte subroutine call instruction in the header before the flag byte and have ' return that address but that kind of defeats the space savings