EP2069937A2 - Verfahren zum rechnergestützten optimieren des ressourcenverbrauchs eines programms - Google Patents

Verfahren zum rechnergestützten optimieren des ressourcenverbrauchs eines programms

Info

Publication number
EP2069937A2
EP2069937A2 EP07820575A EP07820575A EP2069937A2 EP 2069937 A2 EP2069937 A2 EP 2069937A2 EP 07820575 A EP07820575 A EP 07820575A EP 07820575 A EP07820575 A EP 07820575A EP 2069937 A2 EP2069937 A2 EP 2069937A2
Authority
EP
European Patent Office
Prior art keywords
program
benchmark
mib
resource consumption
computer system
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.)
Ceased
Application number
EP07820575A
Other languages
English (en)
French (fr)
Inventor
Michael PÖNITSCH
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.)
Siemens AG
Original Assignee
Siemens AG
Siemens Corp
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 Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP2069937A2 publication Critical patent/EP2069937A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3428—Benchmarking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Definitions

  • the invention relates to a method for computer-aided optimizing the resource consumption of a program that comprises least about ⁇ a separately executable program part, in particular distributed in the flow of the program on a, computer system.
  • use cases of the entire distributed computer system are checked as part of a so-called integration or system test.
  • profiler run times response times of individual hardware and software components, resource consumption of computing units, memory, input / output allocation, etc. are measured. This is done once for the entire system and once for individual hardware and / or software components.
  • Profilers are program tools that analyze the runtime behavior of a program. By means of the profiler, it is possible to analyze and compare uncover ongoing programs problem areas of the program or of individual program components ⁇ and fix it.
  • the chiefs ⁇ te use of a profiler is the counting and measuring of calls and runs the program parts of the program.
  • Another aspect is the tracking of memory usage by a program. By means of a profiler, for example, the consumption of the available working memory can be optimized. If necessary, errors can be found in the program which no longer release unused memory areas.
  • instrumentation There are different types of instrumentation: manual instrumentation by extending the source code with commands that calculate the runtime; compiler options for extended programs, thereby providing profiler marks; subsequent modification of compiled programs by inserting marks; Runtime instrumentation, which leaves the stored program untouched and adds the profiler marks to a memory before executing.
  • An inventive method for computer-aided optimize the use of resources of a program at ⁇ least one separately executable program part, during execution of the program on a particular distributed computer system, comprising the steps of: initial detection of the resource consumption during execution of the program;
  • resource ⁇ consumption of individual executable program components may add through the inlet and sequential varying the benchmark program ge ⁇ aims be varied.
  • the respective effects on the resource consumption of the subprogram and finally of the (total) program are determined.
  • the changes This is not limited to the addition of analysis code that does not affect the resource consumption of the program, such as instrumental profiling. Rather, code is added in such a way that a significant change in the consumption of resources can be detected, so that effects on other parts of the program or soft or hard ware components ⁇ occur.
  • This procedure allows a single system test individual components to determine the performance of the ver ⁇ shared computer system as a whole and its inputs. It also allows statements about the degree of dependence of resource consumption or the performance of individual program parts. This makes it possible to supply program parts with a strong dependence targeted optimization.
  • one or more of the following parameters are measured as a measure of resource consumption: the total run time of the program; a memory load of the computer system; an assignment of inputs and / or outputs;
  • At least one program part of a run-time change in at least effected by the benchmark program in the program of the one part, in particular an exten ⁇ tion.
  • a waiting loop which extends the duration of the at least one program part in a defined manner, can be inserted into the program code of the program part.
  • At least one program part of a workload of the at least changed ⁇ changed a computing unit of the distributed computing system, in particular increased by the benchmark program.
  • at least one input and / or one output of the distributed computer system are occupied by the benchmark program in the at least one program part.
  • the benchmark program in the at least one part of the program changed through a said at least one program part memory induced ⁇ consumption of the distributed computer system, in particular increased.
  • the addition of the program code of the at least one program ⁇ part to at least one benchmark program is carried out either at the machine code level or at the source code level.
  • the supplement of the program code the at least one program part to at least one Bench mark ⁇ program in which part of the program with the greatest period begins. It is advantageous if the addition of the Programmco ⁇ of the at least one program part to at least one benchmark program is performed sequentially. This makes it possible to obtain in a relatively short time an overview of which program parts have a strong dependence on the performance of the (overall) program in order to optimize it in a targeted manner.
  • a filing can be performed heat according to another embodiment.
  • the supplementing of the at least one benchmark program in the at least one program part is formed by providing an aspect.
  • the determination of the resource consumption by the READY ⁇ development of an aspect is advantageously carried out with computer assistance.
  • FIG. 1 shows a schematic program sequence of an exemplary application case in which several program parts of a program are run through in different components of a distributed computer system in still unchanged form
  • FIG. 1 A schematic program flow of the use case shown in Fig. 1, in which the programs are mabitese Fig. 2 by additional program code vari ⁇ ated.
  • a fire alarm system is shown as an application.
  • This includes software components A, B, C, D, which are stored, for example, by different computers and / or devices (eg sensors and / or display elements, etc.) of a distributed computer system for the respective execution.
  • the software component A may be, for example, a fire detector.
  • the software component B is assigned to a fault computer (so-called "Incident Server"), which receives a fault message from the software component A.
  • the Softwarekomponen ⁇ te C represents for example a control and evaluation unit which analyzes supplied thereto fault indications.
  • the software component D represented in this application, such as a display unit on which messages can be ⁇ be displayed quo an accident.
  • the software components B and C can for example be provided on ei ⁇ nem single computer.
  • program parts M1,..., M7 on the different software components A, B, C, D of the distributed computer system in a predetermined by the program code order from ⁇ out.
  • the durations for the execution of a respective program part Ml,..., M7 are indicated in the figures by ti,..., T 7 .
  • the execution of the entire program from start to finish is t tot •
  • the sequence is designed as an example as follows.
  • the software component A a message is delivered to the Nl Soft ⁇ ware component B.
  • the software component B then executes the program part Ml, for which the time ti is required.
  • Result of the process of the program part Ml is a Mel ⁇ dung N2 to the software component C of the distributed computer system. This takes in the program part M2, for example, an evaluation.
  • the time duration for the execution of the program part M2 is t 2 .
  • As a result of the execution of the Pro ⁇ gram partly M2 Messages N3, N4, transmitted to the software component ⁇ B N5 which another example of the program parts M3, M4 and M5 performs ⁇ in the embodiment of ⁇ .
  • the time t 3 , t 4 and t 5 is required.
  • the execution of the program parts M3, M4, M5 also be carried out in parallel by the Softwarekompo ⁇ B component.
  • ⁇ N6 and N7 sent to the software component D transmitted.
  • the time t ⁇ , for carrying out the program section M7 t is the time 7 required.
  • M6 can be done playing, on the display a notice Ü about the occurrence of a fire, etc. at ⁇ .
  • the time t ges ⁇ Need Beer Untitled.
  • the determination of the respective durations of the program parts Ml, ..., M7 and the total runtime t ges can be carried out, for example, by means of instrumenting profiling.
  • the program parts M1,..., M7 may be methods, i. Functions or subcalls that act on objects.
  • the program parts are at least partially supplemented by at least one benchmark program. This is shown in FIG. 2.
  • each program part is supplemented by exactly one benchmark program.
  • the program part Ml ' comprises a section MIa, which corresponds to M1 of FIG. 1, and a section MIb, which represents the benchmark program.
  • the program part Ml ' has a time of ti' at the expiration. The same applies to the other program parts M2 ', ..., M7'.
  • the benchmark programs MIb, ..., M7b the resource consumption of individual components or program parts can be changed by a defined value, in particular ver be ⁇ enlarges.
  • the benchmark programs can be formed by holding loops which increase the duration of the execution of a program part in a defined manner.
  • the change of the program code of a program part does not have to take place simultaneously for all program parts. Rather, a change of respective program parts can be carried out sequentially, it being expedient to begin first with such program parts which have the longest execution duration.
  • the source code of the program or program parts vol ⁇ lstieri is available, the introduction of the "artificial resource consumer" on the source code level can be done.
  • the approach of aspect-oriented programming (AOP) is particularly suitable for this.
  • Factor analysis can hereby be as a separate “aspect” decor with dark ⁇ tet, where the "where" as so-called. "Pointcut” and the "what” and “how much” as so-called. "Advice” are easy to formulate.
  • the performance of a system can not only be determined in its entirety and with regard to the individual components in a single system test, but statements about the degree of dependence of the overall performance on the individual components are possible. Components with a strong dependency can then be targeted for optimization, so-called code refactoring.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Multi Processors (AREA)

