DE102020129195A1 - Vereinheitlichtes programmiermodul für eine funktion-als-ein-dienst-berechnung - Google Patents

Vereinheitlichtes programmiermodul für eine funktion-als-ein-dienst-berechnung Download PDF

Info

Publication number
DE102020129195A1
DE102020129195A1 DE102020129195.7A DE102020129195A DE102020129195A1 DE 102020129195 A1 DE102020129195 A1 DE 102020129195A1 DE 102020129195 A DE102020129195 A DE 102020129195A DE 102020129195 A1 DE102020129195 A1 DE 102020129195A1
Authority
DE
Germany
Prior art keywords
service call
platform
cloud
specific
parameters
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.)
Pending
Application number
DE102020129195.7A
Other languages
English (en)
Inventor
Sara Baghsorkhi
Mohammad R. Haghighat
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.)
Intel Corp
Original Assignee
Intel 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 Intel Corp filed Critical Intel Corp
Publication of DE102020129195A1 publication Critical patent/DE102020129195A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482Procedural
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017Runtime instruction translation, e.g. macros
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083Techniques for rebalancing the load in a distributed system
    • G06F9/5088Techniques for rebalancing the load in a distributed system involving task migration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/541Interprogram communication via adapters, e.g. between incompatible applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/50Indexing scheme relating to G06F9/50
    • G06F2209/501Performance criteria

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

Systeme, Vorrichtungen und Verfahren können Technologie bereitstellen, die einen generischen Cloud-Dienstaufruf in einer Anwendung erkennt, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind. Die Technologie kann auch eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit der ersten Cloud-Plattform auswählen und automatisch einen für die erste Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes erzeugen. Bei einem Beispiel ordnet die Technologie den Cloud-Dienstaufruf auch dem für die erste Plattform spezifischen Dienstaufruf zu. Zusätzlich kann die Technologie den Cloud-Dienstaufruf zu einer zweiten Cloud-Plattform migrieren, ohne den generischen Cloud-Dienstaufruf umzuschreiben.

