ES2904537T3 - Procedimiento y dispositivo para la ejecución acelerada de aplicaciones - Google Patents

Procedimiento y dispositivo para la ejecución acelerada de aplicaciones Download PDF

Info

Publication number
ES2904537T3
ES2904537T3 ES16790566T ES16790566T ES2904537T3 ES 2904537 T3 ES2904537 T3 ES 2904537T3 ES 16790566 T ES16790566 T ES 16790566T ES 16790566 T ES16790566 T ES 16790566T ES 2904537 T3 ES2904537 T3 ES 2904537T3
Authority
ES
Spain
Prior art keywords
data
application
order
execution
data parts
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.)
Active
Application number
ES16790566T
Other languages
English (en)
Inventor
Sixten Boeck
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.)
DACS Laboratories GmbH
Original Assignee
DACS Laboratories GmbH
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 DACS Laboratories GmbH filed Critical DACS Laboratories GmbH
Application granted granted Critical
Publication of ES2904537T3 publication Critical patent/ES2904537T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44578—Preparing or optimising for loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/1724—Details of de-fragmentation performed by the file system

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)
  • Debugging And Monitoring (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Procedimiento para ejecutar una aplicación interactiva, en la que el usuario influye en el flujo de programa, llevado a cabo por al menos una instalación de procesamiento de datos, comprendiendo el procedimiento: - facilitar (790) partes de datos requeridas para la ejecución de la aplicación desde una memoria de datos, en donde las partes de datos están almacenadas en la memoria de datos en un orden físico por áreas o por completo basándose en un orden cronológico requerido esperado, de tal modo que, cuando se lee una parte de datos solicitada desde la memoria de datos, se logra una precarga de partes de datos, al leerse en una etapa también partes de datos físicamente adyacentes, y en donde el orden cronológico requerido esperado se basa en una combinación de varios órdenes cronológicos requeridos adquiridos durante la ejecución de la aplicación.

Description

DESCRIPCIÓN
Procedimiento y dispositivo para la ejecución acelerada de aplicaciones
Campo de la invención
La presente invención, de acuerdo con un primer aspecto, se refiere a un procedimiento para ejecutar una aplicación. De acuerdo con un segundo aspecto, la invención se refiere a un procedimiento para enviar partes de datos. De acuerdo con un tercer aspecto la invención se refiere a un procedimiento para almacenar partes de datos. De acuerdo con aspectos adicionales la invención se refiere además a dispositivos y programas informáticos.
Antecedentes de la invención
Los procedimientos de tipo genérico citados al principio, en particular procedimientos para ejecutar una aplicación se conocen por el estado de la técnica.
Durante la operación de inicio de una aplicación pueden transcurrir muchos segundos o minutos o, en el caso de que la aplicación solo tenga que descargarse desde un servidor remoto a través de una red como Internet, pueden transcurrir incluso horas, hasta que la aplicación finalmente pueda utilizarse de manera interactiva por un usuario. Por regla general, sin embargo, el usuario desea emplear lo más inmediatamente posible la aplicación seleccionada, es decir, la operación de inicio debe ser lo más breve posible.
A esto se añade que recientemente deben transmitirse aplicaciones ejecutables con cada vez más frecuencia, dado que estas ya no se distribuyen sobre un soporte de datos, sino a través de una red, por ejemplo Internet. Para lograr también en este caso un tiempo breve hasta el inicio de la aplicación, se han seguido distintos planteamientos.
Como ejemplo puede emplearse el denominado "video streaming" (video de flujo continuo), en el que la aplicación se ejecuta en un servidor y solo se transmite un flujo de audio y de vídeo a un cliente, en el que debe utilizarse la aplicación.
No obstante, lo desventajoso de esto es que eventualmente el periodo de latencia sea demasiado grande, para permitir un uso de la aplicación satisfactorio y en particular fluido en el cliente situado en remoto con respecto al servidor. Por ejemplo, el ancho de banda puede no ser suficiente, o pueden aparecer periodos de latencia de hasta varios cientos de milisegundos, en particular en transmisiones a través del Internet. Además, es necesaria una transmisión duradera de datos en forma de un flujo de audio y/o de vídeo, de modo que el cliente debe estar permanentemente conectado.
Para tratar en particular estas desventajas, se emplea el denominado flujo continuo de aplicaciones "applicationstreaming', por lo que se pone a disposición de un cliente una aplicación a demanda ("on-demand') desde un servidor. Sin embargo, la aplicación no se ejecuta en el servidor como en el descrito "video streaming' y solo se transmiten datos de audio y/o de vídeo al cliente, sino que la aplicación en sí se transmite y se ejecuta localmente mediante el cliente. Al ejecutarse la aplicación localmente en el cliente, no es requerido diseñar el rendimiento del servidor para la ejecución de la aplicación. Además, los periodos de latencia elevados no son problemáticos o son incluso irrelevantes.
Por lo tanto, si la aplicación debe descargarse solo por un servidor remoto a través de una red, como, por ejemplo Internet, pueden transcurrir incluso muchas horas, hasta que la aplicación finalmente pueda utilizarse de manera interactiva por un usuario.
Para tratar en particular esta desventaja, por el estado de la técnica se conoce por ejemplo el acortar el tiempo requerido para la descarga e instalación de la aplicación, de modo que al fin y al cabo el tiempo hasta el inicio de la aplicación se reduce. Para ello pueden descargarse, por ejemplo, bloques de un título de software hasta alcanzar un umbral ejecutable. Entonces puede ejecutarse el título de software y la descarga de bloques adicionales del título de software puede continuar, mientras que el título de software se ejecuta.
Aunque gracias a esto el tiempo antes y hasta el inicio de una aplicación puede reducirse, en particular cuando la aplicación debe descargarse por un servidor remoto. Sin embargo, al fin y al cabo la aplicación después de la descarga (parcial) como es habitual se almacena en una memoria local del usuario, por ejemplo de su disco duro. En este aspecto, la operación de inicio propiamente dicha de la aplicación se realizaría entonces en el mejor de los casos con la misma rapidez que en una aplicación instalada localmente. Es decir, también en este caso el inicio de la aplicación, aunque los datos requeridos ya están presentes localmente, requiere de nuevo segundos o minutos, hasta que el usuario pueda utilizar la aplicación de forma interactiva.
Sin embargo, tal como se exponen al principio, existe un interés en reducir no solo el tiempo hasta el inicio de la aplicación, sino también en acelerar la ejecución en sí y en particular el inicio en sí. En el caso de juegos de ordenador con frecuencia se distrae a los usuarios o jugadores durante el inicio del juego de ordenador por ejemplo mediante secuencias de vídeo, hasta que el juego de ordenador puede jugarse finalmente. En este aspecto es deseable un acortamiento también del inicio de aplicación en sí. Esto se cumple del mismo modo para otras aplicaciones. Por lo demás esto se cumple tanto para aplicaciones, que se facilitan al usuario en el marco de un flujo continuo de aplicaciones, como para aplicaciones, que se ponen a disposición del usuario ya localmente.
En el documento US 2010/011323 A1 se describe un procedimiento para la desfragmentación. Mediante una desfragmentación se reorganizan físicamente ficheros, de modo que las partes de software se almacenan de tal modo que se realiza una reunión física de partes de datos lógicamente correspondientes. La cuestión de qué datos están agrupados a este respecto y en qué ficheros, no expresa nada sobre el momento y las partes de datos de un fichero que se necesitan en el inicio de una aplicación.
Descripción de algunos diseños a modo de ejemplo de la presente invención
Por lo tanto un objetivo de la invención es dar a conocer procedimientos, dispositivos y programas informáticos de tipo genérico, en donde debe hacerse posible acelerar la ejecución, en particular el inicio de la aplicación.
De acuerdo con un primer aspecto, la invención se refiere a un procedimiento para ejecutar una aplicación, llevado a cabo por al menos un dispositivo, de acuerdo con la reivindicación 1.
La invención aprovecha el hecho de que, cuando se facilitan partes de datos desde una memoria de datos, las partes de datos están almacenadas en la memoria de datos en un orden determinado, concretamente en un orden al menos por áreas basándose en un orden requerido esperado. Gracias a esto se logra que las partes de datos requeridas de la aplicación pueden estar a disposición regularmente con más rapidez de lo habitual, y en particular el proceso del inicio de aplicación - independientemente de si el programa ya está instalado localmente o de si inicialmente debe descargarse de un servidor en remoto- puede acelerarse drásticamente. Por lo tanto, en particular, se facilita un procedimiento para la ejecución acelerada de una aplicación.
La memoria de datos puede estar disponible a este respecto por ejemplo mediante un disco duro, un disco de estado sólido (SSD, solid state disk), una memoria principal (RAM) o una disquetera externa, por nombrar solo algunos ejemplos.
En cambio, si una aplicación de manera convencional se almacena en una memoria (por ejemplo un disco duro), entonces el orden de las partes de datos individuales en la memoria, por ejemplo, depende de la asociación de los ficheros o de la estructura de carpetas. A esto se añade que las partes de datos a menudo se presentan en una forma fragmentada, lo que ralentiza por lo demás la ejecución de la aplicación. Sobre todo, la fragmentación puede deberse sobre todo al sistema de ficheros en sí empleados. La mayoría de los sistemas de ficheros están desarrollados de modo que puede lograrse un rendimiento total óptimo, lo que lleva a que las partes de datos que pertenecen a una aplicación se fragmenten en el transcurso del tiempo en la memoria de datos.
Si bien, los sistemas de ficheros modernos pueden minimizar este efecto durante el funcionamiento, sin embargo, no obstante, el orden de las partes de datos de ficheros individuales sigue rompiéndose. Independientemente de los diferentes mecanismos de acceso físicos de memorias de datos disponibles, es decir, sin importar si se trata, por ejemplo, de un disco duro con ejes giratorios, un disco de estado sólido (SSD, solid state disk), o una memoria principal (RAM), sin embargo, el acceso directo (también llamado en inglés "random access" o acceso mediante saltos precisos, llamados en inglés "seek operations") es comparativamente lento.
La invención permite ahora por ello que las partes de datos estén almacenadas en la memoria de datos en un orden al menos por áreas basándose en un orden requerido esperado, y se ponen a disposición las partes de datos de manera similar a un flujo continuo en una operación de flujo continuo. Si la memoria de datos es, por ejemplo, un disco duro con un eje rotatorio, por regla general se leen todas las partes de datos, que se encuentran en la misma pista, como una parte de datos solicitada, dado que estas pasan en todo caso por el cabezal de escritura/ lectura. No surge por tanto ningún retardo adicional mediante la lectura de partes de datos adicionales en la misma pista. Si estas se solicitaran a continuación, están listas directamente. En este aspecto se logra una precarga de las partes de datos ("data-prefetching'). Si la memoria de datos, por ejemplo, una memoria de datos se basa en un cuerpo sólido (por ejemplo SSD, RAM) por regla general se lee en una etapa se lee un lado de memoria global ("memory page") en lugar de solo la parte de datos pedida. Por ello una memoria intermedia ("caché") también contiene las partes de datos almacenadas de manera adyacente. Si poco tiempo después se pide la siguiente parte de datos requerida, esta ya está disponible en la memoria intermedia. También en este caso se alcanza una carga previa de las partes de datos. Finalmente este procedimiento puede ser ventajoso también en la comunicación a través de una red, dado que en distancias mayores (con muchos "saltos ") el tiempo de circulación de paquete puede ascender a algunos cientos de milisegundos y la solicitud de partes de datos individuales puede tener una larga duración en correspondencia.
Esta aplicación puede ser en particular un programa informático, que se utiliza para tratar, respaldar o facilitar un funcionalidad útil o deseada no con la tecnología de sistemas. Básicamente es concebible que la aplicación pueda servir para el tratamiento de imágenes, tratamiento de vídeo, tratamiento de textos, hojas de cálculo puede y/o pueda facilitar determinadas funciones operativas como contabilidad financiera, gestión de clientes, etc. La aplicación se ejecuta al menos parcialmente en el espacio de usuario. De manera especialmente preferente la aplicación es o comprende un juego de ordenador o una parte del mismo. El procedimiento puede comprender también la etapa de la ejecución de la aplicación.
Para el aumento adicional de la productividad el procedimiento se lleva a cabo preferentemente (al menos parcialmente) en el espacio del kernel.
Para ejecución de la aplicación, la aplicación puede comprender por ejemplo uno o varios ficheros ejecutables. En este sentido puede tratarse, por ejemplo, de un fichero binario en lenguaje de máquina o de un fichero de código de bytes, que puede ejecutarse directamente o mediante un sistema de tiempo de ejecución, o de un fichero de texto, que puede interpretarse por un intérprete de comandos del sistema operativo. Las partes de datos pueden ser en particular partes de datos del fichero ejecutable.
Por las partes de datos requeridas para la ejecución de la aplicación pueden entenderse en particular partes de datos requeridas forzosamente y/u opcionalmente.
El hecho de que el orden en el que las partes de datos están almacenadas en la memoria de datos, se base en un orden requerido esperado, significa en particular que el orden (físico), en el que las partes de datos están almacenadas en la memoria de datos, se ha determinado a partir del orden (cronológico) requerido esperado. Por ejemplo, el orden, en el que las partes de datos están almacenadas en la memoria de datos, es el orden requerido esperado. El hecho de que esto se realice al menos por áreas, significa en particular que las partes de datos requeridas en la memoria de datos para la ejecución de la aplicación pueden almacenarse parcialmente también de manera clásica, es decir, pueden estar almacenadas independientemente del orden requerido esperado.
Por un orden requerido esperado se entiende en este sentido en particular que puede esperarse que la aplicación requiera las partes de datos en el orden. En otras palabras, las partes de datos están almacenadas en particular físicamente en un orden, que reproduce la demanda cronológico de las partes de datos para la aplicación. El orden requerido esperado puede determinarse en particular empíricamente. En particular el orden requerido esperado, puede determinarse como se describe con más detalle con respecto al tercer aspecto de la invención.
No tienen que estar almacenadas forzosamente todas las partes de datos requeridas para la ejecución de la aplicación como se ha descrito. Por ejemplo, puede estar almacenada también solo una parte de las partes de datos requeridas para la ejecución de la aplicación en un orden al menos por áreas sobre la base de un orden requerido esperado.
El procedimiento de acuerdo con el primer aspecto puede realizarse en particular por al menos un primer dispositivo, que se describe con más detalle en el marco de aspectos adicionales.
De acuerdo con un diseño del procedimiento del primer aspecto el procedimiento comprende por lo demás:
- solicitar las partes de datos requeridas para la ejecución de la aplicación.
La solicitud puede realizarse, por ejemplo, mediante la aplicación, mediante un sistema operativo y/o un sistema de ficheros. Por ejemplo, la aplicación necesita una parte de datos para la ejecución y la pasa al sistema de ficheros. La solicitud puede realizarse por ejemplo al transmitirse un direccionamiento (relativo y/o absoluto), que identifica unívocamente la parte de datos en la memoria de datos. El direccionamiento puede denominar, por ejemplo, una posición de la parte de datos en la memoria de datos (por ejemplo en forma de una dirección de memoria o de un valor de desplazamiento de memoria). Por ejemplo, el direccionamiento puede denominar una área que comprende varias partes de datos en la memoria de datos. Basándose en el direccionamiento entonces (al menos) la parte de datos necesaria se lee y se facilita, por ejemplo se devuelve a la aplicación, el sistema de ficheros y/o el sistema operativo. Como se ha expuesto al principio, por regla general no se lee solo la parte de datos pedida sino que se leen también otras, partes de datos físicamente adyacentes. En un caso óptimo, la parte de datos necesaria ya no debe leerse desde la memoria de datos, sino que se ha leído ya debido a una solicitud anterior de otra parte de datos desde la memoria de datos y por consiguiente, por ejemplo, ya está disponible en una memoria intermedia más rápida. Por consiguiente, la parte de datos respondiendo a una solicitud puede facilitarse con el procedimiento descrito de una manera claramente más rápida.
De acuerdo con un diseño del procedimiento del primer aspecto el procedimiento comprende por lo demás:
- representación gráfica de un direccionamiento empleado para la solicitud de las partes de datos requeridas para la ejecución de la aplicación en el orden de las partes de datos almacenadas en la memoria de datos.
Mediante una representación gráfica del direccionamiento empleado para la solicitud el direccionamiento puede realizarse (por ejemplo en el plano del sistema de ficheros) como habitualmente. Es decir, las partes de datos requeridas pueden pedirse por medio del direccionamiento original, como si se realizara por ejemplo, después de una instalación habitual de la aplicación. En particular el direccionamiento empleado para la solicitud puede ser un primer direccionamiento, que se representa ( 'mapping').en un segundo direccionamiento. Por ejemplo, se representa una dirección de memoria pedida o una primera área de dirección de memoria en una segunda dirección de memoria o una segunda área de dirección de memoria. Por ejemplo, se representa gráficamente un primer número de bloque o una primera área de número de bloque (o varias áreas) en un segundo número de bloque o una segunda área de número de bloque (o varias áreas). La representación gráfica es preferentemente unívoca, en particular biunívoca.
De acuerdo con un diseño del procedimiento del primer aspecto la representación gráfica del direccionamiento empleado se realiza por debajo de la capa del sistema de ficheros.
En general, el sistema de ficheros simboliza una capa determinada del sistema operativo. Las capas por encima (por ejemplo capas adicionales del sistema operativo o aplicaciones) pueden acceder a ficheros. Mediante el sistema de ficheros estos datos abstractos se convierten por regla general en un direccionamiento (por ejemplo un número de bloque, pista, sector o similar). En la capa subyacente el controlador de sistema de datos puede comunicar para ello por ejemplo con un controlador de dispositivo responsable.
Al realizarse ahora la representación gráfica del direccionamiento empleado por debajo de la capa del sistema de ficheros, la representación gráfica puede llevarse a cabo de manera muy eficaz. Si las partes de datos requeridas por ejemplo de la capa del sistema de ficheros (o una capa dispuesta por encima) el sistema de ficheros puede direccionar las partes de datos de manera habitual, de modo que puede renunciarse a adaptaciones al plano del sistema de ficheros o superior. Por ejemplo, la representación se realiza gráfica mediante un controlador de dispositivo. Por lo tanto, la representación gráfica se realiza preferentemente en una capa asociada a controladores de dispositivo.
Por lo tanto, la facilitación de partes de datos requeridas para la ejecución de la aplicación puede realizarse en particular desde una capa asociada a controladores de dispositivo en una capa situada por encima.
De acuerdo con un diseño del procedimiento del primer aspecto el procedimiento comprende por lo demás:
- recibir las partes de datos requeridas para la ejecución de la aplicación.
Es posible que las partes de datos requeridas para la ejecución de la aplicación durante la ejecución de la aplicación todavía no estén almacenadas, o al menos solo parcialmente en la memoria de datos. Entonces las partes de datos restantes pueden recibirse por completo o parcialmente. Las partes de datos pueden recibirse, por ejemplo, por otra memoria de datos local o en remoto. Por ejemplo, las partes de datos se reciben a través de una red, por ejemplo a través de Internet. Preferentemente las partes de datos se reciben por un servidor remoto a través de Internet.
Si por ejemplo se constata que las partes de datos requeridas pedidas no están almacenadas en la memoria de datos, estas partes de datos (por ejemplo en el servidor remoto) pueden pedirse, para recibir estas. Sin embargo, preferentemente no es necesaria una solicitud individual de partes de datos requeridas y todavía no almacenadas en la memoria de datos, dado que las partes de datos se reciben preferentemente de manera continua. Es decir, las partes de datos se reciben paulatinamente de manera similar a un flujo, sin que tengan que pedirse partes de datos individuales. Esto acelera además la ejecución de la aplicación. Si, por ejemplo, se constata por otro lado que ya están almacenadas partes de datos requeridas en la memoria de datos o no se necesitan momentáneamente, la recepción continua descrita también (al menos parcialmente) puede omitirse para las partes de datos ya almacenadas o no requeridas (momentáneamente). Estas partes de datos pueden recibirse entonces, por ejemplo, en un momento posterior.
Las partes de datos pueden recibirse preferentemente (al menos parcialmente) en el orden al menos por áreas basándose en el orden requerido esperado. De este modo, las partes de datos requeridas primeramente de acuerdo con lo esperado se reciben también inicialmente. Esto es ventajoso en particular, cuando las partes de datos requeridas (en particular partes de datos requeridas para el inicio de la aplicación) deben recibirse solo por un servidor remoto.
Las partes de datos requeridas para la ejecución de la aplicación pueden recibirse en particular por al menos un segundo dispositivo, que se describe con más detalle en el marco de aspectos adicionales.
De acuerdo con un diseño del procedimiento del primer aspecto el procedimiento comprende por lo demás:
- almacenar las partes de datos en una memoria de datos en el orden al menos por áreas basándose en el orden requerido esperado.
Si las partes de datos requeridas todavía no están almacenadas en la memoria de datos, por ejemplo porque estas deben recibirse primero, estas se almacenan preferentemente después de la recepción en la memoria de datos. Al realizarse el almacenamiento en el orden al menos por áreas basándose en el orden requerido esperado, como ya se ha representado se logra una ejecución de la aplicación acelerada.
De acuerdo con un diseño del procedimiento del primer aspecto las partes de datos son bloques de datos y/o secuencias de bloques de datos y el orden es un orden de bloques.
Se ha mostrado que una aceleración de la ejecución de la aplicación puede lograrse de manera especialmente eficaz, cuando en la memoria de datos están almacenados bloques de datos en un orden de bloques al menos por áreas basándose en un orden de bloques requeridos esperado. El orden de bloques puede especificar por ejemplo el orden de bloques de datos o secuencias de bloques de datos individuales.
Se considera un bloque de datos ("data block") en particular un número de bytes limitado, establecido. Un bloque de datos puede interpretarse como unidad de transporte individual o como unidad más pequeña que puede leerse o escribirse en un acceso. La estructura de un bloque de datos y los elementos de un bloque de datos pueden depender de la memoria de datos respectiva, sistema de ficheros o factores adicionales.
Un bloque de datos puede tener por ejemplo un tamaño de 512 bytes a 4096 bytes. Sin embargo, básicamente también son concebibles bloques de datos más pequeños y en particular más grandes. En general cada bloque de datos puede direccionarse unívocamente en la memoria de datos. Esto puede realizarse a través de diferentes procedimientos. Por ejemplo, un direccionamiento de los bloques de datos puede realizarse a través de bloques numerados (LBA) continuamente. Asimismo es concebible (en el caso de discos duros con ejes), direccionar bloques a través de números de cilindro, de cabeza y de sector (CHS). También son concebibles otros métodos de direccionamiento de los bloques de datos.
En una realización del procedimiento de acuerdo con el primer aspecto basándose en bloques de datos y un orden de bloques es especialmente ventajoso además que por ello se logra una compatibilidad elevada con prácticamente todos los sistemas operativos. La funcionalidad propiamente dicha puede implementarse de forma práctica independientemente de la plataforma. Debe lograrse por ejemplo únicamente una adaptación del controlador de dispositivo correspondiente al modo de funcionamiento del dispositivo de bloque (virtual) correspondiente en el sistema operativo respectivo.
De acuerdo con un diseño del procedimiento del primer aspecto las partes de datos están almacenadas en un dispositivo de bloque, en particular un dispositivo de bloque virtual.
Mediante el uso de un dispositivo de bloque (virtual) puede ponerse a disposición una memoria de datos y lograrse el orden deseado de las partes de datos en forma de bloques de datos. Por un dispositivo de bloque (virtual) o dispositivo ("block device") orientado en bloques se entiende un dispositivo (virtual), que almacena o transmite datos en bloques de datos. Un dispositivo de bloque puede utilizar en particular la memoria intermedia adecuada para el sistema operativo. Un dispositivo de bloque puede ser en particular un disco duro, un SSD, un lápiz USB o similar. Mediante un dispositivo de bloque virtual prácticamente se simula al sistema operativo que está presente un dispositivo de bloque y puede comunicar o comunica con el sistema operativo. En particular es ventajoso un dispositivo de bloque virtual, dado que este puede ponerse a disposición en cada sistema, en el lado del software, en particular mediante un controlador de dispositivo. La memoria de datos física puede facilitarse en el caso, por ejemplo, mediante una parte de la memoria de datos de un disco duro local.
Al controlador de dispositivo puede estar asignada o facilitarse ventajosamente una memoria intermedia propia ("caché") en particular en el espacio del kernel. Esto acelera la facilitación de bloques de datos adicionalmente.
A este respecto, el procedimiento del primer aspecto comprende preferentemente por lo demás: integración ("mounten") del dispositivo de bloque en un sistema de ficheros existente. Gracias a esto pueden ponerse a disposición de un sistema operativo los datos almacenados en el dispositivo de bloque o en el sistema de ficheros situado por encima. En el caso de un dispositivo de bloque virtual los datos están almacenados, por ejemplo, en una imagen ("image").
De acuerdo con un diseño del procedimiento del primer aspecto para facilitar las partes de datos requeridas para la ejecución de la aplicación desde la memoria de datos se emplea un controlador de dispositivo, preferentemente un controlador de dispositivo de bloque. El controlador de dispositivo es preferentemente un controlador de dispositivo para un dispositivo de bloque virtual.
Por un controlador de dispositivo se entiende en particular un programa informático o módulo de software, que controla la interacción con dispositivos (virtuales). Para ello el controlador de dispositivo en uno de los lados puede comunicar, por ejemplo, directamente con el dispositivo (virtual) e intercambiar datos con el dispositivo (virtual). Por otro lado, el controlador de dispositivo puede ofrecer una interfaz estandarizada, por ejemplo, al sistema operativo y/o al software de aplicación (es decir, en particular capas, que están situadas por encima de la capa asociada el controlador de dispositivo), de modo que puede accederse al dispositivo (virtual) del mismo modo que dispositivos del mismo tipo.
A este respecto, el procedimiento del primer aspecto comprende preferentemente por lo demás: instalación de un controlador de dispositivo para facilitar las partes de datos requeridas para la ejecución de la aplicación desde la memoria de datos. Por ejemplo, la instalación se inicia mediante un usuario. A continuación el dispositivo (virtual) puede integrarse en un sistema de ficheros existente. Mediante el dispositivo (virtual) puede accederse finalmente a la memoria de datos y la aplicación puede ejecutarse.
De acuerdo con un diseño del procedimiento del primer aspecto el procedimiento comprende por lo demás: - suspender un tratamiento de una cola de eventos, en particular en el caso de que las partes de datos requeridas no estén disponibles en la memoria de datos; y
- reanudar el tratamiento de la cola de eventos.
Una cola de eventos puede comprender en particular operaciones (en particular operaciones de escritura y/o de lectura), que deben aplicarse en la memoria de datos.
Por ejemplo, para el caso de que partes de datos requeridas pedidas (todavía) no estén almacenadas en la memoria de datos y por consiguiente no estén disponibles, puede ser ventajoso suspender el tratamiento de una cola de eventos, para evitar un comportamiento incorrecto de la aplicación. Es especialmente ventajoso cuando la cola de eventos es la cola de eventos ("event-queue") de un controlador de dispositivo o dispositivo (virtual) anteriormente descrito. Después, la suspensión puede realizarse por ejemplo mediante el controlador de dispositivo. Sin embargo, fundamentalmente es posible también suspender la cola de eventos de un controlador de dispositivo mediante un comando externo(del sistema operativo o de un programa). A este respecto puede aprovecharse ventajosamente el hecho de que capas situadas por encima de la capa asociada al controlador de dispositivo, como por ejemplo el sistema de ficheros, esperen al controlador de dispositivo. Por lo tanto, si las partes de datos no están disponibles, prácticamente es como si una lectura lenta por parte del dispositivo (virtual) provocara un retardo.
Por ejemplo, el tratamiento de la cola de eventos se suspende durante un tiempo predeterminado. Por ejemplo, el tiempo, durante el cual se suspende el tratamiento de la cola de eventos, se determina (por ejemplo se calcula o se estima). Si las partes de datos se reciben, por ejemplo, a través de una red, puede determinarse por ejemplo mediante la velocidad de transmisión, cuándo pueden recibirse las partes de datos requeridas (previsiblemente) y almacenarse en la memoria de datos y por consiguiente facilitarse.
A continuación puede comprobarse si las partes de datos están disponibles. Si las partes de datos están disponibles, el tratamiento de la cola de sucesos puede reanudarse. En caso contrario, puede realizarse de nuevo una suspensión del tratamiento de la cola de eventos.
De acuerdo con un diseño del procedimiento del primer aspecto las partes de datos están almacenadas en la memoria de datos al menos con respecto a partes de datos relevantes para el inicio de aplicaciones en un orden al menos por áreas basándose en un orden requerido esperado.
Por partes de datos relevantes para el inicio de aplicaciones se entienden partes de datos, que son relevantes para el inicio de la aplicación. Por ejemplo, las partes de datos relevantes para el inicio de las aplicaciones, son aquellas partes de datos, que se necesitan para la ejecución de la aplicación en una medida tal que la aplicación pueda utilizarse de manera interactiva por el usuario. Por ejemplo, las partes de datos relevantes para el inicio de aplicaciones son más del 10 % y/o menos del 50 megabytes de toda la aplicación. Esto puede acelerar en particular el inicio en la ejecución de la aplicación.
Independientemente de esto, sin embargo también es naturalmente posible almacenar partes de datos, que no se necesitan directamente para el inicio de la aplicación (sino solo hasta más tarde), en un orden al menos por áreas basándose en un orden requerido esperado.
Por ejemplo también es concebible que esté prevista una primera cantidad de partes de datos de la aplicación, en la que las partes de datos están almacenadas basándose en el orden requerido esperado, y está prevista una segunda cantidad de partes de datos de la aplicación, en la que las partes de datos no están almacenadas basándose en, sino independientemente del orden requerido esperado. La primera cantidad puede comprender entonces por ejemplo partes de datos relevantes para el inicio de aplicaciones, de modo que se hace posible una ejecución rápida, mientras que el orden de las partes de datos en la segunda cantidad no necesita optimizarse.
De acuerdo con un diseño del procedimiento del primer aspecto el procedimiento comprende por lo demás:
- emplear informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación.
Por informaciones de metadatos se entienden en particular informaciones específicas de cada aplicación, que se necesitan (al menos parcialmente) para la ejecución de la aplicación. Por ejemplo, las informaciones de metadatos comprenden modificaciones, que se han realizado durante la instalación y/o la ejecución de la aplicación en el sistema que ejecuta la aplicación (por ejemplo sistema operativo y/o sistema de ficheros). Por ejemplo, las informaciones de metadatos comprenden informaciones de ruta, informaciones de ficheros, informaciones de carpetas, informaciones sobre variables de entorno y/o informaciones sobre bancos de datos (por ejemplo bancos de datos de registro) o modificaciones en estas (por ejemplo, nuevas entradas). También otras dependencias pueden estar comprendidas en las informaciones de metadatos.
Asimismo las informaciones de metadatos pueden comprender informaciones de representación gráfica, que permiten la representación gráfica del direccionamiento empleado para la solicitud de las partes de datos requeridas para la ejecución de la aplicación en el orden de las partes de datos almacenadas en la memoria de datos. Sin embargo, las informaciones de representación gráfica pueden transmitirse también independientemente de las informaciones de metadatos.
De acuerdo con un segundo aspecto la invención se refiere también a un procedimiento para enviar partes de datos, en particular para el uso en un procedimiento de acuerdo con el primer aspecto, llevado a cabo por al menos un dispositivo, de acuerdo con la reivindicación 8.
Como ya se ha expuesto con respecto a al primer aspecto, puede lograse por ello que las partes de datos estén almacenadas en una memoria de datos en un orden al menos por áreas basándose en un orden requerido esperado, que las partes de datos requeridas de la aplicación puedan estar a disposición regularmente con más rapidez de lo habitual, y en particular el proceso del inicio de aplicación pueda acelerarse drásticamente.
El procedimiento de acuerdo con el segundo aspecto puede comprender en particular al menos un segundo dispositivo, que se describe con más detalle en el marco de aspectos adicionales.
Las partes de datos pueden enviarse por ejemplo a un primer dispositivo, que ejecuta un procedimiento de acuerdo con el primer aspecto. Por ejemplo, las partes de datos están almacenadas en al menos un fichero, por ejemplo una imagen ("mage"). Es decir, únicamente debe enviarse la imagen. Cuando las partes de datos enviadas se reciben y almacenan, estas se almacenan ventajosamente en el receptor de manera automática en una memoria de datos directamente en un orden al menos por áreas basándose en un orden requerido esperado.
En el marco del tercer aspecto de la invención se describe cómo puede determinarse un orden de este tipo.
De acuerdo con un diseño del procedimiento del segundo aspecto las partes de datos se envían al menos parcialmente en el orden almacenado.
Al enviarse las partes de datos al menos parcialmente en el orden almacenado, las partes de datos requeridas se envían en primer lugar de acuerdo con lo esperado y pueden recibirse en primer lugar. Por ello, en particular en una situación, en la que las partes de datos requeridas (en particular partes de datos requeridas para el inicio de la aplicación) todavía deben recibirse (por ejemplo por el primer dispositivo), puede reducirse también el tiempo hasta el inicio de la aplicación.
De acuerdo con un diseño del procedimiento del segundo aspecto el procedimiento comprende por lo demás:
- recibir una solicitud de envío de al menos una parte de las partes de datos requeridas para la ejecución de la aplicación.
Si por ejemplo mediante el primer dispositivo se constata que las partes de datos requeridas no están almacenadas en la memoria de datos en este, estas partes de datos puede pedirse, para recibir estas. La solicitud de envío de las partes de datos puede recibirse en el marco del procedimiento del segundo aspecto, por ejemplo mediante un segundo dispositivo.
Es concebible que con la solicitud de envío se pidan partes de datos o áreas individuales de partes de datos. Preferentemente, sin embargo no es necesaria una solicitud individual de partes de datos requeridas, dado que las partes de datos se envían preferentemente de manera continua. Es decir, las partes de datos se envían paulatinamente de manera similar a un flujo, sin que tenga que recibirse la solicitud con respecto a partes de datos individuales. Esto acelera la recepción y con ello la ejecución de la aplicación por lo demás.
De acuerdo con un diseño del procedimiento del segundo aspecto el procedimiento comprende por lo demás:
- enviar informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación.
Como ya se ha explicado en el marco del primer aspecto, las informaciones de metadatos comprenden por ejemplo informaciones de rutas, informaciones de ficheros, informaciones de carpetas, informaciones sobre variables de entorno y/o informaciones sobre bancos de datos (por ejemplo bancos de datos de registro) o modificaciones en estas (por ejemplo, nuevas entradas). Las informaciones de metadatos pueden estar contenidas por ejemplo asimismo en el al menos un fichero. Asimismo puede estar previsto al menos un fichero independiente, en el que están contenidas las informaciones de metadatos. Las informaciones de metadatos pueden reservarse también en la memoria. Las informaciones de metadatos se envían preferentemente en primer lugar. Por ejemplo, las informaciones de metadatos pueden enviarse en el marco de una operación de transmisión (push) o en el marco de una operación de acceso (pulí).
Asimismo las informaciones de metadatos pueden comprender informaciones de representación gráfica, que permiten la representación gráfica del direccionamiento empleado para la solicitud de las partes de datos requeridas para la ejecución de la aplicación en el orden de las partes de datos almacenadas en la memoria de datos. Sin embargo, las informaciones de representación gráfica pueden transmitirse también independientemente de las informaciones de metadatos.
Con referencia a otros diseños, en particular con vistas al diseño de las partes de datos como bloques de datos se remite a las realizaciones en el marco del primer aspecto.
De acuerdo con un tercer aspecto la invención se refiere también a un procedimiento para el almacenamiento de partes de datos requeridas, llevado a cabo por al menos un dispositivo, de acuerdo con la reivindicación 11.
El procedimiento permite, almacenar las partes de datos requeridas en una memoria de datos en un orden al menos por áreas basándose en el orden requerido esperado.
Al menos basándose en el orden requerido adquirido puede determinarse un orden requerido esperado. Por ejemplo, el orden requerido adquirido se corresponde con el orden requerido esperado. Por ejemplo, el orden requerido adquirido solo es solo uno de varios factores (por ejemplo otros órdenes requeridos adquiridos), para determinar el orden requerido esperado.
Finalmente pueden almacenarse las partes de datos requeridas en una memoria de datos en un orden al menos por áreas basándose en el orden requerido esperado. Como resultado, por consiguiente, las partes de datos están reordenadas en comparación con el orden almacenado original, como se da, por ejemplo, después de una instalación habitual de la aplicación en una memoria de datos. Por consiguiente está disponible una aplicación optimizada. Como ya se ha explicado en el marco del primer aspecto, esto permite que la aplicación pueda ejecutarse ahora de manera acelerada, por ejemplo de acuerdo con el procedimiento del primer aspecto.
Además, pueden almacenarse informaciones de representación gráfica, que permiten una representación gráfica entre el orden almacenado original, como se da, por ejemplo, después de una instalación habitual de la aplicación en una memoria de datos, y el orden reordenado. En otras palabras las informaciones de representación gráfica permiten una representación gráfica del direccionamiento empleado para la solicitud de las partes de datos requeridas para la ejecución de la aplicación en el orden de las partes de datos almacenadas reordenadas en la memoria de datos.
El procedimiento no tiene que llevarse a cabo forzosamente para todas las partes de datos requeridas para la aplicación, puede llevarse a cabo, por ejemplo, también solo para una parte de las partes de datos requeridas.
El procedimiento puede llevarse a cabo en particular por al menos un tercer dispositivo, que se describe con más detalle en el marco de aspectos adicionales.
De acuerdo con un diseño del procedimiento del tercer aspecto el procedimiento comprende además una o varias de las etapas siguientes:
- instalar un controlador de dispositivo, preferentemente un controlador de dispositivo de bloque;
- crear una imagen;
- integrar un dispositivo a través de un controlador de dispositivo, en particular a través del controlador de dispositivo instalado;
- instalar la aplicación, en particular en la imagen creada,
- determinar informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación;
- ejecutar la aplicación;
- adquirir el orden requerido de partes de datos requeridas para la ejecución de una aplicación.
Una o varias de las etapas sirven en particular para la preparación para el registro de un orden requerido de partes de datos requeridas para la ejecución de la aplicación. Una o varias (en particular todas) de las etapas anteriores se llevan a cabo, por ejemplo, en una o varias instalaciones de procesamiento de datos, en particular en un entorno analítico. Por un entorno analítico se entiende en particular una infraestructura técnica-preparatoria, que se utiliza para el análisis de software.
Mediante un controlador de dispositivo, en particular un controlador de dispositivo de bloque, la adquisición de un orden requerido de partes de datos requeridas para la ejecución de la aplicación puede llevarse a cabo de manera especialmente eficiente. Por lo demás puede crearse una imagen ("Image"). Tras la instalación del controlador de dispositivo un dispositivo, en particular un dispositivo de bloque puede integrarse a través del controlador de dispositivo y con ello la imagen en un sistema de ficheros existente. El dispositivo de bloque es a este respecto preferentemente un dispositivo de bloque virtual. A través del controlador de dispositivo puede accederse al dispositivo y por consiguiente a la imagen. A continuación la aplicación puede instalarse en el dispositivo y por consiguiente en la imagen.
Ahora pueden determinarse adicionalmente informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación. Esto puede realizarse, por ejemplo, mediante una comparación del sistema (por ejemplo del sistema operativo y/o sistema de fichero) antes de la instalación y después de la instalación de la aplicación. Asimismo también la realización de modificaciones de sistema en sí mismas (por ejemplo mediante registro de operaciones de lectura y/o de escritura) puede adquirirse. Esto simplifica la ejecución de la aplicación en otros dispositivos (por ejemplo el primer dispositivo). Esto requiere únicamente una imagen de la aplicación ya instalada y las informaciones de metadatos se ponen a disposición, sin que daba realizarse una nueva instalación. Como ya se ha explicado en el marco del primer y segundo aspecto, las informaciones de metadatos comprenden por ejemplo informaciones de rutas, informaciones de ficheros, informaciones de carpetas, informaciones sobre variables de entorno y/o informaciones sobre bancos de datos (por ejemplo bancos de datos de registro) o modificaciones en estas (por ejemplo, nuevas entradas).
A continuación la aplicación puede ejecutarse. Esta aplicación se corresponde con la aplicación que va a ejecutarse de acuerdo con el procedimiento del primer aspecto. En este aspecto se remite a las realizaciones en el marco del primer aspecto. A este respecto, sin embargo las partes de datos requeridas para la aplicación inicialmente (al menos parcialmente) todavía no están almacenadas en un orden al menos por áreas basándose en el orden requerido esperado.
En el marco de la ejecución de la aplicación la aplicación necesitará partes de datos para su ejecución en un cierto orden (cronológico). Para ello, por ejemplo la aplicación, el sistema operativo y/o el sistema de ficheros puede solicitar partes de datos requeridas. Este orden puede registrarse, pudiendo realizarse esto ventajosamente por debajo de plano del sistema de ficheros. Por ejemplo, la adquisición se realiza mediante un controlador de dispositivo. Como ya se ha explicado en el marco del primer aspecto, las partes de datos son preferentemente bloques de datos y el orden es un orden de bloques. Para ello se remite a la ejecución en el marco del primer aspecto.
El orden requerido adquirido de las partes de datos requeridas para la ejecución de la aplicación comprende informaciones registradas sobre operaciones de lectura en las partes de datos requeridas durante la ejecución de la aplicación.
Gracias a ello, la adquisición del orden requerido de las partes de datos requeridas para la ejecución de la aplicación puede realizarse de manera especialmente eficiente. De manera especialmente ventajosa el registro de las informaciones se realiza mediante el controlador de dispositivo. Por ejemplo, se han ampliado operaciones de escritura y/o lectura definidas en el controlador de dispositivo, de modo que estas en cualquier caso permiten un registro de informaciones sobre operaciones de lectura en las partes de datos requeridas durante la ejecución de la aplicación. Un registro de informaciones a través de operaciones de lectura en las partes de datos requeridas puede realizarse por ejemplo al registrar un direccionamiento (relativo o absoluto). Por ejemplo, se genera un fichero de registro (por ejemplo, un fichero log), que contiene las informaciones registradas.
De acuerdo con un diseño del procedimiento del tercer aspecto las informaciones registradas permiten una identificación unívoca de la parte de datos necesaria respectiva.
Una identificación unívoca puede lograrse por ejemplo mediante el registro de un direccionamiento inequívoco (relativo y/o absoluto). El direccionamiento puede comprender por ejemplo una posición unívoca de la parte de datos en la memoria de datos (por ejemplo, en forma de una dirección de memoria unívoca o de un valor de desplazamiento de memoria unívoco). Por ejemplo, el direccionamiento puede denominar una área unívoca que comprende varias partes de datos de la memoria. Si las partes de datos son, por ejemplo, bloques de datos, puede registrarse por ejemplo un número de bloque unívoco o un área de número de bloque univoca.
De acuerdo con un diseño del procedimiento del tercer aspecto las informaciones registradas comprenden por lo demás una o varias de las informaciones siguientes:
- informaciones de tiempo;
- eventos específicos de cada aplicación;
- informaciones específicas de cada usuario.
Las informaciones de tiempo pueden comprender por ejemplo informaciones de tiempo relativa y/o absolutas sobre el momento, sobre cuándo una parte de datos o una área de partes de datos se ha requerido, es decir, en particular cuándo se ha realizado un acceso de lectura a la parte de datos o el área correspondiente.
Los sucesos específicos de cada aplicación pueden ser por ejemplo el comienzo del inicio de la aplicación, el comienzo de una parte interactiva de la aplicación, y/o el comienzo de una sección de aplicación determinada (en el caso de un juego, por ejemplo, el comienzo del primer nivel, del segundo nivel, del tercer nivel, etc.).
Las informaciones específicas de cada usuario pueden ser, por ejemplo, informaciones de entrada del usuario. Las informaciones de entradas son en particular informaciones sobre entradas realizadas mediante dispositivos de entrada (por ejemplo con el teclado o con el ratón), por ejemplo qué teclas se han pulsado.
La determinación del orden requerido esperado puede realizarse entonces de manera adicionalmente ventajosa basándose en una o varias de estas informaciones. Por ejemplo, determinadas informaciones específicas de cada usuario como informaciones de entrada pueden influir en el orden requerido esperado. Esto puede considerarse entonces por ejemplo en la recepción de las partes de datos requeridas para la ejecución de la aplicación.
De acuerdo con un diseño del procedimiento del tercer aspecto se obtienen órdenes requeridos adquiridos de forma múltiple para la ejecución de una aplicación partes de datos requeridas, y el orden requerido esperado se determina al menos basándose en el orden requerido adquirido de forma múltiple.
Por ejemplo, el registro al menos se lleva a cabo dos veces, pero preferentemente una pluralidad de veces. Si el orden requerido esperado se determina entonces al menos basándose en los órdenes requeridos adquiridos de forma múltiple, el orden requerido esperado puede determinarse de manera más fiable. Esto es ventajoso en particular en aplicaciones interactivas, en las que el usuario puede influir en el flujo de programa de la aplicación, dado que esto puede influir también en el orden de las partes de datos requeridas. Por ejemplo, para ello los órdenes requeridos adquiridos respectivos para ello se unifican, para formar un orden unificado o combinado, sobre cuya base el orden requerido esperado puede determinarse.
El registro múltiple puede llevarse a cabo por ejemplo en diferentes dispositivos, por ejemplo en una serie de dispositivos de análisis. En cambio, la determinación del orden requerido esperado y el almacenamiento de las partes de datos requeridas puede llevarse a cabo preferentemente en un dispositivo central.
De acuerdo con un diseño del procedimiento del tercer aspecto, en el caso de una sección secuencial de un orden requerido adquiridora sección secuencial se agrupa.
Esto puede lograr que se mantengan como una secuencia en la medida de lo posible secciones secuenciales de órdenes requeridos, en particular también, cuando la adquisición se lleva a cabo de forma múltiple y los órdenes requeridos se reúnen. Por lo tanto, si por ejemplo en un caso se adquisición la sección secuencial (2, 3, 4, 5... n-1, n) de partes de datos requeridas, la sección secuencial puede agruparse como (2...n) y registrarse de este modo. Sin embargo, las secciones secuenciales no tienen que agruparse forzosamente. Por ejemplo, se agrupan solo secciones secuenciales de una longitud determinada o un número máximo de secciones secuenciales.
De acuerdo con el tercer aspecto pueden enviarse partes de datos requeridas almacenadas, por ejemplo de acuerdo con el procedimiento del segundo aspecto. En un procedimiento del primer aspecto entonces el inicio de la aplicación finalmente puede realizarse de manera acelerada.
De acuerdo con un aspecto adicional la invención se refiere también a un dispositivo, que está preparado o comprende medios correspondientes, para ejecutar y/o controlar el procedimiento de acuerdo con el primer aspecto (primer dispositivo). El primer dispositivo puede ser, en particular una instalación de procesamiento de datos de un usuario final, por ejemplo un cliente.
De acuerdo con un aspecto adicional la invención se refiere también a un programa informático, que comprende instrucciones de programa, que llevan a un procesador a la ejecución y/o control de un procedimiento de acuerdo con el primer aspecto (o partes del mismo), cuando el programa informático se ejecuta en el procesador (primer programa informático).
De acuerdo con un aspecto adicional el objetivo mencionado al principio se consigue también mediante un dispositivo, que está preparado o comprende medios correspondientes, para ejecutar y/o controlar el procedimiento de acuerdo con el segundo aspecto (segundo dispositivo). El segundo dispositivo puede ser en particular un servidor, que pone a disposición datos para usuarios finales.
De acuerdo con un aspecto adicional la invención se refiere también a un programa informático, que comprende instrucciones de programa, que llevan a un procesador a la ejecución y/o control de un procedimiento de acuerdo con el segundo aspecto (o partes del mismo), cuando el programa informático se ejecuta en el procesador (segundo programa informático).
De acuerdo con un aspecto adicional el objetivo mencionado al principio se consigue también mediante un dispositivo, que está preparado o comprende medios correspondientes, para ejecutar y/o controlar el procedimiento de acuerdo con el tercer aspecto (tercer dispositivo). El tercer dispositivo puede comprender en particular varias instalaciones de procesamiento de datos, por ejemplo el tercer dispositivo comprende varias instalaciones de procesamiento de datos de análisis y un servidor central.
De acuerdo con un aspecto adicional la invención se refiere también a un programa informático, que comprende instrucciones de programa, que llevan a un procesador a la ejecución y/o control de un procedimiento de acuerdo con el tercer aspecto (o partes del mismo), cuando el programa informático se ejecuta en el procesador (tercer programa informático).
Preferentemente el dispositivo respectivo comprende al menos un procesador y al menos una memoria con código de programa informático, en donde la al menos una memoria y el código de programa informático están preparados para ejecutar y/o controlar con el al menos un procesador, al menos un procedimiento de acuerdo con el primer, segundo y/o tercer aspecto.
Por ejemplo, el primer, el segundo y el tercer dispositivo son instalaciones de procesamiento de datos distintas unas de otras, que están preparadas en términos de software y/o en términos de hardware, para poder ejecutar las etapas respectivas (o una parte de estas) del procedimiento de acuerdo con la invención respectivo. Por preparadas en términos de software y/o en términos de hardware ha de entenderse, por ejemplo, la preparación de la instalación de procesamiento de datos respectiva, que es necesaria para poder ejecutar las etapas (o una parte de ellas) de un procedimiento respectivo por ejemplo en forma de un programa informático. Ejemplos para una instalación de procesamiento de datos son, un ordenador de sobremesa, un ordenador portátil como un portátil, un ordenador de tableta, un asistente digital personal, un teléfono inteligente y/o un cliente ligero.
Sin embargo, básicamente también es concebible por ejemplo llevar a cabo etapas de aspectos individuales, por ejemplo del segundo y tercer aspecto, en una instalación de procesamiento de datos común. Asimismo es concebible que se lleven a cabo etapas de un aspecto en diferentes instalaciones de procesamiento de datos.
Por ejemplo, el primer, el segundo y/o el tercer dispositivo comprenden en cada caso medios para ejecutar uno de los programas informáticos de acuerdo con la invención como un procesador. Por un procesador ha de entenderse por ejemplo una unidad de control, un microprocesador, una unidad de microcontrol como un microcontrolador, un procesador de señales digital (DSP), un circuito integrado específico de cada aplicación (ASIC) o una matriz de puerta programable en campo (FPGA Field Programmable Gate Array).
Por ejemplo, el primer, el segundo y/o el tercer dispositivo comprenden además en cada caso medios para el almacenamiento de informaciones como una memoria de programa y/o una memoria principal.
Por ejemplo, el primer, el segundo y/o el tercer dispositivo comprenden además en cada caso medios para la recepción de informaciones a través de una red como una interfaz de red. Por ejemplo, el primer, el segundo y/o el tercer dispositivo están conectados y/o pueden conectarse entre sí a través de una o varias redes.
Los programas informáticos pueden distribuirse, por ejemplo a través de una red. Un programa informático puede ser al menos parcialmente software y/o firmware de un procesador.
El primer, el segundo y/o el tercer programa informático puede comprender, por ejemplo, un programa de aplicación. El primer y/o segundo programa informático comprende en particular un controlador de dispositivo.
Los programas informáticos de acuerdo con la invención pueden estar almacenados en cada caso en un medio de almacenamiento legible por ordenador, que contiene uno o varios programas informáticos de acuerdo con la invención y está configurado, por ejemplo, como medio de almacenamiento magnético, eléctrico, electro-magnético, óptico y/o de otro tipo. Un medio de almacenamiento legible por ordenador de este tipo es preferentemente concreto (es decir, "tangible"), por ejemplo está configurado como dispositivo de soporte de datos. Un dispositivo de soporte de datos de este tipo es por ejemplo portátil o está instalado fijamente en un dispositivo. Ejemplos para un dispositivo de soporte de datos de este tipo son memoria volátil o no volátil con acceso aleatorio (RAM) como por ejemplo, memoria flash NOR o con acceso secuencial como memoria flash NAND y/o memoria con acceso de solo lectura (ROM) o acceso de solo escritura. Por legible por ordenador ha de entenderse, por ejemplo, que el medio de almacenamiento puede leerse y/o escribirse por un ordenador o una instalación de procesamiento de datos, por ejemplo por un procesador. Los diseños de la presente invención a modo de ejemplo descritos previamente en esta descripción han de entenderse también como desvelados en todas las combinaciones entre sí.
Otros diseños de la invención ventajosos a modo de ejemplo de la invención pueden deducirse de la siguiente descripción detallada de algunas formas de realización a modo de ejemplo de la presente invención, en particular en conexión con las figuras.
Sin embargo, las figuras adjuntas en la solicitud deben servir para propósitos de aclaración, pero no para la determinación del ámbito de protección de la invención. Los dibujos adjuntos no están representados a escala, y únicamente deben reflejar a modo de ejemplo el concepto general de la presente invención. En particular las características, que están contenidas en las figuras, no deben considerarse de ninguna manera como componente necesario de la presente invención.
Breve descripción del dibujo
En el dibujo, muestra
figura 1 un diagrama de flujo de una instalación de procesamiento de datos a modo de ejemplo;
figura 2 una representación esquemática de un sistema de distintos dispositivos a modo de ejemplo para llevar a cabo los procedimientos de acuerdo con diferentes aspectos;
figura 3 un diagrama de flujo de un procedimiento a modo de ejemplo, que puede llevarse a cabo en el marco de un ejemplo de realización de un procedimiento de acuerdo con el tercer aspecto;
figura 4 una representación esquemática de distintas capas de un sistema operativo;
figura 5 un diagrama de flujo de un ejemplo de realización de un procedimiento de acuerdo con el tercer aspecto;
figura 6 un diagrama de flujo de un ejemplo de realización de un procedimiento de acuerdo con el segundo aspecto;
y
figura 7 un diagrama de flujo de un ejemplo de realización de un procedimiento de acuerdo con el primer aspecto.
Descripción detallada de algunas forma de realización a modo de ejemplo de la presente invención
La figura 1 muestra un diagrama de flujo de una forma de realización a modo de ejemplo de una instalación de procesamiento de datos 1. La instalación de procesamiento de datos 1 sirve como ejemplo para dispositivos de acuerdo con los diferentes aspectos, en particular el primer, el segundo y/o el tercer dispositivo puede estar realizado de acuerdo con la instalación de procesamiento de datos 1.
La instalación de procesamiento de datos 1 puede ser, por ejemplo, un ordenador, un ordenador de sobremesa, un ordenador portátil como un portátil, un ordenador de tableta, un asistente digital personal, un teléfono inteligente y/o un cliente ligero. La instalación de procesamiento de datos puede cumplir, por ejemplo, la función de un servidor o de un cliente.
El procesador 100 de la instalación de procesamiento de datos 1 está configurado en particular como microprocesador, unidad de microcontrol como microcontrolador, procesador de señales digital (DSP), circuito integrado específico de cada aplicación (ASIC) o matriz de puerta programable en campo (FPGA Field Prngrammable Gate Array).
El procesador 100 ejecuta instrucciones de programa, que están almacenadas en la memoria de programa 120, y almacena por ejemplo eventos intermedios o similares en la memoria principal 110. Por ejemplo, la memoria de programa 120 es una memoria no volátil como una memoria flash, una memoria magnética, una memoria EEPROM (memoria de solo lectura programable borrable eléctricamente) y/o una memoria óptica. La memoria principal 110 es por ejemplo una memoria volátil o no volátil, en particular una memoria con acceso aleatorio (RAM) como una memoria RAM (SRAM) estática, una memoria RAM dinámica (DRAM), una memoria RAM ferroeléctrica (FeRAM) y/o una memoria RAM magnética (MRAM).
La memoria de programa 120 es preferentemente un soporte de datos local conectado de manera fija con la instalación de procesamiento de datos 1. Los soportes de datos conectados con la instalación de procesamiento de datos 1 son, por ejemplo, discos duros, que están integrados en la instalación de procesamiento de datos 1. Como alternativa el soporte de datos puede ser también por ejemplo un soporte de datos que puede conectarse de manera separable con la instalación de procesamiento de datos 1 como un lápiz de memoria, un medio extraíble, un disco duro portátil, un CD, un DVD y/o un disquete.
La memoria de programa 120 contiene el sistema operativo de la instalación de procesamiento de datos 1, que al iniciar la instalación de procesamiento de datos 1 se carga al menos parcialmente en la memoria principal 110 y se ejecuta mediante el procesador 100. En particular, al iniciar la instalación de procesamiento de datos 1 al menos una parte del núcleo del sistema operativo se carga en la memoria principal 110 y se ejecuta mediante el procesador 100. El sistema operativo de la instalación de procesamiento de datos 1 es por ejemplo un sistema operativo Windows, UNIX, en particular Linux, Android, Apple iOS y/o MAC.
El sistema operativo permite en particular el uso de la instalación de procesamiento de datos 1 para el procesamiento de datos. Gestiona por ejemplo recursos como memoria principal 110 y memoria de programa 120, interfaz de red 130, unidad de entrada y de salida 140, pone a disposición, entre otros, mediante interfaces de programación funciones basadas en otros programas y controla la ejecución de programas.
El procesador 100 controla la interfaz de red 130, que es por ejemplo una tarjeta de red, un módulo de red y/o un módem y está preparado para establecer una conexión de la instalación de procesamiento de datos 1 con una red. La interfaz de red 130 puede recibir, por ejemplo, datos a través de la red y transmitirlos al procesador 100 y/o recibir datos del procesador 100 y enviarlos a través de la red. Ejemplos para una red son una red local (LAN) como una red Ethernet o una red IEEE 802, una red de área amplia (WAN), una red inalámbrica, una red alámbrica, una red de telefonía móvil, una red telefónica y/o Internet.
Por lo demás, el procesador 100 puede controlar al menos una unidad de entrada/salida 140. Una unidad de entrada/salida 140 es, por ejemplo un teclado, un ratón, una unidad de visualización, un micrófono, una unidad de visualización sensible al tacto, un altavoz, un lector, una disquetera y/o una cámara. La unidad de entrada/salida 140 puede por ejemplo alojar entradas de un usuario y transmitirlas al procesador 100 y/o recibir y emitir informaciones para el usuario por el procesador 100.
La figura 2 muestra una representación esquemática de un sistema 2 de distintos dispositivos a modo de ejemplo para llevar a cabo los procedimientos de acuerdo con los diferentes aspectos.
El servidor 200 puede ejecutar junto con los ordenadores 210 diseños del procedimiento de acuerdo con el tercer aspecto, como se describe con más detalle en relación con la figura 3. Asimismo el servidor 200 puede ejecutar diseños del procedimiento de acuerdo con el segundo aspecto, como se describe con más detalle en relación con la figura 5. Finalmente los ordenadores 250 pueden ejecutar diseños del procedimiento de acuerdo con el tercer aspecto, como se describe con más detalle en relación con la figura 6.
La figura 3 muestra inicialmente un diagrama de flujo 3 de un procedimiento a modo de ejemplo, que puede llevarse a cabo en el marco de un ejemplo de realización de un procedimiento de acuerdo con el tercer aspecto.
El procedimiento puede llevarse a cabo en uno o varios de los ordenadores 210. Los ordenadores 210 facilitan a este respecto un entorno analítico. Inicialmente en cada caso un controlador de dispositivo de bloque se instala para un dispositivo de bloque virtual (etapa 310). A continuación en el ordenador respectivo 210 se crea una imagen (etapa 320). Mediante el controlador de dispositivo de bloque puede integrarse un dispositivo de bloque virtual y por consiguiente la imagen en el sistema de ficheros del sistema operativo del ordenador respectivo 210 (etapa 330). A continuación una aplicación que va a optimizarse (por ejemplo, un juego de ordenador) puede instalarse sobre la imagen creada (etapa 340). La imagen está almacenada a este respecto físicamente por ejemplo en la memoria de programa 120 local respectiva (por ejemplo, sobre el disco duro) del ordenador respectivo 210. Por consiguiente, en la memoria de programa 120 respectiva para ejecutar se encuentran bloques de datos requeridos para la aplicación. Sin embargo, estos están almacenados en un orden todavía sin optimizar.
En la etapa 350, que puede llevarse a cabo después de la etapa 340, o al menos parcialmente también durante la etapa 340, pueden determinarse informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación. A este respecto se registran modificaciones en el sistema operativo y sistema de ficheros instalado en el ordenador 210 respectivo, que son requeridas, para poder iniciar la aplicación. Estas se almacenan por ejemplo en un fichero.
A continuación la aplicación puede ejecutarse en el ordenador 210 respectivo etapa 360) y utilizarse por el usuario 220 respectivo. A este respecto, se adquisición el orden requerido de bloques de datos requeridos para la ejecución de una aplicación (etapa 370).
La figura 4 muestra para ello una representación esquemática de distintas capas de un sistema operativo 4, como está presente por ejemplo en los ordenadores individuales 210 o 250. Están representadas cuatro capas 410, 420, 430, 440. Un sistema operativo 4 puede presentar también otras capas adicionales, que están dispuestas por encima, por debajo o entremedias. En la capa 420 están previstos controladores de dispositivo 421, 422 ("controlador 1", "controlador 2"). Estos pueden ser un programa informático o módulo de software, que controla la interacción con el hardware de la capa 410 subyacente. En el otro lado, el controlador de dispositivo comunica con un sistema de ficheros 431,432 de la capa 430 ("sistema de ficheros 1", "sistema de ficheros 2"). Los sistemas de ficheros pueden comunicar a su vez con las rutinas de apertura de programa de la capa 440, que pueden emplearse por ejemplo mediante la aplicación. Básicamente pueden emplearse también distintas instancias de un controlador, por ejemplo para que diferentes sistemas de fichero deban comunicar con solo un controlador. Por ejemplo, pueden emplearse varias instancias de un dispositivo de bloque virtual, que contiene en cada caso otra aplicación.
Si la aplicación requiere ahora bloques de datos determinados, estos se piden a través de un sistema de ficheros, por ejemplo sistema de ficheros 431. El controlador de dispositivo de bloque, por ejemplo controlador 421, que puede acceder a la aplicación instalada en la imagen, maneja esta solicitud y los bloques de datos requeridos se devuelven.
A este respecto, las operaciones de escritura y/o de lectura en el controlador de dispositivo de bloque 421 están ampliadas de tal modo que se registra el bloque de datos pedido (por ejemplo mediante registro de un número de bloque que identifica unívocamente el bloque de datos, de una dirección de memoria y/o de un valor de desplazamiento de memoria). Por consiguiente el orden de bloques requerido de los bloques de datos requeridos para la ejecución de la aplicación se registra mediante el controlador de dispositivo de bloque 421. Adicionalmente se registran informaciones de tiempo en forma de un desplazamiento de tiempo. Asimismo pueden registrarse informaciones adicionales como eventos específicos de cada aplicación o informaciones específicas de cada usuario.
Por ejemplo, en uno de los ordenadores 210 se adquisición el primer orden requerido siguiente, que indica el número de bloque del bloque de datos requerido y el desplazamiento de tiempo correspondiente:
Figure imgf000015_0003
Por ejemplo, en un ordenador adicional de los ordenadores 210 se adquisición el segundo orden requerido siguiente, que indica el número de bloque del bloque de datos requerido y el desplazamiento de tiempo correspondiente:
Figure imgf000015_0002
La figura 5 muestra un diagrama de flujo 5 de un ejemplo de realización de un procedimiento de acuerdo con el tercer aspecto.
Los órdenes adquiridos de forma múltiple por ejemplo pueden ponerse a disposición del servidor 200 a través de la red 230, de modo que el servidor recibe los órdenes requeridos adquiridos de bloques de datos requeridos para la ejecución de una aplicación (etapa 510).
Sobre esta base, el servidor 200 puede determinar un orden requerido esperado (etapa 520). Para ello los órdenes adquiridos de forma múltiple pueden clasificarse según la información de tiempo y unificarse, de modo que resulta el orden siguiente:
Figure imgf000015_0001
A partir de esto, por lo tanto puede determinarse el orden de bloques (0, 2, 0, 8, 9, 5, 6, 7) requerido esperado. Opcionalmente pueden ignorarse bloques de datos obtenidos de manera múltiple, de modo que esto produce el orden de bloques (0, 2, 8, 9, 5, 6, 7) requerido esperado.
El orden de bloques requerido determinado esperado se emplea entonces, para almacenar los bloques de datos requeridos en una memoria de datos en un orden al menos por áreas basándose en el orden requerido esperado, en particular en el orden requerido en sí mismo esperado (etapa 530).
Por ejemplo, los bloques de datos del imagen original, que presenta la aplicación instalada, se clasifican de nuevo. Además, se almacenan informaciones de representación gráfica que permiten una representación de la imagen original en la imagen nuevamente clasificada.
La figura 6 muestra ahora un diagrama de flujo 6 de un ejemplo de realización de un procedimiento de acuerdo con el segundo aspecto. El procedimiento puede llevarse a cabo por ejemplo asimismo mediante el servidor 200.
Inicialmente el servidor 200 recibe una solicitud de envío de al menos una parte de los bloques de datos requeridos para la ejecución de la aplicación (etapa 610). La solicitud puede realizarse por ejemplo mediante uno de los ordenadores 250 a través de una red, por ejemplo, Internet 240.
Si en el ordenador 250 correspondiente no existe todavía ninguna información de metadatos asociada a la aplicación; para la ejecución de la aplicación, estas puede enviarse (etapa 620). Junto con las informaciones de metadatos o de manera independiente a esta además las informaciones de representación gráfica almacenadas, que permiten una representación de la imagen original en la imagen nuevamente clasificada, se transfieren al ordenador 250. A continuación los bloques de datos requeridos se envían al ordenador correspondiente (etapa 630). Por ejemplo, la imagen con los bloques de datos de la aplicación nuevamente clasificados como se ha descrito se envía. A este respecto, los bloques de datos están almacenados en el servidor 200 en una memoria de datos ya en el orden al menos por áreas basándose en el orden requerido esperado, como se hace posible mediante la etapa 530. Preferentemente los bloques de datos se envían a este respecto también en el orden almacenado.
La figura 7 muestra un diagrama de flujo 7 de un ejemplo de realización de un procedimiento de acuerdo con el primer aspecto. El procedimiento puede llevarse a cabo por ejemplo en cada caso mediante el ordenador 250. Por ejemplo, si un usuario 260 de un ordenador 250 quiere la ejecución de la aplicación. Para ello, el ordenador 250 correspondiente puede enviar por ejemplo una solicitud a través de Internet 240 al servidor 200.
En el ordenador 250 correspondiente ya está instalado un controlador de dispositivo de bloque para un dispositivo de bloque virtual. Esto puede vincular un dispositivo de bloque virtual en el sistema de ficheros del sistema operativo del ordenador 250. La instalación de un controlador de dispositivo de bloque (por ejemplo, controlador 421) y la integración de un dispositivo virtual se han explicado ya con más detalle con relación a las figura 3 y 4 y puede realizarse en este caso de manera análoga. Si esto no sucede, el ordenador 250 puede recibir informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación (etapa 710), que se enviaron por ejemplo de acuerdo con la etapa 620. Asimismo el ordenador 250 con las informaciones de metadatos (o independientemente de estas) recibe además las informaciones de representación gráfica almacenadas, que permiten una representación de la imagen original en la imagen nuevamente clasificada (etapa 711).
Preferentemente el ordenador 250 recibe además informaciones (por ejemplo el tamaño) sobre una área de almacenamiento necesaria para las partes de datos.
Con ayuda de estas informaciones (por ejemplo, informaciones de rutas e informaciones de ficheros) puede realizarse una integración de una imagen con el tamaño requerido y la aplicación puede llevarse a cabo (etapa 720) (por ejemplo mediante un fichero ejecutable). Esto se cumple incluso cuando todavía no está almacenado ningún bloque de datos de la aplicación localmente en la memoria de datos del ordenador correspondiente 250, dado que ya se presentan informaciones sobre un fichero ejecutable.
La aplicación requiere ahora bloques de datos para su ejecución. Estos se piden por ejemplo mediante el sistema de ficheros (por ejemplo sistema de ficheros 431) mediante el controlador de dispositivo de bloque (por ejemplo, controlador 421) (etapa 730).
Para el caso de que los bloques de datos requeridos no estén disponibles en la memoria de datos, se realiza una suspensión del tratamiento de la cola de eventos ("event-queue") del controlador de dispositivo (etapa opcional 740). Si los bloques de datos ya están disponibles, puede continuar el procedimiento con la etapa 780 (véase más abajo). Sin embargo, si se realiza una suspensión, pueden recibirse (etapa 750) inicialmente por ejemplo mediante el servidor 200 bloques de datos requeridos para la ejecución de la aplicación.
Los bloques de datos se almacenan en la memoria de datos local (por ejemplo un disco duro) del ordenador correspondiente 250 directamente en un orden al menos por áreas basándose en el orden requerido esperado (etapa 760), dado que estos se transfieren así por el servidor 200 debido a la imagen clasificada nuevamente.
Si los bloques de datos están presentes localmente el tratamiento de la cola de eventos del controlador de dispositivo puede retomarse de nuevo (etapa opcional 770).
Dado que los bloques de datos pedidos debido al orden de bloques modificado de los bloques de datos se ha modificado en la imagen recibida, mediante el controlador de dispositivo se realiza una representación gráfica ("mapping') de los bloques de datos requeridos para la solicitud de las partes de datos requeridas para la ejecución de la aplicación en el orden de las bloques de datos almacenados en la memoria de datos (etapa 780). Esto es posible dado que las informaciones de representación gráfica almacenadas previamente por el servidor 200, que permiten una representación de la imagen original en la imagen nuevamente clasificada, se transmitieron al ordenador 250.
Por consiguiente los bloques de datos requeridos para la ejecución de la aplicación pueden facilitarse desde la memoria de datos del ordenador 250 mediante el controlador de dispositivo de bloque. Al estar almacenados los bloques de datos en la memoria de datos ya en el orden al menos por áreas basándose en el orden requerido esperado (etapa 790), la facilitación puede realizarse de manera muy eficiente. En particular el inicio de la aplicación puede acelerarse de este modo, independientemente de si la aplicación debe descargarse primero todavía por el servidor 200 o ya está almacenada en el ordenador 250.

Claims (16)

REIVINDICACIONES
1. Procedimiento para ejecutar una aplicación interactiva, en la que el usuario influye en el flujo de programa, llevado a cabo por al menos una instalación de procesamiento de datos, comprendiendo el procedimiento:
- facilitar (790) partes de datos requeridas para la ejecución de la aplicación desde una memoria de datos, en donde las partes de datos están almacenadas en la memoria de datos en un orden físico por áreas o por completo basándose en un orden cronológico requerido esperado, de tal modo que, cuando se lee una parte de datos solicitada desde la memoria de datos, se logra una precarga de partes de datos, al leerse en una etapa también partes de datos físicamente adyacentes, y en donde el orden cronológico requerido esperado se basa en una combinación de varios órdenes cronológicos requeridos adquiridos durante la ejecución de la aplicación.
2. Procedimiento según la reivindicación 1,
en donde el procedimiento comprende además:
- solicitar (730) las partes de datos requeridas para la ejecución de la aplicación, y
- representar gráficamente (780) un direccionamiento empleado para la solicitud de las partes de datos requeridas para la ejecución de la aplicación en el orden de las partes de datos almacenadas en la memoria de datos, en donde la representación gráfica del direccionamiento empleado se realiza por debajo de la capa (430) del sistema de ficheros (431, 432).
3. Procedimiento según una de las reivindicaciones 1 o 2,
en donde el procedimiento comprende además:
- recibir (750) las partes de datos requeridas para la ejecución de la aplicación, y
- almacenar (760) las partes de datos en una memoria de datos en el orden al menos por áreas basándose en el orden requerido esperado.
4. Procedimiento según la reivindicación según una de las reivindicaciones 1 a 3,
en donde las partes de datos son bloques de datos o secuencias de bloques de datos y en donde el orden es un orden de bloques, y
en donde las partes de datos están almacenadas en un dispositivo de bloque, en particular un dispositivo de bloque virtual, y
en donde para facilitar partes de datos requeridas para la ejecución de la aplicación desde la memoria de datos se emplea un controlador de dispositivo de bloque (421, 422).
5. Procedimiento según una de las reivindicaciones 1 a 4,
en donde el procedimiento comprende además:
- suspender (740) un tratamiento de una cola de eventos, en particular en el caso de que las partes de datos requeridas no estén disponibles en la memoria de datos; y
- reanudar (770) el tratamiento de la cola de eventos.
6. Procedimiento según una de las reivindicaciones 1 a 5,
en donde las partes de datos están almacenadas en la memoria de datos al menos con respecto a partes de datos relevantes para el inicio de aplicaciones en un orden al menos por áreas, basándose en un orden requerido esperado.
7. Procedimiento según una de las reivindicaciones 1 a 6,
en donde el procedimiento comprende además:
- emplear informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación.
8. Procedimiento para enviar partes de datos para el uso en un procedimiento según una de las reivindicaciones 1 a 7, llevado a cabo por al menos un dispositivo, comprendiendo el procedimiento:
- enviar (630) partes de datos requeridas para una ejecución de una aplicación, en donde la aplicación es una aplicación interactiva, en la que el usuario influye en el flujo de programa, en donde las partes de datos están almacenadas en una memoria de datos en un orden físico al menos por áreas basándose en un orden cronológico requerido esperado, de tal modo que, cuando se lee una parte de datos solicitada desde la memoria de datos, se logra una precarga de partes de datos, al leerse en una etapa también partes de datos físicamente adyacentes, en donde el orden cronológico requerido esperado se basa en una combinación de varios órdenes cronológicos requeridos adquiridos durante la ejecución de la aplicación.
9. Procedimiento según la reivindicación 8,
en donde las partes de datos se envían al menos parcialmente en el orden almacenado.
10. Procedimiento de acuerdo con las reivindicaciones 8 o 9,
en donde el procedimiento comprende además:
- recibir (610) una solicitud de envío de al menos una parte de las partes de datos requeridas para la ejecución de la aplicación, y
- enviar (630) informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación.
11. Procedimiento para almacenar partes de datos para el uso en un procedimiento según una de las reivindicaciones 1 a 7, llevado a cabo por al menos una instalación de procesamiento de datos, comprendiendo el procedimiento:
- obtener (510) órdenes cronológicos requeridos adquiridos de forma múltiple de partes de datos requeridas para la ejecución de una aplicación, en donde la aplicación es una aplicación interactiva, en la que el usuario influye en el flujo de programa, en donde el orden cronológico requerido adquirido de las partes de datos requeridas para la ejecución de la aplicación comprende informaciones registradas sobre operaciones de lectura en las partes de datos requeridas durante la ejecución de la aplicación;
- determinar (520) un orden cronológico requerido esperado al menos basándose en los órdenes cronológicos requeridos adquiridos de forma múltiple; y
- almacenar (530) las partes de datos requeridas en una memoria de datos en un orden físico al menos por áreas basándose en el orden cronológico requerido esperado, de modo que, cuando se lee una parte de datos solicitada desde la memoria de datos, se logra una precarga de partes de datos, al leerse en una etapa también partes de datos físicamente adyacentes.
12. Procedimiento según la reivindicación 11,
en donde el procedimiento comprende además una o varias de las etapas siguientes:
- instalar (310) un controlador de dispositivo, preferentemente un controlador de dispositivo de bloque;
- crear (320) una imagen;
- integrar (330) un dispositivo a través de un controlador de dispositivo, en particular a través del controlador de dispositivo instalado;
- instalar (340) la aplicación, en particular en la imagen creada;
- determinar (350) informaciones de metadatos asociadas a la aplicación para la ejecución de la aplicación; - ejecutar (360) la aplicación;
- registrar (370) el orden requerido de partes de datos requeridas para la ejecución de una aplicación.
13. Procedimiento de acuerdo con las reivindicaciones 11 o 12,
en donde las informaciones registradas permiten una identificación unívoca de la parte de datos requerida respectiva, y en donde las informaciones registradas comprenden además una o varias de las informaciones siguientes:
- informaciones de tiempo;
- eventos específicos de cada aplicación;
- informaciones específicas de cada usuario.
14. Procedimiento según una de las reivindicaciones 11 a 13,
en donde en el caso de una sección secuencial de un orden requerido adquirido se agrupa la sección secuencial.
15. Instalación de procesamiento de datos, que está preparada o comprende medios correspondientes, para llevar a cabo y/o controlar un procedimiento según una de las reivindicaciones 1 a 14.
16. Programa informático, que comprende instrucciones de programa, que llevan a un procesador a la ejecución y/o al control de un procedimiento de acuerdo con una de las reivindicaciones 1 a 14, cuando el programa informático se ejecuta en el procesador.
ES16790566T 2015-10-29 2016-10-28 Procedimiento y dispositivo para la ejecución acelerada de aplicaciones Active ES2904537T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015118522.9A DE102015118522A1 (de) 2015-10-29 2015-10-29 Verfahren und Vorrichtung zum beschleunigten Ausführen von Applikationen
PCT/EP2016/076111 WO2017072312A2 (de) 2015-10-29 2016-10-28 Verfahren und vorrichtung zum beschleunigten ausführen von applikationen

Publications (1)

Publication Number Publication Date
ES2904537T3 true ES2904537T3 (es) 2022-04-05

Family

ID=57226961

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16790566T Active ES2904537T3 (es) 2015-10-29 2016-10-28 Procedimiento y dispositivo para la ejecución acelerada de aplicaciones

Country Status (11)

Country Link
US (1) US11216286B2 (es)
EP (1) EP3368975B1 (es)
JP (1) JP6529678B2 (es)
KR (1) KR102119832B1 (es)
CN (2) CN108475203A (es)
CA (1) CA3003543C (es)
CY (1) CY1124987T1 (es)
DE (2) DE102015118522A1 (es)
ES (1) ES2904537T3 (es)
PL (1) PL3368975T3 (es)
WO (1) WO2017072312A2 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108389124B (zh) * 2018-02-26 2020-11-03 平安普惠企业管理有限公司 数据处理方法、装置、计算机设备和存储介质
JP6649989B2 (ja) * 2018-05-25 2020-02-19 株式会社日立製作所 ストレージシステム及びその制御方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5819082A (en) * 1995-06-07 1998-10-06 Sierra On-Line, Inc. Data storage optimization using an access order resource list
US20010044850A1 (en) * 1998-07-22 2001-11-22 Uri Raz Method and apparatus for determining the order of streaming modules
US7062567B2 (en) * 2000-11-06 2006-06-13 Endeavors Technology, Inc. Intelligent network streaming and execution system for conventionally coded applications
US20030142561A1 (en) * 2001-12-14 2003-07-31 I/O Integrity, Inc. Apparatus and caching method for optimizing server startup performance
US7464250B2 (en) 2004-03-11 2008-12-09 International Business Machines Corporation Method to reduce disk access time during predictable loading sequences
JP4625271B2 (ja) * 2004-05-26 2011-02-02 株式会社日立製作所 ネットワークブート用キャッシュ装置
US8607005B2 (en) * 2006-02-17 2013-12-10 International Business Machines Corporation Monitoring program execution to learn data blocks accessed by software process for facilitating efficient prefetching
US10002000B2 (en) * 2007-04-09 2018-06-19 Open Invention Network, Llc Trace-assisted startup optimization from a virtual disk
US8141001B2 (en) * 2008-07-09 2012-03-20 Harold Lee Peterson System, method and computer-readable medium for directing a computational system to defragment and maintain a disc memory
JP2010237837A (ja) * 2009-03-30 2010-10-21 Nec Corp ファイルシステム及びそのデータ再配置方法，プログラム
US10489295B2 (en) * 2012-10-08 2019-11-26 Sandisk Technologies Llc Systems and methods for managing cache pre-fetch

Also Published As

Publication number Publication date
JP6529678B2 (ja) 2019-06-12
CY1124987T1 (el) 2023-01-05
CA3003543A1 (en) 2017-05-04
DE202016009093U1 (de) 2022-03-29
PL3368975T3 (pl) 2022-02-28
JP2018538637A (ja) 2018-12-27
KR20180100111A (ko) 2018-09-07
EP3368975B1 (de) 2022-01-05
CN116048409A (zh) 2023-05-02
US20180246737A1 (en) 2018-08-30
CA3003543C (en) 2021-03-23
CN108475203A (zh) 2018-08-31
EP3368975A2 (de) 2018-09-05
US11216286B2 (en) 2022-01-04
DE102015118522A1 (de) 2017-05-04
KR102119832B1 (ko) 2020-06-16
WO2017072312A2 (de) 2017-05-04
WO2017072312A3 (de) 2017-07-27

Similar Documents

Publication Publication Date Title
US11573701B2 (en) Memory device and host device
CN110471618A (zh) 快速侧通道访问存储设备
US20180356992A1 (en) Multi-Device Platform
TW200719143A (en) Method and system for dual mode access for storage devices
RU2006138014A (ru) Запоминающее устройство и ведущее устройство
US8825946B2 (en) Memory system and data writing method
US11675709B2 (en) Reading sequential data from memory using a pivot table
WO2010047915A3 (en) Method for controlling performance aspects of a data storage and access routine
JP2011530731A5 (es)
US8433847B2 (en) Memory drive that can be operated like optical disk drive and method for virtualizing memory drive as optical disk drive
ES2904537T3 (es) Procedimiento y dispositivo para la ejecución acelerada de aplicaciones
WO2015130315A1 (en) Delay destage of data based on sync command
EP2695067B1 (en) Encryption of memory device with wear leveling
US10503695B2 (en) Method and apparatus for file system
JP2018530817A5 (es)
US9904622B2 (en) Control method for non-volatile memory and associated computer system
KR20160075703A (ko) 비휘발성 메모리를 위한 전송 버퍼의 관리
JP2015088145A (ja) 情報処理装置
US20110035557A1 (en) Fragmentation reduction using virtual sectors for static data
CN107209720A (zh) 持久存储器上的页面高速缓存
JP2013033338A (ja) メモリシステム
TW200900929A (en) Data management systems, methods and computer program products using a phase-change random access memory for selective data maintenance
ES2917252T3 (es) Establecimiento dinámico de una compatibilidad de sistemas de archivos en tiempo real
TW201142603A (en) Method to improve read/write speed of nonvolatile memory
TW201705001A (zh) 電腦系統及隨機存取記憶體控制方法