Abstract

Die Erfindung beschreibt ein Verfahren zum rechnergestützten Optimieren des Ressourcenverbrauchs eines Programms, das zumindest einen separat ausführbaren Programmteil (M1,.., M7) umfasst, beim Ablauf des Programms auf einem, insbesondere verteilten, Rechnersystem. Das erfindungsgemäße Verfahren weist folgende Schritte auf: initiales Feststellen des Ressourcenverbrauchs beim Ablauf des Programms; Ergänzen des Programmcodes des zumindest einen separat ausführbaren Programmteils (M1,.., M7) um zumindest ein Benchmarkprogramm (M1b,.., M7b) derart, dass eine Veränderung des Ressourcenverbrauchs des Programmteils daraus resultiert; Ermitteln des Ressourcenverbrauchs des Programms; sowie wiederholtes Variieren des zumindest einen Benchmarkprogramms (M1b,.., M7b) in dem zumindest einen separat ausführbaren Programmteil (M1,.., M7) und Ermitteln des Ressourcenverbrauchs des Programms bis ein minimaler Ressourcenverbrauch des Programms vorliegt.

Description

Beschreibung
Verfahren zum rechnergestützten Optimieren des Ressourcenverbrauchs eines Programms
Die Erfindung betrifft ein Verfahren zum rechnergestützten Optimieren des Ressourcenverbrauchs eines Programms, das zu¬ mindest einen separat ausführbaren Programmteil umfasst, beim Ablauf des Programms auf einem, insbesondere verteilten, Rechnersystem.
Bei verteilten Rechnersystemen mit einer Vielzahl von Hardware- und Softwarekomponenten besteht oft während der Ent- wicklungs- und Inbetriebnahmephase das Problem, dass dieses keine ausreichende Performance bietet. Die Ursache hierfür ist darin zu sehen, dass das Zusammenspiel der Hardware- und Softwarekomponenten nicht optimal ist. Bei der Analyse zeigt sich häufig, dass einzelne Komponenten für sich betrachtet eine zufrieden stellende Performance aufweisen. Es ist jedoch in der Regel nicht absehbar, welche Auswirkungen eine einzel¬ ne Softwarekomponente auf andere Hardware- und/oder Software¬ komponenten hat. Insbesondere kann nicht erkannt werden, wel¬ che Auswirkung eine einzelne Softwarekomponente auf die Per¬ formance des gesamten verteilten Rechnersystems hat.
Zur Optimierung des Ressourcenverbrauchs werden im Rahmen eines sog. Integrations- bzw. Systemtests Anwendungsfälle (sog. Usecases) des gesamten verteilten Rechnersystems überprüft. Dabei werden in der Regel unter Verwendung sog. Profiler Ge- samtlaufzeiten, Antwortzeiten einzelner Hard- und Softwarekomponenten, der Ressourcenverbrauch von Recheneinheiten, Speicher, Ein-/Ausgabebelegung, usw. gemessen. Dies erfolgt einmal für das Gesamtsystem und einmal für einzelne Hard- und/oder Softwarekomponenten.
Als Profiler werden Programmwerkzeuge bezeichnet, die das Laufzeitverhalten eines Programms analysieren. Anhand des Profilers ist es möglich, durch Analyse und Vergleich von laufenden Programmen Problembereiche des Programms oder ein¬ zelner Programmteile aufzudecken und zu beheben. Die häufigs¬ te Anwendung eines Profilers ist das Zählen und Messen von Aufrufen und Durchläufen der Programmteile des Programms. Ein weiterer Aspekt ist die Verfolgung von Speichernutzung durch ein Programm. Mittels eines Profilers kann z.B. der Ge- und Verbrauch des zur Verfügung stehenden Arbeitsspeichers optimiert werden. Gegebenenfalls können Fehler in dem Programm aufgefunden werden, welche ungenutzte Speicherbereiche nicht mehr freigeben. Darüber hinaus können Profiler parallel ablaufende Programmteile zur leichteren Analyse optisch aufbe¬ reiten .
Mit einer Instrumentation werden bestimmte oder alle Pro- grammteile, z.B. während der Laufzeit, mit Analysecode erwei¬ tert. Dies bedeutet, es werden in den oder die Programmab¬ schnitte Unterbrechungs-Marken (sog. Interrupts) oder Pro¬ grammcode eingefügt, die dem Profiler während des Programm¬ laufs signalisieren, dass der Abschnitt gerade abgearbeitet wird. Die Zeit zwischen den Aufrufen der Analysepunkte (sowie das Speicherverhalten als Differenz zu einem vorherigen Durchlauf) können als Laufzeitwerte in das Ergebnis der Ana¬ lyse einfließen. Die Instrumentation verändert das Programm derart, dass Analysedaten berechnet werden können.
Dabei gibt es verschiedene Typen der Instrumentation: eine manuelle Instrumentation durch Erweiterung des Quelltextes durch Befehle, die die Laufzeit berechnen; durch Compiler- Optionen erweiterte Programme, die dadurch Profiler-Marken erhalten; nachträgliche Veränderung von kompilierten Programmen durch Einfügen von Marken; Laufzeit-Instrumentation, bei der das gespeicherte Programm unangetastet bleibt, und die Profiler-Marken vor dem Ausführen in einem Arbeitsspeicher hinzugefügt werden.
Bei der Optimierung des Ressourcenverbrauchs ergibt sich häu¬ fig das Problem, dass durch eine Verbesserung des Programmco¬ des eines Programmteils dieser Programmteil zwar tatsächlich weniger Ressourcen beansprucht, der Ressourcenverbrauch des Gesamtprogramms sich dadurch jedoch nicht oder nur unwesent¬ lich verbessert.
Es ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren anzugeben, welches ein Optimieren des Ressourcenverbrauchs eines gesamten Programms, das auf einem, insbesondere verteilten, Rechnersystem abläuft, ermöglicht.
Diese Aufgabe wird durch die Merkmale des Patentanspruches 1 gelöst. Vorteilhafte Ausführungsformen sind in den abhängigen Patentansprüchen wiedergegeben.
Ein erfindungsgemäßes Verfahren zum rechnergestützten Opti- mieren des Ressourcenverbrauchs eines Programms, das zumin¬ dest einen separat ausführbaren Programmteil umfasst, beim Ablauf des Programms auf einem, insbesondere verteilten, Rechnersystem, umfasst die folgenden Schritte: initiales Feststellen des Ressourcenverbrauchs beim Ablauf des Programms;
Ergänzen des Programmcodes des zumindest einen separat ausführbaren Programmteils um zumindest ein Benchmarkprogramm derart, dass eine Veränderung des Ressourcenverbrauchs des Programmteils daraus resultiert; - Ermitteln des Ressourcenverbrauchs des Programms; - wiederholtes Variieren des zumindest einen Bench¬ markprogramms in dem zumindest einen separat ausführbaren Programmteil und Ermitteln des Ressourcenverbrauchs des Programms bis ein minimaler Ressourcenverbrauch des Pro- gramms vorliegt.
Bei dem erfindungsgemäßen Verfahren kann während eines Systemtests des verteilten Rechnersystems der Ressourcen¬ verbrauch einzelner ausführbarer Programmteile durch das Ein- fügen und sequentielle Variieren des Benchmarkprogramms ge¬ zielt variiert werden. Dabei werden die jeweiligen Auswirkungen auf den Ressourcenverbrauch zunächst des Teilprogramms und schließlich des (Gesamt-) Programms ermittelt. Die Verän- derung beschränkt sich dabei nicht, wie z.B. beim instrumentierenden Profiling, auf das Hinzufügen von Analysecode, der den Ressourcenverbrauch des Programms nicht beeinflusst. Vielmehr wird Code derart hinzugefügt, dass eine signifikante Änderung des Ressourcenverbrauchs feststellbar ist, so dass Auswirkungen auf andere Programmteile bzw. Hard- oder Soft¬ warekomponenten auftreten. Dieses Vorgehen erlaubt in einem einzigen Systemtest die Bestimmung der Performance des ver¬ teilten Rechnersystems in seiner Gesamtheit und seinen Ein- zelkomponenten . Es lässt ferner Aussagen über den Grad der Abhängigkeit des Ressourcenverbrauchs bzw. der Performance von einzelnen Programmteilen zu. Hierdurch wird es ermöglicht, Programmteile mit einer starken Abhängigkeit gezielt einer Optimierung zuzuführen.
In einer Ausführungsform werden als Maß für den Ressourcenverbrauch einer oder mehrere der folgenden Parameter gemessen : die Gesamtlaufzeit des Programms; - eine Speicherauslastung des Rechnersystems; eine Belegung von Ein- und/oder Ausgängen;
- eine Auslastung zumindest einer Recheneinheit (CPU) des Rechnersystems .
In einer Ausführungsform wird durch das Benchmarkprogramm in dem zumindest einen Programmteil eine Laufzeitänderung des zumindest einen Programmteils, insbesondere eine Verlänge¬ rung, bewirkt. Gemäß dieser Variante kann eine Warteschleife, welche die Dauer des zumindest einen Programmteils definiert verlängert, in den Programmcode des Programmteils eingesetzt werden .
In einer anderen Variante wird durch das Benchmarkprogramm in dem zumindest einen Programmteil eine Auslastung der zumin- dest einen Recheneinheit des verteilten Rechnersystems verän¬ dert, insbesondere erhöht. In einer weiteren Ausführungsform werden durch das Benchmarkprogramm in dem zumindest einen Programmteil wenigstens ein Eingang und/oder ein Ausgang des verteilten Rechnersystems belegt.
In einer weiteren Ausführungsform wird durch das Benchmarkprogramm in dem zumindest einen Programmteil ein durch das zumindest eine Programmteil hervorgerufener Speicher¬ verbrauch des verteilten Rechnersystems verändert, insbeson- dere erhöht.
Je nach Ausgestaltung des Benchmarkprogramms kann damit eine Beeinflussung des Ressourcenverbrauchs des betreffenden Pro¬ grammteils herbeigeführt werden.
Die Ergänzung des Programmcodes des zumindest einen Programm¬ teils um zumindest ein Benchmarkprogramm erfolgt entweder auf Maschinencode-Ebene oder auf Sourcecode-Ebene .
Zweckmäßigerweise beginnt die Ergänzung des Programmcodes des zumindest einen Programmteils um zumindest ein Bench¬ markprogramm bei dem Programmteil mit der größten Laufzeit. Dabei ist es vorteilhaft, wenn die Ergänzung des Programmco¬ des des zumindest einen Programmteils um zumindest ein Bench- markprogramm sequentiell erfolgt. Hierdurch ist es möglich, sich in verhältnismäßig kurzer Zeit einen Überblick darüber zu verschaffen, welche Programmteile eine starke Abhängigkeit bezüglich der Performance des (Gesamt-) Programms aufweisen, um diese gezielt zu optimieren. Zur Ermittlung der Laufzeit zumindest eines Teils der Programmteile und/oder zur Ermitt¬ lung der Speichernutzung und/oder zur Ermittlung einer Neben- läufigkeit kann gemäß einer weiteren Ausführungsform ein Pro- filing durchgeführt werden.
Gemäß einer weiteren Ausführungsform wird das Ergänzen des zumindest einen Benchmarkprogramms in dem zumindest einen Programmteil durch das Bereitstellen eines Aspekts gebildet. Die Bestimmung des Ressourcenverbrauchs durch die Bereitstel¬ lung eines Aspekts erfolgt zweckmäßigerweise rechnergestützt.
Die Erfindung wird nachfolgend weiter anhand eines Ausfüh- rungsbeispiels in der Zeichnung erläutert. Es zeigen:
Fig. 1 einen schematischen Programmablauf eines beispiel¬ haften Anwendungsfalls, in dem mehrere Programmtei¬ le eines Programms in unterschiedlichen Komponenten eines verteilten Rechnersystems in noch unveränderter Form durchlaufen werden, und
Fig. 2 einen schematischen Programmablauf des in Fig. 1 dargestellten Anwendungsfalls, in dem die Program- mabschnitte durch zusätzlichen Programmcode vari¬ iert sind.
In den Fig. 1 und 2 ist als Anwendungsfall ein Feuermelder- System dargestellt. Dieses umfasst Softwarekomponenten A, B, C, D, welche beispielsweise durch unterschiedliche Rechner und/oder Geräte (z.B. Sensoren und/oder Anzeigeelemente, usw.) eines z.B. verteilten Rechnersystems zur jeweiligen Ausführung gespeichert sind. Bei der Softwarekomponente A kann es sich beispielsweise um einen Brandmelder handeln. Die Softwarekomponente B ist einem Störfall-Rechner (sog. "Inci- dent-Server" ) zugeordnet, welcher eine Störfallmeldung von der Softwarekomponente A entgegennimmt. Die Softwarekomponen¬ te C stellt beispielsweise eine Kontroll- und Auswerteeinheit dar, welche ihr zugeführte Störfallmeldungen analysiert. Die Softwarekomponente D repräsentiert in diesem Anwendungsfall beispielsweise eine Anzeigeeinheit, auf welcher Meldungen be¬ züglich eines Störfalls zur Anzeige gebracht werden können. Die Softwarekomponenten B und C können beispielsweise auf ei¬ nem einzigen Rechner vorgesehen sein.
Beim Ablauf eines Programms auf dem verteilten Rechnersystem werden Programmteile Ml, ..., M7 auf den unterschiedlichen Softwarekomponenten A, B, C, D des verteilten Rechnersystems in einer durch den Programmcode vorgegebenen Reihenfolge aus¬ geführt. Die Zeitdauern für die Durchführung eines jeweiligen Programmteils Ml, ..., M7 sind in den Figuren durch ti, ..., t7 gekennzeichnet. Die Ausführung des gesamten Programms von ei- nem Start bis zu einem Ende beträgt tges •
Der Ablauf gestaltet sich dabei beispielhaft wie folgt. Von der Softwarekomponente A wird eine Meldung Nl an die Soft¬ warekomponente B abgegeben. Die Softwarekomponente B führt daraufhin den Programmteil Ml aus, wofür die Zeit ti benötigt wird. Ergebnis des Ablaufs des Programmteils Ml ist eine Mel¬ dung N2 an die Softwarekomponente C des verteilten Rechnersystems. Diese nimmt im Programmteil M2 beispielsweise eine Auswertung vor. Die Zeitdauer für den Ablauf des Programm- teils M2 beträgt t2. Als Ergebnis der Abarbeitung des Pro¬ grammteils M2 werden Nachrichten N3, N4, N5 an die Software¬ komponente B übertragen, welche im Ausführungsbeispiel nach¬ einander beispielhaft die Programmteile M3, M4 und M5 aus¬ führt. Hierfür wird die Zeit t3, t4 und t5 benötigt. Entgegen der zeichnerischen Darstellung könnte die Ausführung der Programmteile M3, M4, M5 auch parallel durch die Softwarekompo¬ nente B erfolgen. Am Ende des Programmteils M5 werden Nach¬ richten N6 und N7 an die Softwarekomponente D übermittelt. Diese führt zunächst einen Programmteil M6 und anschließend einen Programmteil M7 aus. Zur Durchführung des Programmteils M6 wird die Zeit tβ, zur Durchführung des Programmteils M7 die Zeit t7 benötigt. In den Programmteilen M6, M7 kann bei¬ spielsweise auf der Anzeige eine entsprechende Mitteilung ü- ber das Auftreten eines Brandherdes, usw. erfolgen. Zur Durchführung des gesamten Programms wird die Zeit tges benö¬ tigt .
Das Feststellen der jeweiligen Zeitdauern der Programmteile Ml, ..., M7 sowie der Gesamtlaufzeit tges kann beispielsweise mittels instrumentierenden Profilings durchgeführt werden.
Hierbei kann in den Maschinencode oder Bytecode des zur Aus¬ führung stehenden Programmteils zu Beginn und am Ende jeden Programmteils eine Timer-Start- bzw. Timer-Stopp-Sequenz ein- gebracht werden. Hierdurch ist die Dauer des Aufrufs jedes Programmteils messbar.
Bei den Programmteilen Ml, ..., M7 kann es sich beispielsweise, sofern das Programm in einem objektorientierten Programmcode vorliegt, um Methoden, d.h. Funktionen oder Unteraufrufe, der Objekte handeln.
Zur Optimierung des Ressourcenverbrauchs, insbesondere der Gesamtlaufzeit tges, des Speicherverbrauchs, der Belegung von Ein- und Ausgängen jeweiliger Rechner des verteilten Rechnersystems, usw., erfolgt eine gezielte Variierung der einzelnen Programmteile Ml, ..., M7, wobei die Auswirkungen der Variatio¬ nen auf die Gesamtlaufzeit tges gemessen werden. Hierzu werden die Programmteile zumindest teilweise um jeweils zumindest ein Benchmarkprogramm ergänzt. Dies ist in Fig. 2 dargestellt. In dem Ausführungsbeispiel ist lediglich exemplarisch jeder Programmteil um genau ein Benchmarkprogramm ergänzt.
Das Programmteil Ml' umfasst einen Abschnitt MIa, welcher Ml aus Fig. 1 entspricht, sowie einen Abschnitt MIb, welcher das Benchmarkprogramm repräsentiert. Das Programmteil Ml' weist beim Ablauf eine Zeit von ti' auf. Entsprechendes gilt auch für die anderen Programmteile M2 ' , ..., M7 ' .
Durch das Einbringen der Benchmarkprogramme MIb, ..., M7b kann der Ressourcenverbrauch einzelner Komponenten bzw. Programmteile um einen definierten Wert verändert, insbesondere ver¬ größert werden. Im einfachsten Fall können die Benchmark- programme durch Warteschleifen gebildet sein, welche die Dau¬ er der Ausführung eines Programmteils definiert vergrößern.
Die Veränderung des Programmcodes eines Programmteils braucht nicht bei sämtlichen Programmteilen gleichzeitig erfolgen. Vielmehr kann eine Veränderung jeweiliger Programmteile sequentiell erfolgen, wobei zweckmäßigerweise zunächst bei sol¬ chen Programmteilen begonnen wird, welche die längste Ausführungsdauer aufweisen. Wenn der Sourcecode des Programms bzw. der Programmteile vol¬ lständig zugänglich ist, kann das Einbringen der "künstlichen Ressourcenverbraucher" auch auf Sourcecode-Ebene erfolgen. Für einen Sourcecode in Java bietet sich hierfür insbesondere der Ansatz der aspektorientierten Programmierung (AOP) an. Die Faktorenanalyse kann hierbei als eigener "Aspekt" gestal¬ tet werden, in dem das "wo" als sog. "Pointcut" und das "was" und "wieviel" als sog. "Advice" leicht zu formulieren sind. "Wo" bedeutet, welcher Programmteil einer Veränderung unterzogen werden soll und "was" bedeutet, welche Ressourcen (Speicher, Laufzeit, Ein-/Ausgänge) einer Veränderung unterworfen werden sollen. Die aspektorientierte Programmierung kann auch dann zur Anwendung gelangen, wenn das Programm nur als Bytecode vorliegt. AspectJ erlaubt das "Verweben" von neuen, eigenen Aspekten mit dem Bytecode der Anwendung, von der lediglich die Schnittstellen bekannt sein müssen. Dies ist dem Fachmann auch unter "Bytecode-Weaving" bekannt.
Entgegen der Erwartung, dass die Verschlechterung des Ressourcenverbrauchs eines oder mehrerer Programmteile auch zu einer Verschlechterung des Ressourcenverbrauchs des Gesamt- Programms führt, hat sich herausgestellt, dass im Ergebnis eine Verbesserung des Ressourcenverbrauchs des Gesamtsystems herbeiführbar ist, indem insbesondere diejenigen Programmtei¬ le ausfindig gemacht werden können, welche die größten Aus¬ wirkungen auf den Ablauf des (Gesamt-) Programms haben. Diese können dann beispielsweise einer gezielten Optimierung unterzogen werden.
Durch die Erfindung kann in einem einzigen Systemtest die Performance eines Systems nicht nur in seiner Gesamtheit und bezüglich der einzelnen Komponenten bestimmt werden, sondern es sind Aussagen über den Grad der Abhängigkeit der Gesamt- Performance von den Einzelkomponenten möglich. Komponenten mit einer starken Abhängigkeit können dann gezielt einer Optimierung, sog. Code-Refacturing, zugeführt werden.

