Skip to content

Table

Jump to bottom
Yuzhen Huang edited this page Jan 16, 2018 · 12 revisions

Table

Table is served as the interface for fetching or processing parameters on the server side. The system consists of three kinds of tables: KVTable, KVClientTable, SparseKVClienTable. The first two tables have the same API and workflow:

  1. Get(keys, vals)
  2. Add(keys, vals)
  3. Clock()

A complete flow is like Get (optional) -> Add (optional) -> Clock -> next iteration.

KVClientTable

This is the first version of the client table in FlexPS. In this table, all Get messages are coordinated by one background thread: worker_helper_thread. Once worker_helper_thread receives the responses from the server side, it identities message and deliver it to the corresponding worker.

Use auto table = info.CreateKVClientTable<float>(kTableId); in the Task lambda to create the table.

Note that the return table is a unique_ptr pointing to the client table.

Details (can be skipped)

The constructor is as follow:

KVClientTable(app_thread_id, model_id, send_queue, range_manager, callback_runner)

app_thead_id is an identity for the worker using this table; model_id is an identity for model on the server side; send_queue is a threadsafe queue used to send message, usually all workers in one node share on one queue; range_manager is manager to coordinate the partition strategy of the parameter; callback_runner is an intermediator between KVClientTable and worker_helper_thread

KVTable

Actually, in most scenario, the background thread (worker_helper_thread) is redundant. So a more clean and less-dependent version of KVClientable, KVTable, is released. In KVTable, each worker maintains its only send queue and receive queue. The responses are delivered directly to worker side. The constructor for this KVTable is a little different from previous one: KVTable(app_thread_id, model_id, send_queue, range_manager, mailbox)

The only difference is that KVTable doesn’t need callback_runner anymore, which is replaced by a mailbox used among the whole program.

Use auto table = info.CreateKVTable<float>(kTableId); in the Task lambda to create the table.

KVTable is the recommended one.

KVTable makes the relationship between workers and servers much simpler and should be a better example for learning PS architecture. While KVClientTable with worker_helper_thread provides more opportunity when we later implement process cache on FlexPS.

KVChunkTable

Both KVClientTable and SimpleKVTable are enhanced to KVTable which supports chunk based get and add. The constructor for these two tables are indentical to previous two except the class name. These two table has two more API to support chunk operation:

  1. GetChunk(chunk_keys, vector<chunk>)
  2. AddChunk(chunk_keys, vector<chunk*>)

What need to pay attetion is that the ChunkTable supports chunk-based API and normal API in the same time. When you use chunk API, the keys you provide is chunk_id, otherwise, you need to provide global key_id.

SparseKVClientTable

SparseKVClientTable is specially designed for experimenting the SparseSSP protocol and it should be used together with SparseSSPModel in the server side. Users do not need to call Clock testing with SparseSSP and it is called by internally by the Get function since it has a much stricter constraint. The workload for it is Get (required) -> Add (optional) -> Get (optional) ->... The detail of SparseSSP will be introduced in other wiki.

Clone this wiki locally