Review Binod Kumar (Roll No.

-143079023)

Strong points:

The paper proposes to achieve a higher single-thread performance by the use of an adaptive
asymmetric multicore system which involves a large number of lightweight cores and an
aggressive core shared among them. This is made possible through hint generation from
program distilling by a just-in-time compiler. Furthermore, the authors have presented an
application-specific predictor which can identify fruitful phases of program execution.
The most important contribution of this paper as compared to previous approaches is that it
does not rely on overclocking the aggressive core for performance enhancement and the
practice of register file checkpointing between two cores is not needed here.
Another strong point includes the concept of resynchronization to ensure that aggressive
core returns to a valid state and the idea of hint disabling mechanism which helps in
avoiding the occupancy of resources of the lightweight core with ineffective hints. In
addition, hint disabling makes sure that the aggressive core is stalled less often because the
queue (for transfer between aggressive and lightweight cores) fills up less often.
Experimental results indicate an appreciably high 35% better single thread performance for
all the threads running on the system compared to a chip multi-processor with all
lightweight cores. It also achieves almost 2X better throughput compared to a chip multi-
processor with all aggressive cores.

Weak points:

Execution assistance has been cleverly used for performance improvement in this paper.
However, it has some weak points. The success of this approach is dependent on the
workload (although the architecture is transparent to workload/OS) as the type of
instructions remaining after the program distillation varies from one type to another
workload type.
The authors claim that, Based on a pre-specified threshold value for the similarity between
access patterns, the lightweight core decides whether the cache hint should be disabled.
Since the access patterns vary from workload to workload, this threshold should also vary
for optimum results. A static threshold would essentially lead to ineffective hints (because of
disabling at some later instant than what should have been for that workload) being getting
used by the lightweight core.

Points of disagreement:

The resynchronization step (through which aggressive cores restores to a valid state) takes
help of the hint disabling information. There is no mention of identifying the potential
resynchronization policy. The authors suggest disabling of atleast two hints as such a policy.
However, this may lead to much frequent resynchronization, the overhead of which is
definitely not negligible (atleast hundreds of cycles).
The assumption that both types of cores run at the same frequency is not always valid.
Although authors claim that performance improvement can be acheived if lightweight cores
are allowed to operate at a higher frequency, they do not perform an analysis as to how
much performance can be enhanced with this and the instruction removal step (i.e., program
distillation) can be done in a less aggressive fashion due to this. It is relatively easier to run
the other type (lightweight) cores at a higher frequency via features of DVFS.
Suggestions for improvement:

To save the lightweight cores from being misled by unprofitable hints, the hint disabling
mechanism can be improved further by characterizing/identifying hints on a per workload
basis. For some workload, some kind of hints may be more useful than other.
The error in prediction of IPC with the regression-based predictor after using 100% of
benchmarks is 8% which is quite high. A different method of training/learning may help in
improvement in this.

Points which are not clear:

The back-off period( i.e., time for which hint remains disabled throughout)
calculation/estimation is not presented. In experimental results section too, this time-period
is not mentioned.
The idea of release window and age tag determines the right time for hint re-utilization.
However, the calculation of an optimum release window is not shown. It appears that a
fixed/static release window may not be always useful for all kind of workloads. Can this
calculation/estimation be performed in a dynamic manner?

Points to be discussed in class:

The larger window size results into more aggressive program distilling (i.e., instruction
removal) which leads to higher loss of accuracy. Hence, a relation should be developed
between the window size and the program distillation (by the compiler).
The design of the predictor (which predicts during which program execution phases a
lightweight core can benefit the most from the execution hints) is not elaborately explained
as to how it leads to a phase-based program pruning.