Description

  • TECHNISCHES GEBIET
  • Ausführungsformen betreffen allgemein Anwendungsprogrammierschnittstellen (APIs). Ausführungsformen betreffen insbesondere ein vereinheitlichtes Programmiermodell für eine Funktion-als-ein-Dienst(FaaS)-Berechnung.
  • HINTERGRUND
  • Wenn eine Anwendung auf einer Cloud-Recheninfrastruktur („Cloud“) installiert wird, werden die Anwendungsprogrammierschnittstellen (APIs) und Protokolle, die innerhalb der Anwendung verwendet werden, typischerweise eng mit einer spezifischen Plattform (beispielsweise von einem spezifischen Cloud-Anbieter betrieben) gekoppelt. Weil die Landschaft der Cloud-Anbieter wächst und heterogener wird, kann diese enge Kopplung Herausforderungen in Bezug auf Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit hervorrufen. Falls beispielsweise eine günstigere Dienstplattform verfügbar wird, nachdem eine Cloud-Anwendung installiert wurde (oder während der Installation), kann der Zusatzaufwand des Migrierens der Cloud-Anwendung zur günstigeren Dienstplattform die Vorteile der neuen Dienstplattform überwiegen. Eine solche Situation kann in einer Funktion-als-ein-Dienst (FaaS)-Architektur sogar noch ausgeprägter werden, wobei ein API-Endpunkt für einen einzigen Zweck auf einer Cloud bereitgestellt wird, um Codeausführungsanforderungen für einen verhältnismäßig kurzen Zeitraum zu empfangen und auszuführen.
  • Figurenliste
  • Die verschiedenen Vorteile der Ausführungsformen werden Fachleuten beim Lesen der folgenden Beschreibung und der anliegenden Ansprüche und mit Bezug auf die folgenden Zeichnungen verständlich werden. Es zeigen:
    • 1 ein Blockdiagramm eines Beispiels einer heterogenen Cloud gemäß einer Ausführungsform,
    • 2 ein Blockdiagramm eines Beispiels des Portierens einer Cloud-Anwendung auf ein oder mehrere Module, die auf einer heterogenen Cloud laufen, gemäß einer Ausführungsform,
    • 3 ein Blockdiagramm eines Beispiels einer portierten Cloud-Anwendung auf einer heterogenen Cloud-Rechenarchitektur gemäß einer Ausführungsform,
    • 4 ein Flussdiagramm eines Beispiels eines Verfahrens zum Portieren einer Anwendung auf eine heterogene Cloud gemäß einer Ausführungsform,
    • 5 ein Flussdiagramm eines Beispiels eines detaillierteren Verfahrens zum Portieren einer Anwendung auf eine heterogene Cloud gemäß einer Ausführungsform,
    • 6A ein Blockdiagramm eines Beispiels einer inkrementellen Migration einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform,
    • 6B ein Blockdiagramm eines Beispiels einer abgeschlossenen Migration einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform,
    • 7 ein Flussdiagramm eines Beispiels eines Verfahrens zum Migrieren einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform,
    • 8 ein Flussdiagramm eines Beispiels eines Verfahrens zum Behandeln von Cloud-Dienstaufrufen gemäß einer Ausführungsform,
    • 9A ein Flussdiagramm eines Beispiels eines Verfahrens zum Übertragen von Zustandsdaten zwischen Cloud-Plattformen gemäß einer Ausführungsform,
    • 9B ein Flussdiagramm eines Beispiels eines detaillierteren Verfahrens zum Behandeln von Cloud-Dienstaufrufen gemäß einer Ausführungsform,
    • 10 ein Blockdiagramm eines Beispiels eines Rechensystems mit erhöhter Leistungsfähigkeit gemäß einer Ausführungsform,
    • 11 eine Darstellung eines Beispiels einer Halbleitervorrichtung gemäß einer Ausführungsform,
    • 12 ein Blockdiagramm eines Beispiels eines Prozessors gemäß einer Ausführungsform und
    • 13 ein Blockdiagramm eines Beispiels eines Multiprozessor-basierten Rechensystems gemäß einer Ausführungsform.
  • BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
  • 1 zeigt eine heterogene Cloud 20, bei der eine Cloud-portierbare Anwendung 22 einen Speicherdienst, einen Natürliche-Sprachverarbeitung(NLP)-Dienst, einen Datenbankdienst, einen Authentifizierungsdienst usw. während des Betriebs verwendet. Gemäß einer Ausführungsform wird ein vereinheitlichtes Programmiermodell 28 (28a - 28d) beispielsweise in der Art von ONEAPI verwendet, um die Anwendung 22 zur Ausführung über die heterogene Cloud 20 zu konfigurieren, die sehr verschiedene Typen von Hardware-Ressourcen (beispielsweise Host-Prozessoren, Graphikprozessoren, feldprogrammierbare Gate-Arrays/FPGAs, Beschleuniger für spezielle Zwecke usw.) aufweisen kann.
  • Beim dargestellten Beispiel wird eine Cloud-Plattform automatisch aus einem Satz heterogener Speicherdienstplattformen 24 (24a, 24b) ausgewählt, um den Speicherdienst bereitzustellen. Beispielsweise könnte eine erste Speicherdienstplattform 24a („1. Speicherdienstplattform“) eine AMAZON-SIMPLE-STORAGE-SERVICE(S3)-Plattform sein, während eine zweite Speicherdienstplattform 24b („n-te Speicherdienstplattform“) eine GOOGLE-CLOUD-STORAGE-Plattform sein kann. Demgemäß kann der Speicherdienst von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die Speicherdienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine Speicherdienstkomponente 28a zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener Speicherdienstplattformen 24 auf.
  • Wie in weiteren Einzelheiten erörtert wird, kann die Speicherdienstkomponente 28a transparente Migrationen der Anwendung 22 (beispielsweise aus der Perspektive des Anwendungsbenutzers) zwischen den Cloud-Plattformen im Satz heterogener Speicherdienstplattformen 24 auf der Grundlage von Änderungen in verfügbaren Speicherdiensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22 ermöglichen. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit verbessern.
  • Eine Cloud-Plattform kann auch automatisch aus einem Satz heterogener NLP-Dienstplattformen 30 (30a, 30b) ausgewählt werden, um den NLP-Dienst bereitzustellen. Beispielsweise kann eine erste NLP-Dienstplattform 30a („1. Übersetzungsplattform“) eine AMAZON-TRANSLATE-Plattform sein, während eine zweite NLP-Dienstplattform 30b („m-te Übersetzungsplattform“) eine GOOGLE-TRANSLATE-Plattform sein könnte. Demgemäß kann der NLP-Dienst auch von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die NLP-Dienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine NLP-Dienstkomponente 28b zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener NLP-Dienstplattformen 30 auf.
  • Demgemäß kann die NLP-Dienstkomponente 28b transparente Migrationen der Anwendung 22 (beispielsweise aus der Perspektive des Anwendungsbenutzers) zwischen den Cloud-Plattformen im Satz heterogener NLP-Dienstplattformen 30 auf der Grundlage von Änderungen in verfügbaren NLP-Diensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22 ermöglichen. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit weiter verbessern.
  • Zusätzlich kann eine Cloud-Plattform automatisch aus einem Satz heterogener Datenbank-Dienstplattformen 32 (32a - 32d) ausgewählt werden, um den Datenbankdienst bereitzustellen. Beispielsweise könnte eine erste Datenbank-Dienstplattform 32a („Datenbankplattform A“) eine AMAZON-DYNAMODB-Plattform sein, kann eine zweite Datenbank-Dienstplattform 32b („Datenbankplattform i“) eine AMAZON-AURORA-Plattform sein, könnte eine dritte Datenbank-Dienstplattform 32c („Datenbankplattform i+1“) eine GOOGLE-CLOUD-FIRESTORE-Plattform sein und kann eine vierte Datenbank-Dienstplattform 32d („Datenbankplattform N“) eine GOOGLE-CLOUD-SQL-Plattform sein. Demgemäß kann der Datenbankdienst von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die Datenbankdienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine Datenbank-Dienstkomponente 28c zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener Datenbank-Dienstplattformen 32 auf.
  • Die Datenbank-Dienstkomponente 28c ermöglicht transparente Migrationen der Anwendung 22 zwischen den Cloud-Plattformen im Satz heterogener Datenbank-Dienstplattformen 32 auf der Grundlage von Änderungen in verfügbaren Datenbankdiensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit weiter verbessern.
  • Überdies kann eine Cloud-Plattform automatisch aus einem Satz heterogener Authentifizierungsdienstplattformen 34 (34a, 34b) ausgewählt werden, um den Authentifizierungsdienst bereitzustellen. Beispielsweise kann eine erste Authentifizierungsdienstplattform 34a („Authentifizierungsplattform #1“) eine AMAZON-CONGNITO-Plattform sein, während eine zweite Authentifizierungsdienstplattform 34b („Authentifizierungsplattform #M“) eine GOOGLE-FIREBASE-Plattform sein könnte. Demgemäß kann der Authentifizierungsdienst von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die Authentifizierungsdienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine Authentifizierungsdienstkomponente 28d zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener Authentifizierungsdienstplattformen 34 auf.
  • Bei einem Beispiel ermöglicht die Authentifizierungsdienstkomponente 28d transparente Migrationen der Anwendung 22 zwischen den Cloud-Plattformen im Satz heterogener Authentifizierungsdienstplattformen 34 auf der Grundlage von Änderungen in verfügbaren Authentifizierungsdiensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit weiter verbessern.
  • FaaS ist ein ereignisorientiertes, hochskalierbares Computercode-Ausführungsmodell, das typischerweise einen API-Endpunkt für einen einzigen Zweck auf einer Cloud-Recheninfrastruktur bereitstellt, um die Codeausführungsanforderungen für einen verhältnismäßig kurzen Zeitraum zu empfangen und auszuführen. Diese Codeausführungsanforderungen und/oder Ausführungen angeforderten Codes werden verschiedenartig und üblicherweise als Lambdas, Funktionen, Aktionen und/oder Ausführung-bis-zum-Abschluss-Prozeduren bezeichnet. Der erläuterte Ansatz zur Portierung von Teilen der Anwendung 22 auf Cloud-Plattformen und zum Migrieren von Teilen der Anwendung 22 zwischen Cloud-Plattformen kann infolge der transienten Natur der Verknüpfungen zwischen Funktionen und der zugrunde liegenden Hardware in einer FaaS-Umgebung besonders vorteilhaft sein.
  • 2 zeigt die Portierung einer Cloud-portierbaren Anwendung 40 (beispielsweise einschließlich FaaS-Lambdas, -Funktionen, -Aktionen und/oder - Ausführung-bis-zum-Abschluss-Prozeduren) auf eine heterogene Cloud 42 (42a - 42c), die eine erste Cloud-Plattform 42a (beispielsweise GOOGLE-Cloud), eine zweite Cloud-Plattform 42b (beispielsweise MICROSOFT-Cloud) und eine dritte Cloud-Plattform 42c (beispielsweise AMAZON-Cloud) umfasst. Beim erläuterten Beispiel verwendet ein Abfertiger 44 („vereinheitlichter dynamischer Cloud-Abfertiger und Cloud-Übertragungs-Laufzeit“) einen ersten Modulmanager 46 zur Erzeugung eines ersten portierten Moduls 48 für die erste Cloud-Plattform 42a und einen zweiten Modulmanager 50 zur Erzeugung eines zweiten portierten Moduls 52 für die zweite Cloud-Plattform 42b. Zur Installationszeit mustert der Abfertiger 44 die verfügbaren Cloud-Dienste/Verkäufer und entscheidet auf der Grundlage von durch die Anwendung 40 geforderten Anforderungen des Dienstes, wie beispielsweise Skalierbarkeit und Lese-/Schreibbandbreite, welcher Ressource in der Cloud 42 der Dienst zugeordnet werden sollte. Zu dieser Zeit können spezialisierter Code/spezialisierte Aufrufe für jeden generischen API-Aufruf erzeugt werden, so dass sie mit der API und Konsistenzprotokollen des Verkäufers übereinstimmen/diesen genügen.
  • 3 zeigt eine portierte Cloud-Anwendung. Beim dargestellten Beispiel werden Kommunikationen zwischen dem ersten portierten Modul 48 und der ersten Cloud-Plattform 42a, zwischen dem zweiten portierten Modul 52 und der zweiten Cloud-Plattform 52 und zwischen dem ersten portierten Modul 48 und dem zweiten portierten Modul 52 eingerichtet. Abgesehen von Rechenressourcenanforderungs-/Randbedingungserwägungen können auch Faktoren in der Art des Dienstpreises vom Abfertiger 44 berücksichtigt werden (beispielsweise durch Installieren eines dynamischen Bieterschemas zwischen Cloud-Anbietern).
  • 4 zeigt ein Verfahren 60 zum Portieren einer Anwendung auf eine heterogene Cloud. Das Verfahren 60 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 ( 2 und 3), wie bereits erörtert. Insbesondere kann das Verfahren 60 in einem oder mehreren Modulen als ein Satz in einem maschinen- oder computerlesbaren Speichermedium in der Art eines Direktzugriffsspeichers (RAMs), Nurlesespeichers (ROMs), programmierbaren ROMs (PROMs), Firmware, Flash-Speichers usw., in konfigurierbarer Logik in der Art beispielsweise programmierbarer Logik-Arrays (PLAs), FPGAs, komplexer programmierbarer Logikvorrichtungen (CPLDs), in Festfunktionalitäts-Logikhardware unter Verwendung von Schaltungstechnologie in der Art beispielsweise anwendungsspezifischer integrierter Schaltungen (ASIC), komplementärer MetallOxid-Halbleiter(CMOS)- oder Transistor-Transistor-Logik(TTL)-Technologie oder einer Kombination davon gespeicherter Logikbefehle implementiert werden.
  • Beispielsweise kann Computerprogrammcode zur Ausführung der im Verfahren 60 dargestellten Operationen in einer Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache in der Art von JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen in der Art der Programmiersprache „C“ oder ähnlichen Programmiersprachen geschrieben werden. Zusätzlich könnten Logikbefehle Assembler-Befehle, ISA-Befehle, Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Zustandsfestlegungsdaten, Konfigurationsdaten für integrierte Schaltungsanordnungen, Zustandsinformationen, die elektronische Schaltungsanordnungen und/oder andere Strukturkomponenten, die für Hardware nativ sind (beispielsweise Host-Prozessor, Zentralverarbeitungseinheit/CPU, Mikrosteuereinrichtung usw.) personalisieren, einschließen.
  • Der dargestellte Verarbeitungsblock 62 erfasst einen generischen Cloud-Dienstaufruf in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind. Falls sich der Cloud-Dienstaufruf auf einen Datenbankdienst bezieht, könnte der Aufruf beispielsweise die Erzeugung einer Schlüsselwert-Datenbanktabelle, das Hinzufügen von Zeilen/Spalten, das Entfernen von Bestandteilen, das Initiieren von Anfragen, das Aktualisieren von Anfragen usw. unter Verwendung generischer API-Aufrufe, ohne verkäuferspezifische APIs oder Module zu spezifizieren, aufweisen. Eine erste Cloud-Plattform wird in Block 64 auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen (beispielsweise Skalierbarkeit und/oder Lese-/Schreibbandbreitenanforderungen) und eines ersten Parametersatzes (beispielsweise verkäuferspezifische APIs und/oder Module), die der ersten Cloud-Plattform zugeordnet sind, ausgewählt.
  • Block 66 sieht die automatische Erzeugung eines für eine erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes vor. Bei einem Beispiel wird in Block 66 eine Kombination von Compileranalyse zur Erkennung von Rückwärts/Vorwärts-Codeabschnitten in Bezug auf einen generischen Aufruf/einen generischen Aufruf umgebend - in der Art eines Ausnahmebehandlungscodes und einer Anfrageantwort-Nachverarbeitung - und Serien spezialisierter Codebestandteile, die entsprechend jedem Verkäufer für die API-Aufrufe vorkompiliert/erzeugt werden, verwendet. Gemäß einer Ausführungsform bildet Block 68 den Cloud-Dienstaufruf auf den für die erste Plattform spezifischen Dienstaufruf ab. Das dargestellte Verfahren 60 erhöht daher die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit durch Ermöglichen, dass eine Anwendung mit unspezifizierten plattformspezifischen Parametern auf eine Cloud-Plattform portiert wird.
  • 5 zeigt ein detaillierteres Verfahren 70 zum Portieren einer Anwendung auf eine heterogene Cloud. Das Verfahren 70 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2 und 3), wie bereits erörtert. Insbesondere kann das Verfahren 70 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
  • Der dargestellte Verarbeitungsblock 72 sieht die Bestimmung, ob die Anwendung generische Cloud-Dienst-API-Aufrufe enthält, vor. Falls dies nicht der Fall ist, kann das Verfahren 70 enden. Andernfalls greift Block 74 eine Klasse existierender Cloud-Dienste wie beispielsweise Datenbankdienste heraus/wählt diese aus. In Block 76 wird festgestellt, ob es eine durch die Anwendung für den Dienst festgelegte Leistungsfähigkeitsanforderung oder ein dafür festgelegtes Kostenbudget gibt. Falls dies der Fall ist, können in Block 78 dementsprechend minimale („min“) Leistungsfähigkeitsanforderungen (beispielsweise Lese-/Schreibbandbreite für Datenbanken) festgelegt werden. Block 80 sieht dann das Mustern von Cloud-Anbietern für die Dienste mit übereinstimmenden Leistungsfähigkeitsprofilen und Kostenangaben vor. Es kann dann in Block 84 festgestellt werden, ob ein Anbieter mit einem übereinstimmenden Dienst/Profil/Budget gefunden wurde. Falls dies der Fall ist, stellt Block 86 spezialisierten Code/spezialisierte Aufrufe zusammen, um die generischen Dienst-API-Aufrufe zu ersetzen, um den API- und Konsistenzprotokollen des Verkäufers zu entsprechen. Block 86 kann eine Kombination von Compileranalyse und einer Reihe von Codeabschnitten verwenden, die entsprechend jedem Verkäufer für die API-Aufrufe vorkompiliert/erzeugt werden. Das dargestellte Verfahren 70 kehrt dann zu Block 72 zurück.
  • Falls in Block 76 keine Leistungsfähigkeitsanforderungen oder kein Kostenbudget erkannt werden, verwendet der dargestellte Block 82 Standardschwellenwerte und wird das Verfahren 70 in Block 80 fortgesetzt. Falls zusätzlich in Block 84 keine Anbieter gefunden werden, stellt Block 88 die Schwellenwerte (beispielsweise mit Rückmeldung von der Anwendung und/oder vom Benutzer oder ohne diese) wieder ein. Das Verfahren 70 kann dann zu Block 80 zurückkehren. Das Verfahren 70 erhöht daher die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit durch Ermöglichen, dass eine Anwendung mit unspezifizierten plattformspezifischen Parametern auf eine Cloud-Plattform portiert wird.
  • 6A zeigt, dass, wenn sich die Verfügbarkeit des Dienstes, Anforderungen der Anwendung oder sogar der Preis während des Lebenszyklus einer Anwendung ändert, der dargestellte Abfertiger 44 in der Lage ist, eine vollständige Anwendung oder einen Teil davon allmählich von einem Cloud-Anbieter zu einem anderen zu migrieren, wobei nur eine geringe oder minimale Unterbrechung der Anwendungsausführung auftritt. Beim dargestellten Beispiel verwendet der Abfertiger 44 einen dritten Modulmanager 90 für die Erzeugung eines dritten portierten Moduls 92 für die dritte Cloud-Plattform 42c, wodurch schließlich die zweite Cloud-Plattform 42b ersetzt wird. Während der Laufzeit und während Zustandsdaten von der zweiten Cloud-Plattform 42b zur dritten Cloud-Plattform 42c übertragen werden, wird das dargestellte dritte portierte Modul 92 als „kalt“ angesehen. Wie in weiteren Einzelheiten erörtert wird, kann die Übertragung von Zustandsdaten in einer Weise verfolgt werden, welche es ermöglicht, dass die Migration im Wesentlichen für den Anwendungsbenutzer transparent ist.
  • 6B zeigt eine abgeschlossene Migration. Beim erläuterten Beispiel werden Kommunikationen zwischen dem dritten portierten Modul 92 und der dritten Cloud-Plattform 42c und zwischen dem dritten portierten Modul 92 und dem ersten portierten Modul 48 eingerichtet. Zusätzlich ist die Übertragung interner Zustandsdaten abgeschlossen, so dass das dritte portierte Modul 92 nicht mehr als kalt angesehen wird.
  • 7 zeigt ein Verfahren 100 zum Migrieren einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform. Das Verfahren 100 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 100 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
  • Der dargestellte Verarbeitungsblock 102 wählt eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen (beispielsweise Skalierbarkeits- und/oder Lese-/Schreibbandbreitenanforderungen) und eines zweiten Parametersatzes (beispielsweise verkäuferspezifischer APIs und/oder Module) in Zusammenhang mit der zweiten Plattform aus. Block 104 kann automatisch einen zweiten plattformspezifischen Aufruf auf der Grundlage des generischen Cloud-Dienstaufrufs und des zweiten Parametersatzes erzeugen. Gemäß einer Ausführungsform wird in Block 104 eine Kombination von Compileranalyse und einer Reihe von Codeabschnitten, die für die jedem Dienstanbieter/Verkäufer entsprechenden API-Aufrufe vorkompiliert/erzeugt wurden, verwendet. Der generische Cloud-Dienstaufruf kann in Block 106 dem zweiten plattformspezifischen Dienstaufruf zugeordnet werden. Block 108 führt eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform aus, wobei der dargestellte Block 110 die Übertragung über eine Bitmap verfolgt. Gemäß einer Ausführungsform entspricht jedes Bit der Bitmap einem Segment, einem Byte und/oder einem Teil (beispielsweise einer Untermenge) des internen Zustands der aktuellen (beispielsweise „alten“) Cloud-Plattform. Demgemäß kann die Bitmap aktualisiert werden, wenn die verschiedenen Teilmengen des internen Zustands zur nächsten (beispielsweise „zweiten“ oder „neuen“) Cloud-Plattform übertragen werden (beispielsweise entweder durch eine direkte Kopie durch den Abfertiger/die Laufzeit oder Schreiboperationen der Anwendung). Das dargestellte Verfahren 100 erhöht daher die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit durch Ermöglichen, dass eine Anwendung mit unspezifizierten plattformspezifischen Parametern transparent zwischen Cloud-Plattformen migriert wird.
  • 8 zeigt ein Verfahren 120 zur Behandlung von Cloud-Dienstaufrufen. Das Verfahren 120 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 120 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
  • Der dargestellte Verarbeitungsblock 122 sieht das Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs vor. Wie bereits erwähnt, können plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert (beispielsweise nicht darin vorhanden) sein. Gemäß einer Ausführungsform gibt Block 124 selektiv ansprechend auf die Laufzeitinstanz den für die erste Plattform spezifischen Dienstaufruf und/oder den für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Status der Übertragung aus. Falls der Cloud-Dienstaufruf beispielsweise nur Teilmengen der Zustandsdaten betrifft, die bereits zur zweiten (beispielsweise neuen) Cloud-Plattform übertragen wurden, kann Block 124 sowohl den für die erste als auch für die zweite Plattform spezifischen Dienstaufruf ausgeben. Falls der Cloud-Dienstaufruf dagegen Teilmengen der Zustandsdaten betrifft, die noch nicht zur zweiten Cloud-Plattform übertragen worden sind, kann Block 124 nur den für die erste Plattform spezifischen Dienstaufruf (beispielsweise an die erste Cloud-Plattform) ausgeben. Ein solcher Ansatz kann gewährleisten, dass die Migration inkrementell und transparent stattfindet.
  • 9A zeigt ein Verfahren 130 zum Übertragen von Zustandsdaten zwischen Cloud-Plattformen. Das Verfahren 130 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 130 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
  • Der dargestellte Verarbeitungsblock 132 erzeugt eine Bitmap, wobei jedes Bit ein Segment, ein Byte oder einen Teil des internen Zustands des aktuellen/alten Dienstverkäufers (beispielsweise Cloud-Plattform) repräsentiert. Gemäß einer Ausführungsform kopiert und überträgt Block 134 jedes interne Zustandssegment des alten Verkäufers zum internen Zustand des neuen Verkäufers. Zusätzlich kann Block 134 für jedes übertragene Byte/Segment das entsprechende Bit in der Bitmap festlegen, um anzugeben, dass die Übertragung abgeschlossen ist. In Block 136 kann festgestellt werden, ob alle Bits der Bitmap gesetzt wurden. Falls dies nicht der Fall ist, kehrt das dargestellte Verfahren 130 zu Block 134 zurück. Andernfalls trennt sich Block 138 vom alten Verkäufer und lässt sich ganz mit dem neuen Verkäufer ein, und das Verfahren 130 endet.
  • 9B zeigt ein detaillierteres Verfahren 140 zur Behandlung von Cloud-Dienstaufrufen. Das Verfahren 140 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 ( 2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 140 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
  • Der dargestellte Verarbeitungsblock 142 erkennt einen neuen Dienstaufruf (beispielsweise Instanz des Cloud-Dienstaufrufs) von der Anwendung. Gemäß einer Ausführungsform wird in Block 144 festgestellt, ob die neue Anforderung nur Teilmengen des internen Zustands liest, wobei Bits für die vollständige Übertragung festgelegt sind. Falls dies der Fall ist, kann die Anforderung in Block 146 erneut sowohl an den alten als auch an den neuen Verkäufer (beispielsweise Cloud-Plattformen) erteilt werden (beispielsweise durch plattformspezifische Dienstaufrufe ausgeführt). Bei einem Beispiel stellt Block 148 dann fest, ob die neue Anforderung nur in Teilmengen des internen Zustands schreibt, wobei Bits für die vollständige Übertragung festgelegt sind. Falls dies der Fall ist, endet die Verarbeitung der Anforderung in Block 150. Falls in Block 148 festgestellt wird, dass die neue Anforderung nicht nur in Teilmengen des internen Zustands schreibt, wobei Bits für die vollständige Übertragung festgelegt sind, legt Block 152 die Übertragung-vollständig-Bits für die durch die Anforderung aktualisierte Teilmenge fest.
  • Falls in Block 144 festgestellt wird, dass die neue Anforderung nicht nur Teilmengen des internen Zustands, wobei Bits für eine vollständige Übertragung festgelegt sind, liest, erteilt der dargestellte Block 154 die Anforderung nur an den alten Verkäufer (gibt sie beispielsweise durch einen plattformspezifischen Dienstaufruf aus). Zusätzlich kann in Block 156 festgestellt werden, ob die neue Anforderung in jegliche der Teilmengen des internen Zustands schreibt, bei denen Bits für eine vollständige Übertragung festgelegt sind. Falls dies der Fall ist, löscht Block 158 die Übertragung-vollständig-Bits für die durch die Anforderung aktualisierte Teilmenge des internen Zustands/setzt diese zurück. Andernfalls wird die Verarbeitung der Anforderung in Block 160 abgeschlossen.
  • 10 zeigt ein Rechensystem 170 mit erhöhter Leistungsfähigkeit. Das System 170 kann allgemein Teil einer elektronischen Vorrichtung/Plattform sein, die Rechenfunktionalität (beispielsweise persönlicher digitaler Assistent/PDA, Notebookcomputer, Tabletcomputer, konvertibles Tablet, Server), Kommunikationsfunktionalität (beispielsweise Smartphone), Bildgebungsfunktionalität (beispielsweise Kamera, Camcorder), Medienwiedergabefunktionalität (beispielsweise Smart-Fernsehgerät/TV), tragbare Funktionalität (beispielsweise Uhr, Brille, am Kopf getragene Vorrichtung, am Fuß getragene Vorrichtung, Schmuck), Fahrzeugfunktionalität (beispielsweise PKW, Lastwagen, Motorrad), Roboterfunktionalität (beispielsweise autonomer Roboter) usw. oder eine Kombination davon aufweist. Beim dargestellten Beispiel weist das System 170 einen Host-Prozessor 172 mit einer integrierten Speichersteuereinrichtung (IMC) 174, die mit einem Systemspeicher 176 gekoppelt ist, auf.
  • Das dargestellte System 170 weist auch ein Eingabe-/Ausgabe(EA)-Modul 178 auf, das zusammen mit dem Host-Prozessor 172 und einem Grafikprozessor 180 auf einem Halbleiter-Die 182 als System-on-Chip (SoC) implementiert ist. Das dargestellte EA-Modul 178 kommuniziert beispielsweise mit einer Anzeige 184 (beispielsweise Touchscreen-, Flüssigkristallanzeige/LCD-, Leuchtdioden/LED-Anzeige), einer Netzsteuereinrichtung 186 (beispielsweise festverdrahtet und/oder drahtlos) und einem Massenspeicher 188 (beispielsweise Festplattenlaufwerk/HDD, optische Scheibe, Halbleiterlaufwerk/SSD, Flash-Speicher).
  • Gemäß einer Ausführungsform führen der Host-Prozessor 172, der Grafikprozessor 180 und/oder das EA-Modul 178 aus dem Systemspeicher 176 und/oder dem Massenspeicher 188 abgerufene Programmbefehle 190 aus, um einen oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B), wie bereits erörtert, auszuführen. Demgemäß kann die Ausführung der dargestellten Befehle 190 das Rechensystem 170 veranlassen, einen Cloud-Dienstaufruf in einer Anwendung zu erkennen, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, und eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und einem ersten Parametersatz in Zusammenhang mit der ersten Cloud-Plattform auszuwählen. Die Ausführung der Befehle 190 kann das Rechensystem 170 auch veranlassen, automatisch einen für die erste Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes zu erzeugen.
  • Überdies kann die Ausführung der Befehle 190 das Rechensystem 170 veranlassen, eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform auszuwählen und automatisch einen für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes zu erzeugen. Das dargestellte Rechensystem 170 weist daher zumindest in dem Maße eine erhöhte Leistungsfähigkeit auf, dass es Anwendungen mit generischen Cloud-Dienstaufrufen auf Cloud-Plattformen portiert und/oder die Anwendungen zwischen Cloud-Plattformen migriert.
  • 11 zeigt eine Halbleiterbaugruppenvorrichtung 192. Die dargestellte Vorrichtung 192 weist ein oder mehrere Substrate 194 (beispielsweise Silicium, Saphir, Galliumarsenid) und Logik 196 (beispielsweise Transistor-Array und andere Integrierte-Schaltung/IC-Komponenten), die mit dem einen oder den mehreren Substraten 194 gekoppelt ist, auf. Die Logik 196 kann zumindest teilweise in Konfigurierbare-Logik- oder Festfunktionalitäts-Logikhardware implementiert sein. Bei einem Beispiel implementiert die Logik 196 einen oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B), wie bereits erörtert. Demgemäß kann die Logik 196 einen Cloud-Dienstaufruf in einer Anwendung erkennen, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, und eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform auswählen. Die Logik 196 kann auch einen für die erste Plattform spezifischen Dienstaufruf automatisch auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes erzeugen.
  • Überdies kann die Logik 196 eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform auswählen und automatisch einen für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes erzeugen. Die dargestellte Vorrichtung 192 weist daher zumindest in dem Maße eine erhöhte Leistungsfähigkeit auf, dass sie Anwendungen mit generischen Cloud-Dienstaufrufen auf Cloud-Plattformen portiert und/oder die Anwendungen zwischen Cloud-Plattformen migriert.
  • Bei einem Beispiel weist die Logik 196 Transistorkanalgebiete auf, die innerhalb des einen oder der mehreren Substrate 194 angeordnet (beispielsweise darin eingebettet) sind. Demgemäß kann die Schnittstelle zwischen der Logik 196 und dem einen oder den mehreren Substraten 194 kein abrupter Übergang sein. Die Logik 196 kann auch als eine Epitaxieschicht, die auf einem anfänglichen Wafer des einen oder der mehreren Substrate 194 aufgewachsen ist, aufweisend angesehen werden.
  • 12 zeigt einen Prozessorkern 200 gemäß einer Ausführungsform. Der Prozessorkern 200 kann der Kern für einen beliebigen Prozessortyp in der Art eines Mikroprozessors, eines eingebetteten Prozessors, eines digitalen Signalprozessors (DSP), eines Netzprozessors oder einer anderen Vorrichtung zur Ausführung von Code sein. Wenngleich in 12 nur ein Prozessorkern 200 dargestellt ist, kann ein Verarbeitungselement alternativ mehr als einen von dem in 12 dargestellten Prozessorkern 200 aufweisen. Der Prozessorkern 200 kann ein Einzel-Thread-Kern sein, oder er kann für zumindest eine Ausführungsform in der Hinsicht mehrere Threads aufweisen, dass er mehr als einen Hardware-Thread-Kontext (oder „logischen Prozessor“) pro Kern aufweisen kann.
  • 12 zeigt auch einen Speicher 270, der mit dem Prozessorkern 200 gekoppelt ist. Der Speicher 270 kann einer von einer breiten Vielfalt von Speichern (einschließlich verschiedener Schichten einer Speicherhierarchie) sein, die Fachleuten bekannt sind oder auf andere Weise zur Verfügung stehen. Der Speicher 270 kann einen oder mehrere Codebefehle 213 aufweisen, die durch den Prozessorkern 200 auszuführen sind, wobei der Code 213 einen oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B), wie bereits erörtert, implementieren kann. Der Prozessorkern 200 folgt einer durch den Code 213 angegebenen Programmsequenz von Befehlen. Jeder Befehl kann in einen Vorverarbeitungsabschnitt 210 eingegeben werden und durch einen oder mehrere Decoder 220 verarbeitet werden. Der Decoder 220 kann als Ausgabe eine Mikrooperation in der Art einer Mikrooperation fester Breite in einem vordefinierten Format erzeugen oder andere Befehle, Mikrobefehle oder Steuersignale erzeugen, welche den ursprünglichen Codebefehl widerspiegeln. Der dargestellte Vorverarbeitungsabschnitt 210 weist auch eine Registerumbenennungslogik 225 und eine Planungslogik 230 auf, die im Allgemeinen Ressourcen zuordnen und den Betrieb entsprechend dem umgewandelten Befehl für die Ausführung einreihen.
  • Der Prozessorkern 200 weist wie dargestellt eine Ausführungslogik 250 mit einem Satz von Ausführungseinheiten 255-1 bis 255-N auf. Einige Ausführungsformen können eine Anzahl von Ausführungseinheiten aufweisen, die spezifischen Funktionen oder Funktionssätzen zugewiesen sind. Andere Ausführungsformen können nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine bestimmte Funktion ausführen kann, aufweisen. Die dargestellte Ausführungslogik 250 führt die durch Codebefehle spezifizierten Operationen aus.
  • Nach Abschluss der Ausführung der durch die Codebefehle spezifizierten Operationen zieht eine nachgeschaltete Logik 260 die Befehle des Codes 213 zurück. Gemäß einer Ausführungsform ermöglicht der Prozessorkern 200 eine Ausführung außerhalb der Reihenfolge, erfordert jedoch ein Zurückziehen von Befehlen in der Reihenfolge. Die Zurückziehungslogik 265 kann eine Vielzahl Fachleuten bekannter Formen annehmen (beispielsweise Umordnungspuffer oder dergleichen). Auf diese Weise wird der Prozessorkern 200 während der Ausführung des Codes 213 zumindest in Bezug auf die vom Decoder erzeugte Ausgabe, die Hardwareregister und -tabellen, die von der Registerumbenennungslogik 225 verwendet werden, und jegliche Register (nicht dargestellt), die von der Ausführungslogik 250 modifiziert werden, transformiert.
  • Wenngleich dies in 12 nicht dargestellt ist, kann ein Verarbeitungselement andere Elemente auf dem Chip mit dem Prozessorkern 200 aufweisen. Beispielsweise kann ein Verarbeitungselement eine Speichersteuerlogik zusammen mit dem Prozessorkern 200 aufweisen. Das Verarbeitungselement kann eine E/A-Steuerlogik und/oder eine mit Speichersteuerlogik integrierte E/A-Steuerlogik aufweisen. Das Verarbeitungselement kann auch einen oder mehrere Caches aufweisen.
  • 13 zeigt ein Blockdiagramm eines Rechensystems 1000 gemäß einer Ausführungsform. 13 zeigt ein Mehrprozessorsystem 1000, das ein erstes Verarbeitungselement 1070 und ein zweites Verarbeitungselement 1080 aufweist. Wenngleich zwei Verarbeitungselemente 1070 und 1080 dargestellt sind, ist zu verstehen, dass eine Ausführungsform des Systems 1000 auch ein solches Verarbeitungselement aufweisen kann.
  • Das System 1000 ist als ein Punkt-zu-Punkt-Zwischenverbindungssystem dargestellt, wobei das erste Verarbeitungselement 1070 und das zweite Verarbeitungselement 1080 über eine Punkt-zu-Punkt-Zwischenverbindung 1050 gekoppelt sind. Es sei bemerkt, dass einige oder alle der in 13 dargestellten Zwischenverbindungen an Stelle einer Punkt-zu-Punkt-Zwischenverbindung als ein Multi-Drop-Bus implementiert werden können.
  • Wie in 13 dargestellt ist, kann jedes der Verarbeitungselemente 1070 und 1080 ein Mehrkernprozessor sein, der erste und zweite Prozessorkerne aufweist (d. h. Prozessorkerne 1074a und 1074b und Prozessorkerne 1084a und 1084b). Diese Kerne 1074a, 1074b, 1084a, 1084b können dafür ausgelegt sein, einen Befehlscode ähnlich wie vorstehend in Zusammenhang mit 12 erörtert auszuführen.
  • Jedes Verarbeitungselement 1070, 1080 kann wenigstens einen geteilten Cache 1896a, 1896b aufweisen. Der geteilte Cache 1896a, 1896b kann Daten (beispielsweise Befehle) speichern, die von einer oder mehreren Komponenten des Prozessors in der Art der Kerne 1074a, 1074b bzw. 1084a, 1084b verwendet werden. Beispielsweise kann der geteilte Cache 1896a, 1896b in einem Speicher 1032, 1034 gespeicherte Daten für einen schnelleren Zugriff durch Komponenten des Prozessors lokal cachen. Gemäß einer oder mehreren Ausführungsformen kann der geteilte Cache 1896a, 1896b einen oder mehrere Mid-Level-Caches in der Art eines Level-2(L2)-, Level-3(L3)-, Level-4(L4)- oder anderen Cache-Levels, einen Last-Level-Cache (LLC) und/oder Kombinationen davon aufweisen.
  • Wenngleich sie nur mit zwei Verarbeitungselementen 1070, 1080 dargestellt sind, ist zu verstehen, dass der Geltungsbereich der Ausführungsformen nicht darauf beschränkt ist. Gemäß anderen Ausführungsformen können ein oder mehrere zusätzliche Verarbeitungselemente in einem gegebenen Prozessor vorhanden sein. Alternativ können ein oder mehrere Verarbeitungselemente 1070, 1080 ein anderes Element als ein Prozessor sein, wie ein Beschleuniger oder ein feldprogrammierbares Gate-Array. Beispielsweise kann das eine oder können die mehreren zusätzlichen Verarbeitungselemente einen oder mehrere zusätzliche Prozessoren, die dem ersten Prozessor 1070 gleichen, einen oder mehrere zusätzliche Prozessoren, die zum ersten Prozessor 1070 heterogen oder asymmetrisch sind, Beschleuniger (beispielsweise in der Art von Grafikbeschleunigern oder digitalen Signalverarbeitungseinheiten (DSP-Einheiten)), feldprogrammierbare Gate-Arrays oder ein anderes Verarbeitungselement aufweisen. Es kann eine Vielzahl von Unterschieden zwischen den Verarbeitungselementen 1070, 1080 in Bezug auf ein Spektrum von Gütemetriken, einschließlich architektonischer, mikroarchitektonischer, thermischer, Stromverbrauchseigenschaften usw., geben. Diese Unterschiede können sich effektiv als Asymmetrie und Heterogenität zwischen den Verarbeitungselementen 1070, 1080 manifestieren. Für zumindest eine Ausführungsform können sich die verschiedenen Verarbeitungselemente 1070, 1080 im selben Die-Gehäuse befinden.
  • Das erste Verarbeitungselement 1070 kann ferner eine Speichersteuereinrichtungslogik (MC) 1072 und Punkt-zu-Punkt-(P-P)-Schnittstellen 1076 und 1078 aufweisen. Ähnlich kann das zweite Verarbeitungselement 1080 eine MC 1082 und P-P-Schnittstellen 1086 und 1088 aufweisen. Wie in 13 dargestellt ist, koppeln die MCs 1072 und 1082 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 1032 und einem Speicher 1034, die Teile eines lokal an den jeweiligen Prozessoren angebrachten Hauptspeichers sein können. Wenngleich die MCs 1072 und 1082 als in die Verarbeitungselemente 1070, 1080 integriert dargestellt sind, kann die MC-Logik für alternative Ausführungsformen eine diskrete Logik außerhalb der Verarbeitungselemente 1070, 1080 statt darin integriert sein.
  • Das erste Verarbeitungselement 1070 und das zweite Verarbeitungselement 1080 können über jeweilige P-P-Zwischenverbindungen 1076, 1086 mit einem E/A-Untersystem 1090 gekoppelt sein. Wie in 13 dargestellt ist, weist das E/A-Untersystem 1090 P-P-Schnittstellen 1094 und 1098 auf. Ferner weist das E/A-Untersystem 1090 eine Schnittstelle 1092 zum Koppeln des E/A-Untersystems 1090 mit einer Hochleistungs-Grafikmaschine 1038 auf. Gemäß einer Ausführungsform kann der Bus 1049 verwendet werden, um die Grafikmaschine 1038 mit dem E/A-Untersystem 1090 zu koppeln. Alternativ kann eine Punkt-zu-Punkt-Zwischenverbindung diese Komponenten koppeln.
  • Das E/A-Untersystem 1090 kann wiederum über eine Schnittstelle 1096 mit einem ersten Bus 1016 gekoppelt sein. Gemäß einer Ausführungsform kann der erste Bus 1016 ein Peripheriekomponenten-Zwischenverbindungs(PCI)-Bus oder ein Bus in der Art eines PCI-Express-Busses oder eines anderen E/A-Zwischenverbindungsbusses der dritten Generation sein, wenngleich der Geltungsbereich der Ausführungsformen nicht darauf beschränkt ist.
  • Wie in 13 dargestellt ist, können verschiedene E/A-Vorrichtungen 1014 (beispielsweise biometrische Scanner, Lautsprecher, Kameras, Sensoren) zusammen mit einer Busbrücke 1018, die den ersten Bus 1016 mit einem zweiten Bus 1020 koppeln kann, mit dem ersten Bus 1016 gekoppelt sein. Gemäß einer Ausführungsform kann der zweite Bus 1020 ein Bus mit einer geringen Stiftanzahl (LPC-Bus) sein. Verschiedene Vorrichtungen können mit dem zweiten Bus 1020 gekoppelt werden, einschließlich beispielsweise einer Tastatur/einer Maus 1012, einer oder mehrerer Kommunikationsvorrichtungen 1026 und einer Datenspeichereinheit 1019 in der Art eines Plattenlaufwerks oder einer anderen Massenspeichervorrichtung, die gemäß einer Ausführungsform einen Code 1030 aufweisen kann. Der dargestellte Code 1030 kann ein oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B) aufweisen, wie bereits erörtert. Ferner kann eine Audio-E/A 1024 mit dem zweiten Bus 1020 gekoppelt sein und kann eine Batterie 1010 dem Rechensystem 1000 Strom zuführen.
  • Es sei bemerkt, dass auch andere Ausführungsformen erwogen werden. Beispielsweise kann an Stelle der Punkt-zu-Punkt-Architektur aus 13 ein System einen Multi-Drop-Bus oder eine andere derartige Kommunikationstopologie implementieren. Auch können die Elemente aus 13 alternativ unter Verwendung von mehr oder weniger integrierten Chips als in 13 dargestellt partitioniert werden.
  • Zusätzliche Bemerkungen und Beispiele:
  • Beispiel 1 weist ein Rechensystem mit erhöhter Leistungsfähigkeit auf, das eine Netzsteuereinrichtung, einen Prozessor, der mit der Netzsteuereinrichtung gekoppelt ist, und einen Speicher, der mit dem Prozessor gekoppelt ist, umfasst, wobei der Speicher einen Satz ausführbarer Programmbefehle umfasst, die, wenn sie durch den Prozessor ausgeführt werden, das Rechensystem veranlassen, einen Cloud-Dienstaufruf in einer Anwendung zu erkennen, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform auszuwählen und automatisch einen für die erste Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes zu erzeugen.
  • Beispiel 2 weist das Rechensystem nach Beispiel 1 auf, wobei die Befehle, wenn sie ausgeführt werden, das Rechensystem veranlassen, den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuzuordnen.
  • Beispiel 3 weist das Rechensystem nach einem der Beispiele 1 bis 2 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform auszuwählen, automatisch einen für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes zu erzeugen und den Cloud-Dienstaufruf dem für die zweite Plattform spezifischen Dienstaufruf zuzuordnen.
  • Beispiel 4 weist das Rechensystem nach Beispiel 3 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform auszuführen.
  • Beispiel 5 weist das Rechensystem nach Beispiel 4 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, die Übertragung über eine Bitmap zu verfolgen.
  • Beispiel 6 weist das Rechensystem nach Beispiel 4 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Laufzeitinstanz des Cloud-Dienstaufrufs zu erkennen und ansprechend auf die Laufzeitinstanz den für die erste Plattform spezifischen Dienstaufruf und/oder den für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage eines Status der Übertragung selektiv auszugeben.
  • Beispiel 7 weist eine Halbleitervorrichtung auf, die ein oder mehrere Substrate und mit dem einen oder den mehreren Substraten gekoppelte Logik umfasst, wobei die Logik zumindest teilweise in einer oder mehreren von einer konfigurierbaren Logik oder einer Festfunktionalitäts-Hardwarelogik implementiert ist, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
  • Beispiel 8 weist die Halbleitervorrichtung nach Beispiel 7 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuordnen soll.
  • Beispiel 9 weist die Halbleitervorrichtung nach einem der Beispiele 7 bis 8 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
  • Beispiel 10 weist die Halbleitervorrichtung nach Beispiel 9 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform ausführen soll.
  • Beispiel 11 weist die Halbleitervorrichtung nach Beispiel 10 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik die Übertragung über eine Bitmap verfolgen soll.
  • Beispiel 12 weist die Halbleitervorrichtung nach Beispiel 10 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
  • Beispiel 13 weist wenigstens ein computerlesbares Speichermedium auf, das einen Satz ausführbarer Programmbefehle umfasst, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen, Folgendes auszuführen: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
  • Beispiel 14 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 13 auf, wobei die Befehle, wenn sie ausgeführt werden, das Rechensystem veranlassen, den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuzuordnen.
  • Beispiel 15 weist das wenigstens eine computerlesbare Speichermedium nach einem der Beispiele 13 bis 14 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, Folgendes auszuführen: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
  • Beispiel 16 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 15 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform auszuführen.
  • Beispiel 17 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 16 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, die Übertragung über eine Bitmap zu verfolgen.
  • Beispiel 18 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 16 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Laufzeitinstanz des Cloud-Dienstaufrufs zu erkennen und ansprechend auf die Laufzeitinstanz den für die erste Plattform spezifischen Dienstaufruf und/oder den für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage eines Status der Übertragung selektiv auszugeben.
  • Beispiel 19 weist ein Verfahren zum Betreiben eines Rechensystems mit erhöhter Leistungsfähigkeit auf, wobei das Verfahren Folgendes umfasst: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
  • Beispiel 20 weist das Verfahren nach Beispiel 19 auf, wobei der Cloud-Dienstaufruf ferner dem für die erste Plattform spezifischen Dienstaufruf zugeordnet wird.
  • Beispiel 21 weist das Verfahren nach einem der Beispiele 19 bis 20 auf, und es weist ferner Folgendes auf Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
  • Beispiel 22 weist das Verfahren nach Beispiel 21 auf, wobei ferner eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform ausgeführt wird.
  • Beispiel 23 weist das Verfahren nach Beispiel 22 auf, wobei ferner die Übertragung über eine Bitmap verfolgt wird.
  • Beispiel 24 weist das Verfahren nach Beispiel 22 auf, und es weist ferner Folgendes auf: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
  • Beispiel 25 weist Mittel zur Ausführung des Verfahrens nach einem der Beispiele 19 bis 24 auf.
  • Demgemäß stellt die hier beschriebene Technologie eine vereinheitlichte Programmierschnittstelle bereit, die auf generische Cloud-Dienste und eine Laufzeit, die eine Anwendung oder Teile von ihr transparent bewegt, um von verschiedenen Cloud-Verkäuferdiensten zu profitieren, abzielt. Die Cloud-Anwendungsentwickler können ihren Code einmal unter Verwendung generischer Cloud-Dienst-APIs schreiben, wie hier beschrieben. Eine Laufzeit kann die generische API auf verfügbare/optimale Cloud-Dienste portieren/abbilden (beispielsweise durch Wählen aus einem Pool von Verkäufern). Die Laufzeit kann auch eine allmähliche Migration der Anwendung oder spezifischer Module von einem Cloud-Verkäufer zu einem anderen bereitstellen, ohne den Dienst zu unterbrechen.
  • Ausführungsformen sind für eine Verwendung mit allen Typen von Chips integrierter Halbleiterschaltungen („IC-Chips“) geeignet. Beispiele dieser IC-Chips umfassen Prozessoren, Steuereinrichtungen, Chipsatz-Komponenten, programmierbare Logik-Arrays (PLA), Speicherchips, Netzchips, Systems-on-Chip (SoC), SSD/NAND-Steuereinrichtungs-ASICs und dergleichen, sind jedoch nicht darauf beschränkt. Zusätzlich sind in einigen der Zeichnungen Signalleitungen durch Linien dargestellt. Einige können verschieden sein, um weitere Signalteilwege anzugeben, eine Nummernbezeichnung aufweisen, um eine Nummer von Signalteilwegen anzugeben, und/oder an einem oder mehreren Enden Pfeile aufweisen, um die primäre Informationsflussrichtung anzugeben. Dies sollte jedoch nicht einschränkend ausgelegt werden. Vielmehr können solche zusätzlichen Einzelheiten zusammen mit einer oder mehreren beispielhaften Ausführungsformen verwendet werden, um das Verständnis einer Schaltung zu erleichtern. Jegliche dargestellte Signalleitungen, ob sie zusätzliche Informationen aufweisen oder nicht, können tatsächlich ein oder mehrere Signale umfassen, die sich in mehreren Richtungen ausbreiten, und durch einen geeigneten Typ eines Signalschemas implementiert werden, beispielsweise als digitale oder analoge Leitungen, die mit differenziellen Paaren, optischen Faserleitungen und/oder unsymmetrischen Leitungen implementiert sind.
  • Beispielhafte Größen/Modelle/Werte/Bereiche können angegeben worden sein, wenngleich Ausführungsformen nicht darauf beschränkt sind. Weil die Herstellungstechniken (beispielsweise die Photolithographie) im Laufe der Zeit reifen, wird erwartet, dass Vorrichtungen mit einer geringeren Größe hergestellt werden könnten. Zusätzlich können innerhalb der Figuren zur einfachen Darstellung und Erörterung und um bestimmte Aspekte der Ausführungsformen nicht unklar zu machen, wohlbekannte Strom/Masse-Verbindungen zu IC-Chips und anderen Komponenten dargestellt sein, oder dies kann nicht der Fall sein. Ferner können Anordnungen in Blockdiagrammform dargestellt sein, um es zu verhindern, Ausführungsformen unklar zu machen, und auch angesichts der Tatsache, dass spezifische Einzelheiten in Bezug auf die Implementation solcher Blockdiagrammanordnungen in hohem Maße vom Rechensystem abhängen, innerhalb dessen die Ausführungsform zu implementieren ist, d. h. diese spezifischen Einzelheiten sollten für Fachleute leicht verständlich sein. Wo spezifische Details (beispielsweise Schaltungen) dargelegt sind, um beispielhafte Ausführungsformen zu beschreiben, sollte Fachleuten verständlich sein, dass Ausführungsformen ohne eine Variation dieser spezifischen Details oder mit einer Variation von diesen verwirklicht werden können. Die Beschreibung ist demgemäß als erläuternd und nicht als einschränkend anzusehen.
  • Der Begriff „gekoppelt“ kann hier verwendet werden, um auf einen Typ einer Beziehung, ob direkt oder indirekt, zwischen den fraglichen Komponenten Bezug zu nehmen und für elektrische, mechanische, Fluid-, optische, elektromagnetische, elektromechanische oder andere Verbindungen gelten. Zusätzlich können die Begriffe „erster“, „zweiter“ usw. hier nur verwendet werden, um die Erörterung zu erleichtern, und sie weisen keine bestimmte zeitliche oder chronologische Bedeutung auf, es sei denn, dass etwas anderes angegeben wird.
  • Wie in dieser Anmeldung und in den Ansprüchen verwendet, kann eine Liste durch den Begriff „einer oder mehrere von“ verbundener Bestandteile eine beliebige Kombination der aufgelisteten Bestandteile bedeuten. Beispielsweise können die Ausdrücke „eine oder mehrere von A, B oder C“ A; B; C; A und B; A und C; B und C; oder A, B und C bedeuten.
  • Fachleute werden anhand der vorstehenden Beschreibung verstehen, dass die breiten Techniken der Ausführungsformen in einer Vielzahl von Formen implementiert werden können. Daher sollte, wenngleich die Ausführungsformen in Zusammenhang mit bestimmten Beispielen davon beschrieben wurden, der wahre Geltungsbereich der Ausführungsformen nicht darauf begrenzt sein, weil andere Modifikationen sachkundigen Anwendern bei der Betrachtung der Zeichnungen, der Beschreibung und der folgenden Ansprüche verständlich werden.