Claims

Patentansprüche
1. Verfahren zum rechnergestützten Optimieren des Ressourcenverbrauchs eines Programms, das zumindest einen separat aus- führbaren Programmteil (Ml,.., M7) umfasst, beim Ablauf des Programms auf einem, insbesondere verteilten, Rechnersystem, mit den Schritten:
- initiales Feststellen des Ressourcenverbrauchs beim Ab¬ lauf des Programms; - Ergänzen des Programmcodes des zumindest einen separat ausführbaren Programmteils (Ml,.., M7) um zumindest ein Benchmarkprogramm (MIb,.., M7b) derart, dass eine Verän¬ derung des Ressourcenverbrauchs des Programmteils (Ml,.., M7) daraus resultiert; - Ermitteln des Ressourcenverbrauchs des Programms;
- wiederholtes Variieren des zumindest einen Bench¬ markprogramms (MIb,.., M7b) in dem zumindest einen sepa¬ rat ausführbaren Programmteil (Ml, .., M7) und Ermitteln des Ressourcenverbrauchs des Programms bis ein minimaler Ressourcenverbrauch des Programms vorliegt.
2. Verfahren nach Anspruch 1, bei dem als Maß für den Ressourcenverbrauch einer oder mehrere der folgenden Parameter gemessen wird: - die Gesamtlaufzeit (tges) des Programms; eine Speicherauslastung des Rechnersystems; eine Belegung von Ein- und/oder Ausgängen;
- eine Auslastung zumindest einer Recheneinheit (CPU) des Rechnersystems .
3. Verfahren nach Anspruch 1 oder 2, bei dem durch das Benchmarkprogramm (MIb,.., M7b) eine Laufzeit (ti,.., t7) des zu¬ mindest einen Programmteils (Ml,.., M7) verändert, insbeson¬ dere verlängert, wird.
4. Verfahren nach einem der vorherigen Ansprüche, bei dem durch das Benchmarkprogramm (MIb,.., M7b) in dem zumindest ei- nen Programmteil (Ml,.., M7) eine Auslastung der zumindest einen Recheneinheit verändert, insbesondere erhöht, wird.
5. Verfahren nach einem der vorherigen Ansprüche, bei dem durch das Benchmarkprogramm (MIb, .. , M7b) in dem zumindest einen Programmteil (Ml, .., M7) wenigstens ein Eingang und/oder ein Ausgang des verteilten Rechnersystems belegt wird.
6. Verfahren nach einem der vorherigen Ansprüche, bei dem durch das Benchmarkprogramm (MIb, .. , M7b) in dem zumindest einen Programmteil (Ml, .., M7) ein durch das zumindest eine Programmteil (Ml,.., M7) hervorgerufener Speicherverbrauch des verteilten Rechnersystems verändert, insbesondere erhöht, wird.
7. Verfahren nach einem der vorherigen Ansprüche, bei dem die Ergänzung des Programmcodes des zumindest einen Programmteils
(Ml,.., M7) um zumindest ein Benchmarkprogramm (MIb,.., M7b) auf Maschinencodeebene oder auf Sourcecode-Ebene erfolgt.
8. Verfahren nach einem der vorherigen Ansprüche, bei dem die Ergänzung des Programmcodes des zumindest einen Programmteils
(Ml, .., M7 ) um zumindest ein Benchmarkprogramm (MIb, .., M7b) bei dem Programmteil mit der größten Laufzeit beginnt.
9. Verfahren nach Anspruch 8, bei dem die Ergänzung des Programmcodes des zumindest einen Programmteils (Ml, .., M7) um zumindest ein Benchmarkprogramm (MIb, .. , M7b) sequentiell er- folgt.
10. Verfahren nach einem der vorherigen Ansprüche, bei dem zur Ermittlung der Laufzeit (ti,.., t7; ti',.., t7') zumindest eines Teils der Programmteile (Ml, .., M7) und/oder zur Er- mittlung einer Speichernutzung und/oder zur Ermittlung einer Nebenläufigkeit ein Profiling durchgeführt wird.
11. Verfahren nach einem der vorherigen Ansprüche, bei dem das Ergänzen des zumindest einen Benchmarkprogramms (MIb, .. , M7b) in dem zumindest einen Programmteil (Ml,.., M7) durch das Bereitstellen eines Aspekts gebildet wird.
12. Verfahren nach einem der vorherigen Ansprüche, bei dem die Bestimmung des Ressourcenverbrauchs durch die Bereitstel¬ lung eines Aspekts rechnergestützt erfolgt.
EP07820575A 2006-09-29 2007-09-26 Verfahren zum rechnergestützten optimieren des ressourcenverbrauchs eines programms Ceased EP2069937A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006046201A DE102006046201A1 (de) 2006-09-29 2006-09-29 Verfahren zum rechnergestützten Optimieren des Ressourcenverbrauchs eines Programms
PCT/EP2007/060180 WO2008040662A2 (de) 2006-09-29 2007-09-26 Verfahren zum rechnergestützten optimieren des ressourcenverbrauchs eines programms

