01Step
CONTEXTLogin & Hardware Context
Anchor every prediction and optimization to the real machine.
WHAT HAPPENS
User signs in to the SelfAware system UI
Hardware + core configuration is explicit (not abstract)
Start of flowStep 02
Compilation: translating a book into another language.SelfAware Compute: reorganizing the story so it flows better before the translation.
SelfAware Compute occurs before compilation. It analyzes a program's execution pathways, separates static and variable work, and restructures the execution model for optimal performance. The resulting code then compiles normally with standard toolchains.
TypicalC Code›Compiling›Machine Code
TALPsC Code›Analyzing›TALPs›Compiling›Machine Code
Compiler Optimization vs SelfAware Compute Optimization
Compilers optimize instructions. SelfAware optimizes execution pathways.
Typical compiler improvements
- Inlining
- Vectorization
- Loop unrolling
- Register allocation
SelfAware Compute Pipeline
Execution-structure optimization occurs before the compiler runs.
What SelfAware Compute does (high level)
- Identify execution pathways through control flow
- Separate static vs variable work
- Restructure the execution model for performance
Why "before machine code" matters
Because SelfAware Compute happens before machine code generation, it can optimize things that compilers usually can't see well:
- cross-function execution paths
- control-flow-driven parallel opportunities
- real runtime scaling behavior
- input-driven loop variation
Compiler focus
Make each step faster
Instruction-level improvements within a mostly fixed structure.
SelfAware Compute focus
Improve the execution structure
Optimize pathways, static vs variable work, and how execution is organized end-to-end.
Compilers usually optimize instructions. SelfAware optimizes execution structure.
Traditional build pipeline
Source Code ↓ Compiler ↓ Machine Code ↓ Execution
Standard compilation translates a given program structure into machine instructions and applies instruction-level optimizations.
With SelfAware Compute
Source Code ↓ SelfAware Compute (analysis + optimization) ↓ Transformed Code / Optimized Execution Model ↓ Compiler ↓ Machine Code ↓ Execution
SelfAware Compute adds an execution-structure optimization stage before compilation, while still compiling normally with standard toolchains.
Static vs variable work
SelfAware finds the parts of your program that must take about the same time every run, and the parts that grow/shrink depending on the input. Then it focuses optimization effort where it can move the needle.
This viewpoint is less about "adding threads" and more about understanding why runtime changes across inputs—then optimizing the parts that actually drive that change.
A SelfAware view separates time
A simple decomposition that helps explain real-world scaling.
Variable time
Time that changes because loop iterations change with input-variable attributes (how much work the input causes).
Static time
Everything else—work that stays about the same regardless of input size or shape.
Why this matters
If you only measure "total time," it’s hard to know what to fix. Splitting work into static vs variable helps you target the part that grows with input—where optimization produces the biggest gains.
Pathway-first optimization
Start with how the program actually executes, then optimize the pathways.
Pathway-first optimization
Source code ↓ Execution pathways (SelfAware) (branches become selectable paths) ↓ Static time vs Variable time ↓ Optimize what can move: - variable-time loops (partition / discretize work) - pathway-level scheduling choices ↓ Faster + lower energy + predictable outcomes
More than "parallelize the innermost loop"
The focus shifts from a local code fragment to an end-to-end execution pathway.
Traditional performance work often starts by finding a "hot loop" and applying local tactics like unrolling, vectorization, or a task framework. Those can help—but they usually treat the program’s control flow as fixed.
With SelfAware, the unit of optimization becomes the execution pathway (the concrete route your program takes through branches and calls). Once a pathway is identified, the variable work along that pathway is often dominated by loops whose iteration counts are driven by input properties.
What "manipulate loop bounds" means (plain-English)
- Identify loops whose work grows with the input (variable time).
- Represent their iteration ranges in terms of input-driven parameters.
- Use those ranges to partition / schedule work more effectively (instead of blindly "throwing threads" at a loop).
Why it's more than parallelism
Parallelism can be a result—structure optimization is the driver.
Why it's more than parallelism
Traditional view: ↓ Add threads ↓ [everything mixed together] SelfAware view: Optimize the pathway ↓ [Static time] + [Variable-time loops] ↓ Use input-driven loop ranges to partition / schedule work
"Hidden work" can behave like loops
Not all variable work is written as a clean for-loop.
Real applications spend time in places that don’t look like obvious loops in your source code. SelfAware calls out implied loops: work that repeats or scales with input, even if it isn’t expressed as a literal loop.
Memory allocation
Calls like malloc/calloc can scale with size and frequency—so their cost behaves like repeatable, input-driven work.
I/O operations
Reads/writes and scanning/parsing often scale with bytes, records, or input shape, acting like "loops over data."
Arithmetic forms
Some repeated arithmetic patterns can represent iterative work even when written compactly—again tied to input-driven size or complexity.
Framing these as "loop-like" work helps keep the same mental model: some costs are static, and others scale with input—even if the code doesn’t look like a loop.
Sensitivity analysis: isolate what input really matters
Define it once, then use it everywhere (charts, analytics, explanations).
Simple definition
SelfAware lets you hold all input attributes constant except one, so you can see exactly how that one variable affects runtime, memory, or output — making behavior measurable and explainable.
Why sensitivity analysis helps
- Answers: "Which knob actually changes performance?"
- Avoids guessing when many inputs change at once.
- Makes scaling behavior explainable (and predictable).
Sensitivity overlay
SelfAware (one execution pathway)
+----------------------------------+
| same code blocks & loop structure|
+----------------------------------+
↑ ↑ ↑
Input(x) Input(y) Input(z)
(vary x only) (vary y only) (vary z only)
=> sensitivity: which input drives time/space/output mostTrust and transparency
The SelfAware Compute process flow explicitly compares the changed "optimized" code against the original and emphasizes that it shows what changed, side-by-side in the UI.
visible changes•removed paths
Before (original)
read-only
int total = 0;
for (int i = 0; i < n; i++) {
if (a[i] > 0) {
total += heavy(a[i]);
} else {
total += light(a[i]);
}
}
return total;
After (SelfAware Compute-optimized)
diff highlights
int total = 0;
+// Extracted execution pathways (positive vs non-positive)
+Path p = (a[i] > 0) ? PATH_POS : PATH_NONPOS;
for (int i = 0; i < n; i++) {
- if (a[i] > 0) {
- total += heavy(a[i]);
- } else {
- total += light(a[i]);
- }
+ total += (p == PATH_POS) ? heavy(a[i]) : light(a[i]);
+ // Loop work can be parameterized by input-driven bounds
+ // (e.g., range splitting, staged execution, or other scheduling)
}
return total;
Note: This is an illustrative diff-style view for communication and UI trust. It conveys "what changed" without requiring developers to interpret opaque compiler output.
Predicted Performance
See the tradeoffs before you run.
SelfAware generates time, energy, and memory predictions from real profiling runs — so you can choose the right core count for your goal before committing compute.
Time Analysis
core (count)
Parallel Time Run
SelfAware separates static and variable execution time. Only variable-time work is parallelized across cores, producing a predicted time curve with realistic scaling behavior.
Space Analysis
core (count)
Parallel Space Run
SelfAware's predicted memory footprint stays flat as core count increases — parallel execution doesn't require extra memory for the same workload.
Energy Analysis
core (count)
Serial Energy Run
Total energy is predicted from power × time. Even as power rises with more cores, faster completion reduces overall energy — enabling an explicit energy-minimizing operating point.
Power Analysis
core (count)
Parallel Power Run
Power increases stepwise as more processing elements activate. SelfAware combines this with the time curve to optimize total energy, not just instantaneous watts.
Speedup Analysis
core (count)
Time Efficiency
Speedup is the predicted performance multiplier (T1/Tcore). Gains taper naturally as static work and overhead dominate — showing realistic, production-grade behavior.
Free-up Analysis
core (count)
Space Efficiency
Free-up measures how memory allocation changes with parallelism. A flat line means SelfAware keeps the same memory footprint while improving time and energy.
Power-up Analysis
core (count)
Power-up
Power-up shows normalized power behavior as cores increase. Stepwise changes reflect real system efficiency thresholds — and help explain where energy savings come from.
Green-up Analysis
core (count)
Green-up
Green-up is the energy-efficiency multiplier (E1/Ecore). Higher is better: you use less energy to complete the same workload as parallelism increases.
TECHNOLOGY
SelfAware Compute Demo Flow
A canonical walkthrough: import code safely, decompose into real execution pathways, generate predictive analytics, then transparently parallelize and execute toward explicit goals.
Next →
02Step
TRUSTRepo Import (Clone-Only)
Safety + auditability: work happens on a cloned artifact.
WHAT HAPPENS
Select repo item + dataset + output artifact name
Original source is not mutated
Follows step 01Step 03
03Step
DISCOVERYAuto Decomposition & Profiling
Turn 'code' into selectable execution pathways + real measurements.
WHAT HAPPENS
Functional decomposition + call structure
Runs: serial, standard parallel, persistent parallel
Dataset variables + ranges are characterized
Follows step 02Step 04
04Step
PREDICTIONPredictive Model Generation
Predict behavior before spending compute.
WHAT HAPPENS
Predict time + space for specific input ranges
Extend to energy/cost/carbon accounting
Follows step 03Step 05
05Step
TRANSPARENCYTransparent Source Diff
Nothing is hidden—every change is inspectable.
WHAT HAPPENS
Side-by-side original vs SelfAware Compute-augmented source
Visual highlight of changed vs unchanged logic
Follows step 04Step 06
06Step
STRUCTUREFunctional Decomposition + Complexity
Structure drives parallelism; complexity surfaces hotspots.
WHAT HAPPENS
Function tree + cyclomatic complexity annotations
Guides where parallel structure is most valuable
Follows step 05Step 07
07Step
PATHWAYSSelfAware Decomposition (Execution Pathways)
Programs don’t run ‘the code’—they run one pathway.
WHAT HAPPENS
Select a SelfAware pathway explicitly
See exact blocks, order, and variables on that path
Follows step 06Step 08
08Step
VALIDATIONInput Variable Analysis & Test Generation
Ranges → cases → correctness + scaling behavior checks.
WHAT HAPPENS
Track pathway-driving input attributes
Auto-generate tests across valid ranges
Follows step 07Step 09
09Step
CONTROLGoal-Driven Execution
Optimize toward performance or energy.
WHAT HAPPENS
User selects goal + constraints (e.g., max cores)
System chooses core count (not always 'max')
Run + report deltas (time/energy/cost)
Follows step 08End
KEY IDEA
SelfAware makes execution pathways explicit, generates predictive analytics from real runs, and uses those predictions to choose parallel strategies and resource levels aligned to performance or sustainability goals.
Technology
SelfAware explains how software actually executes — then optimizes the execution pathways that matter.
Most optimization tools make individual instructions faster. SelfAware works one level higher. It analyzes execution pathways, identifies which parts of runtime are fixed and which change with the input, and then restructures execution so performance, predictability, and energy efficiency improve together.
Before compilation
Source Code
↓
SelfAware Compute
execution pathways • static vs variable • restructuring
↓
Optimized execution model
↓
Compiler
↓
Machine Code
SelfAware Compute happens before standard compilation, so it can optimize execution structure rather than only optimizing the instructions produced from an already-fixed structure.
Compiler Optimization vs SelfAware Compute Optimization
Compilers optimize instructions. SelfAware optimizes execution pathways.
A compiler is excellent at making a given structure more efficient. SelfAware addresses a different question: is the execution structure itself the right one for the workload, the input, and the target environment?
Traditional Compiler Focus
Make each step faster
Inlining, vectorization, loop unrolling, and register allocation all help inside a mostly fixed program shape.
SelfAware Compute Focus
Improve the execution structure
SelfAware optimizes pathways, identifies the work that drives runtime, and reorganizes execution end-to-end for better scaling and lower waste.
Static vs Variable Work
SelfAware separates the time that stays constant from the time that moves with the input.
That distinction matters because optimization effort should go where it can actually change outcomes. If you only look at total runtime, you know a program is slow. If you separate static and variable time, you know why.
Static Time
Work that stays about the same every run
Static time is the part of execution that does not materially change with the input. Setup work, fixed control logic, and loops whose bounds do not vary with the input all tend to live here.
Variable Time
Work that grows or shrinks with the input
Variable time is the part of execution that changes because input attributes change loop iterations, recursion depth, memory activity, parsing effort, or other repeatable work. This is where runtime really moves.
Pathway-first optimization
Source code
↓
Execution pathways (SelfAware)
↓
Static time vs Variable time
↓
Optimize variable-time work and scheduling choices
↓
Faster + lower energy + more predictable outcomes
This is more than "parallelize the innermost loop."
SelfAware shifts the unit of optimization from a local code fragment to the complete execution pathway the program takes through branches, calls, and loop structures.
- Traditional optimization often starts by improving a local hot loop.
- SelfAware starts with the full execution pathway the program actually takes.
- That makes it possible to understand end-to-end runtime behavior instead of just improving isolated fragments.
- Once the pathway is clear, optimization can focus on the variable work that actually determines runtime, energy use, and scaling.
How SelfAware improves common understanding
Sensitivity analysis: isolate which input actually matters.
SelfAware lets you hold all other input attributes constant and vary one at a time, so you can see exactly how that variable affects runtime, memory, or output.
- Hold everything else constant and vary one input attribute at a time.
- See exactly which input knob changes runtime, memory, or output.
- Turn multi-variable behavior into something explainable, measurable, and predictable.
- Make charts and analytics easier for non-specialists to understand while still being rigorous enough for technical readers.
Sensitivity Overlay
SelfAware (one execution pathway)
same code blocks • same loop structure
Input(x)
vary x only
Input(y)
vary y only
Input(z)
vary z only
Result: sensitivity analysis that shows which inputs drive time, space, and output most.
Hidden work
Not all variable work looks like a clean loop in the source code.
Real software spends time in places that hide scaling behavior. SelfAware surfaces that hidden work so runtime is modeled honestly, not optimistically.
Memory Allocation
Allocation can behave like repeated work
Calls such as malloc or calloc may not look like loops in source code, but their cost still scales with the amount and frequency of allocation. SelfAware treats that as execution work that should be modeled, not ignored.
I/O Operations
Input and output often scale like loops over data
Reading, writing, scanning, and parsing all grow with bytes, records, and input shape. That means they can drive runtime in the same way visible loops do.
Compact Arithmetic
Some concise expressions still represent repeated effort
Certain mathematical or structural patterns hide iterative behavior behind clean syntax. SelfAware surfaces that hidden cost so runtime is modeled honestly.
Why this matters
SelfAware makes software behavior explainable before it becomes expensive.
The value of SelfAware is not just that it can uncover safe parallelism. It is that it provides a way to understand what code will execute, which input attributes drive runtime, how scaling will behave, and where optimization effort will actually move the needle.
For general audiences
SelfAware explains why execution time changes and which inputs are responsible.
For technologists
SelfAware exposes pathway-level structure, variable-time work, and input-driven scaling behavior that compilers rarely model directly.