Seeking feedback on possible Msc Thesis idea: Exploring the benefits of purely functional programming languages for mobile computation offloading
This might be slightly off-topic, but anyhow, in the hopes that anyone had any comments or ideas, I'm airing my idea for my Msc thesis project here – would be happy to hear if people think these ideas are infeasible or have any suggestions for better approaches. Also, I still only consider myself a novice in Haskell, so that'll be part of the journey, but I am confident in my ability to pick up things as needed.
The overall focus is on offloading code/computation for the purpose of lowering energy consumption on mobile devices.
Possible title: Exploring the benefits of purely functional programming languages for mobile computation offloading
The short version: I was interested in seeing if it was possible to tackle some of the obstacles which most offloading frameworks run into, with a) transferring state to the cloud and b) knowing what specifically can be offloaded (e.g. no UI code), by utilising the things that a purely functional language brings to the table by, amongst others, encoding I/O in the type system and referential transparency of pure functions, which simplifies a) and b) significantly.
The long version: While there exist several methods to approach offloading, transferring state still is one of the bigger problems, according to [J. Benedetto, et al]. This is, amongst other things, caused by the fact that so far the programming languages used to design these frameworks, are based on the principles of allowing side-effects (I/O, networking, shared state) everywhere in the program without limitations. In other words, it becomes hard to impossible to guarantee the code you want to offload has no effects elsewhere in the system, without advanced analyses of the code itself. Therefore these systems impose certain restrictions, mentioned in table 1, page 5 [L. Jiao, et al], where UI updates, local I/O and altercations of shared state is not allowed.
There are ways to circumvent some of the problems with shared state, by having a bidirectional transfer of memory, ala [C. Lin, H. Kung] (although they only did unidirectional, from the client to cloud) – but this increases the complexity significantly.
Haskell separates itself here by being a "pure functional programming language", in other words: things such I/O and other effects are modelled in the type system and you cannot by accident throw a print call into a normal function without indicating that it is doing I/O (a bit of a brief explanation, more detail can be read at [SOH]). This means function that prints a string does not simply have the type
print :: String but
print :: IO String. Changing global state is also considered a side-effect.
This means that we can know from a functions type if it is doing I/O or not. We can use this knowledge to know with certainty if a method can be offloaded or not. Furthermore we also get determinism, by referential transparency, which means we can cache the results of various function calls. It also becomes easier to transfer a functions "state", since in Haskell this corresponds to the functions input arguments.
The goal is then to make a framework/library or compiler extension, inspired a bit by Facebooks Haxl system [Haxl] (which is written in Haskell), which shares many of the ideas that would help energy savings, but also describes a way to, with very little effort, make the compiler do the tedious work of optimizing for performance without specifically incorporating it into the logic of the application itself. Haxl itself, in brief terms, allows for easy batching, caching and optimization of calls to external systems, such as databases.
[L. Jiao, et al] http://ift.tt/2ux10Dl
[J. Benedetto, et al] http://ift.tt/2v6gDim
[C. Lin, H. Kung] http://ift.tt/2uwXyIX
Submitted July 16, 2017 at 10:50AM by Tehnix
via reddit http://ift.tt/2ux6sGs