Motivation:
The authors of this paper were motivated to create a system
for offloading multi-threaded applications, without requiring program
modifications, to use multiple machines with dynamic thread migration dependent
on workload. The multiple machines they
are referring to are the server (high-powered machine) and the client (low-powered
cell phone or mobile device).
Main Points:
- Their system worked towards five primary goals:
- Require only program binary (no manual effort): in part this goal was to make the service useful for improving performance of ore-existing applications in the wild.
- Execute multi-threaded programs correctly
- Improve speed of computation – with a hopeful side benefit of reduced energy consumption due to heavy computations occurring on a server machine instead of a low-power client such as a cell phone.
- Resist network and server failures – controlled in part due to which methods are allowed to run on the server (restricting migration of native methods.)
- Generalize well with existing applications – Tested on several applications available in the wild on Google Play market.
- Through relying on synchronization techniques within DSM(merging changes between endpoints using a “happen-before” method for handling multiple dirtied fields) and VM (virtual heap, stacks, bytecode sources, class initialization states, and synthetic classes), they are able to keep the machine in a consistent state.
- Even with large initial state transfers, there are still performance gains and energy savings on low latency networks, and COMET makes the decision to exploit this opportunity, and does the inverse on high latency networks like 3G.
Trade-offs/Influence:
- Though the authors introduce COMET as a system to allow for unmodified multi-threaded applications to use multiple machines, they mention in the limitations that they have not found many applications that would benefit from their system stating that these applications have one or several of the following characteristics which do not utilize the benefits of the COMET system:
o
They do not rely on heavy computation.
o
They already have offloading logic. (Making the
use of COMET void)
o
The intensive portions of their program are
written in C which does not allow for easy testing with COMET.
I would be curious to know how
COMET’s task migration would compare between a base program with no offloading
logic and that same program with offloading logic. By this I am curious how COMET’s handling would
compare to a program containing the logic. If it was comparable, it could
potentially improve development time/energy, but if the reverse were true, a
more hands on development system might be something to investigate.
- The scheduling decision was not heavily focused upon, which is interesting since it is the center of determining when to migrate tasks. In their tests they mentioned that they could tune the τ for risk and potential benefit, yet they do not mention if they used the same τ for all tests or tweaked it from program to program.
- It is unclear, aside from scheduling – how COMET makes offloading decisions. It didn’t really seem like it had load balancing and simply used the τ to determine when to migrate a task. How can it choose between using migration on a low or high latency network?
Excellent analysis. It would be useful to compare a pre-baked remote execution vs. a more dynamic automatic method such as Maui or COMET. You are correct that the scheduling decision was not a focus of the paper -- they are focused much more on mechanism. They mention that heavy computation seems to be a requirement for offload, but I wonder if the ability to share in the cloud might provide additional benefits?
ReplyDelete