SuperSonic.utils¶

SuperSonic uses A TaskEngine to call run() to deployment specific policy to

objective task.

A Halide, to start agent and environment. To apply a tuned RL, SuperSonic creates a session to apply a standard RL loop to optimize the input program by using the chosen RL exploration algorithms to select an action for a given state. Using stoke_rl, to register a RL environment.

SuperSonic Tasks Policy Search:

TaskEngine
Optimizing Image Pipelines
Neural Network Code Generation Reduction
Code Size
Superoptimization
Optimizing Image Pipelines RL Environments
Neural Network Code Generation Reduction RL Environments
Code Size Reduction RL Environments
Superoptimization RL Environments

TaskEngine ¶

Optimizing Image Pipelines ¶

Neural Network Code Generation Reduction ¶

Code Size ¶

Superoptimization ¶

Optimizing Image Pipelines RL Environments ¶

class SuperSonic.utils.environments.Halide_env.halide_rl(env_config)[source]¶

A :class:: Halide is a domain-specific language and compiler for image processing pipelines (or graphs) with multiple computation stages. This task builds upon Halide version 10. Our evaluation uses ten Halide applications that have been heavily tested on the Halide compiler. We measure the execution time of each benchmark when processing three image datasets provided by the Halide benchmark suite. The benchmarks are optimized to run on a multi-core CPU.
Source:: This environment corresponds to the version of the Halide. (https://github.com/halide/Halide) paper link: https://people.csail.mit.edu/jrk/halide-pldi13.pdf
Observation:: Type: Box(100) Pipeline’s schedule will be convert to vectors by different embedding approaches, e.g. Word2vec, Doc2vec, CodeBert …
Actions:: Type: Discrete(4) Num Action Description 0 adding Adds an optimization to the stage. 1 removing Removes an optimization to the stage. 2 decreasing Decreases the value (by one) of an enabled parameterized option. 3 increasing Increases the value (by one) of an enabled parameterized option.
Reward:: In all cases, lower cost is better. We measure the execution time of each benchmark when processing three image datasets provided by the Halide benchmark suite.
Starting State:: All observations are assigned a uniform random value in [-1..1]

get_state()[source]¶

Returns actor state.

Returns: current environment and reward

init_from_env_config(env_config)[source]¶

Defines the reinforcement leaning environment. Initialise with an environment.

Parameters: env_config – including “state_function”, “action_function”, “reward_function”, “observation_space”

reset()[source]¶: reset the RL environment.

set_state(state)[source]¶

Set policy to specific state and action mask.

Parameters: state – Current reward and environments

:return

step(action)[source]¶

Take a step.

Parameters: action – An action, or a sequence of actions. When multiple actions are provided the observation and reward are returned after running all of the actions.
Returns: A tuple of observation, observation_mask, score, done, and info.

Neural Network Code Generation Reduction RL Environments ¶

Code Size Reduction RL Environments ¶

Superoptimization RL Environments ¶

class SuperSonic.utils.environments.Stoke_env.stoke_rl(env_config)[source]¶

A :class:: STOKE is a stochastic optimizer and program synthesizer for the x86-64 instruction set. This classical compiler optimization task finds a valid code sequence to maximize the performance of a loop-free sequence of instructions. Superoptimizaiton is an expensive optimization technique as the number of possible configurations grows exponentially as the instruction count to be optimized increases.
Source:: This environment corresponds to the version of the STOKE described by stanfordPL. (https://github.com/StanfordPL/stoke) paper link: https://raw.githubusercontent.com/StanfordPL/stoke/develop/docs/papers/asplos13.pdf
Observation:: Type: Box(100) Optimized code will be convert to vectors by different embedding approaches, e.g. Word2vec, Doc2vec, CodeBert …
Actions:: Type: Discrete(9) NUm Action Description 0 add_nops Adds one extra nop instruction into the rewrite. 1 delete Deletes one instruction at random. 2 instruction Replaces an instruction with another one chosen at random. 3 opcode Replaces an instruction’s opcode with a new one that takes operands of the same type. 4 operand Replaces an operand of one instruction with another. 5 rotate Formerly “resize”. Moves an instruction from one basic block to another, and shifts all the instructions in between. 6 local_swap Takes two instructions in the same basic block and swaps them. 7 global_swap Takes two instructions in the entire program and swaps them. 8 weighted Selects from among several other transforms at random.
Reward:: In all cases, lower cost is better. We combine the value of correctness with other values we want to optimize for. Name Description binsize The size (in bytes) of the assembled rewrite using the x64asm library. correctness How “correct” the rewrite’s output appears. Very configurable. size The number of instructions in the assembled rewrite. latency A poor-man’s estimate of the rewrite latency, in clock cycles, based on the per-opcode latency table in src/cost/tables. measured An estimate of running time by counting the number of instructions actually executed on the testcases. Good for loops and algorithmic improvements. sseavx Returns ‘1’ if both avx and sse instructions are used (this is usually bad!), and ‘0’ otherwise. Often used with a multiplier like correctness + 1000*sseavx nongoal Returns ‘1’ if the code (after minimization) is found to be equivalent to one in –non_goal. Can also be used with a multiplier.
Starting State:: All observations are assigned a uniform random value in [-1..1]