Publications (1)

Publication Number Publication Date
EP2069937A2 true EP2069937A2 (de) 2009-06-17

Family

ID=39149422

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07820575A Ceased EP2069937A2 (de) 2006-09-29 2007-09-26 Verfahren zum rechnergestützten optimieren des ressourcenverbrauchs eines programms

Country Status (4)

Country Link
US (1) US20090276762A1 (de)
EP (1) EP2069937A2 (de)
DE (1) DE102006046201A1 (de)
WO (1) WO2008040662A2 (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007029133A1 (de) * 2007-03-20 2008-09-25 Ludwig-Maximilians-Universität Verfahren zum rechnergestützten Ermitteln der Abhängigkeiten einer Vielzahl von Modulen eines technischen Systems, insbesondere eines Softwaresystems
WO2008113681A1 (de) * 2007-03-20 2008-09-25 Siemens Aktiengesellschaft Verfahren zum rechnergestützten bestimmen des optimierungspotentials eines softwaresystems
US8837721B2 (en) * 2007-03-22 2014-09-16 Microsoft Corporation Optical DNA based on non-deterministic errors
US8788848B2 (en) 2007-03-22 2014-07-22 Microsoft Corporation Optical DNA
US20100094861A1 (en) * 2008-10-01 2010-04-15 Henrique Andrade System and method for application session tracking
US9135948B2 (en) * 2009-07-03 2015-09-15 Microsoft Technology Licensing, Llc Optical medium with added descriptor to reduce counterfeiting
US8990779B2 (en) * 2009-08-11 2015-03-24 Sap Se Response time measurement system and method
US8527817B2 (en) 2010-11-19 2013-09-03 International Business Machines Corporation Detecting system component failures in a computing system
US9195810B2 (en) * 2010-12-28 2015-11-24 Microsoft Technology Licensing, Llc Identifying factorable code
US8881125B2 (en) * 2012-06-11 2014-11-04 International Business Machines Corporation Indirect software performance analysis
US9274920B2 (en) * 2012-09-28 2016-03-01 Dialog Semiconductor B.V. Code profiling in embedded ULE applications
DE102013007676A1 (de) 2013-05-03 2014-11-06 All4Ip Management Gmbh Dynamische App-Rechenlast-Verteilung und nahtlose Netzwerkausfallverarbeitung zwischen Smartphone, Fahrzeug und Cloud
WO2016018249A1 (en) * 2014-07-29 2016-02-04 Hewlett-Packard Development Company, L.P. Processor monitoring of thermal degradation
US11709750B2 (en) * 2020-05-12 2023-07-25 International Business Machines Corporation Dynamically mapping software infrastructure utilization

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6381558B1 (en) * 1998-12-18 2002-04-30 International Business Machines Corporation Alternative profiling methodology and tool for analyzing competitive benchmarks

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6126329A (en) * 1993-06-08 2000-10-03 Rational Software Coporation Method and apparatus for accurate profiling of computer programs
US5794011A (en) * 1996-07-19 1998-08-11 Unisys Corporation Method of regulating the performance of an application program in a digital computer
US6332212B1 (en) * 1997-10-02 2001-12-18 Ltx Corporation Capturing and displaying computer program execution timing
US6070009A (en) * 1997-11-26 2000-05-30 Digital Equipment Corporation Method for estimating execution rates of program execution paths
US6549930B1 (en) * 1997-11-26 2003-04-15 Compaq Computer Corporation Method for scheduling threads in a multithreaded processor
US6584611B2 (en) * 1999-02-17 2003-06-24 Elbrus International Limited Critical path optimization—unload hard extended scalar block
US6594824B1 (en) * 1999-02-17 2003-07-15 Elbrus International Limited Profile driven code motion and scheduling
US6374369B1 (en) * 1999-05-21 2002-04-16 Philips Electronics North America Corporation Stochastic performance analysis method and apparatus therefor
US6598012B1 (en) * 1999-10-07 2003-07-22 International Business Machines Corporation Method and system for compensating for output overhead in trace date using trace record information
US6725180B2 (en) * 2001-01-12 2004-04-20 Ingersoll-Rand Company Environmental monitoring system
US8108843B2 (en) * 2002-09-17 2012-01-31 International Business Machines Corporation Hybrid mechanism for more efficient emulation and method therefor
US7496897B1 (en) * 2004-03-17 2009-02-24 Timesys Corporation Multiple code sets for multiple execution contexts
US7770161B2 (en) * 2005-12-28 2010-08-03 International Business Machines Corporation Post-register allocation profile directed instruction scheduling
US7770163B2 (en) * 2006-03-24 2010-08-03 International Business Machines Corporation Method of efficiently performing precise profiling in a multi-threaded dynamic compilation environment
US7823130B2 (en) * 2006-09-22 2010-10-26 Sap Ag Testing machine-readable instructions
US8239830B2 (en) * 2006-11-03 2012-08-07 Accenture Global Services Limited System for portal architecture
US20080141335A1 (en) * 2006-12-08 2008-06-12 Novell, Inc. Provisioning software with policy-appropriate capabilities

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6381558B1 (en) * 1998-12-18 2002-04-30 International Business Machines Corporation Alternative profiling methodology and tool for analyzing competitive benchmarks

Also Published As

Publication number Publication date
DE102006046201A1 (de) 2008-04-17
WO2008040662A2 (de) 2008-04-10
US20090276762A1 (en) 2009-11-05
WO2008040662A3 (de) 2008-05-29

Similar Documents

Publication Publication Date Title
EP2069937A2 (de) Verfahren zum rechnergestützten optimieren des ressourcenverbrauchs eines programms
EP2137615B1 (de) Verfahren zum rechnergestützten ermitteln der abhängigkeiten einer vielzahl von modulen eines technischen systems, insbesondere eines softwaresystems
DE102016100383A1 (de) Verfahren und System zum Testen eines mechatronischen Systems
EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
EP3306295B1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
DE102009027627B3 (de) Simulation von Echtzeit-Software-Komponenten auf Basis der Logischen Ausführungszeit
DE112019002778T5 (de) Simulationsvorrichtung, simulationsverfahren und elektronische steuereinheitsvorrichtung
DE69128908T2 (de) Verfahren zum Durchführen von erlässlichen Befehlen in einem Rechner
DE102011101064A1 (de) Formale methoden nutzende zeitsteuerungsanalyse
EP2363809B1 (de) Verfahren zur Optimierung eines Steuerprogramms für Aktuatoren
DE102011014831A1 (de) Verfahren und vorrichtung zum analysieren vonsoftware mit einem kalibrierten wert
DE10038499A1 (de) Verfahren und System für die verbesserte Entwicklungsprüfung mittels angepasster Ablaufverfolgung
DE102013000857A1 (de) Kompakte Funktionsablaufprotokollierung
EP1502189B1 (de) Verfahren zur ermittlung der prioritätsabhangigen rechenzeitverteilung in einem priorit tsgesteuerten mehrprozess-rechenysystem
DE112021005655B4 (de) Datenvergleichsgerät, Datenvergleichssystem und Datenvergleichsverfahren
DE102006041444B4 (de) Schaltungsanordnung und Verfahren zum Erfassen einer Ausführungszeit eines Befehls in einem Rechnersystem
DE202016008563U1 (de) Konfigurationssystem zum Konfigurieren eines für das Testen eines Steuergeräts eingerichteten Testgeräts
WO2011038863A1 (de) Verfahren und anordnung zum installieren und konfigurieren eines computersystems
DE102018221534A1 (de) System und Verfahren zum Messen der Reaktionszeit von Ereignisketten
EP2592504B1 (de) Verfahren zur Abschätzung eines Ressourcenverbrauchs bei der Erzeugung eines Steuergeräteprogrammcodes
DE102010053701A1 (de) Beziehungsmodellierung für Leistungsanalyse von Mehrkernprozessoren
DE10041111A1 (de) Verfahren zum Überarbeiten eines in einer Programmiersprache verfaßten Computerprogramms
EP4198722A1 (de) Konfiguration einer auf einem computer laufenden sil-simulation eines steuergeräts
DE102010053971A1 (de) Aufteilen eines gezählten Wertes auf einem auf einem Mehrkernprozessor ausgeführten Task
DE102008048862A1 (de) Testmodul und Verfahren zum Testen einer O/R-Abbildungs-Middleware

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20090219

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090827

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20150210