WO2018059897A1 - Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique - Google Patents

Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique Download PDF

Info

Publication number
WO2018059897A1
WO2018059897A1 PCT/EP2017/072376 EP2017072376W WO2018059897A1 WO 2018059897 A1 WO2018059897 A1 WO 2018059897A1 EP 2017072376 W EP2017072376 W EP 2017072376W WO 2018059897 A1 WO2018059897 A1 WO 2018059897A1
Authority
WO
WIPO (PCT)
Prior art keywords
instructions
core
specialized
hardware
execution
Prior art date
Application number
PCT/EP2017/072376
Other languages
English (en)
Inventor
Karim Ben Chehida
Paul-Antoine ARRAS
Original Assignee
Commissariat A L'energie Atomique Et Aux Energies Alternatives
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat A L'energie Atomique Et Aux Energies Alternatives filed Critical Commissariat A L'energie Atomique Et Aux Energies Alternatives
Priority to US16/333,974 priority Critical patent/US10846086B2/en
Priority to EP17761281.9A priority patent/EP3519954A1/fr
Publication of WO2018059897A1 publication Critical patent/WO2018059897A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/30156—Special purpose encoding of instructions, e.g. Gray coding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3228—Monitoring task completion, e.g. by use of idle timers, stop commands or wait commands
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • a computer-implemented method for managing computation tasks on a functionally asymmetric multi-core processor It also relates to a computer program product, a multi-core processor and a computer system for implementing such a method.
  • a multi-core processor may include one or more hardware extensions for accelerating specific software code portions.
  • these hardware extensions may include circuits for floating point computation or vector computation.
  • a multi-core processor is said to be "functionally asymmetric" when not all cores have the same hardware extensions, and therefore some extensions are missing from some processor cores.
  • a functionally asymmetric processor is characterized by unequal distribution (or association) of the extensions to the cores of processors.
  • the management of a functionally asymmetrical multi-core processor poses several technical problems, and notably that of efficiently managing the placement of calculation tasks on the various processor cores.
  • the invention aims to overcome, in all or at least in part, the aforementioned drawbacks of the prior art. More specifically, it aims to allow both optimal use of computing resources (especially in terms of energy) and compliance with QoS constraints. To do this, she perfected the approach proposed in A. Aminot's thesis.
  • any parameter representing the performance of the system can be used as a QoS constraint according to various embodiments of the invention.
  • the QoS of a calculation task can be defined as the execution speed (that is to say the inverse of the execution time) of said task.
  • the invention provides several improvements to the prior art, which can be implemented separately or in combination. In particular :
  • the management choices are made at key moments of the execution of each application, dynamically identified instead of being predefined, allowing the guarantee of QoS and minimizing the energy consumed.
  • Management choices are made taking into account an "opportunity cost" in QoS and energy of each execution option. This makes it possible to exactly quantify the difference in terms of performance with respect to a minimum QoS setpoint that we want to guarantee. A new method of calculating this opportunity cost is also proposed.
  • the invention also proposes, in a first characterization step, a method for selecting different classes of instructions according to their emulation costs in terms of performance and energy, making it possible to minimize the error in estimating the cost of opportunity of each opportunity (or "options") of management.
  • An object of the invention is a computer-implemented method for managing a computation task on a functionally asymmetric multi-core processor, the execution of said task comprising a succession of application periods, said processor comprising a plurality of cores sharing so-called basic instructions, at least one said heart comprising at least one hardware extension, said or each hardware extension being adapted to allow the execution of so-called specialized instructions, different from said basic instructions, each specialized instruction being thus associated to a said hardware extension, the method comprising the following steps:
  • Another object of the invention is a computer program product stored on a non-volatile computer readable medium comprising computer executable instructions for carrying out such a method.
  • Another object of the invention is a functionally asymmetric multi-core processor comprising a plurality of cores sharing so-called basic instructions, said at least one core comprising at least one hardware extension, said or each hardware extension being adapted to allow the execution instructions, called specialized instructions, different from said basic instructions, each specialized instruction being thus associated with a said hardware extension, characterized in that it also comprises:
  • filter circuits configured to sort the basic instructions and specialized instructions associated with the different hardware extensions, and to assign each specialized instruction to a family;
  • a specialized instruction counter associated with said hardware extension and belonging to said family loaded by the core.
  • Yet another object of the invention is a computer system comprising such a functionally asymmetrical multi-core processor and a non-volatile memory storing instructions executable by said processor for the implementation of a method according to the invention.
  • FIG. 1 an example of a functionally asymmetric multi-core processor whose architecture is known from the prior art
  • FIG. 2 a histogram of the cost of emulation of a floating-point calculation instruction
  • FIG. 3 the functionally asymmetrical multi-core processor of FIG. 1, equipped with instruction hardware counters in accordance with one embodiment of the invention
  • FIG. 4 a graph illustrating the division of the execution of an application into application periods, the monitoring of the quality of service for each period and the number of specialized instructions loaded for each hardware extension;
  • FIG. 5 a graph illustrating the division of the application periods into segments, in accordance with one embodiment of the invention.
  • Figure 6 is a graph illustrating the management choices made according to one embodiment of the invention.
  • Hardware Expansion or simply “Hardware Extension” a circuit such as a Floating Point Unit (FPU), a vector calculation unit , a cryptographic processing unit, a signal processing unit, etc.
  • a hardware extension introduces a dedicated hardware circuit accessible or connected to a processor core, which circuit provides high performance for specific computing tasks. Such a specific circuit improves the performance and energy efficiency of a core for particular calculations, but their intensive use can lead to reduced performance in terms of Watt per unit area.
  • These hardware extensions associated with the core processor are provided with an instruction set that extends the standard or default (ISA) set. Hardware extensions are usually well integrated into the core's "pipeline", which provides efficient access to functions through instructions added to the "basic" set.
  • a hardware extension The function of a hardware extension is to speed up the processing of a specific set of instructions: a hardware extension may not speed up the processing of another type of instruction (eg floating point versus integer).
  • Extended core a processor core comprising a “basic” core, supporting a minimum set of instructions common to all processor cores, plus one or more hardware extensions.
  • a processor core may be associated with none (i.e., zero), one or more hardware extensions. These hardware extensions are then "exclusive", that is to say, a given hardware extension can not be accessed from a third heart.
  • the processor core includes the hardware extension (s).
  • a processor core (or simply “heart") is a set of physical circuits capable of executing programs “autonomously”.
  • a hardware extension is able to execute a part of the program but is not “autonomous”: it requires the association with at least one processor core.
  • FIG. 1 schematically illustrates the architecture of a functionally asymmetric multi-core processor PR integrating four cores PC1, PC2, PC3, PC4 which share a common base called “basic core” BASE and which may each have one or more extensions hardware HW1, HW2, giving them more or less extensive functionalities.
  • the PC1 core is "complete”, that is to say that it comprises the basic core and the two available hardware extensions;
  • the PC2 and PC3 cores comprise, in addition to the basic core, the only extension HW1 or HW2, respectively;
  • the PC4 core is "basic", not including hardware extensions.
  • the reference MM designates a read-only memory storing instructions executable by the processor PR and making it possible to implement the method of the invention.
  • CPU cores other than PC1 do not include all available hardware extensions. Thus, when a computation task is executed by such a heart, it is possible that the latter encounters specific instructions associated with hardware extensions that it does not have. It is therefore necessary to make a "management choice”: continue execution on the current processor core by emulating unsupported specialized instructions (that is, converting them into basic instruction sets) or migrate the core task with the required hardware extensions; in both cases, it is also possible to act on the voltage-frequency torque.
  • QoS Quality of Service
  • the invention makes it possible to optimize the management choices by accurately predicting the quality of service (QoS) and the dissipated energy associated with each possible management opportunity, thus facilitating the taking into account of several criteria.
  • QoS quality of service
  • this prediction requires a preliminary step of calibration, implemented "offline", consisting in characterizing the time and energy costs of the execution of the different specific instructions on the basic cores (by emulating these instructions) and extended (in the performers normally on these hearts).
  • this step comprises the determination (generally empirical) of calibration parameters representative of the statistical distribution of the time and energy emulation costs of the specialized instructions.
  • these parameters can be the maximum cost, the minimum cost, the average cost and the standard deviation of the cost distribution, measured over several executions of these instructions, with different sequences and various data sets.
  • these parameters are not determined for each instruction considered in isolation, but for "families” comprising specific instructions associated with the same hardware extension and having comparable execution costs.
  • This has a twofold advantage: firstly, a simplification of the task cost prediction operations (performed “online”), secondly - if the decomposition into families is carried out timely - a minimization of the estimation error made during these prediction operations.
  • Figure 2 shows the cost of emulating the floating-point square root statement "fsqrt" in equivalent basic instructions (y-axis). It has a constant part (rectangle in thick line in figure 2) with more than 120 equivalent instructions (for the backup of context, its restitution and the call to the routine of emulation) and a part dependent on the instruction to emulate (fine line).
  • the average cost of emulating this instruction is 360 basic instructions with a large standard deviation, represented by an error bar.
  • the cost of emulation in time and energy
  • This exploration is done on the basis of test games including unit tests per instruction and tests of real applications from sets of tests commonly used by the scientific community. It can be conducted experimentally / empirically, as by the use of a heuristic or any other operational search algorithm. For example, it is advantageous to group the instructions having a low standard deviation or an important occurrence frequency together to avoid degrading the final estimation error. The increase in the number of families reduces the width of the cost ranges and thus the error in estimating these costs.
  • the monitoring is performed by means of digital filtering circuits of part of the binary encoding of each instruction ("opcode", from the English “operation code” it is “operating code”), used to sort the basic instructions and specialized instructions associated with the different hardware extensions and, where applicable, to assign each specialized instruction to a family, as well as to similar hardware counters the counters commonly present in embedded processors (cycle counters, floating instruction counters, cache failure counters ...), which would count the occurrence of the instructions of each family. These counters can be read, and resets can be controlled at specific times of the method. We favor the counting of instructions loaded by the heart because the loading of the instructions is always carried out whatever the type of heart (they can then be executed if the heart supports them or cause an exception and call an emulation routine in the opposite case).
  • the PC1 core includes: a set of counters Nb (HW1, i) counting the number of loaded instructions belonging to each family "i" of the hardware extension "HW1";
  • the PC2 core includes:
  • HW2 a counter Nb (HW2) counting the number of loaded instructions associated with the hardware extension "HW2", without distinguishing the different families of instructions;
  • Nb_emul counting the number of basic instructions used to emulate the specialized instructions associated with the hardware extension "HW2".
  • the PC3 core includes:
  • HW1 a counter Nb (HW1) counting the number of loaded instructions associated with the hardware extension "HW1", without distinguishing the different families of instructions;
  • the PC4 core includes:
  • HW1 a counter Nb (HW1) counting the number of loaded instructions associated with the hardware extension "HW1", without distinguishing the different families of instructions;
  • HW2 a counter Nb (HW2) counting the number of loaded instructions associated with the hardware extension "HW2", without distinguishing the different families of instructions;
  • Nb_emul counting the number of basic instructions used to emulate the specialized instructions associated with the hardware extension "HW1";
  • Nb_emul counting the number of basic instructions used to emulate the specialized instructions associated with the hardware extension "HW2".
  • the instruction filtering circuits are not shown so as not to overload the figure.
  • the digital filtering circuits perform the filtering of the instructions loaded by the heart at the time of the instruction decoding (opcode filtering) to identify whether the current instruction is of type "m" (that is to say is associated with the hardware extension "m") and, if so, if it belongs to the "i" family of this extension.
  • One possible optimization of this embodiment is to rectify the family cut made in the first step of the method to reduce these intervals to similar classes of instructions (memory access, calculation, control ...) that share the same opcode thus facilitating the filtering of the instructions at the time of decoding.
  • a calculation of the estimation error with the new cut must be made to check that it remains below the tolerable error.
  • Nb_basic For the counting of basic instructions ⁇ Nb_basic), it may be advantageous to filter the specialized instructions at the time of decoding by opcode and to disengage the counter Nb_basic when the execution of these instructions.
  • the counter Nb_basic is also disengaged at the entrance of an exception and engaged at its exit.
  • Nb (m) is obtained by summing Nb (m, i) for all the values of "i".
  • QoS we just calculated. This is illustrated in Figure 4, which shows a chronogram of the number of loaded specialized instructions that are associated with the two hardware extensions considered, HW1 and HW2; "T” designates the execution time.
  • the PS pulses are indicated by vertical lines, and cut the execution time into “application periods” (or simply “periods") PRD.
  • Quality of QoS service is measured at each heartbeat for the past period, and an MRG margin is calculated against a minimum quality level of Qos_Min.
  • a maximum quality level QoS_Max is also indicated; indeed, we do not generally want to provide an unnecessarily high level of quality.
  • the prediction of future executions of specialized instructions is generally based on an understanding of the past use of the extension.
  • the learning period is often constant, linked to events of the scheduler.
  • the invention proposes to track and predict the use of specialized instructions on portions of the "application period” and thus adapt to profiles of use of specialized instructions changing from one period to another.
  • a "portion" is the minimum time interval for each management decision of the proposed method.
  • each period is subdivided into N "portions" of non-constant durations and this as a function of the number of loaded specialized instructions associated with the hardware extension "HW m " whose emulation cost over this period will be the most penalizing in terms of performance.
  • ⁇ / is a number that can be arbitrarily fixed from the beginning of the execution or after a calibration phase at the beginning of the execution.
  • the determination of the most penalizing hardware extension can be done offline for each application to run on the platform. It can be calculated online and updated each time a new application is run (so with only one calibration phase at the beginning of the execution of each application) or within the same application (in the case of very dynamic applications) after each "P" application pulsations (the calibration phase is repeated after each P pulses, P being a constant and predefined number before execution).
  • Nb_Pred (m , n + i> a-Nb (m , n) + (1-a) Nb_Pred (m , n) [3]
  • m a portion of the current period ends when the number predicts specialized instructions from the hardware extension "HW m " over the current period ⁇ Nb_Pred (mt n j), divided by N, has been loaded.
  • the second application period PRD2 was executed on a basic core and the third, PRD3, on an extended core (just like the first period PRD1). If fixed duration portions were used, no simple relationship could be found between the data collected at the PRD2 period to predict that of the same portion at the PRD3 period. Cutting into periods of fixed duration also requires, on the one hand, more controller interventions and, on the other hand, fairly expensive interpolations to reduce the measurements collected to usable data for the prediction.
  • the portions comprise a substantially equal number of specialized instructions, which makes it possible to relate portions of the same rank of different periods.
  • the periods preferably comprise exactly the same number of instructions dedicated to the "HW m " extension (except the last period, which may be incomplete). In degraded variants, however, a margin of tolerance - typically less than 10% or even 5% - may be allowed.
  • an alarm type counter with a fixed quantum of time which raises an interruption on the current heart.
  • the routine called by this interrupt consults the hardware counter of the number of specialized instructions of the extension "HW m " and calls the management routine when the number of specialized instructions required per serving is reached.
  • the number of specialized instructions responsible for the extension "HW m " is approximately the same, with a margin of error all the smaller as the quantum of time is small.
  • this quantum will be chosen such that the margin of error is less than 5%, or even 10%.
  • the transition from one application period to the next occurs when the number of specialized instructions reaches or exceeds a predefined threshold value.
  • the invention provides a follow-up, for each portion "k" of the period "n":
  • Nb_basiC the total number of instructions executed outside emulation for basic cores and without specialized instructions for extended cores: Nb_basiC (k, n );
  • the method provides the prediction, for the same portion k of the following application period n + 1 of:
  • Nb_Pred (m , h K n + 1) a. Nb (m , /, K n) + (1 - a) Nb_Pred (m , K n)
  • Nb_Pred_basic (k , n + i) a. Nb_basic (k , n) + (1 - a) Nb_Pred_basic (n )
  • Nb_Pred_emul (m, k, n + 1) a.Nb_emul (m, k, n) + (1-a) Nb_Pred_emul (m, k, n)
  • the initialization values can for example be obtained by calibration.
  • an extended core (with its variants Full, ⁇ base + HW-i), (base + HW 2 )) (respectively basic) to a basic (or extended) heart.
  • DVFS voltage-frequency torque
  • the estimate of the costs / gains in performance and energy is based on an entire period.
  • the method estimates QoS and the energy consumed at the end of the period by estimating decisions at the portion level.
  • the application QoS is often reduced to the inverse of an execution time over the application period considered. This time can be estimated by summing the estimates of the execution times on the different portions of this period.
  • the energy consumed is the sum of the contributions of the cores, estimated according to the allocation made and according to the DVFS pair chosen on each portion, then reduced over the entire period.
  • Nb_Pred (m, /, k, n + 1) is the number of specialized instructions predicted over the period n + 1 of the family / ' over the portion k (see equation [4]).
  • CPI cycles per instruction
  • F1 the frequency of the processor
  • P1 and P2 respectively represent the average powers of the current and the destination core.
  • P1 represents the power of the heart having the extension "m” (respectively devoid of the extension "m") and P2 is that of the heart devoid of this extension (respectively having the extension "m") and towards which the migration cost in the case of an emulation (respectively in the case of an acceleration).
  • Nb_total (k, n ) is the total number of instructions on the previous period "n” and on the same portion "k”. Cost of change of voltage / frequency (DVFS):
  • K D VFS_time (m, k, n + 1, F1 ⁇ F2) Nb Otdl ⁇ X CPI X ( ⁇ 2 ) [0]
  • P1 represents the average power of the current heart at the operating point DVFS given by the frequency F1 (respectively F2).
  • K-DVFS_emul / accel_time (m, k, n + 1, F1 _ ⁇ F2) Kemul / accel_time (m, k, n + 1, F2) + KDVFS_time (m, k, n + 1, F1 _> F2) [12]
  • the energy overcharge predicted for the period n + 1 of the change of torque voltage frequency on the portion "k" and for a change of a frequency of execution F1 to F2 with migration is given by the following equation with both variants:
  • KDVFs_emui_energie additional cost due to emulation and DVFS; and KDVFs_accei_energie additional cost due to the acceleration on the core with extension "m” and DVFS: KDVFS_emul / accel_energie (m, k, n + 1, F1 ⁇ F2) ⁇ Kemul / accel_time (m, k, n + 1, F2) X P2 ) + KDVFS_energie (m, k, n + 1, F1 _> F2) [13]
  • P1 represents the average power of the current heart at the operating point DVFS given by the frequency F1 and P2 represents the average power of the destination heart at the operating point given by the frequency F2.
  • Estimating the cost of different management options is used to enable decision-making to ensure a minimum QoS while minimizing the energy consumed.
  • Figure 6 gives an example of decision making at the granularity of a portion to maintain a quality of service above the minimum QoS and minimize energy. This figure is taken from Figure 4 by adding:
  • QoS_bas and [QoS_Haut, QoS_Max] (represented on figure 6) on which one decides to trigger actions of management and one keeps the system such what if the calculated QoS falls within the intermediate interval [QoS_bas, QoS_Haut].
  • the margin with respect to the quality of service QoS_bas (as illustrated by FIG. 6) over the last period executed and to distribute this margin over the different portions of the following period. so that the decisions taken at the portion level benefit from this portion of the margin to choose a management opportunity (migration, DVFS change of couple, a combination of the two) which reduces the energy consumed under constraint of respect of this portion of margin.
  • the margin of QoS is reduced to a time margin "jUoos": positive when the QoS n is greater than QoS_bas and negative otherwise (case of the margin on the third period of Figure 6) and its distribution on the N Portions of the period can be done in the same way as it can be more intelligently chosen for example compared to the utilization ratio of the extension "m” whose emulation is the most penalizing in time (T m see equation [1 ]) calculated on each "k" portion: T ( m , k, n
  • An implementation would prefer, for example, the distribution of the margin to period portions with the lowest utilization ratios because they have greater emulation opportunities .
  • a second margin (positive or negative too) can be introduced in relation to the prediction of the evolution of the number of specialized instructions in time.
  • the second useable margin can be calculated by the following equation:
  • the margin collected by the / portion is:
  • this method operates incrementally starting from the implementation chosen at the same portion of the previous period and estimating the additional costs of management opportunities.
  • the choice of the most appropriate management opportunity vis-à-vis the margin " ⁇ ⁇ " allocated to the k portion is advantageously considering a parameter that jointly integrates performance and energy as the EDP (product energy latency, Energy Delay Product).
  • the difference of the additional costs is used as a parameter to be maximized in order to guide the choice of the management opportunity.
  • a management opportunity "opp" for a portion "k”, and an average power P 1 (power of the core used at the portion k of the preceding period)
  • P 1 power of the core used at the portion k of the preceding period
  • K oppJemps ⁇ k is the time cost of a management opportunity, depending on the chosen opportunity, it can be worth for example K emu ij emps , K acC ei_time or KovFsjemps-
  • K opp _ e energy (k) is the energy cost of a management opportunity; depending on whether retained, it may be worth eg K em Ui_ energy Kaccel_energie OR KoVFS_energie- The condition to be satisfied is that:
  • Dopp (k) MaX all opp ⁇ D 0 pp (k)) [1 8]
  • Another possible embodiment of the decision-making phase is based on the principle of favoring basic core allocation over the first portions, as long as the QoS estimate at the end of the period remains above the quality of the core. minimum service, and then speed up execution by migrating to an extended heart in the last portions. This method tends to delay the migration to an extended core as much as possible while guaranteeing a minimum QoS at the end of the period, thus favoring the use of basic cores that are less efficient but not very energy intensive.
  • the estimate of QoS at the end of the period considers an allocation of the k portion on a basic core and an allocation of the following portions ⁇ k + 1 to N) on an extended heart.
  • the allocation to the first portion is estimated on a basic core with all the other portions on an extended core and it is checked whether the QoS at the end of the period remains greater than QoS m j n .
  • the prediction of the extended core execution time of the k (T_Etondu_Prod ( k )) portion corresponds to the calculation of T_Pred ( ki n + i) of the equation [14] considering that all the extensions are present.
  • the prediction of the basic core execution time of the k (T_Basic_Pred (k j) portion corresponds to the calculation of T_Pred (kt n + 1) of equation [14] assuming that all the extensions are emulated.
  • the QoS predicted at the end of the period by estimating that the portion k is allocated on a basic core and that the rest of the portions are allocated on an extended core is calculated by the following equation:
  • the predicted allocation is executed. Otherwise, the frequency of the allocation of the portion k is incrementally changed, then a change of allocation is considered at a low frequency and the frequency is gradually increased and so on.
  • the dual implementation which favors the allocation of the portion / on an extended core by considering that the other following portions (k + 1 to N) will be allocated on a basic core is also a possible realization.
  • QoS_Pred n + i> QoS m j n is not verified, we decide to continue to allocate on the extended heart the next portion.
  • the QoS at the end of the period is predicted incrementally by estimating, in the same order as in the previous method, the possible management opportunities.
  • a method according to the invention is implemented by means of a computer program product comprising instructions executable by a functionally asymmetric multi-core processor (processor PR of FIG. 1), stored on a non-volatile support readable by said processor. (by for example a ROM memory MM, illustrated in Figure 1).
  • a functionally asymmetric multi-core processor may have specific hardware means: instruction filtering circuits and counters.
  • Such a processor and a non-volatile memory storing the computer program product can advantageously form, with other components (RAMs, peripherals ...), a computer system, typically embedded.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Procédé de la gestion d'une tâche de calcul sur un processeur multi-cœurs fonctionnellement asymétrique comprenant une pluralité de cœurs (PC1 – PC4) dont au moins un comprend au moins une extension matérielle (HW1, HW2) permettant l'exécution d'instructions spécialisées, comprenant les étapes suivantes: a) démarrer l'exécution de la tâche de calcul sur un cœur du processeur; b) effectuer un suivi d'un paramètre (QoS) indicatif d'une qualité de service de la tâche de calcul, ainsi que d'un nombre d'instructions spécialisées chargées par ledit cœur; c) identifier des instants découpant une période applicative de la tâche de calcul en un nombre prédéterminé de portions (PTS); d) calculer des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes options de gestion de la tâche de calcul; et e) effectuer un choix de gestion en fonction des coûts ou gains ainsi calculés. Produit programme d'ordinateur, processeur et système informatique pour la mise en œuvre d'un tel procédé.