Claims (15)

  1. Halbleitervorrichtung, welche Folgendes umfasst: ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, wobei die Logik zumindest teilweise in einer oder mehreren von einer konfigurierbaren Logik oder einer Festfunktionalitäts-Hardwarelogik implementiert ist, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
  2. Halbleitervorrichtung nach Anspruch 1, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuordnen soll.
  3. Halbleitervorrichtung nach einem der Ansprüche 1 bis 2, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf
  4. Halbleitervorrichtung nach Anspruch 3, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform ausführen soll.
  5. Halbleitervorrichtung nach Anspruch 4, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik die Übertragung über eine Bitmap verfolgen soll.
  6. Halbleitervorrichtung nach Anspruch 4, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
  7. Computerlesbares Speichermedium bzw. computerlesbare Speichermedien, umfassend einen Satz ausführbarer Programmbefehle, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen, Folgendes auszuführen: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
  8. Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 7, wobei die Befehle, wenn sie ausgeführt werden, das Rechensystem veranlassen, den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuzuordnen.
  9. Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach einem der Ansprüche 7 bis 8, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, Folgendes auszuführen: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf
  10. Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 9, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform auszuführen.
  11. Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 10, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, die Übertragung über eine Bitmap zu verfolgen.
  12. Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 10, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, Folgendes auszuführen: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
  13. Verfahren, welches Folgendes umfasst: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
  14. Verfahren nach Anspruch 13, wobei ferner der Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zugeordnet wird.
  15. Verfahren nach einem der Ansprüche 13 bis 14, welches ferner Folgendes aufweist: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
