EP3286647A1 - Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique - Google Patents

Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique

Info

Publication number
EP3286647A1
EP3286647A1 EP16711185.5A EP16711185A EP3286647A1 EP 3286647 A1 EP3286647 A1 EP 3286647A1 EP 16711185 A EP16711185 A EP 16711185A EP 3286647 A1 EP3286647 A1 EP 3286647A1
Authority
EP
European Patent Office
Prior art keywords
processor
instructions
core
hardware
task
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP16711185.5A
Other languages
German (de)
English (en)
Inventor
Alexandre AMINOT
Yves LHUILLIER
Andréa CASTAGNETTI
Alain CHATEIGNER
Henri-Pierre CHARLES
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Publication of EP3286647A1 publication Critical patent/EP3286647A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic instructions
    • G06F9/30014—Arithmetic instructions with variable precision
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30021—Compare instructions, e.g. Greater-Than, Equal-To, MINMAX
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30083—Power or thermal control instructions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/3017—Runtime instruction translation, e.g. macros
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F9/4893—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues taking into account power or heat criteria
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • 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

  • the invention relates to multi-core processors in general and the management of the placement of calculation tasks on multi-core processors that are functionally asymmetrical in particular.
  • a multi-core processor may include one or more hardware extensions, intended to accelerate parts of very specific software codes that are difficult to parallelize.
  • these hardware extensions may include circuits for floating point computation or vector computation.
  • a multi-core processor is said to be "functionally asymmetric" when certain extensions fail some processor cores, i.e. when at least one core of the multi-core processor does not have the hardware extension required for execution of a given instruction set.
  • a functionally asymmetric processor can be characterized by unequal distribution (or association) of extensions to the cores of processors. Managing a functionally asymmetric multi-core processor poses several technical problems. One of these technical problems is to effectively manage the placement of computing tasks on different processor cores.
  • Patent document WO2013101139 entitled "PROVIDING AN ASYMMETRIC MULTICORE PROCESSOR SYSTEM TRANSPARENTLY TO AN OPERATING SYSTEM” discloses a system comprising a multi-core processor with several groups of cores.
  • the second group may be of an instruction set architecture (ISA) different from the first group, or of the same ISA architecture to be defined but with a different level of power and performance of media.
  • the processor further includes a migration unit that processes the migration requests for a number of different scenarios and causes a context switch to dynamically migrate a process from a second core to a first core of the first group. This change of material context dynamic can be transparent to the operating system.
  • the present invention relates to a method for managing a computing task on a functionally asymmetric multi-core processor, wherein at least one core of said processor is associated with one or more hardware extensions, the method comprising the steps of receiving a task of calculation associated with instructions executable by a hardware extension; receive calibration data associated with the hardware extension; and determining an opportunity cost of performing the computing task based on the calibration data.
  • Developments describe the determination of the calibration data, in particular by counting or by calculation (online and / or offline) of the classes of instructions executed, the execution of a predefined set of instructions representative of the execution space of extension, consideration of energy and temperature aspects, translation or emulation of instructions or placement of calculation tasks on different cores. System and software aspects are described.
  • the invention is implemented at the hardware level (hardware) and the operating system.
  • the invention retrieves and analyzes certain information of the last quanta of execution (time allocated by the scheduler to the task on a heart) and thus estimates the cost future task placement on different types of hearts.
  • the task placement is flexible and transparent for the user.
  • the method according to the invention performs the placement of the calculation tasks according to more diversified and global objectives than the known solutions of the state of the art which stick to the instructions associated with the calculation tasks.
  • the placement of computation tasks involving the switching on or off of one or more cores is achieved by considering only the "strict" use of the extension.
  • a core that does not include extensions can not execute instructions for one or more particular extensions.
  • current solutions examine whether an extension is used (e.g. application placement on an extended core) or not used (e.g. placement on a core without an extension).
  • the known approaches consider the presence of call of such extensions within the source code but proceed to the placement of the tasks exclusively according to the code instructions and ignore in particular any other criterion, including energy.
  • Other known approaches are based on an analysis of the source code and the planned use of hardware extensions, proceed to code mutations, but without estimating criteria including, for example, degradation of performance or energy.
  • the invention can meet the so-called "multi-objective" needs to be met by a task scheduler such as a) performance, b) energy efficiency and c) thermal stresses ("dark-silicon").
  • a task scheduler such as a) performance, b) energy efficiency and c) thermal stresses ("dark-silicon”).
  • Certain embodiments make it possible to increase the number of cores of a multi-core processor, while keeping a performance / energy / surface efficiency. The additional programming effort remains small.
  • the prediction of the costs and the performance gains of a given task on each of the different cores of a heterogeneous system can be performed dynamically.
  • the method according to the invention takes into account dynamic criteria related to the execution of a program.
  • a hardware extension by a software code is dictated either explicitly by the programmer of the code, or automatically performed by the compiler.
  • the compilation of a software being most often done offline, the programmer or the compiler, can not base his choice to exploit or not an extension only on criteria which are linked to the software itself, and not on dynamic criteria for program execution.
  • Without information about the execution environment workload, instant task scheduling, availability of resources), it is usually impossible to determine in advance whether or not to use a given hardware extension.
  • the method according to the invention makes it possible to predict and / or estimate the use of one or more hardware extensions.
  • a dynamic scheduling and task placement strategy removing various constraints such as (i) predictability and interoperability in the use of constrained heterogeneous systems (functional asymmetry with common base ) and (ii) optimization against global objectives of the system (eg performance, consumption and surface), enabled by a fast, dynamic and transparent prediction of the execution of a given code on a given core .
  • certain embodiments of the invention include prediction steps as to the use of the extensions, which can advantageously optimize the energy efficiency and optimize the computing performance. These embodiments may in particular leave the scheduler a certain freedom as to the choice of cores on which to execute the different program phases.
  • the method according to the invention makes it possible to optimize the energy consumption, including in the case of a weak use of an extension.
  • the method according to the invention makes it possible to place a task on a processor, whether this processor is associated with a hardware extension or not, depending on the implementation of the task (thus with or without exploitation of the extension). As a result, a scheduler can dynamically optimize energy or performance without worrying about the initial implementation of the task.
  • the invention makes it possible to predict or dynamically determine the advantage of using one or more hardware extensions and to place the calculation tasks (ie to allocate these tasks to the different processors and or core processors) according to of this prediction.
  • the process according to the invention makes it possible to delay the whether or not to use a run-time extension, gives the programmer a higher level of abstraction, and gives the system software increased decision-making freedom for scheduling optimization. Once this flexibility is achieved, the quality of system software decisions becomes solely dependent on the execution environment. To do this, the system software measures the relevant variables of the runtime environment.
  • the method according to the invention makes it possible to have task migration freedoms and accumulated knowledge concerning the execution environment in order to optimize the placement of the calculation tasks on one or more asymmetrically functional multicore processors, and this according to the overall objectives of the scheduler.
  • the method according to the invention confers freedom of action with regard to the placement of calculation tasks.
  • Such freedom of action allows the system to migrate tasks (computation) on any processor core, and this despite the different extensions present in each of these cores.
  • the software applications running on the system are associated with a more continuous and flexible exploration space to achieve the objectives (or multi-objectives) in terms of power (eg thermal performance).
  • embodiments of the invention may be implemented for "System-on-Chip" (SoC) for consumer-type or on-board electronic applications (eg phones, embedded components, desktop, Internet of Things, etc.) .
  • SoC System-on-Chip
  • electronic applications eg phones, embedded components, desktop, Internet of Things, etc.
  • the use of heterogeneous systems is common to optimize computational efficiency for a workload specific. Since the latter systems are becoming increasingly complex (eg increasing the number of cores and workloads), certain embodiments of the invention make it possible to reduce the impact of this complexification, disregarding the heterogeneity of the systems.
  • the method according to the invention allows a dynamic optimization of the performance and the energy thanks to the estimator of the degradation and the unit of prediction.
  • the scalability of multi-core processors is improved.
  • the asymmetry management of the platform is done transparently for the user, that is to say does not increase the effort or constraints of software development.
  • an optimization of the scheduling makes it possible to better answer the technical problems which increase with the number of cores such as the reduction of the surface and the energy consumed, the priority of the tasks, the dark-silicon (temperature).
  • the placement / scheduling of tasks according to the invention is flexible.
  • the scheduling is done in an optimized and transparent manner for the user.
  • the method according to the invention provides for the use of prediction units ("predictor") and / or interest estimators, allowing optimized task placement.
  • the compiler can use an extension by planning that it will accelerate the execution, but because of the additional memory displacement (eg between the extension and the register of the "basic" cores), the performance will actually be depreciated.
  • the choice of job placement according to the method is flexible.
  • the objective of the operating system is not always to optimize the performance, the objective can be a minimization of the energy consumed or a placement optimizing the temperature of the cores ("dark silicon") . Due to dependency on the instruction set, the scheduler may be forced to execute an application according to its resource requirements and not considering a overall objective.
  • the placement is independent of other parameters supervised by the scheduler.
  • a scheduler typically allocates a quanta of time to each compute task on a processor. If the calculation of a task is not completed, another quanta will be associated with it. The size of these quanta is variable to allow a fair and optimized sharing of different tasks between different processors (typically between 0.1 and 100ms).
  • the quantum dimensioning involves a more or less fine detection of the basic type phases. There may be edge effects (eg, ceaseless migrations). Sticking to these edge effects ultimately reduces investment flexibility and optimizations. Description of figures
  • FIG. 1 illustrates examples of processor architectures
  • FIGS. 2A and 2B illustrate some aspects of the invention in terms of energy efficiency, depending on whether hardware extensions are used or not;
  • Figure 3 illustrates examples of architectures and job placement
  • Figure 4 provides examples of steps of the method according to the invention. Detailed description of the invention
  • the invention generally allows optimized placement of computational tasks on a functionally asymmetric multi-core processor.
  • a functionally asymmetric multi-core processor comprises programmable elements or processor cores, using more or less extensive functionalities.
  • An “extended” core ie, with one or more hardware extensions
  • a “hardware extension” or “hardware extension” is a circuit such as an FPU floating data computing unit, a vector computing unit, a SIMD, a cryptographic processing unit, a communication unit. signal processing, 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. These specific circuits improve 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 pipeline, allowing efficient access to functions through instructions added to the "basic" set (by comparison, a specialized "coprocessor” usually requires protocol-like instructions.
  • a calculation task (or "thread” in English) includes instructions, which may be grouped into instruction sequences (temporally) or games or classes of instructions (by nature).
  • the term “computational task” (or “task”) refers to a “thread” or “thread”.
  • Other denominations include phrases such as “light process”, “processing unit”, “execution unit”, “instruction thread”, “lightened process” or “exetron”.
  • the expression designates the execution of a set of instructions of the machine language of a processor. From the user's point of view, these executions seem to run in parallel. However, where each process has its own virtual memory, threads in the same process share virtual memory. However, all threads have their own call stack.
  • a computational task does not necessarily use a hardware extension: in the most common case, a compute task is executed using instructions common to all processor cores.
  • a computation task can (optionally) be executed by a hardware extension (which nevertheless requires the associated core to "decode" the instructions).
  • the function of a hardware extension is to speed up the processing of a specific instruction set: a hardware extension may not speed up the processing of another type of instruction (eg floating point versus integer).
  • a processor core can be associated with none (ie zero) or one or more hardware extensions. These hardware extensions are then "exclusive" (a given hardware extension can not be accessed from a third core).
  • the processor core includes the hardware extension (s).
  • the physical circuits of a hardware extension may include a processor core.
  • a processor core is a 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).
  • a processor core may have all the hardware extensions required to execute the instructions contained in a given task.
  • a processor core may also not necessarily have all the hardware extensions required to execute the instructions included in the computational task: the technical problem of moving and / or emulating (ie, functionality or instruction ) - and associated costs - arise.
  • Hardware extensions may be of a different nature. An extension can process a set of instructions specific to it.
  • Hardware expansion is usually expensive in circuit area and static energy.
  • An asymmetric platform compared to a symmetric processor, reduces surface and energy costs by reducing the number of extensions and by turning on or off cores containing extensions only when necessary or advantageous.
  • a processor core accesses exclusively one or more hardware extensions dedicated thereto.
  • an extension may be "shared" between multiple processor cores.
  • the computational load should be distributed as well as possible. For example, it is advantageous not to overload an extension that would be shared.
  • the operating system through the scheduler provides quanta of time, each quantum of time being allocated to a given software application.
  • the scheduler (or "scheduler" in English) is preemptive type (ie the quanta of time are imposed on software applications).
  • a method for managing a computing task on a functionally asymmetric multi-core processor, wherein at least one core of said processor is associated with one or more hardware extensions, the method comprising the steps receiving a computing task, said computing task being associated with executable instructions by a hardware extension associated with the multi-core processor; receive calibration data associated with said hardware extension; and determining an opportunity cost of performing the computing task based on the calibration data.
  • One or more opportunity costs of execution can be determined. At least one processor core among the plurality of cores is thus characterized by an opportunity cost of executing the received computation task.
  • the method according to the invention considers various "opportunities" of placement, i.e. possibilities or potentialities, which are analyzed.
  • the computation task comprises instructions associated with one or more predefined classes of instructions and the hardware extension is associated with one or more predefined classes of instructions, said classes being executable by said extension.
  • the calibration data includes coefficients indicative of a unit execution cost per instruction class, said coefficients being determined by comparison between the execution of a predefined set of instructions representative of the execution space of said extension on said hardware extension of on the one hand and the execution of said predefined set of instructions on a processor core without hardware extension on the other hand.
  • the "predefined set of instructions representative of the execution space” aims to represent the various possibilities of execution of the instructions, in the most complete i.e. way as exhaustive as possible. With regard to the nature of the instructions (i.e. the classes or types of instructions), completeness can be achieved. On the other hand, the combinatorics of the sequences of the different instructions being virtually infinite, the representation is necessarily imperfect. It can nevertheless be approached asymptotically.
  • the principle of executing a set of instructions makes it possible to determine "control points" of the method according to the invention (e.g., effective calibration data). Experimentally, a hundred “programs” were conducted, each containing "tests" (unitary executions) and the execution of software applications in real conditions.
  • the unit tests aimed to execute a small number of instruction types, mainly floating point, control and / or memory. Different benchmarks have been used (eg MiBench, SDVBS, WCET, fbench, Polybench).
  • Execution of actual software applications has aimed to represent the main sequences in the execution of instructions.
  • software applications used different data sets.
  • each software application can be compiled for a processor core with hardware extension and also compiled for a core without extension. Both versions of binaries are then executed on the different cores. The difference in execution time is determined as well as the number and nature of the classes of instructions executed. For a fairly large set of applications, it is possible to determine a scatter plot representing the total execution space. As a result, it is possible to correlate the number of instructions associated with each class of instructions and the difference in execution time between cores with or without extension.
  • the number of software applications can be increased.
  • this representativeness can be determined (use of random instructions, thresholds, confidence intervals, cloud distribution, etc.).
  • a minimum (or optimal) number of software applications to be executed under real conditions can be determined. Comparing the execution of instructions on a core with extension and on a core without extension, some results have highlighted deviations of the order of 10 to 20% between the performances as estimated according to the process and the performances actually measured. This order of magnitude reflects the possibility of operational implementation of the invention (and this without additional optimization).
  • the method further comprises a step of determining a number of uses of each instruction class associated with the compute task by said hardware extension.
  • the step of determining the number of uses of each instruction class includes a step counting the number of uses of each class of instructions.
  • the history ie the past is used to estimate or evaluate the future.
  • the step of determining the number of uses of each instruction class includes a step of estimating the number of uses of each instruction class, including from uses counted in the past. It is also possible to estimate the number of uses from other methods. It is also possible to combine counting and estimating the number of uses of instruction classes.
  • the opportunity cost of execution is determined by summation indexed by instruction class of the coefficients per class of instructions multiplied by the number of uses per instruction class.
  • the opportunity cost of execution is also sometimes referred to as “degradation” (from the perspective of a loss of performance). Symmetrically, it can also be “performance gains”("accelerations” or “benefits” or “improvements”).
  • the opportunity cost of execution can be determined from the number of uses that are actually counted and / or estimated based on the count history.
  • the upstream determination of the "opportunity cost of execution" allows efficient optimizations conducted downstream (as described below).
  • the "opportunity cost of execution" therefore corresponds to a "reading grid" specific to the processor and to the management of calculation tasks, that is to say to the definition of a "result". intermediary '(decision support) allowing subsequent specific management and dependent on this characterization.
  • This perspective is particularly relevant insofar as it makes it possible to control the processor efficiently (intermediate aggregates make it possible to improve the controllability of the system).
  • taking into account the classes of instructions and the number of uses of these classes of instructions allow the determination of said "opportunity cost of execution".
  • the coefficients are determined offline. It is possible to determine the calibration data once and for all ("offline").
  • the calibration data can be provided by the processor manufacturer.
  • the calibration data can be present in a configuration file.
  • the coefficients are determined online. The coefficients can be determined during the execution of a program, for example at the "reset" of the platform. In an open system (for example cluster or "Cloud”), whose topology is unknown a priori, it is possible to calibrate each extension at startup and determine the topology globally.
  • an open system for example cluster or "Cloud”
  • the coefficients are determined by multivariate statistical analysis. Different multivariate statistical analysis techniques can be used, possibly combined.
  • the regression (linear) is advantageously fast.
  • Principal component analysis (PCA) advantageously makes it possible to reduce the number of coefficients.
  • Other techniques that can be used include factorial analysis of correspondence (AFC), so-called factorial analysis, data partitioning (clustering), multidimensional scaling (MDS), the analysis of similarities between variables. , multiple regression analysis, analysis of the ANOVA variance (bivariate), and its multivariate generalization (multivariate analysis of variance), discriminant analysis, canonical correlation analysis, logistic regression (logit model), artificial neural networks, decision trees , models of structural equations, joint analysis etc.
  • the received compute task is associated with a predetermined processor core and the opportunity cost of performing the compute task is associated with a processor core other than the predetermined processor core. It is generally considered (but not required) what would be the cost of execution on the predetermined processor (if any), ie what would be the cost of "chasing” execution. In other cases, the other "candidate" cores are taken into consideration (one, several or all of the addressable cores).
  • the opportunity cost of performing the computational task is determined for at least one processor core other than the predetermined processor core.
  • all processor cores are considered each in turn and the placement optimization is to minimize the opportunity cost of execution (ie, for example, to select the processor core associated with the processor. lowest or lowest opportunity cost of execution).
  • such a "minimum" function can be used.
  • specific algorithms sequence of steps
  • / or analytic functions and / or heuristics may be used (for example, the candidate cores may be compared in pairs and / or sampled according to various modalities. for example, to speed up investment decision-making).
  • other criteria can be taken into account to optimize the placement of the calculation task. These criteria may be taken into account additionally (but in some cases may be substituted for the opportunity cost of execution criterion).
  • These generally complementary criteria can include, in particular, parameters relating to the execution time of the calculation task and / or to the energy cost associated with the execution of the calculation task and / or the temperature (ie to the local consequence of the calculation task). execution considered).
  • the various costs can be compared with each other and various arbitration logic can select a particular heart in consideration of these different criteria.
  • combinatorial optimization or multi-objective optimization (some objectives may be antagonistic)
  • different mathematical techniques are applicable.
  • the weighting of these different criteria can in particular be variable and / or configurable.
  • the respective weights allocated to the different placement optimization criteria can for example be configured online or offline. They can be "static” or “dynamic”. For example, the priority and / or weight of these different criteria may be variable over time.
  • Analytical functions or algorithms can regulate the different allocations or arbitrations or trade-offs or priorities between optimization criteria for the placement of calculation tasks.
  • the energy cost determination includes one or more of the steps of receiving initial indications of use of one or more predefined hardware extensions and / or receiving consumption states. of energy (eg DVFS) per processor core and / or receiving performance asymmetry information and a step of determining a power-gating and / or clock-gating energy optimization.
  • energy eg DVFS
  • the method further comprises a step of determining an adaptation cost of the instructions associated with the computing task, said step comprising one or more of the steps of translating one or more instructions and / or selecting a or multiple instruction versions and / or emulate one or more instructions and / or execute one or more instructions in a virtual machine.
  • the adaptation of the instructions becomes necessary if it is determined, following the previous steps, a processor core not having the required hardware extension (heart "not equipped")
  • the method further comprises a step of receiving a parameter and / or a logical scheduling and / or placement rule.
  • Logical rules Boolean expressions, fuzzy logic, business rules, etc.
  • factual threshold values such as maximum temperatures, time ranges, etc.
  • the method further comprises a step of moving the compute task from the predetermined processor core to the determined processor core.
  • the method further includes a step of disabling or shutting down one or more processor cores. Disable or “cut off the clock signal” or “put the heart in a reduced consumption status "(eg decreasing the clock frequency) or” darkening "(" dark silicon ")
  • the functionally asymmetric multi-core processor is a physical processor or a virtual processor.
  • the processor is a tangible or physical processor.
  • the processor may also be a virtual processor, i.e. logically defined.
  • the scope can be defined by the operating system.
  • a processor can also be determined by a hypervisor.
  • a computer program product comprising code instructions for performing one or more steps of the method, when said program is run on a computer.
  • the system comprises a functionally asymmetric multi-core processor, at least one core of said processor being associated with one or more hardware extensions, the system comprising receiving means for receiving a computing task, said computing task being associated executable instructions by a hardware extension associated with the multi-core processor; receiving means for receiving calibration data; and means for determining an opportunity cost of executing the calculation task based on the calibration data.
  • the system further comprises means selected from placement means for placing one or more computing tasks on one or more cores of the processor; means for counting the use of instruction classes by a hardware extension, said means including software and / or hardware counters; means or registers for saving the execution context of a calculation task; means for determining the migration cost and / or the adaptation cost and / or energy cost associated with continuing the execution of a calculation task on a predefined processor core; means for receiving one or more parameters and / or scheduling rules; means for determining and / or selecting a processor core; means for executing on a processor core without associated hardware extension a computational task initially intended to execute on a processor comprising one or more hardware extensions; means for moving a compute task from one processor core to another processor core; and means for disabling or shutting down one or more processor cores.
  • Figure 1 illustrates examples of processor architectures.
  • a functionally asymmetric multi-core processor FAMP 120 is compared to a symmetrical multi-core processor SMP 110 where each core contains all the hardware extensions and compared to a SMP 130 symmetrical multi-core processor containing only basic cores.
  • the architecture may be shared memory or distributed. Hearts can sometimes be connected by a NoC (Network-on-Chip).
  • a FAMP 120 architecture is close to that of a SMP 130 symmetrical multi-core processor.
  • the memory architecture remains homogeneous, but the features of the cores can be heterogeneous.
  • a FAMP 120 architecture may comprise four different types of cores (with the same base). The Processor size can therefore be reduced. Because of the ability to turn on or off the cores, and therefore to choose which to turn on the software application as needed, various optimizations can be made (energy gain, reduction of core temperature, etc.). .
  • FIGS. 2A and 2B illustrate some aspects of the invention in terms of energy efficiency, depending on whether hardware extensions are used or not.
  • FIG. 2A refers to a processor "Full” (or “extended”, ie with one or more hardware extensions) and “Basic” (without hardware extension).
  • the figure illustrates the energy consumed by a processor (surfaces 121 and 122) as a function of the power consumed ("Power" on the ordinate 111) during an execution time (time on the abscissa 112) for the same application or thread on the two types of processors.
  • a calculation task executed during a time tf consumes an energy E FU II 121.
  • a “Basic” processor with an energy power P b a calculation task executed during a time t b consumes E BaS ic 122.
  • the power Pf is greater than the power Pb because the hardware extension requires more power. It is common for the execution time t b to be greater than the execution time t f since it does not have an extension, a basic processor performs the calculation task less quickly.
  • a general objective is to minimize the energy consumed, ie the area of the surface (shortest possible execution time with minimal power).
  • the Full processor is more efficient.
  • the ratio t b / t f indicates "acceleration" of the computation due to the extension hardware.
  • FIG. 2B illustrates the variation of the energy gain (E BaS ic / E FU II) as a function of the acceleration tb t f , which indicates the opportunity to use an extended processor with hardware extension (s) rather than without. If the E Ba sic / EFuii ratio is less than 1, this indicates that there is less energy consumed with a Basic processor than with an Extended processor (if so, this operation domain 141 is called "Slighlty extended" which means that the hardware extension is not used enough).
  • the ratio E Ba sic / EFuii is less than 1 and the acceleration ratio t b t f is less than 1, this shows a gain in both energy consumed and computing time performance to the advantage of the processor without hardware extension (this can happen in cases where the extension is misused).
  • the ratio E Ba sic / EFuii is greater than 1, the extended processor consumes less energy (section 143 "highly extended"): the extension accelerates the code (ie the instructions) and the gains are obtained both in terms of energy (it is less) than in terms of acceleration (faster execution).
  • the operating domain 144 corresponds to an acceleration of the calculations simultaneously with a lower energy consumption, to the advantage of an extended processor with hardware extension.
  • a hardware expansion can reduce power consumption by reducing the number of steps required to perform specific calculations.
  • the acceleration of the calculation on the extension can compensate for the additional power required by the extension itself.
  • a hardware extension may be more efficient because of the strong coupling between extension and core.
  • Hardware extensions frequently share a significant portion of the basic core and take advantage of direct access to L1 and L2 cache types. This coupling notably makes it possible to reduce data transfers and synchronization complexity.
  • Hardware expansion usually involves additional cost in terms of area and static power consumption.
  • An extension often includes registers of significant size, which may require a larger bandwidth as well as larger data transfers than those required by the core circuit. If the hardware expansion usage is too low, its clean energy consumption is likely to exceed the expected energy savings due to hardware acceleration. Worse, an underutilized hardware extension can lead to a reduction in the performance of a software application. For example, in the case of intensive data transfers between the hardware extension and the core registers, the overhead of the memory transfer may cancel the benefit of the acceleration.
  • a hardware extension is usually not "transparent" to the application developer.
  • the developer is frequently forced to explicitly handle extended instruction sets.
  • the use of hardware extensions can be expensive compared to the single core circuit.
  • the ARM processor NEON / VFP extension accounts for about 30% of the surface area of a Cortex A9 processor (not including caches, and 10% counting L1 cache).
  • the method according to the invention makes it possible to (a) asymmetrically distribute the extensions in a multi-core processor, (b) to know when the use of an extension is "useful" from a performance and energy point of view and (c) moving the application over time on different cores, regardless of their starting requirement (which is chosen at compile time and therefore not necessarily adequate with the execution context)
  • Figure 3 illustrates examples of architectures and job placement. The figure shows examples of scheduling tasks on an SMP, and two types of scheduling on a FAMP. The FPU adds FP-like instructions to an ISA circuit.
  • each quanta of the task is executed on a processor having a Floating Point Unit (FPU). It turns out that the first and the last quanta do not contain FP instructions.
  • FPU Floating Point Unit
  • the first and the last quanta can run on a single core (having no FPU), which reduces the consumption of energy during execution.
  • the 3rd quanta contains FP extensions, but not enough to "value" the FP unit.
  • the method according to the invention allows the third quanta to be run on a "basic" type of processor, which optimizes the energy consumption to perform this calculation task.
  • Figure 4 provides examples of steps of the method according to the invention.
  • step 400 which takes place online and in a loop, the data relating to the use of the hardware extensions are collected (for example by the scheduler).
  • the use of extensions is monitored ("monitoring" in English).
  • the method for recovering data during execution focuses only on instructions for hardware or hardware extensions. According to this embodiment, the method is independent of the process scheduling.
  • the code is executed on a processor with extension (ie with one or more extensions)
  • the monitoring can rely on hardware counters.
  • the extended instructions are no longer executed natively.
  • routines for example at the time of adaptation of the code or in the emulation function if applicable
  • routines for example at the time of adaptation of the code or in the emulation function if applicable
  • the method according to the invention can use software counters and / or hardware counters associated with said software counters.
  • a monitoring system can be very heavy at runtime.
  • the data collected are linked to the instructions only involving extensions, and in fact the slowdown is negligible because it can be done in parallel with the execution.
  • the filling of the counters can be done sequentially during the emulation of the accelerated functionality by the other cores, which can add an additional cost in terms of performance. To reduce this extra cost, it is possible to collect the data periodically, and, if necessary, to interpolate.
  • step 410 an event of the scheduler (e.g., the end of a quanta) is determined, which triggers step 320.
  • step 420 the collected data is read.
  • the scheduler retrieves the data collected by the monitor (A.0) (for example by reading the hardware or software registers).
  • a prediction is made. Thanks to the data retrieved, the prediction system studies the behavior of the application with respect to the use of extended instruction classes. By analyzing this behavior, he predicts the future behavior of the application.
  • the prediction is said to be simple, ie it is reactive, assuming that the behavior of the application in the next quanta will be similar to the last quanta executed.
  • the prediction is said to be "complex" and comprises steps of determining the different types of program phases. For example, these types of phases can be determined by saving a behavior history table and analyzing that history. Signatures can be used.
  • the prediction unit may associate signatures with behaviors subsequently executed. When a signature is detected, the prediction unit can indicate the future behavior ie predict the future operations known and associated with the signature.
  • step 430 an estimate is made of "degradation”.
  • Base versus "Full”
  • a given task is not tested on each teacher but it is estimated, at the time of scheduling, the cost that the task would have on different processors.
  • the entire code is simulated, taking into account the complete features of the processor.
  • This type of approach is generally not usable dynamically (online). Considering the particular case in which the processor cores all have the same base, all the instructions are executed in the same way in the different cores (for example two cores). Some edge effects may appear between cores, for example due to caching, but these effects remain residual and can be taken into account when learning the model.
  • the estimation of performance degradation can be done in different ways.
  • the estimation of the degradation may in fact be based on a model making it possible to calculate the said degradation as a function of the percentage of each instruction class by the extension. This approach is not necessarily appropriate, however, since different types of instructions can have very different accelerations for the same hardware extension.
  • an estimate of the performance degradation can take into account the classes of instructions and assume a form according to:
  • the values of the weighting coefficients ⁇ can be calculated dynamically online by performing a learning process performed by executing several codes on different types of processors. These values can also be calculated offline (and stored in a table readable by the scheduler for example).
  • the calibration data determined from the execution of real calculation tasks make it possible in particular to take into account the cost of emulation and the complex evolutions of the beta coefficients.
  • the beta values can be distinguished for a real platform and for a simulated platform.
  • the beta coefficients are used by the scheduler to estimate performance degradation.
  • the calibration must be repeated for each implementation of a hardware extension.
  • the steps of prediction 430 and estimation of the degradation 440 are chronologically independent.
  • the degradation can be estimated (440) from the predicted data (430).
  • the degradation 440 can be calculated from the data recovered in step 400 and 420, before the prediction 430 is based on the degradation 440 thus calculated.
  • the future degradation is predicted (and not the future instructions of the extensions). The data changes but the prediction process remains the same.
  • step 430 the objective is to "predict" the number of instructions of each class that will be executed at t + 1 as a function of the past (of t, t-1 ... t-n).
  • step 440 the objective is to "estimate" the execution cost at t + 1 on the different types of cores.
  • the steps 430 and 440 can be performed in any order because it is possible independently to estimate the cost at time t on the recovered data and to predict the cost at time t + 1 from the cost at time t.
  • a "prediction” approach consists of a relative determination of the future based on the data available in the present.
  • An “estimate” allows a determination of the present using data observed in the past.
  • an “estimate” allows the determination of the past in a new context from observations of the past in another context.
  • a monitoring module captures the calibration data and an analysis module estimates the acceleration associated with the use of an extension.
  • the input data must be as close as possible to the time of the extended instructions to be executed at the next quanta (assuming a continuity assumption, eg stable use of a floating point unit).
  • a prediction module can then be used. This assumption is realistic when programs have distinct phases of stable behavior over sufficiently long time intervals. In the case of more erratic behavior, more advanced prediction modules can be implemented,
  • a decision step is performed.
  • a logical decision unit may take into account the information of the predicted degradation estimate and / or the overall objectives assigned to the platform, the objectives including, for example, objectives in terms of energy reduction, performance, priority and availability of hearts.
  • the degradation can also take into account parameters such as the migration cost and / or the cost of adaptation of the code.
  • the migration cost and the cost of the station may be static (e.g. offline learning) or dynamic (e.g. e-learning or online time monitoring).
  • step 460 it is possible to proceed from the migration of one core to another ("core-switching").
  • Migration techniques implemented can be performed with context saving (for example with saving the extension registers in software registers accessible from emulation).
  • the code is optionally adapted.
  • code for example, to execute code with extensions on a "basic" processor, it is possible to use binary adaptation techniques (eg by code translation), multi-code version, or even 'emulation.
  • the present invention can be implemented from hardware and / or software elements. It may be available as a computer program product on a computer readable medium.
  • the support can be electronic, magnetic, optical or electromagnetic.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)

Abstract

La présente invention concerne un procédé pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un cœur dudit processeur étant associé à une ou plusieurs extensions matérielles, le procédé comprenant les étapes consistant à recevoir une tâche de calcul associée à des instructions exécutables par une extension matérielle; recevoir des données de calibration associées à l'extension matérielle; et déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. Des développements décrivent la détermination des données de calibration notamment par comptage ou par calcul (en ligne et/ou hors ligne) des classes des instructions exécutées, l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de l'extension, la prise en compte d'aspects énergétiques et de température, la traduction ou l'émulation d'instructions ou le placement de tâches de calcul sur les différents coeurs. Des aspects de système et de logiciel sont décrits.

Description

PLACEMENT D'UNE TÂCHE DE CALCUL SUR UN PROCESSEUR FONCTIONNELLEMENT ASYMETRIQUE
Domaine de l'invention
L'invention concerne les processeurs multi-cœurs en général et la gestion du placement de tâches de calcul sur des processeurs multi-cœurs fonctionnellement asymétriques en particulier.
Etat de la Technique
Un processeur multi-cœurs peut comprendre une ou plusieurs extensions matérielles, destinées à accélérer des parties de codes logiciels très spécifiques et difficilement parallélisables. 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 certaines extensions font défaut à certains cœurs de processeurs, c'est-à-dire quand au moins un cœur du processeur multi-coeurs ne possède l'extension matérielle requise pour l'exécution d'un jeu d'instructions donné. Il existe un jeu d'instruction commun à tous les cœurs et un jeu d'instruction spécifique qui est exécutable uniquement par certains cœurs prédéfinis. En faisant l'union de tous les jeux d'instructions des cœurs composant le processeur multi-cœurs, toutes les instructions (de l'application) sont représentées. Un processeur fonctionnellement asymétrique peut se caractériser par une distribution (ou association) inégale des extensions aux cœurs de processeurs. La gestion d'un processeur multi-cœurs fonctionnellement asymétrique pose plusieurs problèmes techniques. Un de ces problèmes techniques consiste à 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 (e.g. des calculs sur des données de type virgule flottante) tandis que d'autres phases de calcul l'utiliseront peu voire pas du tout (e.g 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 sur des processeurs multi-cœurs fonctionnellement asymétriques ne décrivent pas de solutions satisfaisantes. Le document de brevet WO2013101139 intitulé « PROVIDING AN ASYMMETRIC MULTICORE PROCESSOR SYSTEM TRANSPARENTLY TO AN OPERATING SYSTEM » divulgue un système comprenant un processeur multi-cœurs avec plusieurs groupes de coeurs. Le second groupe peut être d'une architecture de jeu d'instructions (ISA) différente du premier groupe, ou bien relever de la même architecture ISA définir mais avec un niveau de puissance et de performance des supports différents. Le processeur comprend en outre une unité de migration qui traite les demandes de migration pour un certain nombre de scénarios différents et provoque un changement de contexte pour migrer dynamiquement un processus à partir d'un second cœur à un premier cœur du premier groupe. Ce changement de contexte matériel dynamique peut être transparent pour le système d'exploitation.
Cette approche comporte des limitations par exemple en matière de flexibilité de placement et de dépendance au jeu d'instructions. Il existe un besoin pour des procédés et systèmes pour la gestion de tâches de calcul sur des processeurs multi-coeurs fonctionnellement asymétriques, les coeurs de processeurs étant associés à une ou plusieurs extensions matérielles. Résumé de l'invention
La présente invention concerne un procédé pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un cœur dudit processeur étant associé à une ou plusieurs extensions matérielles, le procédé comprenant les étapes consistant à recevoir une tâche de calcul associée à des instructions exécutables par une extension matérielle; recevoir des données de calibration associées à l'extension matérielle; et déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. Des développements décrivent la détermination des données de calibration notamment par comptage ou par calcul (en ligne et/ou hors ligne) des classes des instructions exécutées, l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de l'extension, la prise en compte d'aspects énergétiques et de température, la traduction ou l'émulation d'instructions ou le placement de tâches de calcul sur les différents coeurs. Des aspects de système et de logiciel sont décrits.
Selon un mode de réalisation, l'invention est implémentée au niveau matériel (« hardware ») et du système d'exploitation. L'invention récupère et analyse certaines informations des derniers quanta d'exécution (temps alloué par l'ordonnanceur à la tâche sur un cœur) et ainsi estime le cout du futur placement de tâche sur différents types de cœurs.
Avantageusement selon l'invention, le placement de tâche est flexible et transparent pour l'utilisateur.
Avantageusement, le procédé selon l'invention effectue le placement des tâches de calcul en fonction d'objectifs plus diversifiés et globaux que les solutions connues de l'état de la technique qui s'en tiennent aux seules instructions associées aux tâches de calcul. En effet, selon les solutions connues, le placement des tâches de calcul impliquant l'allumage ou l'extinction d'un ou de plusieurs cœurs est réalisé en considérant seulement l'utilisation « stricte » de l'extension. En effet, un cœur ne comprenant pas d'extensions ne peut pas exécuter des instructions visant une ou plusieurs extensions particulières. Par suite, les solutions actuelles examinent si une extension est utilisée (e.g. placement de l'application sur un cœur avec extension) ou n'est pas utilisée (e.g. placement sur un cœur sans extension). En d'autres termes, les approches connues considèrent la présence d'appel de telles extensions au sein du code source mais procèdent au placement des tâches exclusivement en fonction des instructions de code et ignorent en particulier tout autre critère, notamment énergétique. D'autres approches connues se fondent sur une analyse du code source et de l'emploi planifié d'extensions matérielles, procèdent à des mutations de code, mais sans estimer des critères comprenant par exemple la dégradation de performance ou d'énergie.
Avantageusement, l'invention peut répondre aux besoins dits « multi- objectifs » auxquels doit satisfaire un ordonnanceur de tâche tels que a) la performance, b) l'efficacité énergétique et c) les contraintes thermiques (« dark-silicon »). Certains modes de réalisation permettent d'augmenter le nombre de cœurs d'un processeur multi-cœurs, tout en gardant une efficacité performance/énergie/surface élevée. L'effort de programmation additionnelle reste quant à lui réduit.
Avantageusement selon l'invention, la prédiction des coûts et des gains d'exécution d'une tâche donnée sur chacun des différents cœurs d'un système hétérogène peut être effectués de manière dynamique.
Avantageusement, le procédé selon l'invention tient compte de critères dynamiques liés à l'exécution d'un programme. Actuellement, l'exploitation d'une extension matérielle par un code logiciel est dictée soit explicitement par le programmeur du code, soit effectuée automatiquement par le compilateur. La compilation d'un logiciel étant le plus souvent faite hors-ligne, le programmeur ou le compilateur, ne peut fonder son choix d'exploiter ou non une extension que sur des critères qui sont liés au logiciel lui-même, et non sur des critères dynamiques à l'exécution du programme. Sans information sur l'environnement d'exécution (charge de travail, ordonnancement instantané des tâches, disponibilité des ressources), il est généralement impossible de déterminer à l'avance s'il faut ou non exploiter une extension matérielle donnée. Le procédé selon l'invention permet de prédire et/ou d'estimer l'utilisation d'une ou de plusieurs extensions matérielles.
Avantageusement selon l'invention, il devient possible d'implémenter une stratégie dynamique d'ordonnancement et de placement de tâches, levant différentes contraintes telles que (i) la prédictibilité et l'interopérabilité en utilisation de systèmes hétérogènes contraints (asymétrie fonctionnelle avec base commune) et (ii) l'optimisation au regard d'objectifs globaux du système (e.g. performance, consommation et surface), permise au moyen d'une prédiction rapide, dynamique et transparente de l'exécution d'un code donné sur un cœur donné. Avantageusement, certains modes de réalisation de l'invention comprennent des étapes de prédiction quant à l'utilisation des extensions, ce qui peut avantageusement optimiser l'efficacité énergétique et optimiser les performances de calcul. Ces modes de réalisation peuvent en particulier laisser une certaine liberté à l'ordonnanceur quant au choix des cœurs sur lesquels exécuter les différentes phases de programme.
Avantageusement, des résultats expérimentaux ont montré que, n'étant plus contraint par le jeu d'instruction, la dépendance à la taille de quanta est très réduite. Le pourcentage de temps passé sur un corps basic sont très proches quelques soit la taille de quanta, ce qui permet d'être indépendant d'autres paramètres de l'ordonnanceur.
Avantageusement, le procédé selon l'invention permet d'optimiser la consommation énergétique, y compris dans le cas d'une faible utilisation d'une extension.
Avantageusement, le procédé selon l'invention permet de placer une tâche sur un processeur, que ce processeur soit associé à une extension matérielle ou non, en fonction de l'implémentation de la tâche (donc avec ou sans exploitation de l'extension). Par suite, un ordonnanceur peut optimiser l'énergie ou la performance dynamiquement sans se soucier de l'implémentation initiale de la tâche. Avantageusement, l'invention permet de prédire ou déterminer dynamiquement l'intérêt de l'utilisation d'une ou plusieurs extensions matérielles et de placer les tâches de calcul (i.e. d'allouer ces tâches aux différents processeurs et ou cœur de processeurs) en fonction de cette prédiction.
Avantageusement, le procédé selon l'invention permet de retarder la décision d'utiliser ou non une extension à l'exécution, donne au programmeur un niveau d'abstraction plus élevé et fournit au logiciel du système une liberté de décision accrue permettant plus d'optimisation en matière d'ordonnancement. Une fois cette flexibilité obtenue, la qualité des décisions du logiciel système devient uniquement en fonction de l'environnement d'exécution. Pour ce faire, le logiciel système mesure les variables pertinentes de l'environnement d'exécution.
Avantageusement, de façon transparente pour le programmeur et de manière dynamique pour le compilateur, le procédé selon l'invention permet d'avoir des libertés de migration de tâche et des connaissances accumulées concernant l'environnement d'exécution afin d'optimiser le placement de tâches de calcul sur un ou plusieurs processeurs multi- cœurs asymétriquement fonctionnels, et ce en fonction des objectifs globaux de l'ordonnanceur.
Avantageusement, le procédé selon l'invention confère de la liberté d'action en matière de placement de tâches de calcul. Une telle liberté d'action permet au système de migrer les tâches (de calcul) sur n'importe quel cœur de processeurs, et ceci malgré les différentes extensions présentes dans chacun de ces cœurs. Les applications logicielles exécutées sur le système sont associées à un espace d'exploration plus continu et plus souple pour atteindre les objectifs (ou multi-objectifs) en termes de puissance (par exemple performances thermiques).
Avantageusement, des modes de réalisation de l'invention pourront être implémentés pour des « System-on-Chip » (SoC) pour des applications de type grand public ou électronique embarquée (e.g. téléphones, composants enfouis, desktop, Internet des Objets, etc). Dans ces domaines d'application, l'utilisation de systèmes hétérogènes est fréquente pour optimiser l'efficacité de calcul pour une charge de travail spécifique. Ces derniers systèmes se complexifiant continuellement (e.g. augmentation du nombre de cœurs et des charges de travail), certains modes de réalisation de l'invention permettent de réduire l'impact de cette complexification, en faisant abstraction de l'hétérogénéité des systèmes.
Avantageusement, des résultats expérimentaux (benchmarks mibench, SDVBS) ont démontré des gains de performance et de consommation énergétique par rapport au système et procédé connu de l'état de la technique.
Avantageusement, le procédé selon l'invention permet une optimisation dynamique de la performance et de l'énergie grâce à l'estimateur de la dégradation et de l'unité de prédiction. Avantageusement, la mise à l'échelle (« scalability » en anglais) des processeurs multi-cœurs est améliorée. En particulier, la gestion de l'asymétrie de la plate-forme s'effectue de manière transparente pour l'utilisateur, c'est-à-dire n'augmente pas l'effort ou les contraintes de développement logiciel.
Avantageusement, une optimisation de l'ordonnancement permet de mieux répondre aux problématiques techniques qui augmentent avec le nombre de cœurs telles que la réduction de la surface et de l'énergie consommée, la priorité des tâches, le dark-silicon (température).
Avantageusement, le placement/ordonnancement des tâches selon l'invention est flexible. Par ailleurs, l'ordonnancement s'effectue de manière optimisée et transparente pour l'utilisateur. Avantageusement en comparaison des solutions connues, le procédé selon l'invention prévoit l'emploi d'unités de prédiction (« prédicteur ») et/ou d'estimateurs d'intérêt, permettant un placement de tâche optimisé.
Les approches connues qui surveillent l'exécution des programmes et tentent d'optimiser le placement des tâches de calcul ne s'intéressent généralement qu'aux différences interne d'un même processeur (e.g. « in- order/out-of-order » , différence de fréquences, etc) et ne peuvent pas s'appliquer aux extensions matérielles elles-mêmes (les données, modèles et contraintes sont différentes). Avantageusement selon l'invention, la dépendance au jeu d'instructions est réduite voire supprimée. Les avantages comprennent notamment une efficacité améliorée en matière énergétique et de performance. L'utilisation d'une extension n'apporte pas toujours des gains en performance et énergie. Par exemple une phase de calcul avec une faible utilisation d'une extension permet d'accélérer les calculs (en comparaison d'une exécution conduite sur un cœur sans extension) mais la consommation d'énergie peut être augmentée en raison de l'énergie statique de l'extension (non compensée par le gain en temps d'exécution). De même, en matière de performance, le compilateur peut utiliser une extension en planifiant que cela va accélérer l'exécution, mais à cause du déplacement de mémoire additionnel (e.g. entre l'extension et les registre des cœurs « basic »), la performance va en réalité être dépréciée. Avantageusement, le choix du placement des tâches selon le procédé est flexible. Dans les systèmes actuels, l'objectif du système d'exploitation n'est pas toujours d'optimiser la performance, l'objectif peut être une minimalisation de l'énergie consommée ou un placement optimisant la température des cœurs (« dark silicon »). Du fait de la dépendance au jeu d'instruction, l'ordonnanceur peut être contraint d'exécuter une application en fonction de ses besoins en ressources et non en considérant un objectif global.
Avantageusement selon le procédé, le placement est indépendant d'autres paramètres supervisés par l'ordonnanceur. Un ordonnanceur alloue généralement un quanta de temps à chaque tâche de calcul sur un processeur. Si le calcul d'une tâche n'est pas achevé, un autre quanta lui sera associé. La taille de ces quanta est variable de façon à permettre un partage juste et optimisé des différentes tâches entre les différents processeurs (typiquement entre 0.1 et 100ms). Le dimensionnement des quanta implique une détection plus ou moins fine des phases de type basic. Il peut exister des effets de bord (par exemple, des migrations incessantes). S'en tenir à ces effets de bord réduit in fine la flexibilité de placement et les optimisations. Description des figures
Différents aspects et avantages de l'invention vont apparaître en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous :
La figure 1 illustre des exemples d'architectures de processeurs ;
Les figures 2A et 2B illustrent certains aspects de l'invention en matière d'efficacité énergétique, selon que des extensions matérielles sont utilisées ou non ;
La figure 3 illustre des exemples d'architectures et de placement des tâches ; La figure 4 fournit des exemples d'étapes du procédé selon l'invention. Description détaillée de l'invention
L'invention permet généralement un placement optimisé de tâches de calcul sur un processeur multi-cœurs fonctionnellement asymétrique. Un processeur multi-cœurs fonctionnellement asymétrique comprend des éléments programmables ou cœurs de processeur, utilisant des fonctionnalités plus ou moins étendues.
Un cœur « étendu » (« full » en anglais, i.e. avec une ou plusieurs extensions matérielles) est un cœur « basique » (ou « basic » en anglais, i.e. sans extension matérielle) augmenté d'une ou plusieurs extensions matérielle.
Une « extension matérielle » ou « extension » (« Hardware Extension » en anglais) est un circuit tel qu'une unité de calcul sur données flottantes FPU, une unité de calcul vectoriel, un SIMD, 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. Ces circuits spécifiques améliorent 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 le pipeline du cœur, ce qui permet d'accéder efficacement aux fonctions par des instructions ajoutées à l'ensemble « basic » (par comparaison, un « coprocesseur » spécialisé requiert généralement des instructions apparentées à des protocoles spécifiques). Une tâche de calcul (ou « thread » en anglais) comprend des instructions, lesquelles peuvent être groupées en séquences d'instructions (temporellement) ou en jeux ou classes d'instructions (par nature). L'expression "tâche de calcul" (ou "tâche") désigne un "thread" ou un "fil d'exécution". D'autres dénominations comprennent des expressions comme "processus léger", "unité de traitement", "unité d'exécution", "fil d'instruction", "processus allégé" ou "exétron". L'expression désigne l'exécution d'un ensemble d'instructions du langage machine d'un processeur. Du point de vue de l'utilisateur, ces exécutions semblent se dérouler en parallèle. Toutefois, là où chaque processus possède sa propre mémoire virtuelle, les threads d'un même processus se partagent de la mémoire virtuelle. Par contre, tous les threads possèdent leur propre pile d'appel. Une tâche de calcul n'utilise pas nécessairement une extension matérielle: dans le cas le plus fréquent, une tâche de calcul est exécutée en utilisant des instructions communes à tous les cœurs de processeur. Une tâche de calcul peut (optionnellement) être exécutée par une extension matérielle (qui requiert néanmoins le cœur associé pour « décoder » les instructions). La fonction d'une extension matérielle est d'accélérer le traitement d'un jeu d'instruction 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). Un cœur de processeur peut être associé avec aucune (i.e. zéro) ou une ou plusieurs extensions matérielles. Ces extensions matérielles lui sont alors « exclusives » (une extension matérielle donnée ne peut pas être accédée depuis un cœur tiers). Dans certaines architectures, le cœur de processeur comprend la ou les extensions matérielles. Dans d'autres architectures, les circuits physiques d'une extension matérielle peuvent englober un cœur de processeur. Un cœur de processeur 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).
Un cœur de processeur peut posséder toutes les extensions matérielles requises pour l'exécution des instructions que contient une tâche donnée. Un cœur de processeur peut aussi ne pas nécessairement posséder toutes les extensions matérielles requises pour l'exécution des instructions comprises dans la tâche de calcul : le problème technique du déplacement et/ou de l'émulation (i.e. de la fonctionnalité ou de l'instruction) - et des coûts associés- se pose. Les extensions matérielles peuvent être de nature différente. Une extension peut traiter un jeu d'instructions qui lui est spécifique.
Une extension matérielle est généralement coûteuse en surface de circuit et en énergie statique. Une plateforme asymétrique, comparée à un processeur symétrique, réduit le coût en surface et en énergie, en réduisant d'une part le nombre d'extensions et d'autre part en allumant ou en éteignant des cœurs contenant les extensions que lorsque cela est nécessaire ou avantageux.
Concernant la nature de l'association entre les cœurs de processeur et les extensions matérielles: dans un mode de réalisation, un cœur de processeur accède de manière exclusive à une ou plusieurs extensions matérielles qui lui sont dédiées. Dans un autre mode de réalisation, une extension peut être « partagée » entre plusieurs cœurs de processeur. Dans ces différentes configurations, il convient de répartir au mieux la charge de calcul. Par exemple, il est avantageux de ne pas surcharger une extension qui serait partagée. Le système d'exploitation par le biais de l'ordonnanceur fournit des quanta de temps, chaque quantum de temps étant alloué à une application logicielle donnée. Selon un mode de réalisation de l'invention, l'ordonnanceur (ou « scheduler » en anglais) est de type préemptif (i.e. les quanta de temps sont imposés aux applications logicielles).
Il est divulgué un procédé (mis en œuvre par ordinateur) pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un cœur dudit processeur étant associé à une ou plusieurs extensions matérielles, le procédé comprenant les étapes consistant à recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur multi-cœurs; recevoir des données de calibration associées à ladite extension matérielle; et déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration.
Un ou plusieurs coûts d'opportunité d'exécution peuvent être déterminés. Au moins un cœur de processeur parmi la pluralité des cœurs est ainsi caractérisé par un coût d'opportunité d'exécution de la tâche de calcul reçue.
Le procédé selon l'invention considère diverses « opportunités » de placement, i.e. des possibilités ou potentialités, qui sont analysées.
Dans un développement, la tâche de calcul comprend des instructions associées à une ou plusieurs classes prédéfinies d'instructions et l'extension matérielle est associée à une ou plusieurs classes prédéfinies d'instructions, lesdites classes étant exécutables par ladite extension.
Dans un développement, les données de calibration comprennent des coefficients indicatifs d'un coût unitaire d'exécution par classe d'instruction, lesdits coefficients étant déterminés par comparaison entre l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de ladite extension sur ladite extension matérielle d'une part et l'exécution dudit ensemble prédéfini d'instructions sur un cœur de processeur sans extension matérielle d'autre part.
L'« ensemble prédéfini d'instructions représentatif de l'espace d'exécution » (ER) vise à représenter les différentes possibilités d'exécution des instructions, de manière la plus complète i.e. la plus exhaustive possible. En ce qui concerne la nature des instructions (i.e. les classes ou types d'instructions), une exhaustivité peut être atteinte. En revanche, la combinatoire des enchaînements des différentes instructions étant virtuellement infinie, la représentation est nécessairement imparfaite. Elle peut néanmoins être approchée asymptotiquement. Le principe consistant à exécuter un ensemble d'instructions permet de déterminer des « points de contrôle » du procédé selon l'invention (e.g. des données de calibration efficaces). Expérimentalement, une centaine de « programmes » ont été conduits, chacun contenant des « tests » (des exécutions unitaires) et l'exécution d'applications logicielles en conditions réelles. Les tests unitaires ont visé à exécuter un petit nombre de type d'instructions, principalement en virgule flottante, de contrôle et/ou de mémoire. Différents benchmarks ont été utilisés (par exemple MiBench, SDVBS, WCET, fbench, Polybench). L'exécution d'applications logicielles réelles a visé à représenter les principaux enchaînements en matière d'exécution d'instructions. Les applications logicielles ont notamment utilisé des jeux de données différents.
Dans un mode de réalisation chaque application logicielle peut être compilée pour un cœur de processeur avec extension matérielle et également compilée pour un cœur sans extension. Les deux versions de binaires sont alors exécutées sur les différents coeurs. La différence en matière de temps d'exécution est déterminée ainsi que le nombre et la nature des classes d'instructions exécutées. Pour un ensemble assez grand d'applications, il est possible de déterminer un nuage de points représentant l'espace total d'exécution. Par suite, il est possible d'établir une corrélation entre le nombre d'instructions associé à chaque classe d'instructions et la différence du temps d'exécution entre cœurs avec ou sans extension.
Pour améliorer la propriété de représentativité de l'espace représentatif (ER), le nombre d'applications logicielles peut être augmenté. Par l'emploi de techniques statistiques, cette représentativité peut être déterminée (utilisation d'instructions aléatoires, seuils, intervalles de confiance, distribution du nuage de points, etc). Par suite, un nombre minimal (ou optimal) d'applications logicielles devant être exécutées en conditions réelles peut être déterminé. En comparant l'exécution d'instructions sur un cœur avec extension et sur un cœur sans extension, certains résultats ont mis en évidence des écarts de l'ordre de 10 à 20% entre les performances telles qu'estimées selon le procédé et les performances réellement mesurées. Cet ordre de grandeur rend compte de la possibilité de mise en œuvre opérationnelle de l'invention (et ceci sans optimisation additionnelle).
Dans un développement, le procédé comprend en outre une étape consistant à déterminer un nombre d'utilisations de chaque classe d'instructions associée à la tâche de calcul par ladite extension matérielle. Dans un développement, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprend une étape consistant à compter le nombre d'utilisations de chaque classe d'instructions. Dans un mode de réalisation, l'historique i.e. le passé sert à estimer ou évaluer le futur. Dans un développement, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprend une étape consistant à estimer le nombre d'utilisations de chaque classe d'instructions, notamment à partir des utilisations comptées dans le passé. Il est aussi possible d'estimer le nombre d'utilisations à partir d'autres méthodes. Il est également possible de combiner le fait de compter et le fait d'estimer le nombre d'utilisations des classes d'instructions.
Dans un développement, le coût d'opportunité d'exécution est déterminé par sommation indexée par classe d'instructions des coefficients par classe d'instructions multipliés par les nombres d'utilisations par classe d'instructions. Dans la présente description, le coût d'opportunité d'exécution est aussi parfois appelé « dégradation » (selon la perspective d'une perte de performances). Symétriquement, il peut aussi s'agir de « gains d'exécution » (« accélérations » ou « bénéfices » ou « améliorations »). Le coût d'opportunité d'exécution peut être déterminé à partir du nombre d'utilisations qui sont donc comptées effectivement et/ou estimées en fonction de l'historique de comptage. Avantageusement, la détermination en amont du « coût d'opportunité d'exécution » (spécifiquement défini par l'invention) permet des optimisations efficaces conduites en aval (telles que décrites ci-après). Le « coût d'opportunité d'exécution » selon l'invention correspond donc à une « grille de lecture » spécifique du processeur et de la gestion des tâches de calcul, c'est-à-dire à la définition d'un « résultat intermédiaire » (d'aide à la décision) permettant par la suite de conduire des étapes de gestion spécifiques et dépendantes de cette caractérisation. Cette perspective est particulièrement pertinente dans la mesure où elle permet de contrôler efficacement le processeur (des agrégats intermédiaires permettent d'améliorer la contrôlabilité du système). Pour rappel, de manière spécifique, la prise en compte des classes d'instructions et du nombre d'utilisations de ces classes d'instructions permettent la détermination dudit «coût d'opportunité d'exécution ».
Dans un développement, les coefficients sont déterminés hors ligne. Il est possible de déterminer les données de calibration une fois pour toute (« offline »). Par exemple les données de calibration peuvent être fournies par le constructeur du processeur. Les données de calibration peuvent être présentes dans un fichier de configuration. Dans un développement, les coefficients sont déterminés en ligne. Les coefficients peuvent être déterminés durant l'exécution d'un programme, par exemple au « reset » de la plateforme. Dans un système ouvert (par exemple cluster ou « Cloud »), dont la topologie est inconnue a priori, il est possible de calibrer chaque extension au démarrage et de déterminer la topologie globalement.
Dans un développement, les coefficients sont déterminés par analyse statistique multivariée. Différentes techniques d'analyse statistique multivariée peuvent être utilisées, éventuellement combinées. La régression (linéaire) est avantageusement rapide. L'analyse en composantes principales (ACP) avantageusement permet de réduire le nombre de coefficients. D'autres techniques utilisables comprennent l'analyse factorielle des correspondances (AFC), l'analyse dite factorielle, le partitionnement de données (clustering), le positionnement multidimensionnel (MDS, pour « multidimensional scaling »), l'analyse des similarités entre variables, l'analyse de régression multiple, l'analyse de la variance ANOVA (bivariée), et sa généralisation multivariée (Analyse de la variance multivariée), l'analyse discriminante, l'analyse canonique des corrélations, la régression logistique (modèle LOGIT), les réseaux de neurones artificiels, les arbres de décision, les modèles d'équations structurelles, l'analyse conjointe etc.
Dans un développement, la tâche de calcul reçue est associée à un cœur de processeur prédéterminé et le coût d'opportunité d'exécution de la tâche de calcul est associé à un cœur de processeur autre que le cœur de processeur prédéterminé. Il est généralement considéré (mais ce n'est pas obligatoire) quel serait le coût d'exécution sur le processeur prédéterminé (le cas échéant), i.e. quel serait le coût de « poursuite » d'exécution. Dans les autres cas, les autres cœurs « candidats » sont pris en considération (un, plusieurs ou la totalité des cœurs adressables).
Dans un développement, le coût d'opportunité d'exécution de la tâche de calcul est déterminé pour au moins un cœur de processeur autre que le cœur de processeur prédéterminé. Dans un développement, tous les cœurs de processeurs sont considérés chacun à leur tour et l'optimisation du placement consiste à minimiser le coût d'opportunité d'exécution (c'est-à-dire par exemple à sélectionner le cœur de processeur associé au coût d'opportunité d'exécution le plus bas ou le plus faible).
Dans certains modes de réalisation, il peut être utilisé une telle fonction « minimum ». Dans d'autres modes de réalisation, des algorithmes spécifiques (séquence d'étapes) et/ou des fonctions analytiques et/ou des heuristiques peuvent être utilisées (par exemple, les cœurs candidats peuvent être comparés par paires et/ou échantillonnés selon diverses modalités, par exemple de manière à accélérer la prise de décision en matière de placement). De manière complémentaire (c'est-à-dire de manière entièrement facultative) à la prise en compte du coût d'opportunité d'exécution, d'autres critères peuvent être pris en compte pour optimiser le placement de la tâche de calcul. Ces critères peuvent être pris en compte de manière additionnelle (mais dans certains cas peuvent se substituer au critère de coût d'opportunité d'exécution). Ces critères généralement complémentaires peuvent notamment comprendre des paramètres relatifs au temps d'exécution de la tâche de calcul et/ou au coût énergétique associé à l'exécution de la tâche de calcul et/ou la température (i.e. à la conséquence locale de l'exécution considérée).
Les différents coûts (opportunités d'exécution, température, énergie, performances, etc) peuvent être comparés entre eux et diverses logiques d'arbitrage peuvent permettre de sélectionner un cœur en particulier en considération de ces différents critères. S'agissant d'optimisation combinatoire ou d'une optimisation multi-objectifs (certains objectifs peuvent être antagonistes), différentes techniques mathématiques sont applicables. La pondération de ces différents critères peut notamment être variable et/ou configurable. Les poids respectifs alloués aux différents critères d'optimisation du placement peuvent par exemple être configurés en ligne ou hors ligne. Ils peuvent être « statiques » ou « dynamiques ». Par exemple, la priorité et/ou le poids de ces différents critères peuvent être variables au cours du temps. Des fonctions analytiques ou des algorithmes peuvent réguler les différentes allocations ou arbitrages ou compromis ou priorités entre critères d'optimisation du placement des tâches de calcul.
Dans un développement, la détermination du coût énergétique comprend une ou plusieurs étapes parmi les étapes consistant à recevoir des indications initiales d'utilisation d'une ou de plusieurs extensions matérielles prédéfinies et/ou à recevoir des états de consommation d'énergie (par exemple DVFS) par cœur de processeur et/ou à recevoir des informations d'asymétrie en performance et une étape consistant à déterminer une optimisation énergétique de type power-gating et/ou clock-gating.
Dans un développement, le procédé comprend en outre une étape consistant à déterminer un coût d'adaptation des instructions associées à la tâche de calcul, ladite étape comprenant une ou plusieurs étapes parmi les étapes consistant à traduire une ou plusieurs instructions et/ou sélectionner une ou plusieurs versions instructions et/ou émuler une ou plusieurs instructions et/ou exécuter une ou plusieurs instructions dans une machine virtuelle. L'adaptation des instructions devient nécessaire s'il est déterminé, à la suite des étapes précédentes, un cœur de processeur ne possédant par l'extension matérielle requise (cœur « non-équipé »)
Dans un développement, le procédé comprend en outre une étape consistant à recevoir un paramètre et/ou une règle logique d'ordonnancement et/ou de placement. Ce développement souligne les différentes possibilités en matière de « contrôlabilité » du procédé selon l'invention. Des règles logiques (expressions booléennes, logique floue, règles métier, etc) peuvent être reçues de modules tiers. Des valeurs seuils factuelles également, telles que des températures maximales, des plages de temps d'exécution etc. Dans un développement, le procédé comprend en outre une étape consistant à déplacer la tâche de calcul du cœur de processeur prédéterminé au cœur de processeur déterminé.
Dans un développement, le procédé comprend en outre une étape consistant à désactiver ou éteindre un ou plusieurs cœurs de processeur. Désactiver ou « couper le signal d'horloge » ou « mettre le cœur dans un état de consommation réduit » (e.g. diminuer la fréquence d'horloge) ou « éteindre » (« dark silicon »)
Dans un développement, le processeur multi-coeurs fonctionnellement asymétrique est un processeur physique ou un processeur virtuel. Le processeur est un processeur tangible ou physique. Le processeur peut aussi être un processeur virtuel, i.e. défini de manière logique. Le périmètre peut par exemple être défini par le système d'exploitation. Un processeur peut aussi être déterminé par un hyperviseur.
Il est divulgué un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer une ou plusieurs étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur.
Il est divulgué un système comprenant des moyens pour la mise en œuvre d'une ou plusieurs étapes du procédé.
Dans un développement, le système comprend un processeur multi- coeurs fonctionnellement asymétrique, au moins un cœur dudit processeur étant associé à une ou plusieurs extensions matérielles, le système comprenant des moyens de réception pour recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur multi- cœurs; des moyens de réception pour recevoir des données de calibration; et des moyens pour déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration.
Dans un développement, le système comprend en outre des moyens choisis parmi des moyens de placement pour placer une ou plusieurs tâches de calcul sur un ou plusieurs cœurs du processeur; des moyens pour compter l'utilisation de classes d'instructions par une extension matérielle, lesdits moyens comprenant des compteurs logiciels et/ou matériels ; des moyens ou des registres pour sauvegarder le contexte d'exécution d'une tâche de calcul ; des moyens pour déterminer le coût de migration et/ou le coût d'adaptation et/ou le coût énergétique associé à la poursuite de l'exécution d'une tâche de calcul sur un cœur de processeur prédéfini; des moyens de réception d'un ou de plusieurs paramètres et/ou règles d'ordonnancement; des moyens pour déterminer et/ou sélectionner un cœur de processeur; des moyens pour exécuter sur un cœur de processeur sans extension matérielle associée une tâche de calcul prévue initialement pour s'exécuter sur un processeur comprenant une ou plusieurs extensions matérielles; des moyens pour déplacer une tâche de calcul d'un cœur de processeur à un autre cœur de processeur; et des moyens pour désactiver ou éteindre un ou plusieurs cœurs de processeur.
La figure 1 illustre des exemples d'architectures de processeurs. Un processeur multi-cœur fonctionnellement asymétrique FAMP 120 est comparé à un processeur multi-cœur symétrique SMP 110 dont chaque cœur contient toutes les extensions matérielles et comparé à un processeur multi-cœur symétrique SMP 130 contenant seulement des cœurs basiques. L'architecture peut-être à mémoire partagée ou distribuée. Les cœurs peuvent parfois être reliés par un NoC (Network- on-Chip).
Une architecture FAMP 120 est proche de celle d'un processeur multi- cœurs symétrique SMP 130. L'architecture mémoire reste homogène, mais les fonctionnalités des cœurs peuvent être hétérogènes. Tel qu'illustré à l'exemple de la figure 1 , une architecture FAMP 120 peut comprendre quatre types de cœurs différents (avec la même base). La taille du processeur peut donc être réduite. Du fait de la faculté de pouvoir allumer ou éteindre les cœurs, et par suite de choisir lequel allumer en fonction de besoin de l'application logicielle, différentes optimisations peuvent être effectuées (gain en énergie, réduction de la température des cœurs, etc.).
Les figures 2A et 2B illustrent certains aspects de l'invention en matière d'efficacité énergétique, selon que des extensions matérielles sont utilisées ou non.
La figure 2A fait référence à un processeur « Full » (ou « étendu », i.e. avec une ou plusieurs extensions matérielles) et « Basic » (sans extension matérielle). La figure illustre l'énergie consommée par un processeur (surfaces 121 et 122) en fonction de la puissance consommée (« Power » en ordonnée 111 ) pendant une durée d'exécution (temps en abscisse 112) pour une même application ou thread sur les deux types de processeurs. Sur un processeur « Full » avec une puissance énergétique Pf, une tâche de calcul exécutée durant un temps tf consomme une énergie EFUII 121 . Sur un processeur « Basic » avec une puissance énergétique Pb, une tâche de calcul exécutée durant un temps tb consomme EBaSic 122. La puissance Pf est supérieure à la puissance Pb car l'extension matérielle demande plus de puissance. Il est fréquent que le temps d'exécution tb soit supérieur au temps d'exécution tf car ne possédant pas d'extension, un processeur basic exécute moins rapidement la tâche de calcul.
Un objectif général consiste à minimiser l'énergie consommée, i.e. l'aire de la surface (temps d'exécution le plus court possible avec une puissance minimale). Dans l'exemple de la figure 2A, le processeur Full est plus efficace. En considérant Pb et Pf comme des constantes, le rapport tb/tf indique « accélération » du calcul due à l'extension matérielle.
La figure 2B illustre la variation du gain en énergie (EBaSic / EFUII) en fonction de l'accélération tb tf, ce qui indique l'opportunité d'utiliser un processeur étendu avec extension(s) matérielle(s) plutôt que sans. Si le rapport EBasic/EFuii est inférieur à 1 , cela indique qu'il y a moins d'énergie consommée avec un processeur de type Basic qu'avec un processeur Etendu (le cas échéant, ce domaine d'opération 141 est appelé « slighlty extended » ce qui traduit que l'extension matérielle n'est pas assez utilisée). Si le rapport EBasic/EFuii est inférieur à 1 et le rapport d'accélération tb tf est inférieur à 1 , cela traduit un gain à la fois en énergie consommée et en performance de temps de calcul à l'avantage du processeur sans extension matérielle (cette situation peut arriver dans les cas où l'extension mal utilisée). Si le rapport EBasic/EFuii est supérieur à 1 , le processeur étendu consomme moins d'énergie (section 143 « highly extended ») : l'extension accélère le code (i.e. les instructions) et les gains sont obtenus tant en matière d'énergie (elle est moindre) qu'en matière d'accélération (exécution plus rapide). II peut être noté que lorsque EBasic/EFuii égale 1 , le ratio tb/tf vaut généralement Pb /Pf (quand les processeurs de type basic et étendu consomment autant d'énergie, l'accélération associée se ramène généralement au rapport des puissances des processeurs). Lorsque tb/tf égale 1 (quand les durées d'exécution sont les mêmes), EBasic/EFuii ¾ Pf/Pb (i.e. il est en général observé que les rapports de consommation d'énergie et de puissance sont généralement sensiblement égaux)
Le domaine d'opération 144 correspond à une accélération des calculs simultanément à une consommation énergétique moindre, à l'avantage d'un processeur étendu avec extension matérielle. Une extension matérielle peut réduire la consommation d'énergie en réduisant le nombre d'étapes requis pour effectuer des calculs spécifiques. Lorsque l'utilisation de l'extension matérielle est suffisamment intensive, l'accélération du calcul sur l'extension peut compenser l'alimentation additionnelle requise par l'extension elle-même.
En comparaison de coprocesseurs, une extension matérielle peut être plus efficace, en raison du fort couplage existant entre extension et cœur. Les extensions matérielles partagent fréquemment une part significative du cœur « basic » et tirent avantage de l'accès direct aux mémoires cache de type L1 et L2. Ce couplage permet notamment de réduire les transferts de données et la complexité de synchronisation.
Quand bien même des outils de compilation permettent de maximiser l'utilisation d'une extension matérielle, les utilisations d'extensions matérielles peuvent demeurer anecdotiques en comparaison de la charge globale du processeur. Une extension matérielle implique généralement un coût additionnel en termes de surface et de consommation d'énergie statique. Une extension comprend souvent des registres de taille significative, qui peuvent requérir une bande passante plus étendue ainsi que des transferts de données plus importants que ceux nécessités par le circuit cœur. Si l'utilisation de l'extension matérielle est trop faible, sa consommation d'énergie propre dépassera vraisemblablement les économies d'énergie visée en raison de l'accélération matérielle. Pire, une extension matérielle sous-utilisée peut amener à une réduction de performance de l'exécution d'une application logicielle. Par exemple, dans le cas de transferts de données intensifs entre l'extension matérielle et les registres du cœur, le surcoût du transfert mémoire peut annuler le bénéfice résidant dans l'accélération. Une extension matérielle n'est généralement pas « transparente » pour le développeur d'applications. Par opposition aux fonctionnalités de type super-scalaire, le développeur est fréquemment contraint de gérer de manière explicite les jeux d'instruction étendus. Par suite, l'emploi d'extensions matérielles peut s'avérer onéreux en comparaison du seul circuit cœur. Par exemple, l'extension NEON/VFP pour processeur ARM compte pour environ 30% de la surface d'un processeur de type Cortex A9 (sans prendre en compte les caches, et 10% en comptant le cache L1 ).
Néanmoins, les extensions matérielles sont critiques et demeurent nécessaires pour adresser certains problèmes techniques, notamment en matière de puissance et de performances requises dans certaines classes d'application (comme par exemple dans les applications multimédias, de cryptographie, de traitement d'images et du signal). Au sein d'une architecture symétrique multiprocesseur (SMP), afin de maintenir une un jeu d'instruction homogène pour les différents cœurs de processeur, des extensions doivent être implémentées dans chaque cœur de processeur. Cette symétrie ISA implique notamment l'emploi d'une surface significative et d'une certaine consommation d'énergie, ce qui à son tour limite les avantages d'accélération matérielle via des extensions.
Avantageusement, le procédé selon l'invention permet de (a) distribuer asymétriquement les extensions dans un processeur multi-cœurs, (b) de savoir quand l'utilisation d'une extension est « utile » d'un point de vue performances et énergie et (c) de déplacer l'application au cours du temps sur différents cœurs, indépendamment de leur besoin de départ (lequel est choisi à la compilation et donc pas nécessairement adéquat avec le contexte d'exécution) La figure 3 illustre des exemples d'architectures et de placement des tâches. La figure montre des exemples d'ordonnancement de tâches sur un SMP, et deux types d'ordonnancement sur un FAMP. L'unité FPU ajoute des instructions de type FP à un circuit ISA.
Dans le premier cas 310 (SMP), chaque quanta de la tâche est exécuté sur un processeur ayant une FPU {Floating Point Unit). Il se trouve que le premier et le dernier quanta ne contiennent pas d'instructions FP.
Dans le deuxième cas 320 (« ISA-constrained »), grâce à l'asymétrie de la plateforme, le premier et le dernier quanta peuvent s'exécuter sur un cœur simple (n'ayant pas de FPU), ce qui réduit la consommation d'énergie lors de l'exécution. Or le 3eme quanta contient des extensions FP, mais pas assez pour « valoriser » l'unité FP.
Dans le troisième cas 330, le procédé selon l'invention permet au troisième quanta d'être exécuté sur un processeur de type « basic », ce qui permet d'optimiser la consommation énergétique pour exécuter cette tâche de calcul.
La figure 4 fournit des exemples d'étapes du procédé selon l'invention.
Les étapes se déroulent au sein d'un processeur multi-cœurs, pour lequel un ordonnanceur (en anglais « scheduler ») procède au placement des tâches de calcul durant l'exécution d'un programme. A l'étape 400, qui se déroule en ligne et en boucle, les données relatives à l'utilisation des extensions matérielles sont collectées (par exemple par l'ordonnanceur). L'usage des extensions est surveillé (« monitoring » en anglais). Dans un mode de réalisation, le procédé pour récupérer les données au cours de l'exécution se concentre seulement sur les instructions à destination des extensions matérielles ou hardware. Selon ce mode de réalisation, le procédé est indépendant du processus d'ordonnancement. Lorsque le code est exécuté sur un processeur avec extension (i.e. avec une ou plusieurs extensions), la surveillance peut s'appuyer sur des compteurs matériels. Lorsque le code est exécuté sur un processeur de type « basic », les instructions étendues ne sont plus exécutées nativement. Par exemple le cas échéant, il faut ajouter des routines (par exemple au moment de l'adaptation du code ou dans la fonction d'émulation si applicable) pour compter le nombre d'instructions de chaque classe de l'extension qu'un processeur avec extension aura ou aurait exécuté. En substitution ou en complément, le procédé selon l'invention peut utiliser des compteurs logiciels et/ou des compteurs matériels associés aux dits compteurs logiciels.
Un système de « monitoring » peut être très lourd à l'exécution. Dans le cadre de l'invention, les données collectées sont liées aux seules instructions impliquant des extensions, et de fait le ralentissement est négligeable car il peut être fait en parallèle de l'exécution. Dans le cadre d'un processeur de type « basic », le remplissage des compteurs peut être fait séquentiellement pendant l'émulation de la fonctionnalité accélérée par les autres cœurs, ce qui peut rajouter un surcoût en matière de performance. Pour réduire ce surcoût, il est possible de récolter les données de manière périodique, et, le cas échéant, de procéder à une interpolation.
A l'étape 410, il est déterminé un événement de l'ordonnanceur (par exemple la fin d'un quanta), lequel déclenche l'étape 320.
A l'étape 420, les données collectées sont lues. Par exemple, l'ordonnanceur récupère les données collectées par le monitor (A.0) (par exemple en lisant les registres hardware ou software).
A l'étape 420, une prédiction est effectuée. Grâce aux données récupérées, le système de prédiction étudie le comportement de l'application par rapport à l'utilisation des classes d'instructions étendues. En analysant ce comportement, il prédit le comportement futur de l'application. Dans un mode de réalisation, la prédiction est dite simple, i.e. s'effectue de manière réactive, en posant l'hypothèse que le comportement de l'application dans le prochain quanta va être similaire au dernier quanta exécuté. Dans un mode de réalisation, la prédiction est dite « complexe » et comprend des étapes consistant à déterminer les différents types de phases du programme. Par exemple, ces types de phases peuvent être déterminés en sauvegardant une table d'historique de comportement et en analysant cet historique. Des signatures peuvent être utilisées. Par exemple, l'unité de prédiction peut associer des signatures à des comportements exécutés par la suite. Quand une signature est détectée, l'unité de prédiction peut indiquer le comportement futur i.e. prédire les futures opérations connues et associées à la signature.
A l'étape 430, il est procédé à une estimation dite de « dégradation ». (« Basic » versus « Full », i.e. estimation de la dégradation de la performance associée à l'exécution d'une tâche de calcul sur un processeur sans extension matérielle comparée à celle exécutée sur un processeur avec extension matérielle). Une tâche donnée n'est pas testée sur chacun des professeurs mais il est estimé, au moment de l'ordonnancement, le coût que la tâche aurait sur des processeurs différents. Dans un mode de réalisation (e.g. hors ligne « offline »), la totalité du code est simulée, en prenant en compte les particularités complètes du processeur. Ce type d'approche n'est généralement pas utilisable dynamiquement (en ligne). En considérant le cas particulier selon lequel les cœurs de processeur ont tous la même base, toutes les instructions sont exécutées de la même façon dans les différents cœurs (par exemples deux cœurs). Certains effets de bord peuvent apparaître entre les cœurs, par exemple en raison de mises en cache, mais ces effets restent résiduels et peuvent être pris en compte lors de l'apprentissage du modèle. L'estimation de la dégradation de performances peut s'effectuer de différentes manières.
Dans une première approche, il est seulement tenu compte du pourcentage global de l'utilisation de l'extension matérielle. L'estimation de la dégradation peut en effet s'appuyer sur un modèle permettant de calculer ladite dégradation en fonction du pourcentage de chaque classe d'instructions par l'extension. Cette approche ne convient néanmoins pas nécessairement puisque différents types d'instructions peuvent avoir des accélérations très différentes pour une même extension matérielle.
Dans une deuxième approche, une estimation de la dégradation de performance peut prendre en compte les classes d'instructions et revêtir une forme selon:
Selon cette approche pondérée, les valeurs des coefficients de pondération β (« beta ») peuvent être calculées dynamiquement en ligne en procédant à un apprentissage effectué grâce à l'exécution de plusieurs codes sur différents types de processeurs. Ces valeurs peuvent être aussi calculées hors ligne (et stockées dans une table lisible par l'ordonnanceur par exemple).
Les données de calibration déterminées à partir de l'exécution de tâches de calcul réelles permettent notamment de prendre en compte le coût d'émulation et les évolutions complexes des coefficients beta. Par exemple ; les valeurs beta peuvent être distinguées pour une plateforme réelle et pour une plateforme simulée.
Au runtime (avant ou durant l'exécution d'une tâche de calcul), les coefficients beta sont utilisés par le scheduler de manière à estimer la dégradation de performances. La calibration doit être réitérée pour chaque implementation d'une extension matérielle.
Les étapes de prédiction 430 et d'estimation de la dégradation 440 sont chronologiquement indépendantes.
La dégradation peut être estimée (440) à partir des données prédites (430). Alternativement, la dégradation 440 peut être calculée à partir des données récupérées à l'étape 400 et 420, avant que la prédiction 430 se fonde sur la dégradation 440 ainsi calculée. Dans ce cadre là, la future dégradation est prédite (et non les futures instructions des extensions). Les données changent mais le processus de prédiction reste le même.
Autrement dit, à l'étape 430, l'objectif est de « prédire » le nombre d'instructions de chaque classe qui sera exécuté à t+1 en fonction du passé (de t, t-1 ...t-n). A l'étape 440, l'objectif est d' « estimer » le coût d'exécution à t+1 sur les différents types de cœurs. Les étapes 430 et 440 peuvent être effectuées dans un ordre indifférent car il est possible de manière indépendante d'estimer le coût au temps t sur les données récupérées et de prédire le coût au temps t+1 à partir du coût au temps t.
Formulé encore différemment, une approche de « prédiction » consiste en une détermination relative du futur à partir des données accessibles au présent. Une « estimation » permet une détermination du présent au moyen des données observées dans le passé. Dans une autre perspective, une « estimation » permet la détermination du passé dans un nouveau contexte à partir d'observations du passé dans un autre contexte.
Selon une implémentation du procédé de l'invention (au « runtime »), un module de surveillance capture les données de calibration et un module d'analyse estime l'accélération associée à l'emploi d'une extension. En matière de surveillance, les données d'entrée doivent être les plus proches possible dans le temps des instructions étendues devant être exécutées au quanta suivant (en faisant une hypothèse de continuité, e.g. utilisation stable d'une unité de calcul en virgule flottante). Un module de prédiction peut alors être utilisé. Cette hypothèse est réaliste quand les programmes possèdent des phases distinctes de comportements stables sur des intervalles de temps suffisamment longs. Dans le cas de comportements plus erratiques, des modules de prédiction plus avancés peuvent être mis en œuvre,
A l'étape 450, il est effectué une étape de décision. Une unité logique de décision par exemple peut prendre en compte les informations de l'estimation de dégradation prédite et/ou les objectifs globaux assignés à la plateforme, les objectifs comprenant par exemple des objectifs en termes de réduction d'énergie, de performance, de priorité et de disponibilité des cœurs. Dans d'autres exemples, la dégradation peut aussi prendre en compte des paramètres tels que le coût de migration et/ou le coût d'adaptation du code. Dans certains cas, le coût de migration et le coût de la station peuvent être statiques (e.g. apprentissage hors ligne) ou bien dynamiques (e.g. apprentissage en ligne ou surveillance temporelle en ligne).
A l'étape 460, il peut être procédé à la migration d'un cœur vers un autre (« core-switching »). Les techniques de migration mise en œuvre peuvent être effectuées avec la sauvegarde du contexte (par exemple avec sauvegarde des registres de l'extension dans des registres logiciels accessibles depuis l'émulation).
A l'étape 470, il est procédé à l'adaptation éventuelle du code. Par exemple, pour exécuter du code avec des extensions sur un processeur de type « basic », il est possible d'utiliser des techniques d'adaptions binaires (e.g. par translation de code), de multi-version de code, ou bien encore d'émulation. La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique ou électromagnétique.

Claims

Revendications
1 . Procédé mis en œuvre par ordinateur pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un cœur dudit processeur étant associé à une ou plusieurs extensions matérielles, le procédé comprenant les étapes consistant à :
- recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur multi-cœurs;
- recevoir des données de calibration associées à ladite extension matérielle;
- déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration.
2. Procédé selon la revendication 1 , la tâche de calcul comprenant des instructions associées à une ou plusieurs classes prédéfinies d'instructions et l'extension matérielle étant associée à une ou plusieurs classes prédéfinies d'instructions, lesdites classes étant exécutables par ladite extension.
3. Procédé selon les revendications précédentes, les données de calibration comprenant des coefficients indicatifs d'un coût unitaire d'exécution par classe d'instruction, lesdits coefficients étant déterminés par comparaison entre l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de ladite extension sur ladite extension matérielle d'une part et l'exécution dudit ensemble prédéfini d'instructions sur un cœur de processeur sans extension matérielle d'autre part.
4. Procédé selon la revendication 3, comprenant en outre une étape consistant à déterminer un nombre d'utilisations de chaque classe d'instructions associée à la tâche de calcul par ladite extension matérielle.
5. Procédé selon la revendication 4, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprenant une étape consistant à compter le nombre d'utilisations de chaque classe d'instructions.
6. Procédé selon la revendication 4 ou 5, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprenant une étape consistant à estimer le nombre d'utilisations de chaque classe d'instructions, notamment à partir des utilisations comptées dans le passé.
7. Procédé selon l'une quelconque des revendications 4 ou 6, le coût d'opportunité d'exécution étant déterminé par sommation indexée par classe d'instructions des coefficients par classe d'instructions multipliés par les nombres d'utilisations par classe d'instructions.
8. Procédé selon la revendication 3, les coefficients étant déterminés hors ligne.
9. Procédé selon la revendication 3, les coefficients étant déterminés en ligne.
10. Procédé selon la revendication 3, les coefficients étant déterminés par analyse statistique multivariée.
11 . Procédé selon l'une quelconque des revendications précédentes, la tâche de calcul reçue étant associée à un cœur de processeur prédéterminé et le coût d'opportunité d'exécution de la tâche de calcul étant déterminé pour au moins un cœur de processeur autre que le cœur de processeur prédéterminé.
1 2. Procédé selon la revendication 11 , comprenant en outre une étape consistant à déterminer un cœur de processeur parmi la pluralité des cœurs du processeur pour l'exécution de ladite tâche de calcul, ladite étape comprenant les étapes consistant à déterminer le coût d'opportunité d'exécution pour tout ou partie des cœurs de processeur du processeur multi-cœurs et à minimiser le coût d'opportunité d'exécution.
1 3. Procédé selon la revendication 1 1 ou 12, comprenant en outre une étape consistant à déterminer un cœur de processeur parmi la pluralité des cœurs du processeur pour l'exécution de ladite tâche de calcul, ladite détermination minimisant le temps d'exécution de la tâche de calcul et/ou le coût énergétique et/ou la température.
14. Procédé selon la revendication 13, la détermination du coût énergétique comprenant une ou plusieurs étapes parmi les étapes consistant à recevoir des indications initiales d'utilisation d'une ou de plusieurs extensions matérielles prédéfinies et/ou à recevoir des états de consommation d'énergie DVFS par cœur de processeur et/ou à recevoir des informations d'asymétrie en performance et une étape consistant à déterminer une optimisation énergétique de type power-gating et/ou clock-gating.
15. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à déterminer un coût d'adaptation des instructions associées à la tâche de calcul, ladite étape comprenant une ou plusieurs étapes parmi les étapes consistant à traduire une ou plusieurs instructions et/ou sélectionner une ou plusieurs versions instructions et/ou émuler une ou plusieurs instructions et/ou exécuter une ou plusieurs instructions dans une machine virtuelle.
1 6. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à recevoir un paramètre et/ou une règle logique d'ordonnancement et/ou de placement.
1 7. Procédé selon la revendication 1 6, comprenant en outre une étape consistant à déplacer la tâche de calcul du cœur de processeur prédéterminé au cœur de processeur déterminé.
1 8. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à désactiver ou éteindre un ou plusieurs cœurs de processeur.
19. Procédé selon l'une quelconque des revendications précédentes, le processeur multi-coeurs fonctionnellement asymétrique étant un processeur physique ou un processeur virtuel.
20. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 19, lorsque ledit programme est exécuté sur un ordinateur.
21 . Système comprenant des moyens pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 1 9.
22. Système selon la revendication 21 comprenant un processeur multi- coeurs fonctionnellement asymétrique, au moins un cœur dudit processeur étant associé à une ou plusieurs extensions matérielles, le système comprenant:
- des moyens de réception pour recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur multi-cœurs;
- des moyens de réception pour recevoir des données de calibration;
- des moyens pour déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration.
23. Système selon la revendication 21 ou 22 comprenant en outre des moyens choisis parmi :
- des moyens de placement pour placer une ou plusieurs tâches de calcul sur un ou plusieurs cœurs du processeur;
- des moyens pour compter l'utilisation de classes d'instructions par une extension matérielle, lesdits moyens comprenant des compteurs logiciels et/ou matériels ;
- des moyens ou des registres pour sauvegarder le contexte d'exécution d'une tâche de calcul ;
- des moyens pour déterminer le coût de migration et/ou le coût d'adaptation et/ou le coût énergétique associé à la poursuite de l'exécution d'une tâche de calcul sur un cœur de processeur prédéfini;
- des moyens de réception d'un ou de plusieurs paramètres et/ou règles d'ordonnancement;
- des moyens pour déterminer et/ou sélectionner un cœur de processeur;
- des moyens pour exécuter sur un cœur de processeur sans extension matérielle associée une tâche de calcul prévue initialement pour s'exécuter sur un processeur comprenant une ou plusieurs extensions matérielles;
- des moyens pour déplacer une tâche de calcul d'un cœur de processeur à un autre cœur de processeur;
- des moyens pour désactiver ou éteindre un ou plusieurs cœurs de processeur.
EP16711185.5A 2015-04-20 2016-03-14 Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique Withdrawn EP3286647A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1553478A FR3035243B1 (fr) 2015-04-20 2015-04-20 Placement d'une tache de calcul sur un processeur fonctionnellement asymetrique
PCT/EP2016/055401 WO2016173766A1 (fr) 2015-04-20 2016-03-14 Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique

Publications (1)

Publication Number Publication Date
EP3286647A1 true EP3286647A1 (fr) 2018-02-28

Family

ID=54291365

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16711185.5A Withdrawn EP3286647A1 (fr) 2015-04-20 2016-03-14 Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique

Country Status (4)

Country Link
US (1) US20180095751A1 (fr)
EP (1) EP3286647A1 (fr)
FR (1) FR3035243B1 (fr)
WO (1) WO2016173766A1 (fr)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102285481B1 (ko) * 2015-04-09 2021-08-02 에스케이하이닉스 주식회사 NoC 반도체 장치의 태스크 매핑 방법
US10700968B2 (en) * 2016-10-19 2020-06-30 Rex Computing, Inc. Optimized function assignment in a multi-core processor
US10355975B2 (en) 2016-10-19 2019-07-16 Rex Computing, Inc. Latency guaranteed network on chip
JP2018092311A (ja) * 2016-12-01 2018-06-14 キヤノン株式会社 情報処理装置、その制御方法、及びプログラム
ES2933675T3 (es) 2016-12-31 2023-02-13 Intel Corp Sistemas, métodos y aparatos para informática heterogénea
CA3108151C (fr) 2017-02-23 2024-02-20 Cerebras Systems Inc. Apprentissage profond accelere
US10795836B2 (en) * 2017-04-17 2020-10-06 Microsoft Technology Licensing, Llc Data processing performance enhancement for neural networks using a virtualized data iterator
US11488004B2 (en) 2017-04-17 2022-11-01 Cerebras Systems Inc. Neuron smearing for accelerated deep learning
WO2018193380A1 (fr) 2017-04-17 2018-10-25 Cerebras Systems Inc. Vecteurs de tissu pour accélération d'apprentissage profond
WO2018193352A1 (fr) 2017-04-17 2018-10-25 Cerebras Systems Inc. Tâches déclenchées par un flux de données pour apprentissage profond accéléré
WO2020044152A1 (fr) 2018-08-28 2020-03-05 Cerebras Systems Inc. Textile informatique mis à l'échelle pour apprentissage profond accéléré
US11321087B2 (en) 2018-08-29 2022-05-03 Cerebras Systems Inc. ISA enhancements for accelerated deep learning
US11328208B2 (en) 2018-08-29 2022-05-10 Cerebras Systems Inc. Processor element redundancy for accelerated deep learning
US11188617B2 (en) * 2019-01-10 2021-11-30 Nokia Technologies Oy Method and network node for internet-of-things (IoT) feature selection for storage and computation
WO2021074867A1 (fr) 2019-10-16 2021-04-22 Cerebras Systems Inc. Filtrage d'ondelettes avancé pour apprentissage profond accéléré
WO2021074795A1 (fr) 2019-10-16 2021-04-22 Cerebras Systems Inc. Routage dynamique pour apprentissage profond accéléré
US12008398B2 (en) * 2019-12-28 2024-06-11 Intel Corporation Performance monitoring in heterogeneous systems
US11775298B2 (en) * 2020-04-24 2023-10-03 Intel Corporation Frequency scaling for per-core accelerator assignments
CN113726474A (zh) * 2020-05-26 2021-11-30 索尼公司 物联网中的操作电子设备、管理电子设备和通信方法
US11989591B2 (en) * 2020-09-30 2024-05-21 Advanced Micro Devices, Inc. Dynamically configurable overprovisioned microprocessor
EP4411541B1 (fr) * 2023-02-01 2025-12-17 Airbus S.A.S. Procédé de planification de tâches mis en uvre par ordinateur

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4784827B2 (ja) * 2006-06-06 2011-10-05 学校法人早稲田大学 ヘテロジニアスマルチプロセッサ向けグローバルコンパイラ
US8782645B2 (en) * 2011-05-11 2014-07-15 Advanced Micro Devices, Inc. Automatic load balancing for heterogeneous cores
US9720730B2 (en) 2011-12-30 2017-08-01 Intel Corporation Providing an asymmetric multicore processor system transparently to an operating system
KR20130115574A (ko) * 2012-04-12 2013-10-22 삼성전자주식회사 단말기에서 태스크 스케줄링을 수행하는 방법 및 장치
US20150355700A1 (en) * 2014-06-10 2015-12-10 Qualcomm Incorporated Systems and methods of managing processor device power consumption

Also Published As

Publication number Publication date
WO2016173766A1 (fr) 2016-11-03
FR3035243B1 (fr) 2018-06-29
US20180095751A1 (en) 2018-04-05
FR3035243A1 (fr) 2016-10-21

Similar Documents

Publication Publication Date Title
EP3286647A1 (fr) Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique
Zhou et al. Aquatope: Qos-and-uncertainty-aware resource management for multi-stage serverless workflows
Um et al. Fastflow: Accelerating deep learning model training with smart offloading of input data pipeline
US10908884B2 (en) Methods and apparatus for runtime multi-scheduling of software executing on a heterogeneous system
EP2257876B1 (fr) Methode de prechargement dans une hierarchie de memoires des configurations d'un systeme heterogene reconfigurable de traitement de l'information
US20230229514A1 (en) Intelligent orchestration of classic-quantum computational graphs
Wu et al. Irina: Accelerating dnn inference with efficient online scheduling
Tarsa et al. Post-silicon cpu adaptation made practical using machine learning
EP3502895A1 (fr) Commande de la consommation énergétique d'une grappe de serveurs
Pandey et al. Funcmem: reducing cold start latency in serverless computing through memory prediction and adaptive task execution
Ahmed et al. RALB‐HC: A resource‐aware load balancer for heterogeneous cluster
Ogden et al. Layercake: Efficient inference serving with cloud and mobile resources
CN112559053B (zh) 可重构处理器数据同步处理方法及装置
Agarwal et al. On-demand cold start frequency reduction with off-policy reinforcement learning in serverless computing
Lozano et al. Learning-based phase-aware multi-core CPU workload forecasting
US20230350485A1 (en) Compiler directed fine grained power management
Saravana Kumar et al. Cold start prediction and provisioning optimization in serverless computing using deep learning
Yu et al. Nitro: Boosting Distributed Reinforcement Learning with Serverless Computing
FR3056786B1 (fr) Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
EP2252933B1 (fr) Architecture de traitement informatique accelere
TW202530983A (zh) 分散式應用之動態適應任務執行並行性
Gao et al. Ymir: A scheduler for foundation model fine-tuning workloads in datacenters
Hu et al. Patchwork: A Unified Framework for RAG Serving
Yuhas et al. Toward state-aware scheduling of machine-learning workloads
Thethi et al. Power optimization of a single-core processor using LSTM based encoder–decoder model for online DVFS

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171010

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190618

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20210106