Description

PROCEDE DE GESTION DES TACHES DE CALCUL SUR UN
PROCESSEUR MULTI-CŒURS FONCTIONNELLEMENT ASYMETRIQUE
L'invention porte sur un procédé mis en œuvre par ordinateur pour la gestion de tâches de calcul sur un processeur multi-cœurs fonctionnellement asymétrique. Elle porte également sur un produit programme d'ordinateur, un processeur multi-cœurs et un système informatique pour la mise en œuvre d'un tel procédé.
Un processeur multi-cœurs peut comprendre une ou plusieurs extensions matérielles, destinées à accélérer des parties de codes logiciels spécifiques. Par exemple, ces extensions matérielles peuvent comprendre des circuits pour du calcul en virgule flottante ou du calcul vectoriel.
Un processeur multi-cœurs est dit «fonctionnellement asymétrique » quand tous les cœurs ne possèdent pas les mêmes extensions matérielles, et par conséquent certaines extensions font défaut à certains cœurs de processeurs. Ainsi, un processeur fonctionnellement asymétrique se caractérise par une distribution (ou association) inégale des extensions aux cœurs de processeurs. Il existe un jeu d'instructions commun à tous les cœurs et des jeux d'instructions spécifiques associés à des extensions matérielles respectives, présentes dans certains cœurs. En faisant l'union de tous les jeux d'instructions des cœurs du processeur, toutes les instructions requises par l'exécution d'une tâche de calcul d'une application sont représentées.
La gestion d'un processeur multi-cœurs fonctionnellement asymétrique pose plusieurs problèmes techniques, et notamment celui de gérer efficacement le placement des tâches de calcul sur les différents cœurs de processeur.
Les applications logicielles utilisent ces extensions matérielles d'une manière dynamique, c'est-à-dire qui varie au cours du temps. Pour une même application, certaines phases de calcul vont utiliser presque à pleine charge une extension donnée (par exemple des calculs sur des données de type virgule flottante) tandis que d'autres phases de calcul l'utiliseront peu voire pas du tout (par exemple des calculs sur des données de type entier). Utiliser une extension n'est pas toujours efficace en termes de performance ou d'énergie (« qualité » d'utilisation).
Les travaux publiés concernant le placement de tâches de calcul (ordonnancement) sur des processeurs multi-cœurs fonctionnellement asymétriques ne décrivent pas de solutions pleinement satisfaisantes.
L'article de H. Shen et F. Pétrot, « Novel Task Migration Framework on Configurable Heterogeneous MPSoC Platforms », Proceedings of the 2009 Asia and South Pacific Design Automation Conférence, Piscataway, NJ, USA, 2009, pp. 733-738, décrit une technique d'ordonnancement hors ligne dite « par affinité », qui consiste à figer l'allocation d'une tâche à un processeur (ou à un type de processeur) avant l'exécution suite à une analyse hors ligne de l'application (faite à la main, par des outils d'analyse de code ou par le compilateur) et l'ordonnanceur en ligne suit exactement ces directives. L'inconvénient principal de cette approche est qu'aucune autre optimisation n'est permise en ligne lorsque les applications sont dynamiques et leur ratio d'utilisation des ressources varie avec le temps et les données.
L'article de G. Georgakoudis, D. S. Nikolopoulos, H. Vandierendonck, et S. Lalis, « Fast Dynamic Binary Rewriting for flexible thread migration on shared-ISA heterogeneous MPSoCs », 2014 International Conférence on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XIV), 2014, pp. 156-163, décrit une technique - dite de réécriture binaire dynamique - qui procède à une réécriture sur faute (c'est-à-dire quand une instruction spécialisée est chargée par un cœur ne la supportant pas) par émulation des instructions non supportées. C'est une technique flexible et qui peut être performante, associée à un ordonnanceur dynamique intelligent. Toutefois, les coûts de réécriture et d'émulation peuvent s'avérer très importants.
L'article de T. Li, P. Brett, R. Knauerhase, D. Koufaty, D. Reddy et S. Hahn, « Operating System support for overlapping-ISA heterogeneous multi-core architectures », 2010 IEEE 1 6th International Symposium on High Performance Computer Architecture (HPCA), 2010, pp. 1-12 décrit une technique dite de migration sur faute. Elle consiste à migrer l'exécution d'une tâche (à la granularité d'un quantum d'instructions), dès lors qu'une instruction spécialisée non-supportée par l'unité d'exécution actuelle est rencontrée, vers une ressource possédant l'extension matérielle correspondante. Son principal point faible est qu'elle peut provoquer des migrations intempestives et un déséquilibrage de charge entre cœurs de base et cœurs avec extension.
La thèse de A. Aminot « Méthode dynamique pour améliorer le placement de tâches sur processeurs asymétriques en fonctionnalités » Université de Grenoble, France, 2015, décrit un procédé d'allocation dynamique des tâches de calcul dans lequel le choix du cœur sur lequel une tâche est exécutée est effectué à partir d'une estimation à la compilation du coût d'émulation de ladite tâche. Cette estimation est obtenue à partir de la mesure du nombre d'utilisation de différentes instructions spécialisées lors d'exécutions antérieures de la même tâche. Bien qu'intéressante dans son principe, cette technique n'est pas optimisée et nécessite aussi d'embarquer une version du binaire de la tâche par extension présente dans l'architecture ; en outre, elle ne permet pas d'assurer le respect de contraintes de qualité de service (QoS, de l'anglais « Quality of Service »).
L'invention vise à surmonter, en tout ou au moins en partie, les inconvénients précités de l'art antérieur. Plus particulièrement elle vise à permettre à la fois une utilisation optimale des ressources de calcul (notamment en termes d'énergie) et le respect de contraintes de QoS. Pour ce faire, elle perfectionne l'approche proposée dans la thèse précitée de A. Aminot.
D'une manière générale, tout paramètre représentatif des performances du système, considérées du point de vue de l'utilisateur, peut être utilisé en tant que contrainte de QoS selon différents modes de réalisation de l'invention. A titre d'exemple non limitatif la QoS d'une tâche de calcul peut être définie comme la vitesse d'exécution (c'est-à-dire l'inverse du temps d'exécution) de ladite tâche. Pour atteindre ce but, l'invention apporte plusieurs améliorations à l'art antérieur, pouvant être mises en œuvre séparément ou en combinaison. En particulier :
Conformément à l'invention, les choix de gestion sont effectués à des instants clés de l'exécution de chaque application, identifiés de manière dynamique au lieu d'être prédéfinis, permettant la garantie de QoS et minimisant l'énergie consommée.
Dans certains modes de réalisation de l'invention, des moyens matériels spécifiques (compteurs...) sont prévus pour faciliter la détermination de ces instants clés.
Les choix de gestion sont effectués en prenant en compte un « coût d'opportunité » en QoS et en énergie de chaque option d'exécution. Cela permet de quantifier exactement l'écart en termes de performance par rapport à une consigne de QoS minimale qu'on cherche à garantir. Une nouvelle méthode de calcul de ce coût d'opportunité est aussi proposée.
L'invention propose également, dans une première étape de caractérisation, une méthode de sélection de différentes classes d'instructions selon leurs coûts d'émulation en termes de performance et d'énergie, permettant de minimiser l'erreur d'estimation du coût d'opportunité de chaque opportunités (ou « options ») de gestion.
Un objet de l'invention est un procédé mis en œuvre par ordinateur pour la gestion d'une tâche de calcul sur un processeur multi- cœurs fonctionnellement asymétrique, l'exécution de ladite tâche comprenant une succession de périodes applicatives, ledit processeur comprenant une pluralité de cœurs partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle, ladite ou chaque extension matérielle étant adaptée pour permettre l'exécution d'instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, le procédé comprenant les étapes suivantes :
a) démarrer l'exécution de la tâche de calcul sur un cœur dudit processeur ; b) effectuer, au cours de ladite exécution, un suivi d'un paramètre indicatif d'une qualité de service de la tâche de calcul, ainsi que d'au moins un nombre d'instructions spécialisées chargées par ledit cœur;
c) sur la base dudit suivi, identifier des instants découpant une période applicative de la tâche de calcul en un nombre prédéterminé de portions de telle façon que, au cours de chacune desdites portions, un nombre sensiblement égal d'instructions spécialisées associées à une extension matérielle prédéfinie soient chargées par ledit cœur ;
d) calculer, auxdits instants et en fonction dudit suivi, des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes options de gestion de la tâche de calcul ; et
e) effectuer un choix de gestion comprenant une décision de poursuivre l'exécution sur le même cœur du processeur ou sur un cœur différent en fonction des coûts ou gains ainsi calculés.
Un autre objet de l'invention est un produit programme d'ordinateur stocké sur un support non-volatil lisible par ordinateur comprenant des instructions exécutables par ordinateur pour la mise en œuvre d'un tel procédé.
Un autre objet de l'invention est un processeur multi-cœurs fonctionnellement asymétrique comprenant une pluralité de cœurs partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle, ladite ou chaque extension matérielle étant adaptée pour permettre l'exécution d'instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, caractérisé en ce qu'il comprend également :
des circuits de filtrage, configurés pour trier les instructions basiques et les instructions spécialisées associées aux différentes extensions matérielles, et pour attribuer chaque instruction spécialisée à une famille ; et
pour chaque cœur : un compteur d'instructions basiques chargées par le cœur ;
pour chaque extension matérielle non comprise par ledit cœur, un compteur d'instructions spécialisées associées à ladite extension matérielle chargées par le cœur, ainsi qu'un compteur du nombre d'instructions basiques utilisées pour l'émulation des instructions spécialisées associées ; et
pour chaque extension matérielle comprise par ledit cœur, et pour chaque famille d'instructions spécialisées associées à ladite extension matérielle, un compteur d'instructions spécialisées associées à ladite extension matérielle et appartenant à ladite famille chargées par le cœur.
Encore un autre objet de l'invention est un système informatique comprenant un tel processeur multi-cœurs fonctionnellement asymétrique et une mémoire non-volatile stockant des instructions exécutables par ledit processeur pour la mise en œuvre d'un procédé selon l'invention.
D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d'exemple et qui représentent, respectivement :
- La figure 1 , un exemple de processeur multi-cœurs fonctionnellement asymétrique, dont l'architecture est connue de l'art antérieur ;
La figure 2, un histogramme du coût d'émulation d'une instruction de calcul en virgule flottante ;
- La figure 3, le processeur multi-cœurs fonctionnellement asymétrique de la figure 1 , équipé de compteurs matériels d'instructions conformément à un mode de réalisation de l'invention ;
La figure 4, un graphique illustrant le découpage de l'exécution d'une application en périodes applicatives, le suivi de la qualité de service pour chaque période et du nombre d'instructions spécialisées chargées pour chaque extension matérielle ; La figure 5, un graphique illustrant le découpage des périodes applicatives en segments, conformément à un mode de réalisation de l'invention ; et
La figure 6, un graphique illustrant les choix de gestion effectués conformément à un mode de réalisation de l'invention.
Dans la suite, on entend par :
« Extension matérielle », ou plus simplement « extension » (« Hardware Extension » en anglais), un circuit tel qu'une unité de calcul sur données flottantes (FPU de l'anglais « Floating Point Unit »), une unité de calcul vectoriel, une unité de traitement cryptographique, une unité de traitement du signal, etc. Une extension matérielle introduit un circuit matériel spécialisé accessible ou relié à un cœur de processeur, lequel circuit fournit de hautes performances pour des tâches de calcul spécifiques. Un tel circuit spécifique améliore les performances et l'efficacité énergétique d'un cœur pour des calculs particuliers, mais leur utilisation intensive peut conduire à réduire la performance en termes de Watt par unité de surface. Ces extensions matérielles associées au cœur de processeur sont fournies avec un jeu d'instruction qui étend le jeu standard ou par défaut (ISA). Les extensions matérielles sont généralement bien intégrées dans la chaîne de traitement (« pipeline ») du cœur, ce qui permet d'accéder efficacement aux fonctions par des instructions ajoutées à l'ensemble « basique ».
La fonction d'une extension matérielle est d'accélérer le traitement d'un jeu d'instructions spécifique: une extension matérielle peut ne pas accélérer le traitement d'un autre type d'instruction (e.g. virgule flottante versus entier).
« Cœur étendu », un cœur de processeur comprenant un cœur « basique », supportant un ensemble minimal d'instructions commun à tous les cœurs du processeur, augmenté d'une ou plusieurs extensions matérielles.
- « Tâche de calcul » (« thread » en anglais), l'exécution d'un ensemble d'instructions du langage machine d'un processeur. Un processus comprend en général plusieurs tâches de calcul qui, du point de vue de l'utilisateur, semblent se dérouler en parallèle. Les différentes tâches d'un même processus partagent la même mémoire virtuelle, mais présentent chacune sa propre pile d'appel.
Comme cela a été évoqué plus haut, dans une architecture multi-cœurs fonctionnellement asymétrique un cœur de processeur peut être associé avec aucune (i.e. zéro), une ou plusieurs extensions matérielles. Ces extensions matérielles lui sont alors « exclusives », c'est-à-dire une extension matérielle donnée ne peut pas être accédée depuis un cœur tiers. Le cœur de processeur comprend la ou les extensions matérielles.
Un cœur de processeur (ou simplement « cœur ») est un ensemble de circuits physiques capables d'exécuter des programmes de façon « autonome ». Une extension matérielle est capable d'exécuter une partie de programme mais n'est pas « autonome » : elle requiert l'association avec au moins un cœur de processeur.
La figure 1 illustre de manière schématique l'architecture d'un processeur multi-cœurs fonctionnellement asymétrique PR intégrant quatre cœurs PC1 , PC2, PC3, PC4 qui partagent une base commune appelée « cœur basique » BASE et qui peuvent posséder chacune une ou plusieurs extensions matérielles HW1 , HW2, leur procurant des fonctionnalités plus ou moins étendues. Plus précisément, le cœur PC1 est « complet », c'est-à-dire qu'il comprend le cœur basique et les deux extensions matérielles disponibles ; les cœurs PC2 et PC3 comprennent, en plus du cœur basique, la seule extension HW1 ou HW2, respectivement ; et le cœur PC4 est « basique », ne comprenant pas d'extensions matérielles.
La référence MM désigne une mémoire morte stockant des instructions exécutables par le processeur PR et permettant de mettre en œuvre le procédé de l'invention.
Les cœurs de processeur autres que PC1 ne comprennent pas toutes les extensions matérielles disponibles. Ainsi, lorsqu'une tâche de calcul est exécutée par un tel cœur, il est possible que ce dernier rencontre des instructions spécifiques associées à des extensions matérielles qu'il ne possède pas. Il est donc nécessaire d'effectuer un « choix de gestion » : continuer l'exécution sur le cœur de processeur actuel en émulant les instructions spécialisées non supportées (c'est-à-dire en les convertissant en séries d'instructions basiques) ou migrer la tâche sur cœur muni des extensions matérielles requises ; dans les deux cas, il est également possible d'agir sur le couple tension-fréquence. Chacune de ces options présente un coût en termes d'énergie consommée et de Qualité de Service (QoS), ce dernier paramètre pouvant notamment être représenté par l'inverse d'un temps d'exécution de la tâche de calcul.
L'invention permet d'optimiser les choix de gestion grâce à une prédiction précise de la qualité de service (QoS) et de l'énergie dissipée liée à chaque opportunité de gestion possible, facilitant ainsi la prise en compte de plusieurs critères.
Cette prédiction nécessite une étape préliminaire d'étalonnage, mise en œuvre « hors ligne », consistant à caractériser les coûts en temps et en énergie d'exécution des différentes instructions spécifiques sur les cœurs basiques (en émulant ces instructions) et étendus (en les exécutants normalement sur ces cœurs). Selon un mode de réalisation préféré de l'invention, cette étape comprend la détermination (généralement empirique) de paramètres d'étalonnage représentatifs de la distribution statistique des coûts d'émulation en temps et énergie des instructions spécialisées. Par exemple, ces paramètres peuvent être le coût maximum, le coût minimum, le coût moyen et l'écart type de la distribution des coûts, mesurés sur plusieurs exécutions de ces instructions, avec des enchaînements différents et des jeux de données variées.
Avantageusement, ces paramètres ne sont pas déterminés pour chaque instruction considérée de manière isolée, mais pour des « familles » comprenant des instructions spécifiques associées à une même extension matérielle et présentant des coûts d'exécution comparables. Cela présente un double avantage : premièrement, une simplification des opérations de prédiction du coût des tâches (effectuées « en ligne »), deuxièmement - si la décomposition en familles est effectuée de manière opportune - une minimisation de l'erreur d'estimation effectuée lors de ces opérations de prédiction.
Par exemple, sur le cœur RISC-V le coût de l'émulation en nombre d'instructions basiques équivalentes pour les instructions spécifiques de type virgule flottantes varie de 150 à 470 instructions basiques. La figure 2 donne le coût d'émulation de l'instruction racine carrée en virgule flottante « fsqrt » en instructions basiques équivalentes (axe des ordonnées). Elle comporte une partie constante (rectangle en trait épais dans la figure 2) avec plus de 120 instructions équivalentes (pour la sauvegarde de contexte, sa restitution et l'appel à la routine d'émulation) et une partie dépendante de l'instruction à émuler (trait fin). Le coût moyen d'émulation de cette instruction est de 360 instructions basiques avec un écart type important, représenté par une barre d'erreur.
La solution consistant à regrouper les instructions spécifiques à virgule flottante en une seule famille et considérer un coût moyen de 282 instructions basiques, correspondant à la caractérisation hors ligne de ces instructions spécifiques, donne une erreur d'estimation de l'ordre de 25-50% sur les jeux de tests considérés, ce qui n'est pas satisfaisant.
Selon un mode de réalisation de l'invention, on propose de procéder à une décomposition par l'exploration du nombre de familles « /' » et de la largeur de l'intervalle de coût de chaque famille qui minimise l'erreur d'estimation du coût d'émulation (en temps et énergie) des instructions spécifiques considérées. Cette exploration est faite sur la base de jeux de tests incluant des tests unitaires par instruction et des tests d'applications réelles issues d'ensembles de tests communément utilisées par la communauté scientifique. Elle peut être conduite de manière expérimentale / empirique, comme par l'utilisation d'une heuristique ou de tout autre algorithme de recherche opérationnelle. Par exemple, il est avantageux de regrouper les instructions possédants un écart type faible ou une fréquence d'occurrence importante ensemble afin d'éviter de dégrader l'erreur d'estimation finale. L'augmentation du nombre de familles réduit la largeur des intervalles de coûts et de la sorte l'erreur d'estimation de ces coûts. Mais si on augmente énormément le nombre de familles, un phénomène inverse est observé qui fait remonter l'erreur d'estimation dû à l'écart type du coût d'émulation de certaines instructions. Un compromis est donc à trouver aussi parce qu'ensuite, comme cela sera expliqué en détail plus loin, une surveillance est nécessaire en mettant en œuvre des compteurs spécifiques pour chaque famille d'instructions.
Une étude a été effectuée sur la base du cœur de processeur RISC-V. En imposant une erreur d'estimation maximale tolérable de 5%, il a été possible de délimiter deux familles d'instructions à virgule flottante avec une erreur moyenne de 3% et une erreur maximale de 4%.
Pour chaque extension {HWm), et une fois le nombre de familles « /' » et leurs coûts moyens en termes de nombre d'instructions basiques équivalent {Coût_moy_lnst(m! ,■)) et d'énergie {Coût_moy_E(m! ,■)) déterminés, ces caractéristiques hors ligne vont être embarquées et utilisées en ligne pour l'estimation des coûts/gains en performance et en énergie des différentes opportunités de gestion.
Pour obtenir cette estimation, il est nécessaire de mettre en œuvre - en ligne - plusieurs étapes :
1 . Un suivi de la QoS et de l'exécution d'instructions spécialisées ;
2. Un découpage de chaque période applicative de la tâche de calcul considéré en « portions », effectué en fonction de ce suivi ;
3. Le calcul des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes opportunités, ou options, de gestion. Ce calcul se base sur le découpage des périodes applicatives et sur les données obtenues par le suivi. 1. Suivi de l'exécution des instructions spécialisées et de la
QoS applicative
1.1 Suivi de l'exécution des instructions spécialisées Afin de mieux prédire l'exécution future des instructions spécialisées, un suivi (monitoring) de l'exécution passée de ces instructions et leur classement selon leurs familles respectives est nécessaire. Ce suivi consiste principalement en un comptage du nombre d'instructions spécialisées associées à chaque extension. Plus précisément, chaque cœur doit compter :
le nombre d'instructions spécialisées associées à chaque extension matérielle que le cœur ne comprend pas (ces instructions provoquent une exception qui appelle une routine d'émulation) ;
- pour les instructions spécialisées associés aux extensions matérielles que le cœur comprend, le nombre d'instructions spécialisées associées à chaque famille (ces instructions sont exécutées directement) ; et le nombre d'instructions basiques.
Selon un mode de réalisation préféré de l'invention, le suivi est réalisé grâce à des circuits numérique de filtrage d'une partie de l'encodage binaire de chaque instruction (« opcode », de l'anglais « opération code » c'est-à-dire « code d'opération »), permettant de trier les instructions basiques et les instructions spécialisées associées aux différentes extensions matérielles et, le cas échéant, pour attribuer chaque instruction spécialisée à une famille, ainsi qu'à des compteurs matériels semblables aux compteurs communément présents dans les processeurs embarqués (compteurs de cycles, compteurs d'instructions flottantes, compteurs de défaut de caches...), qui compteraient l'occurrence des instructions de chaque famille. Ces compteurs peuvent être lus, et des remises à zéro peuvent être commandées à des instants biens spécifiques de la méthode. On privilégie le comptage d'instructions chargées par le cœur car le chargement des instructions est toujours effectué quel que soit le type de cœur (elles peuvent ensuite être exécutées si le cœur les supporte ou provoquer une exception et appeler une routine d'émulation dans le cas contraire).
Sur la figure 3 :
Le cœur PC1 comprend : un ensemble de compteurs Nb(HW1 ,i) comptabilisant le nombre d'instructions chargées appartenant à chaque famille « i » de l'extension matérielle « HW1 » ;
un ensemble de compteurs Nb(HW2,i) comptabilisant le nombre d'instructions chargées appartenant à chaque famille « i » de l'extension matérielle « HW2 » ; et
un compteur Nb_basic comptabilisant le nombre d'instructions basiques chargées.
Le cœur PC2 comprend :
- un ensemble de compteurs Nb(HW1 ,i) comptabilisant le nombre d'instructions chargées appartenant à chaque famille « i » de l'extension matérielle « HW1 » ;
un compteur Nb(HW2) comptabilisant le nombre d'instructions chargées associées à l'extension matérielle « HW2 », sans distinguer les différentes familles d'instructions ;
un compteur Nb_basic comptabilisant le nombre d'instructions basiques chargées ; et
un compteur Nb_emul(HW2). comptabilisant le nombre d'instructions basiques utilisées pour émules les instructions spécialisées associées à l'extension matérielle « HW2 ».
Le cœur PC3 comprend :
un compteur Nb(HW1 ) comptabilisant le nombre d'instructions chargées associées à l'extension matérielle « HW1 », sans distinguer les différentes familles d'instructions ;
- un ensemble de compteurs Nb(HW2,i) comptabilisant le nombre d'instructions chargées appartenant à chaque famille « i » de l'extension matérielle « HW2 » ;
un compteur Nb_basic comptabilisant le nombre d'instructions basiques chargées ; et
- un compteur Nb_emul(HW1 ). comptabilisant le nombre d'instructions basiques utilisées pour émules les instructions spécialisées associées à l'extension matérielle « HW1 ». Le cœur PC4 comprend :
un compteur Nb(HW1 ) comptabilisant le nombre d'instructions chargées associées à l'extension matérielle « HW1 », sans distinguer les différentes familles d'instructions ;
- un compteur Nb(HW2) comptabilisant le nombre d'instructions chargées associées à l'extension matérielle « HW2 », sans distinguer les différentes familles d'instructions ;
un compteur Nb_basic comptabilisant le nombre d'instructions basiques chargées
- un compteur Nb_emul(HW1 ). comptabilisant le nombre d'instructions basiques utilisées pour émules les instructions spécialisées associées à l'extension matérielle « HW1 » ; et
un compteur Nb_emul(HW2). comptabilisant le nombre d'instructions basiques utilisées pour émules les instructions spécialisées associées à l'extension matérielle « HW2 ».
Les circuits de filtrage des instructions ne sont pas représentés pour ne pas surcharger la figure.
Avantageusement, les circuits numériques de filtrage effectuent le filtrage des instructions chargées par le cœur au moment du décodage d'instruction (filtrage û'opcode) pour identifier si l'instruction courante est de type « m » (c'est-à-dire est associée à l'extension matérielle « m ») et, le cas échéant, si elle appartient à la famille « i » de cette extension. Une optimisation possible de ce mode de réalisation consiste à rectifier la découpe en familles faite dans la première étape de la méthode pour ramener ces intervalles à des classes d'instructions similaires (accès mémoire, calcul, contrôle...) qui partagent un même opcode facilitant ainsi le filtrage des instructions au moment du décodage. Un calcul de l'erreur d'estimation avec la nouvelle découpe doit être effectué pour vérifier qu'elle reste en dessous de l'erreur tolérable.
Pour le comptage des instructions basiques {Nb_basic), il peut être avantageux d'effectuer le filtrage des instructions spécialisées au moment du décodage par opcode et débrayer le compteur Nb_basic lors de l'exécution de ces instructions. Le compteur Nb_basic est aussi débrayé à l'entrée d'une exception et embrayé à sa sortie.
En principe, ces compteurs pourraient être mis en œuvre de manière logicielle, mais cela serait coûteux en temps et en énergie. Une réalisation au moins partiellement matérielle est donc préférée.
Le suivi des instructions chargées, effectué par l'intermédiaire de ces compteurs, permet de calculer le ratio d'utilisation de l'ensemble d'instructions spécialisées associées à chaque extension matérielle « m » (indépendamment du fait que ces instructions soient effectivement exécutées par l'extension matérielle idoine ou soient émulées par un cœur basique) :
T j ^
Nb_basic L J
Dans le cas où le comptage se fait par familles, Nb(m) est obtenu en sommant Nb(m,i) pour toutes les valeurs de « i ».
1.2 Suivi de la QoS applicative
Ce suivi peut se baser sur une technique d'instrumentation peu intrusive du code applicatif comme la technique « Heartbeat », divulguée par la publication :
H. Hoffmann, J. Eastep, M. D. Santambrogio, J. E. Miller, A.
Agarwal, « Application Heartbeats: A Generic Interface for Specifying Program Performance and Goals in Autonomous Computing Environments », Proceedings of the 7th International Conférence on Autonomie Computing, New York, NY, USA, 2010, pp. 79-88.
Elle permet au système de récupérer des événements applicatifs (appelés « pulsations applicatives », ou simplement « pulsations » dans la suite) permettant de calculer une qualité de service puis de vérifier qu'elle est au-dessus d'une consigne de QoS minimale donnée par l'utilisateur. Ces événements applicatifs servent aussi à enclencher des actions de gestion qui seraient plus ou moins agressives selon la marge sur la
QoS qu'on vient de calculer. Cela est illustré sur la figure 4, qui montre un chronogramme du nombre d'instructions spécialisées chargées qui sont associées aux deux extensions matérielles considérées, HW1 et HW2 ; « t » désigne le temps d'exécution. Les pulsations PS sont indiquées par des traits verticaux, et découpent le temps d'exécution en « périodes applicatives » (ou simplement « périodes ») PRD. La qualité de service QoS est mesurée à chaque pulsation pour la période qui vient de s'écouler, et une marge MRG est calculée par rapport à un niveau de qualité minimal Qos_Min. Un niveau de qualité maximal QoS_Max est également indiqué ; en effet, on ne souhaite généralement pas fournir un niveau de qualité inutilement élevé.
2. Un découpage de chaque période applicative de la tâche de calcul considéré en « portions »
La prédiction des exécutions futures des instructions spécialisées se base généralement sur un apprentissage de l'utilisation passée de l'extension. Dans la littérature, la période d'apprentissage est souvent constante, liée à des événements de l'ordonnanceur. Pour augmenter et affiner les opportunités de gestion à l'intérieur d'une période, l'invention propose de suivre et prédire l'utilisation des instructions spécialisées sur des portions de la « période applicative » et s'adapter ainsi à des profils d'utilisation des instructions spécialisées changeants d'une période à une autre. Une « portion » est l'intervalle de temps minimum pour chaque décision de gestion de la méthode proposée.
Conformément à l'invention, chaque période est subdivisée en N « portions » de durées non constantes et ceci en fonction du nombre d'instructions spécialisées chargées associées à l'extension matérielle « HWm » dont le coût d'émulation sur cette période sera le plus pénalisant en termes de performance. Λ/ est un nombre qui peut être arbitrairement fixé dès le début de l'exécution ou à la suite d'une phase d'étalonnage au début de l'exécution.
Pour définir quelle est l'extension matérielle « m » qui est la plus pénalisante en termes de performance, on effectue au démarrage de l'application, à la suite d'une phase d'étalonnage (une ou plusieurs pulsations), le calcul du coût d'émulation relatif Coût_relatif(m! n) à la fin de la période courante « n » et pour chaque extension matérielle « m » :
Nb(m,n) x Coûtjnoyjnstçni)
Coût relatif.
Figure imgf000019_0001
= T(m,n) x Coûtjnoyjnstçjfi)
[2] où T(m,n) représente le ratio d'utilisation de l'extension m sur la période n (cf. équation [1 ]) . On choisit m qui donne le coût : Coût_relatif(m!n) = Maxm{ Coût_relatif(m,nj)
La détermination de l'extension matérielle la plus pénalisante peut être faite hors ligne pour chaque application à exécuter sur la plateforme. Elle peut être calculée en ligne et mise à jour à chaque exécution d'une nouvelle application (donc avec une seule phase d'étalonnage au début de l'exécution de chaque application) ou au sein de la même application (dans le cas d'applications très dynamiques) après chaque « P » pulsations applicatives (on répète la phase d'étalonnage après chaque P pulsations, P étant un nombre constant et prédéfini avant l'exécution).
Le découpage d'une période applicative en portions utilise la connaissance, obtenue par le suivi décrit plus haut, du nombre global (toutes familles confondues) d'instructions spécialisées associées à l'extension matérielle « HWm» chargées à la fin de la période courante « n » : Nb(m, n)-
Cette connaissance permet en effet de prédire le nombre global d'instructions spécialisées associées à l'extension matérielle « HWm» pour la période applicative suivante {Nb_Pred(m! n+ i))- Cette prédiction peut, par exemple, être obtenue en calculant une moyenne mobile exponentielle (EMA), avec un facteur de lissage « cr » (cr<1 ) adaptable selon la dynamicité de l'application. On a alors :
Nb_Pred(m, n+ i> = a-Nb(m, n) + (1 - a) Nb_Pred(m, n) [3] Pour cette extension matérielle m, une portion de la période courante s'achève lorsque le nombre prédit d'instructions spécialisées de l'extension matérielle « HWm » sur la période courante {Nb_Pred(mt nj), divisé par N, a été chargée.
Ce découpage des périodes applicatives en portions en fonction du nombre d'instructions spécialisées chargées permet d'estimer directement la QoS intermédiaire. Il permet aussi d'effectuer une prédiction de l'utilisation des instructions spécialisées sur la portion en question indépendamment de l'allocation faite à la même portion de la période précédente (portion exécutée sur un cœur basique ou étendu).
La figure 5montre l'intérêt d'une décomposition des périodes PRD en N portions PTS (dans l'exemple, N = 3) en fonction du nombre d'instructions spécialisées chargées pour la prédiction en restant indépendante de l'allocation. Dans l'exemple considéré, la deuxième période applicative PRD2 a été exécutée sur un cœur basique et la troisième, PRD3, sur un cœur étendu (tout comme la première période PRD1 ). Si on se basait sur des portions de durée fixe, aucune relation simple ne pourrait être trouvée entre les données collectées à la période PRD2 pour prédire celle de la même portion à la période PRD3. Une découpe en périodes de durée fixe nécessite aussi d'une part plus d'interventions du contrôleur et d'autre part des interpolations assez coûteuses pour ramener les mesures collectées à des données exploitables pour la prédiction. Par contre, conformément à l'invention, les portions comprennent un nombre sensiblement égal d'instructions spécialisées, ce qui permet de mettre en relation des portions de même rang de périodes différentes.
Pour délimiter les portions des périodes, il est nécessaire de comptabiliser le nombre global d'instructions spécialisées chargées de l'extension « HWm ». Pour accélérer cette comptabilisation et la rendre la moins intrusive il peut être avantageux de prévoir un compteur matériel dédié qui s'incrémente à chaque chargement d'une instruction spécialisée de l'extension « HWm» et qui déclenche une interruption sur le cœur en question pour appeler une routine de suivi et de gestion système qui doit être enclenchée à chaque portion. Dans ce mode de réalisation, les périodes comprennent de préférence exactement le même nombre d'instructions spécialisées chargées de l'extension « HWm » (sauf la dernière période, qui peut être incomplète). Dans des variantes dégradées, cependant, une marge de tolérance - typiquement inférieure à 10% voire à 5% - peut être admise.
Dans un autre mode de réalisation, il est possible d'utiliser un compteur de type alarme avec un quantum de temps fixe qui lève une interruption sur le cœur courant. La routine appelée par cette interruption consulte le compteur matériel du nombre d'instructions spécialisées de l'extension « HWm» et appelle la routine de gestion lorsque le nombre d'instructions spécialisées requis par portion est atteint. Dans ce mode de réalisation, le nombre d'instructions spécialisées chargées de l'extension « HWm » est approximativement le même, avec une marge erreur d'autant plus petite que le quantum de temps est petit. De préférence, on choisira ce quantum de telle sorte que la marge d'erreur soit inférieure à 5%, voire à 10%.
D'une manière générale, le passage d'une période applicative à la suivante s'effectue lorsque le nombre d'instructions spécialisées atteint ou dépasse une valeur de seuil prédéfinie.
3 Prédiction des exécutions futures des instructions spécialisées
L'invention prévoit un suivi, pour chaque portion « k » de la période « n » :
du nombre d'instructions spécialisées exécutées de chaque famille « /' » identifiée dans la première étape de la méthode:
Nb(m, i, k, n) ;
- du nombre total d'instructions exécutées hors émulation pour les cœurs basiques et hors instructions spécialisées pour les cœurs étendus: Nb_basiC(k,n) ;
du temps d'exécution effectif de la portion k de la période n : T( n) ; et
- du nombre d'instructions basiques liées à l'émulation de chaque extension « HWm» absente : Nb_emul(m!k,n). Sauf en ce qui concerne le temps d'exécution, le suivi est réalisé au moyen des compteurs décrits plus haut en référence à la figure 3.
La méthode prévoit la prédiction, pour la même portion k de la période applicative suivant n+ 1 du :
nombre d'instructions spécialisées de chaque famille « / » de l'extension « HWm » :
Nb_Pred(m, h K n+i) = a. Nb(m, /, K n) + (1 - a) Nb_Pred(m, K n)
[4] - nombre d'instructions exécutées hors émulation et hors instructions spécialisées de l'extension « HWm» :
Nb_Pred_basic(k, n+i) = a. Nb_basic(k, n) + (1 - a) Nb_Pred_basic( n)
[5] nombre d'instructions basiques liées à l'émulation de chaque extension « HWm» absente:
Nb_Pred_emul(m,k,n+ 1) = a.Nb_emul(m,k,n) + (1 -a) Nb_Pred_emul(m,k,n)
[6]
Ces équations recoursives doivent être initialisées. Les valeurs d'initialisation peuvent par exemple être obtenue par étalonnage.
Estimation des coûts/gains en performance et en énergie des différentes opportunités de gestion
Une fois effectuée la prédiction de la future utilisation des extensions matérielles, il est possible d'estimer les coûts/gains en performance et en énergie de chacune des opportunités de gestions qui sont offertes sur la prochaine portion de la période courante. Ces opportunités sont par exemple:
Migration d'un cœur étendu (avec ses variantes Full, {base+HW-i), (base+HW2)) (resp. basique) vers un cœur basique (resp. étendu). Cela comporte une sauvegarde du contexte d'exécution courant sur le cœur étendu (resp. basique), l'activation d'un cœur basique (resp. étendu) s'il n'y a pas de cœurs actifs et libres à ce moment-là, la migration du contexte vers ce nouveau cœur cible, la mise du cœur étendu (resp. basique) en mode non-fonctionnel basse consommation et la poursuite de l'exécution sur le cœur basique (resp. étendu).
Changement du couple tension fréquence (DVFS de l'anglais « Dynamic Voltage and Frequency Setting », c'est-à-dire ajustement dynamique de la tension et de la fréquence) sur le cœur courant : décision de poursuivre l'exécution sur le cœur courant mais avec un couple tension fréquence différent.
Toute combinaison des deux dernières opportunités (migration + DVFS)
L'estimation faite des coûts/gains en performance et en énergie se fait sur la base d'une période entière. La méthode estime à cette étape la QoS et l'énergie consommée en fin de période en estimant des décisions au niveau des portions.
La QoS applicative est souvent ramenée à l'inverse d'un temps d'exécution sur la période applicative considérée. Ce temps peut être estimé en sommant les estimations des temps d'exécution sur les différentes portions de cette période.
L'énergie consommée est la somme des contributions des cœurs, estimées selon l'allocation faite et selon le couple DVFS choisi sur chaque portion, puis ramenées sur la période entière.
Coût d'émulation / accélération:
paré à la même portion de la période précédente, le surcoût d'émulation en temps des instructions de l'extension matérielle « m » sur la portion « / », prédit pour la période n+1 et pour une fréquence d'exécution F1 , est donné par :
∑i (.Nb_Pred(m i CoÛt_moy_Inst m i^) x CPI
Fl m où Nb_Pred(m , /, k, n+ 1) est le nombre d'instructions spécialisées prédit sur la période n+ 1 de la famille /' sur la portion k (voir équation [4]). CPI (« Cycles per Instruction », c'est-à-dire « cycles par instruction »,) est le paramètre permettant de quantifier le coût moyen d'une instruction en termes de cycles processeur. En divisant ce nombre de cycles par la fréquence (ici F1) du processeur on obtient le temps moyen d'exécution d'une instruction.
Comparé à la même portion de la période précédente, le surcoût (ici négatif) d'une accélération des instructions de l'extension matérielle « m » en migrant vers un cœur avec cette extension est donné par :
Comparé à la même portion de la période précédente, le surcoût d'émulation en énergie des instructions de l'extension matérielle « m » sur la portion « / », prédit pour la période n+1 et pour une fréquence d'exécution F1 , est donné par l'équation suivante pour les deux variantes : Kemui_energie surcoût dû à l'émulation et Kaccei_energie surcoût dû à l'accélération sur cœur avec extension « m » :
Kemul/accel_energie(m, k, n+ 1, F1) = x
Figure imgf000024_0001
Où P1 et P2 représentent respectivement les puissances moyennes du cœur courant et celui de destination.
P1 représente la puissance du cœur possédant l'extension « m » (respectivement dépourvu de l'extension « m ») et P2 est celle du cœur dépourvu de cette extension (respectivement possédant l'extension « m ») et vers lequel on estime le coût de migration dans le cas d'une émulation (respectivement dans le cas d'une accélération). Nb_total(k,n) est le nombre total d'instructions sur la période précédente « n » et sur la même portion « k ». Coût de changement de tension/fréquence (DVFS) :
Comparé à la même portion de la période précédente, le surcoût en temps du changement de couple tension fréquence sur la portion « k » à allocation constante, prédit pour la période n+1 et pour un changement d'une fréquence d'exécution F1 vers F2 est donné par l'équation suivante :
F1—F2
KDVFS_temps(m, k, n+ 1, F1 ^ F2) = Nb Otdl^ X CPI X ( ριχρ2 ) [ 0]
Comparé à la même portion de la période précédente, le surcoût en énergie du changement de couple tension fréquence sur la portion « k » à allocation constante, prédit pour la période n+1 et pour un changement d'une fréquence d'exécution F1 vers F2, est donné par l'équation suivante :
„ _ „ rFl X P2 - F2 X Pl^
I^DVFS_energie(m, k, n+ 1, F1 ^ F2) - ^DVFS_temps{m,k,n+l,Fl→F2) x C F1-F2
[1 1 ]
Où P1 (respectivement P2) représente la puissance moyenne du cœur courant au point de fonctionnement DVFS donné par la fréquence F1 (respectivement F2).
Coût de changement simultané de couple tension/fréquence (DVFS) et d'allocation (émulation/accélération):
Comparé à la même portion de la période précédente, le surcoût en temps du changement de couple tension fréquence sur la portion « k » à allocation constante, prédit pour la période n+1 et pour un changement d'une fréquence d'exécution F1 vers F2 est donné par l'équation suivante avec les deux variantes :
- KDVFs_emui_temps surcoût dû à l'émulation et au DVFS ; et
KDVFs_acœi_temps surcoût dû à l'accélération sur cœur avec extension « m » et DVFS:
K-DVFS_emul/accel_temps(m, k, n+ 1, F1 _^ F2) = Kemul/accel_temps(m, k, n+ 1, F2) + KDVFS_temps(m, k, n+ 1, F1 _> F2) [12] Comparé à la même portion de la période précédente, le surcoût en énergie prédit pour la période n+1 du changement de couple tension fréquence sur la portion « k » et pour un changement d'une fréquence d'exécution F1 vers F2 avec migration, est donné par l'équation suivante avec les deux variantes :
KDVFs_emui_energie surcoût dû à l'émulation et au DVFS ; et KDVFs_accei_energie surcoût dû à l'accélération sur cœur avec extension « m » et DVFS: KDVFS_emul/accel_energie(m, k, n+ 1, F1 ^ F2) = {Kemul/accel_temps(m, k, n+ 1, F2) X P2) + KDVFS_energie(m, k, n+ 1, F1 _> F2) [13]
Où P1 représente la puissance moyenne du cœur courant au point de fonctionnement DVFS donné par la fréquence F1 et P2 représente la puissance moyenne du cœur destination au point de fonctionnement donné par la fréquence F2.
Prise de décision
L'estimation du coût des différentes options de gestion sert à permettre une prise de décision garantissant une QoS minimale tout en minimisant l'énergie consommée.
La figure 6 donne un exemple de prise de décision à la granularité d'une portion pour maintenir une qualité de service au-dessus de la QoS minimale et minimiser l'énergie. Cette figure reprend la figure 4 en y ajoutant :
la décomposition des périodes en portions ;
l'indication du cœur de processeur utilisé dans chaque portion, et de la consommation énergétique correspondante.
Pour garantir cette condition et éviter des oscillations et des gestions superflues, on définit deux intervalles de prise de décision [QoS_Min,
QoS_bas] et [QoS_Haut, QoS_Max] (représentés sur la figure 6) sur lesquels on décide de déclencher des actions de gestion et on garde le système tel quel si la QoS calculée rentre dans l'intervalle intermédiaire [QoS_bas, QoS_Haut].
Dans un mode de réalisation de l'invention, on cherche à déterminer la marge par rapport à la qualité de service QoS_bas (comme illustré par la figure 6) sur la dernière période exécutée et de distribuer cette marge sur les différentes portions de la période suivante de manière à ce que les décisions prises au niveau portion bénéficient de cette portion de marge pour choisir une opportunité de gestion (migration, changement de couple DVFS, une combinaison des deux) qui diminue l'énergie consommée sous contrainte de respect de cette portion de marge.
La marge de QoS est ramenée à une marge de temps « jUoos » : positive lorsque la QoSn est supérieure à QoS_bas et négative dans le cas contraire (cas de la marge sur la troisième période de la figure 6) et sa distribution sur les N portions de la période peut se faire de manière égale comme elle peut être plus intelligemment choisie par exemple par rapport au ratio d'utilisation de l'extension « m » dont l'émulation est la plus pénalisante en temps (Tm voir équation [1 ]) calculé sur chaque portion « k » : T(m, k ,n Une implémentation privilégierait par exemple la distribution de la marge aux portions de période avec les ratios d'utilisation les moins élevés car ils ont des opportunités d'émulation plus importantes.
Une seconde marge (positive ou négative aussi) peut être introduite par rapport à la prédiction de l'évolution du nombre d'instructions spécialisées dans le temps.
On calcule à la fin de chaque portion k de la période n la prédiction du temps d'exécution, à allocation constante, de la portion k à la période n+ 1 :
T_Pred (k, n+ i) =
Freq
Nb_Pred_basiC(k n+1-) +
∑emuiées m(∑i Nb_Pred(m:i n+1) x CoÛt_moy_InstM ) + [14]
∑executées m'(∑t Nb_Predçm'iiji n+^ ) Cette estimation prend en compte l'émulation des extensions matérielles non supportées (émulées m) par le cœur utilisé à la portion k de la période n en sommant le cout de leur émulation et l'exécution des instructions prédites des extensions supportées (exécutées m').
La seconde marge utilisable peut être calculée par l'équation suivante :
Figure imgf000028_0001
= T_Pred (k, n+ 1) " T(k n) [ 5] où T(k,n) est le temps d'exécution effectif sur la portion k de la période précédente n:
La marge collectée par la portion / est :
Figure imgf000028_0002
Avantageusement, cette méthode opère de manière incrémentale en partant de la mise en œuvre choisie à la même portion de la période précédente et en estimant les surcoûts des opportunités de gestion. Le choix de l'opportunité de gestion la plus adéquate vis-à-vis de la marge « μ^ » allouée à la portion k se fait avantageusement en considérant un paramètre qui intègre conjointement la performance et l'énergie comme l'EDP (produit énergie - latence, de l'anglais « Energy Delay Product »).
Selon un mode de réalisation de l'invention, la différence des surcoûts (ramenée à une grandeur énergétique) est utilisée comme paramètre à maximiser pour guider le choix de l'opportunité de gestion. Pour une opportunité de gestion « opp », pour une portion « k », et une puissance moyenne P1 (puissance du cœur utilisé à la portion k de la période précédente), cette différence est donnée par la formule suivante :
Dopp(k) = {Kopp_temps(k) X 1 ) " Kopp_energie(k) [17] Dans l'équation [17], KoppJemps{k) est le coût en temps d'une opportunité de gestion ; en fonction de l'opportunité retenue, il peut valoir par exemple Kemuijemps, KacCei_temps ou KovFsjemps- De même, Kopp_energie(k) est le coût en énergie d'une opportunité de gestion ; en fonction de l'opportunité retenue, il peut valoir par exemple Kemui_ énergie, Kaccel_energie OU KoVFS_energie- La condition à satisfaire est donc que :
Kopp emps(k) < f-l(k)
et
Dopp(k) = MaXtoutes les opp{D0pp(k)) [1 8]
Par exemple, sur la première portion de la troisième période de la figure 6 on voit que la décision a été prise de changer l'allocation précédente (première portion de la deuxième période) qui était sur un cœur basique avec une extension HW1 vers un cœur basique car la marge allouée à cette portion de période permettait de le faire avec une consommation d'énergie plus faible. Pour la troisième et dernière portion de la période 3, on peut noter que l'opportunité qui maximisait la différence de surcoût D sur cette portion était celle qui migrait vers un cœur basique et qui changeait en même temps la fréquence d'exécution sur ce cœur.
Un autre mode de réalisation possible de la phase de prise de décision se base sur le principe de privilégier l'allocation sur cœur basique sur les premières portions, tant que l'estimation de la QoS en fin de période reste au dessus de la qualité de service minimale, et accélérer ensuite l'exécution en migrant vers un cœur étendu dans les dernières portions. Cette méthode tend à retarder au maximum la migration sur un cœur étendu tout en garantissant une QoS minimale en fin de période privilégiant ainsi l'utilisation de cœurs basique moins performants mais peu gourmands en énergies.
Dans ce mode de réalisation, juste à la fin de la portion k- 1 de la période courante, l'estimation de la QoS en fin de période considère une allocation de la portion k sur un cœur basique et une allocation des portions suivantes {k+ 1 à N) sur un cœur étendu. Dans cette méthode, l'allocation à la première portion est estimée sur un cœur basique avec toutes les autres portions sur un cœur étendu et on vérifie si la QoS en fin de période reste supérieure à QoSmjn. La prédiction du temps d'exécution sur cœur étendu de la portion k (T_Etondu_Prod(k)) correspond au calcul de T_Pred(ki n+ i) de l'équation [14] en considérant que toutes les extensions sont présentes. De manière similaire, la prédiction du temps d'exécution sur cœur basique de la portion k (T_Basic_Pred(kj) correspond au calcul de T_Pred(kt n+ 1) de l'équation [14] en considérant que toutes les extensions sont émulées.
La QoS prédite en fin de période en estimant que la portion k est allouée sur un cœur basique et que le reste des portions sont allouées sur un cœur étendu est calculée par l'équation suivante :
QoS_Predn+i =∑i≤j <k T n) + T_Base_Pred(k) +∑j≤N-k T_Etendu_Pred(k+j) [19]
Si la condition QoS_Predn+i > QoSmjn est satisfaite, on exécute l'allocation prédite. Sinon, on change de manière incrémentale la fréquence de l'allocation de la portion k, ensuite on considère un changement d'allocation à une basse fréquence et on augmente progressivement la fréquence et ainsi de suite.
La mise en œuvre duale, qui privilégie l'allocation de la portion / sur un cœur étendu en considérant que les autres portions suivantes (k+ 1 à N) vont être alloués sur un cœur basique est aussi une réalisation possible. Tant que la condition QoS_Predn+i > QoSmjn n'est pas vérifiée, on décide de continuer à allouer sur le cœur étendu la portion suivante. Dès que cette condition est vérifiée, on prédit de manière incrémentale la QoS en fin de période en estimant, dans le même ordre que dans la méthode précédente, les opportunités de gestion possibles.
Un procédé selon l'invention est mis en œuvre grâce à un produit programme d'ordinateur comprenant des instructions exécutables par un processeur multi-cœurs fonctionnellement asymétrique (processeur PR de la figure 1 ), stockées sur un support non-volatil lisible par ledit processeur (par exemple une mémoire morte MM, illustrée sur la figure 1 ). Avantageusement, comme cela a été décrit en particulier en relation à la figure 3, le processeur multi-cœurs fonctionnellement asymétrique peut présenter des moyens matériels spécifiques : circuits de filtrage d'instructions et compteurs. Un tel processeur et une mémoire non volatile stockant le produit programme d'ordinateur peut avantageusement former, avec d'autres composants (mémoires vives, périphériques...), un système informatique, typiquement embarqué.
L'invention a été décrite en relation à un mode de réalisation particulier, mais des variantes sont possibles. Par exemple, à titre non limitatif, d'autres formules de calcul des coûts peuvent être utilisées ; les prédictions peuvent ne pas être obtenues par moyenne glissante mais, par exemple, par filtrage de Kalman ; la répartition entre fonctionnalités mises en œuvre de manière logicielle ou matérielle peut varier.

Claims

REVENDICATIONS
1 . Procédé mis en œuvre par ordinateur pour la gestion d'une tâche de calcul sur un processeur multi-cœurs fonctionnellement asymétrique (PR), l'exécution de ladite tâche comprenant une succession de périodes applicatives, ledit processeur comprenant une pluralité de cœurs (PC1 - PC4) partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle (HW1 , HW2), ladite ou chaque extension matérielle étant adaptée pour permettre l'exécution d'instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, le procédé comprenant les étapes suivantes :
a) démarrer l'exécution de la tâche de calcul sur un cœur dudit processeur ;
b) effectuer, au cours de ladite exécution, un suivi d'un paramètre (QoS) indicatif d'une qualité de service de la tâche de calcul, ainsi que d'au moins un nombre d'instructions spécialisées chargées par ledit cœur;
c) sur la base dudit suivi, identifier des instants découpant une période applicative de la tâche de calcul en un nombre prédéterminé de portions (PTS) de telle façon que, au cours de chacune desdites portions, un nombre sensiblement égal d'instructions spécialisées associées à une extension matérielle prédéfinie soient chargées par ledit cœur ;
d) calculer, auxdits instants et en fonction dudit suivi, des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes options de gestion de la tâche de calcul, une dite option de gestion consistant à poursuivre l'exécution sur le même cœur du processeur et au moins une autre option de gestion consistant à poursuivre l'exécution sur un cœur différent ; et
e) effectuer un choix de gestion consistant à choisir parmi lesdites options de gestion en fonction des coûts ou gains ainsi calculés.
2. Procédé selon la revendication 1 dans lequel ladite étape c) comprend la prévision du nombre d'instructions spécialisées associées à ladite extension matérielle chargées au cours de chaque portion d'une période applicative courante à partir du nombre de dites instructions spécialisées chargées lors de portions correspondantes d'au moins une période applicative précédente.
3. Procédé selon l'une des revendications précédentes dans lequel ladite extension matérielle prédéfinie est celle adaptée pour permettre l'exécution des instructions spécialisées dont l'émulation présenterait le coût en qualité de service le plus élevé.
4. Procédé selon l'une des revendications précédentes dans laquelle le choix de gestion effectué lors de l'étape e) comprend la décision de poursuivre l'exécution de la tâche de calcul sur le même cœur ou sur un cœur différent de manière à minimiser la consommation énergétique du processeur tout en respectant une contrainte de qualité de service.
5. Procédé selon la revendication 4 dans lequel ladite étape e) comprend :
e1 ) déterminer une marge de qualité de service sur une période applicative précédente ;
e2) distribuer cette marge entre les portions de la période courante ; et
e3) pour chaque portion de la période courante, effectuer un dit choix de gestion permettant de diminuer la consommation énergétique sous contrainte de respect de la marge de qualité de service distribuée audit portion, lorsque cela est possible.
6. Procédé selon la revendication 4 dans lequel :
lors de l'étape a), l'exécution de la tâche de calcul est démarrée sur un cœur ne comprenant pas d'extensions matérielle ; lors de ladite étape e), une décision de poursuive l'exécution de la tâche de calcul sur un autre processeur, comprenant au moins une exécution matérielle, est prise lorsque cela est nécessaire pour assurer le respect d'une contrainte de qualité de service.
7. Procédé selon l'une des revendications précédentes dans lequel ledit choix de gestion comprend également une décision de maintenir ou de changer un couple fréquence d'horloge - tension d'alimentation du cœur.
8. Procédé selon l'une des revendications précédentes dans lequel les instructions spécialisées associées à chaque extension matérielle sont regroupées en un nombre prédéfini de familles, ce nombre étant supérieur à 1 pour au moins une dite extension matérielle et au moins une dite famille comprenant plusieurs instructions ; et dans lequel, lors de l'étape d), les instructions d'une même famille sont considérées comme une seule et même instruction aux fins du calcul desdits coûts ou gains en qualité de service et en consommation énergétique.
9. Procédé selon la revendication 8 dans lequel le nombre de familles dans lequel les instructions spécialisées associées à chaque extension matérielle sont regroupées est choisi de manière à minimiser des erreurs affectant le calcul des coûts ou gains en qualité de service et en consommation énergétique effectué lors de l'étape d).
10. Procédé selon l'une des revendications 8 et 9 dans lequel l'étape b) comprend le suivi :
du nombre d'instructions basiques;
du nombre d'instructions spécialisées associées à chaque extension matérielle que ledit cœur ne comprend pas ; du nombre d'instructions spécialisées appartenant à chaque famille d'instructions spécialisées associées à chaque extension matérielle que ledit cœur comprend ; et
du nombre d'instructions basiques utilisées pour l'émulation des instructions spécialisées associées à chaque extension matérielle que ledit cœur ne comprend pas ;
chargées par ledit cœur.
1 1 . Procédé selon l'une des revendications précédentes comportant une étape préalable de chargement en mémoire d'un ensemble de paramètres de caractérisation représentatifs d'une distribution statistique des coûts d'émulation en temps et énergie des instructions spécialisées, dans lequel l'étape d) est mise en œuvre utilisant lesdits paramètres de caractérisation.
12. Procédé selon la revendication 1 1 comportant également une étape préalable d'étalonnage pour déterminer lesdits paramètres d'étalonnage.
13. Procédé selon l'une des revendications précédentes dans lequel ledit paramètre (QoS) indicatif d'une qualité de service de la tâche de calcul est représentatif de l'inverse d'un temps d'exécution de ladite tâche de calcul.
14. Produit programme d'ordinateur stocké sur un support
(MM) non-volatil lisible par ordinateur comprenant des instructions exécutables par ordinateur pour la mise en œuvre d'un procédé selon l'une des revendications précédentes.
15. Processeur multi-cœurs (PR) fonctionnellement asymétrique comprenant une pluralité de cœurs (PC1 - PC4) partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle (HW1 , HW2), ladite ou chaque extension matérielle étant adaptée pour permettre l'exécution d'instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, caractérisé en ce qu'il comprend également :
des circuits de filtrage, configurés pour trier les instructions basiques et les instructions spécialisées associées aux différentes extensions matérielles, et pour attribuer chaque instruction spécialisée à une famille, où chaque famille comprend une ou plusieurs instructions spécialisées associées à une même extension matérielle et au moins une extension matérielle est associée à des instructions comprises dans une pluralité de familles distinctes ; et
pour chaque cœur :
un compteur (Nb_basic) d'instructions basiques chargées par le cœur ;
pour chaque extension matérielle non comprise par ledit cœur, un compteur (Nb(HW1 ), Nb(HW2)) d'instructions spécialisées associées à ladite extension matérielle chargées par le cœur, ainsi qu'un compteur du nombre d'instructions basiques utilisées pour l'émulation des instructions spécialisées associées ; et
pour chaque extension matérielle comprise par ledit cœur, et pour chaque famille d'instructions spécialisées associées à ladite extension matérielle, un compteur (Nb(HW1 ,i), Nb(HW2,i)) d'instructions spécialisées associées à ladite extension matérielle et appartenant à ladite famille chargées par le cœur.
1 6. Système informatique comprenant un processeur (PR) multi-cœurs fonctionnellement asymétrique selon la revendication 15 et une mémoire non-volatile (MM) stockant des instructions exécutables par ledit processeur pour la mise en œuvre d'un procédé selon l'une des revendications 1 à 13.
PCT/EP2017/072376 2016-09-29 2017-09-06 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique WO2018059897A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/333,974 US10846086B2 (en) 2016-09-29 2017-09-06 Method for managing computation tasks on a functionally asymmetric multi-core processor
EP17761281.9A EP3519954A1 (fr) 2016-09-29 2017-09-06 Procede de gestion des taches de calcul sur un processeur multi-coeurs fonctionnellement asymetrique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1659367A FR3056786B1 (fr) 2016-09-29 2016-09-29 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
FR1659367 2016-09-29