DE102020129195.7A 2019-12-20 2020-11-05 Vereinheitlichtes programmiermodul für eine funktion-als-ein-dienst-berechnung Pending DE102020129195A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/722,811 US20200137163A1 (en) 2019-12-20 2019-12-20 Unified programming model for function as a service computing
US16/722,811 2019-12-20

Publications (1)

Publication Number Publication Date
DE102020129195A1 true DE102020129195A1 (de) 2021-06-24

Family

ID=70325908

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020129195.7A Pending DE102020129195A1 (de) 2019-12-20 2020-11-05 Vereinheitlichtes programmiermodul für eine funktion-als-ein-dienst-berechnung

Country Status (5)

Country Link
US (1) US20200137163A1 (de)
JP (1) JP2021099782A (de)
KR (1) KR20210080172A (de)
CN (1) CN113010235A (de)
DE (1) DE102020129195A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114830614B (zh) 2019-12-13 2024-06-11 利维帕尔森有限公司 用于双向通信系统的功能即服务云聊天机器人
US20210004276A1 (en) * 2020-09-16 2021-01-07 Intel Corporation Application negotiable resource director technology for efficient platform resource management
BR112023019081A2 (pt) 2021-03-31 2023-10-17 Nippon Steel Corp Chapa de aço elétrico de grão não orientado, e, método e matriz substancialmente colunar para puncionar uma chapa de aço elétrico de grão não orientado
US11770455B2 (en) * 2021-12-14 2023-09-26 Cognizant Technology Solutions India Pvt. Ltd. System and method for application migration between cloud platforms
CN117112074B (zh) * 2023-06-19 2024-03-12 领悦数字信息技术有限公司 将http应用自动转换成无服务器函数的方法、系统和介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8190675B2 (en) * 2010-02-11 2012-05-29 Inditto, Llc Method and system for providing access to remotely hosted services through a normalized application programming interface

