obroadrick / imprecise Goto Github PK

• update test cases accordingly (to check for equal length for stages ie not plus 1)

We need to be able to explain how our scheduling framework works. We would need the following:

• Documentation of what problem our framework is trying to solve
• Diagrams of our framework and how they interact with the NN, the user and the GPU

• Send time table to scheduler
• Send precision table to scheduler
  API:

[]get_time_table(task t) //return range(0, t.task.length)
[]get_precision_table(task t) //return range(0, 100) (increment by t.task.length / 100) mess with later

• Setup NRL GPU machine

Client should send an array of tasks instead of just a single task

Oliver already wrote the scheduler. Once we get an API for that we should be able to integrate with the server/GPU.

• todo: check that equal deadline task sets get same optimal schedule
• check known tasks
• automated tests, not scripts with prints

We should think about how to show our algorithm is optimal.

For right now I think this means

• Deciding what client workloads would look like
• Code to actually profile the systems performance
• Who decides what is good performance, the server or the client? If it's the client we have to deal with the synchronous headache of having a process for each request 🙃
• Generations of data and visualizations
• What is optimal?

In order to simulate a NN we should do some GPU workload. Currently we are thinking of using different sizes of NxN matrix multiplication.

We should also narrow down how different sizes are treated as imprecise and what defined precision/error.

This kind of mistake is unacceptable!

"""Methods to describe how we will tasks will be ran by the GPU""".

Like who wrote this? Probably @obroadrick

• Give charles accsess to server

We wrote out the diagrams on the board, it would be nice to have them in a readable way online.

i.e make delta MAX_REWARD / 10 (or some variable dividend choice)

so add 'divisions' as an input and then compute delta accordingly

We need a better way to run benchmarks and develop.

We would need the following:

• Documentation about how to run our tests and benchmarks
• Make-files and automation to run tests and benchmarks

It would serve as good automation and help if we could have automation for installing CUDA on our benchmark machine. As well as the other python dependencies.

• this will remove our current assumption/expectation of the inputs already being sorted, which might be nice for the scheduler to be able to call this without that extra work of sorting

Use HTTP instead of sockets for client server communication