[Cbe-oss-dev] A couple of MARS questions

Kazunori Asayama asayama at sm.sony.co.jp
Mon Dec 1 14:19:45 EST 2008


tthompso at eecs.utk.edu wrote:
> I have a couple of questions regarding MARS and wasn’t too sure where to
> look or whom to ask, so I thought I’d start here and hopefully get a
> pointer or two.

Please use this ML.

> I came across MARS recently while researching the “library problem” with
> the Cell architecture – namely that creating libraries of independent
> components for the cell is difficult due to the problem of
> cooperating/competing for resources. MARS seems to be well aimed at that
> with its lightweight task switching model, but I haven’t been able to find
> much regarding the plans for MARS outside of the documentation and Geoff’s
> presentations. Is MARS targeted at becoming a library interface framework
> or mainly for application development? Why MARS as opposed to IBM’s ALF?

If I understand ALF correctly, ALF provides a framework to utilize SPEs
as accelerator easily. On the other hand, MARS is trying to provide an
environment that SPEs can play role of main processors (of course MARS
can also be used to implement accelerators). So MARS and ALF propose
different programming model and have different goals, I think.

> Next question, why the context unload/load on every yield? I understand
> the decision to make all blocking spu kernel calls yield to another task
> if it is ready, but throwing out the context every time seems like it
> would hurt for programs that are lock-step synchronized with the PPU (or
> another SPU). For instance, I wouldn’t expect the partial_context_save
> example program to do anything when the mpu task yields. If there aren’t
> any other programs waiting to run, why take the time and bandwidth to save
> context? Could you not do something like specify a processor affinity for

You are right. The description about mars_task_yield in the MARS
reference manual says "If there are no other tasks available to be
scheduled at the time of this function call, then this function has no
effect and will return immediately". So I think that is a bug of the
current implementation.

I know the current implementation has many inefficient parts like what
you pointed out. However MARS is still in development stage, so I
believe the problem will disappear while improving performance in the
future.

Thanks,
-- 
(ASAYAMA Kazunori
  (asayama at sm.sony.co.jp))
t



More information about the cbe-oss-dev mailing list