Look into parallelized/pipelined instructions

[paultag]

Currently, when we execute KCL, we send a command-at-a-time, wait for the response and continue. This is because of a variety of complexities, including the one where UUIDs are minted server-side, not client-side, so we we need to wait for a return before we can continue with dependent operations.

There's a few ways out of this, but the two I see are:

1. Work through an architectural overhaul where the client mints IDs. This will be tough for operations that produce new surfaces, since it won't be obvious to the client (for instance, if I draw a box and extrude, you need to how how many new surfaces that will create, and name each one in a way the engine can use). I think that may become prohibitively hard, but could be possible.

2. Start to represent command dependencies, such that for a given command, we can understand what command(s) need to complete (and get a response we parse) first.

This issue is about 2. I don't know how possible 1 will be.

If we can create a world where 2 is true (for a given command, we know what command UUIDs we depend on results from), we should be able to do a topological sort on the leafs. Here's a rough sketch:

• When the KCL executor is running, it'll produce as many modeling messages as it can and push them into the queue. It'll need some way to represent the dynamic information from the server (some sort of marker that represents "The UUID returned from the engine in response to this message")
• When messages are sent or received, preform some sort of lightweight topological sort on the command DAG.
  • Count the number of "inbound" dependencies to a task (things waiting to hear back about its response from the server).
  • If the number of any inbound dependencies to a node in the DAG is 0 (a "leaf"), send that message to the server without delay.
• When a message is received, update the messages in the queue by:
  • mark the message we just got a value back from as having had a response, noting any uuid(s) in response
  • remove its "outbound" dependencies in the DAG
  • sweep the DAG for new leaf tasks -- tasks without dependencies.

This would (hopefully!) allow us to split off unrelated components from the DAG, and run their tasks in parallel, so that we can render different (non-dependent) geometries at the same time.

Thoughts?

[jtran]

A very similar idea came up before when we were talking about the artifact graph, including topological sorting. But I forget what the motivation was. I think it was about adding other features, not performance, but I could be mistaken.

We do batch the sending of commands. Only certain commands force sending to the engine. So it's not quite as simple as a command-at-a-time anymore, but I agree that it could be better. extrude() is an example that forces sending.