Publications (1)

Publication Number Publication Date
WO2018059897A1 true WO2018059897A1 (fr) 2018-04-05

Family

ID=57906737

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/072376 WO2018059897A1 (fr) 2016-09-29 2017-09-06 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique

Country Status (4)

Country Link
US (1) US10846086B2 (fr)
EP (1) EP3519954A1 (fr)
FR (1) FR3056786B1 (fr)
WO (1) WO2018059897A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200090000A1 (en) 2018-09-18 2020-03-19 Microsoft Technology Licensing, Llc Progress Portal for Synthetic Data Tasks
CN113452788B (zh) * 2021-06-29 2022-04-26 中国地质大学（北京） 一种动态网络中基于服务迁移的适配优化方法
US20230205592A1 (en) * 2021-12-23 2023-06-29 Intel Corporation Asymmetric tuning

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7246219B2 (en) * 2003-12-23 2007-07-17 Intel Corporation Methods and apparatus to control functional blocks within a processor
US8615647B2 (en) * 2008-02-29 2013-12-24 Intel Corporation Migrating execution of thread between cores of different instruction set architecture in multi-core processor and transitioning each core to respective on / off power state
US8892916B2 (en) * 2008-08-06 2014-11-18 International Business Machines Corporation Dynamic core pool management
US9268611B2 (en) * 2010-09-25 2016-02-23 Intel Corporation Application scheduling in heterogeneous multiprocessor computing platform based on a ratio of predicted performance of processor cores
KR102082859B1 (ko) * 2013-01-07 2020-02-28 삼성전자주식회사 복수의 이종 코어들을 포함하는 시스템 온 칩 및 그 동작 방법
US10423216B2 (en) * 2013-03-26 2019-09-24 Via Technologies, Inc. Asymmetric multi-core processor with native switching mechanism

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
A. AMINOT: "Méthode dynamique pour améliorer le placement de tâches sur processeurs asymétriques en fonctionnalités", 2015, UNIVERSITÉ DE GRENOBLE
AMINOT, ALEXANDRE.: "Placement de tâches dynamique et flexible sur processeur multi-coeur asymétrique en fonctionnalités.", 1 October 2015 (2015-10-01), Grenoble, pages pp. 1 - 137, XP008184790, Retrieved from the Internet <URL:https://hal-cea.archives-ouvertes.fr/tel-01288227/document> [retrieved on 20170602] *
G. GEORGAKOUDIS; D. S. NIKOLOPOULOS; H. VANDIERENDONCK; S. LALIS: "Fast Dynamic Binary Rewriting for flexible thread migration on shared-ISA heterogeneous MPSoCs", INTERNATIONAL CONFÉRENCE ON EMBEDDED COMPUTER SYSTEMS: ARCHITECTURES, MODELING, AND SIMULATION (SAMOS XIV, 2014, pages 156 - 163, XP032636988, DOI: doi:10.1109/SAMOS.2014.6893207
GEORGAKOUDIS GIORGIS ET AL: "Fast Dynamic Binary Rewriting for flexible thread migration on shared-ISA heterogeneous MPSoCs", 2014 INTERNATIONAL CONFERENCE ON EMBEDDED COMPUTER SYSTEMS: ARCHITECTURES, MODELING, AND SIMULATION (SAMOS XIV), IEEE, 14 July 2014 (2014-07-14), pages 156 - 163, XP032636988, DOI: 10.1109/SAMOS.2014.6893207 *
H. HOFFMANN; J. EASTEP; M. D. SANTAMBROGIO; J. E. MILLER; A. AGARWAL: "Application Heartbeats: A Generic Interface for Specifying Program Performance and Goals in Autonomous Computing Environments", PROCEEDINGS OF THE 7TH INTERNATIONAL CONFÉRENCE ON AUTONOMIE COMPUTING, 2010, pages 79 - 88
H. SHEN; F. PÉTROT: "Novel Task Migration Framework on Configurable Heterogeneous MPSoC Platforms", PROCEEDINGS OF THE 2009 ASIA AND SOUTH PACIFIC DESIGN AUTOMATION CONFÉRENCE, 2009, pages 733 - 738
T. LI; P. BRETT; R. KNAUERHASE; D. KOUFATY; D. REDDY; S. HAHN: "Operating system support for overlapping-ISA heterogeneous multi-core architectures", IEEE 16TH INTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCE COMPUTER ARCHITECTURE (HPCA, 2010, pages 1 - 12

Also Published As

Publication number Publication date
US10846086B2 (en) 2020-11-24
FR3056786A1 (fr) 2018-03-30
US20190250919A1 (en) 2019-08-15
FR3056786B1 (fr) 2019-11-22
EP3519954A1 (fr) 2019-08-07

Similar Documents

Publication Publication Date Title
Al-Dhuraibi et al. Elasticity in cloud computing: state of the art and research challenges
US10015241B2 (en) Automated profiling of resource usage
FR3035243A1 (fr) Placement d&#39;une tache de calcul sur un processeur fonctionnellement asymetrique
Ananthanarayanan et al. Effective straggler mitigation: Attack of the clones
US9268663B1 (en) Software testing analysis and control
EP2987081B1 (fr) Procédé d&#39;allocation temporelle de tâches permettant une récupération d&#39;erreur deterministe en temps réel
US9612751B2 (en) Provisioning advisor
EP2447838A1 (fr) Technique de parallélisation efficace d&#39;analyse logicielle dans un environnement informatique distribué par l&#39;équilibrage de charge dynamique intelligente
EP3674892B1 (fr) Économie d&#39;énergie par l&#39;intermédiaire d&#39;une programmation de puissance automatisée de machines virtuelles
FR3056786B1 (fr) Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
EP2447840B1 (fr) Gestion de calcul partiel dynamique et intelligent pour parallélisation efficace d&#39;analyse logicielle dans un environnement informatique distribué
Breitgand et al. An adaptive utilization accelerator for virtualized environments
EP3502895A1 (fr) Commande de la consommation énergétique d&#39;une grappe de serveurs
Ferry et al. Towards Bridging the Gap Between Scalability and Elasticity.
WO2014072628A1 (fr) Procédé, dispositif et programme d&#39;ordinateur de placement de tâches dans un système multi-coeurs
Feliu et al. Symbiotic job scheduling on the IBM POWER8
US9087150B2 (en) Performance analysis system for analyzing inter-thread communications to enhance performance in multithreaded system
Khan et al. Modeling the autoscaling operations in cloud with time series data
Yang et al. An analysis of performance interference effects on energy-efficiency of virtualized cloud environments
CA2874115A1 (fr) Procede de gestion d&#39;une execution de taches dans un systeme informatique
Sant'Ana et al. Real-time scheduling policy selection from queue and machine states
EP2656171A1 (fr) Procede de gestion de la consommation energetique d&#39;une application executable dans differents environnements et architecture logicielle mettant en uvre un tel procede
Massari et al. Harnessing performance variability: A HPC-oriented application scenario
CN107729155B (zh) 并行离散事件仿真负载平衡方法、装置、介质和计算机设备
FR3027419A1 (fr) Procede de determination d&#39;une frequence optimale pour l&#39;execution d&#39;une application logicielle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17761281

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017761281

Country of ref document: EP

Effective date: 20190429