Also Published As

Publication number Publication date
CN113010235A (zh) 2021-06-22
US20200137163A1 (en) 2020-04-30
KR20210080172A (ko) 2021-06-30
JP2021099782A (ja) 2021-07-01

Similar Documents

Publication Publication Date Title
DE102020129195A1 (de) Vereinheitlichtes programmiermodul für eine funktion-als-ein-dienst-berechnung
DE102020132716A1 (de) System zum analysieren und verbessern von software auf der basis von graph attention netzen
DE102018130631A1 (de) Hierarchische Spracherkennungsauflösung
DE102020132559A1 (de) Technologie zum anwenden von fahrnormen zur verhaltensvoritersage automatisierter fahrzeuge
DE102004038649B4 (de) Dauerspeichervorrichtung für Sicherungsprozess-Prüfpunktzustände
DE102020120372A1 (de) Programmierbare wandlungshardware
DE112008002634T5 (de) Gerät, System und Verfahren zur systemübergreifenden Proxy-basierten Aufgabenentlastung
DE102018006015A1 (de) Globale und lokale Zeitschrittbestimmungsschemata für neuronale Netzwerke
DE102020113480A1 (de) Zerlegte gleitkomma-multiplikation
DE102020131901A1 (de) Vorrichtung und verfahren zum durchführen nicht lokaler mittelwertfilterung unter verwendung eines bewegungsschätzschaltkreises eines grafikprozessors
DE102020130536A1 (de) Adaptiver Eintritt in und adaptives Verlassen von Niedrigenergiezuständen
DE102020134018A1 (de) Technologie zum ermöglichen sicherer und belastbarer wiederherstellung von firmware-daten
DE112018001088T5 (de) Anwendung von framing-regeln für eine hochgeschwindigkeitsdatenverbindung
DE112017005063T5 (de) Verwalten eines Speichers mit niedrigstem Kohärenzpunkt (LPC) mithilfe eines Dienstschichtadapters
DE202022002976U1 (de) Skalierbares System-on-a-Chip
DE102022107473A1 (de) Technologie für speichereffiziente und parametereffiziente graphneural networks
DE102022124292A1 (de) Analoge multiply-accumulate-einheit für speicherinterne multibit-zellenberechnung
EP3866003A1 (de) Anwendung von bios zum betriebssystemdatenaustausch
DE102017124078A1 (de) Ordinale modifikation der dienstgüte
DE102018214008A1 (de) Dynamische Plattformmerkmaleinstellung basierend auf Laufzeiterfordernissen virtueller Maschinen
DE102018132807A1 (de) Anwendungsprozessor, elektronischer Fahrzeugprozessor und Berechnungsvorrichtung mit Anwendungsprozessor
DE102022107196A1 (de) Sichere direkte Peer-to-Peer-Speicherzugriffsanforderung zwischen Geräten
DE102020130528A1 (de) Technik für automatisches Lernen, um Computeranweisungen für heterogene Systeme zu partitionieren
DE102022107480A1 (de) Verfahren und einrichtungen zum implementieren paralleler architekturen für neuronale netzwerkklassifikatoren
DE102020134345A1 (de) Technologie zum lernen und abladen häufiger speicherzugriffs- und rechenmuster