Accéder au contenu.
Menu Sympa

starpu-devel - [Starpu-devel] StarPU Library Instances

Objet : Developers list for StarPU

Archives de la liste

[Starpu-devel] StarPU Library Instances


Chronologique Discussions 
  • From: Jeff Hand <jeffrey.hand@gmail.com>
  • To: raymond.namyst@labri.fr
  • Subject: [Starpu-devel] StarPU Library Instances
  • Date: Thu, 9 Oct 2014 16:39:15 -0500
  • List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel/>
  • List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
  • Resent-date: Sat, 11 Oct 2014 12:53:12 +0200
  • Resent-from: Raymond Namyst <Raymond.Namyst@labri.fr>
  • Resent-message-id: <20141011105313.7021B9E0@iona.labri.fr>
  • Resent-to: "starpu-devel@lists.gforge.inria.fr" <starpu-devel@lists.gforge.inria.fr>

Dr Namyst,

We have been experimenting with heterogeneous computing using StarPU.

My investigation points include:
1. C++ to C interface for StarPU
- Looked at SkePU and decided based off our requirements, we will have to create our own.
2. Performance profiling between OpenCL, CPU, and SSE.
- Done some testing, currently interested what it will look like at scale.
3. Dynamically adding and removing computation blocks with as little disruption as possible to other computation blocks.
- Currently my main focus.
4. Performance profiling using our existing OpenCL and CPU based solutions using extreme and real world situations.
5. Performance profiling between n-CPU and n-GPU configurations.
6. Investigate MPI


How do I sample multiple input sources, run it through dynamic number of computing blocks streams, and maintain different configurations for computing blocks with minimal disruptions to other streams? 

-- Option 1 --
Create a monolithic StarPU program task hierarchy that samples the input sources, maintains the streams, and maintains the configurations of the different computing blocks.  All within one process or thread.  This is how almost all examples I have seen work.

Pros:
- deals with multiple contexts, schedules, and priorities for everything.
- Likely easier to tell if the hardware is over tasked to complete "real time" work.

Cons:
- This sounds difficult to troubleshoot and maintain given the complexity as scale increases.
- If the process dies, everything dies.
- Possibly adding/removing/modifying a block could interfere with other parts of the system (dropping samples, accumulating too many samples, etc).  Adding/removing/modifying a block may be fast enough it would be seamless.
- etc


-- Option 2 --
Create a StarPU program that sample a input source, maintains the stream, and maintains the configurations of the different computing blocks.  Simply have forked processes/threads per stream.  Perhaps we have to create per thread/task a implementation of starpu (starpu_init, register_data, task_submit, task_wait, etc).

Pros:
- Simplifies the coding blocks per stream.
- Streams shouldn't interfere with each other assuming enough computational resources

Cons:
- Is this even possible?  I have run multiple applications at the same time.  Based off that, I think it might be possible for multiple threads/processes.
- Likely disturbs calibration and task priorities for starpu.
- probably less efficient, but may be worth it depending on the impact.
- etc

-- Option 3 --
Create a StarPU program that sample a input source, maintains the stream, and maintains the configurations of the different computing blocks.  Simply have forked processes/threads per stream.  Perhaps we have to create per thread/task a to deal with the tasks (task_submit and starpu_wait_all).

Pros:
- Simplifies the coding blocks per stream.
- Streams shouldn't interfere with each other assuming enough computational resources

Cons:
- Is this even possible?  I have run multiple applications at the same time.  Based off that, I think it might be possible for multiple threads/processes.
- Likely disturbs calibration and task priorities for starpu.
- probably less efficient, but may be worth it depending on the impact.
- etc

-- Option 4 --
Create StarPU programs that sample a input source, maintains the stream, and maintains the configurations of the different computing blocks.  Create multiple programs that implement each stream.

Pros:
- Simplifies the coding blocks per stream.
- Streams shouldn't interfere with each other assuming enough computational resources

Cons:
- Is this even possible?  I have run multiple applications at the same time.  Based off that, it seems feasible.
- Likely disturbs calibration and task priorities for starpu.
- probably less efficient, but may be worth it depending on the impact.
- etc

Any guidance you could provide would be greatly appreciated!

thanks,
Jeff





Archives gérées par MHonArc 2.6.19+.

Haut de le page