graduado en ingeniería informática - core.ac.uk · adaptacion a tiempo real de los´ ´ındices...

MADRID, JUNIO 2016

Autor: Jose Carlos Padial Diaz-Merino

Director: Francisco Rosales García

Graduado en Ingeniería Informática

Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieros Informáticos

TRABAJO FIN DE GRADO

Adaptación a tiempo real de los índices de sincronización HSLMN y SL

Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL

Agradecimientos

Muchas gracias al DATSI por permitirmetrabajar con ellos, en especial a Fran y a Dopicomis tutores durante estos ultimos dos anos.

Muchas gracias tambien a mis padres, a Carmeny a Laura por el apoyo que me han brindadosiempre que lo necesitaba.

Finalmente, quiero dedicar este trabajo a mihermana Marina, decirle que la quiero yrecordarle que, aunque a veces se desespere, conesfuerzo todo es posible.

iii


Indice general

1. Introduccion 1

1.1. Contexto del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Trabajos Previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Tecnologıas utilizadas en los algoritmos . . . . . . . . . . . . . . . . . . 2

1.3.1. Lenguaje de programacion C . . . . . . . . . . . . . . . . . . . . 2

1.3.2. MatLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.3. OpenMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.4. CUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Los algoritmos originales 5

2.1. FSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. HSLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3. Aspectos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1. Parametros de entrada . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2. Datos de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4. Diferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1. pref vs k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.2. Varianza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Unificacion de algoritmos 9

3.1. Limpieza de los algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2. Estudio de prestaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

v

INDICE GENERAL

4. Procesamiento de datos 13

4.1. Almacenamiento del estado en codigo C . . . . . . . . . . . . . . . . . . 13

4.1.1. Variables estaticas . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.2. Variables globales . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.3. Variables globales dinamicas . . . . . . . . . . . . . . . . . . . . 15

4.2. Almacenamiento del estado en codigo MatLab . . . . . . . . . . . . . . . 16

4.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5. Diseno del algoritmo de tiempo real 19

5.1. Naturaleza de los datos de entrada . . . . . . . . . . . . . . . . . . . . . 19

5.2. Uso eficiente de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 19

5.3. Disposicion de los datos en memoria . . . . . . . . . . . . . . . . . . . . 20

5.3.1. Matrices C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3.2. Matrices Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.4. Almacenamiento de los datos leıdos . . . . . . . . . . . . . . . . . . . . 24

5.5. Informacion para almacenar globalmente . . . . . . . . . . . . . . . . . 24

6. Estructura HSLMN RT 25

6.1. Inicializacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.2.2. Almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.2.3. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.2.4. Reempaquetado de los datos . . . . . . . . . . . . . . . . . . . . 28

6.3. Finalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.4. Diferencias MatLab y lınea de mandatos . . . . . . . . . . . . . . . . . . 28

6.4.1. Lectura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.4.2. Recogida de resultados . . . . . . . . . . . . . . . . . . . . . . . 29

6.4.3. Deteccion del final de lectura . . . . . . . . . . . . . . . . . . . . 29

6.5. Pseudocodigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vi


7. Visualizacion de los resultados 31

7.1. Opciones de visualizacion . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.1.1. Redibujar la grafica en cada iteracion . . . . . . . . . . . . . . . 31

7.1.2. Refreshdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1.3. Modificar graficas . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.2. Comparacion de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.3. Opcion escogida y detalles de la implementacion . . . . . . . . . . . . . 34

8. Resultados obtenidos 35

8.1. Visualizacion de resultados . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.2.1. Tiempo de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . 39

8.2.2. Uso de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9. Conclusiones 43

10. Trabajos futuros 45

10.1. Alternativas en la lectura y el almacenamiento de los datos . . . . . . . . 45

10.2. Recogida de resultados en MatLab . . . . . . . . . . . . . . . . . . . . . 46

10.3. Integracion con HERMES . . . . . . . . . . . . . . . . . . . . . . . . . 46

10.4. Paralelizacion usando CUDA . . . . . . . . . . . . . . . . . . . . . . . . 46

10.5. Usos alternativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

vii

INDICE GENERAL

Resumen

En este documento se explica el trabajo realizado sobre algoritmos que calculan los

denominados como “Indices de Sincronizacion Generalizada” h, s, l, m, n y SL, utiliza-

dos para calcular el nivel de correlacion entre dos senales extraıdas del cerebro humano

mediante el uso de la electroencefalografıa y la magnetoencefalografıa, con el objetivo de

estudiar su funcionamiento.

El principal objetivo del proyecto es unificar y transformar estos algoritmos para con-

seguir un unico algoritmo capaz de calcular el valor de estos ındices sobre flujos de datos.

Para ello se realizan estudios sobre como afrontar distintos aspecto asociados al procesa-

miento de datos en tiempo real como pueden ser la incertidumbre de la naturaleza de los

datos o la manera en la que se almacenan.

Abstract

This document will be focused on the work done onto the algorithms that calculate

the “Generalized Synchronization Indices” know as h, s, l, m, n and SL, which allow

comparation between two signals extracted from the human brain via electroencephalo-

graphy and magnetoencephalography in order to find any possible correlation between

them while trying to study the behaviour of the human brain.

Trough this project we will unify and transform these algorithms into a singe algo-

rithm capable of calculating the value of these indices when applied to data streams. Se-

veral studies about how to deal with different aspects associated with real-time processing

such as the uncertain nature of the data or how to store the data we have already read are

treated through the project.

viii


Capıtulo 1

Introduccion

En los ultimos anos se ha aumentado enormemente la capacidad de computo de los

ordenadores, no tanto por el incremento de la velocidad de los procesadores, sino por el

aumento del numero de operaciones que es capaz de ejecutar en paralelo un solo procesa-

dor. Esto supone una gran ventaja en el campo de la investigacion ya que la mayorıa de las

aplicaciones de calculo cientıfico operan con muchısimos datos y pueden ser facilmente

paralelizables al no depender unos de otros.

En este proyecto en concreto se hace uso de esta capacidad de computo para proce-

sar en tiempo real datos obtenidos de EEG1 y MEG2 con el objetivo de poder estudiar el

comportamiento del cerebro humano ante distintos estımulos. Con los resultados obteni-

dos de este estudio se trata de poder caracterizar y detectar de forma temprana diversas

patologıas como pueden ser Alzheimer o Parkinson.

1.1. Contexto del trabajo

Tras una colaboracion entre el DATSI3 y el CTB4 surgen varios algoritmos para cal-

cular los llamados “Indices de Sincronizacion Generalizada”. Estos ındices son SL5 [1]

y la agrupacion de 5 ındices conocida como HSLMN6 [2], y son utilizados dentro de

HERMES7[3], un toolbox para MatLab desarrollado por el CTB como parte de sus pro-

yectos de investigacion.

Hasta el momento, estos algoritmos operaban sobre un conjunto de datos obtenido

con anterioridad, generando tanto el valor promedio de un ındice para cada par de senales

dadas, ası como las varianza de este. El objetivo de este trabajo consiste en adaptar ambos

1Electroencefalogramas2Magnetoencefalogramas3Departamento de Arquitectura y Tecnologıa de Sistemas Informaticos4Centro de Tecnologıa Biomedica5Synchronization Likelihood6Indices H, S, L, M y N7HERramientas de MEdida de la Sincronizacion

1

CAPITULO 1. INTRODUCCION

algoritmos para que operen sobre flujos de datos, ası como desarrollar una interfaz que

permita visualizar los resultados segun el algoritmo procesa los datos.

Para poder llevar a cabo la tarea se han designado varias fases, siendo las principa-

les unificar los algoritmos HSLMN y FSL8, adaptar el nucleo de la aplicacion para que

funcione en tiempo real, disenar las interfaces para poder invocar ese nucleo bien desde

consola de comandos o bien desde MatLab, para finalmente desarrollar una interfaz de

visualizacion dentro de MatLab.

1.2. Trabajos Previos

Ambos algoritmos han recibido varios cambios y mejoras desde que se empezara a

trabajar sobre ellos en el ano 2011. De estas mejoras destacamos la inclusion de la des-

viacion tıpica como medida de dispersion de los ındices, la funcion de trigger, que permite

obtener resultados parciales de los ındices y base del algoritmo de tiempo real que se desa-

rrolla a lo largo de este trabajo y la posibilidad de trabajar con distintos experimentos de

manera simultanea, cruzando los datos entre ellos.

Ademas de estas mejoras relativas a la naturaleza de los ındices, ambos algoritmos

originalmente secuenciales fueron traducidos del lenguaje MatLab a C, lo que ya de por

si se tradujo en un aumento de las prestaciones de los mismos. Una vez los algoritmos se

tradujeron al lenguaje C se realizo la paralelizacion tanto sobre CPU como sobre GPU,

obteniendo un gran aumento de las prestaciones de los mismos al poder utilizar todos los

nucleos CPU y GPU disponibles.

Ambos algoritmos han pasado por las manos de distintas personas y de ellos han

surgido tanto artıculos cientıficos [4] como Trabajos de Fin de Grado [5], [6]. Todos estos

artıculos han servido como base para aprender tanto el funcionamiento de los algoritmos

como que optimizaciones con las que cuentan y la evolucion de los mismos.

1.3. Tecnologıas utilizadas en los algoritmos

1.3.1. Lenguaje de programacion C

El lenguaje de programacion C es un lenguaje de proposito general desarrollado en

torno al ano 1970 por Dennis M. Ritichie. Se trata de un lenguaje imperativo disenado

para la programacion de sistemas que poco a poco fue ganando popularidad fuera de este

ambito gracias a su gran eficiencia.

En el contexto de este proyecto, es el lenguaje en el que estan escritos todos los algo-

ritmos, aunque disponen de interfaces para ser utilizados desde bien desde el el entorno

MatLab o bien desde lınea de mandatos.

8Fast Synchronization Likelihood

2


1.3.2. MatLab

Al hablar de MatLab no nos referimos unicamente al lenguaje de programacion, sino

tambien al entorno disenado para trabajar con el mismo. Este entorno dispone de una serie

de herramientas que permiten tanto cargar datos, como trabajar con ellos y visualizarlos ,

todo a traves de interfaces o de comandos sencillos, caracterıstica que lo convierte en el

entorno ideal para aquellos investigadores que no son expertos en programacion.

Una de las principales caracterısticas de MatLab es su eficiencia al realizar operacio-

nes de calculo tanto vectorial como matricial, no obstante, no es un lenguaje apropiado

para el desarrollo de software de proposito general, al tratarse de un lenguaje interpretado.

Para poder aprovechar tanto el poder que ofrece su entorno de trabajo como las ventajas

de un lenguaje compilado, existe la opcion de utilizar interfaces MEX9, que permiten eje-

cutar codigo en otros lenguajes de programacion, como por ejemplo C o Java, mucho mas

rapidos que MatLab.

1.3.3. OpenMP

OpenMP [7] es una API10 para la programacion de aplicaciones paralelas de memoria

compartida. Esta disponible para los lenguajes C, C++ y Fortran, bajo un gran numero de

plataformas, arquitecturas y sistemas operativos.

OpenMP utiliza directivas de compilacion que le indican al compilador que debe in-

cluir codigo para lanzar multiples hilos de ejecucion que se dividen el trabajo de la seccion

paralela. Permite tambien la utilizacion de variables de entorno para controlar en tiempo

de ejecucion cual es el grado de paralelismo con el que se va a ejecutar la aplicacion

1.3.4. CUDA

CUDA11 [8] es un conjunto de herramientas desarrollado por Nvidia que permiten

desarrollar algoritmos que ejecutan sobre sus GPUs. Mediante un lenguaje de programa-

cion similar a C y un compilador propio se genera codigo que en tiempo de ejecucion se

ejecutara sobre la GPU en lugar de hacerlo sobre la CPU.

Ademas de las herramientas basicas, CUDA incluye la biblioteca Thrust [9], que ofre-

ce un gran abanico de primitivas como por ejemplo scan, sort o reduce con opcion para

poder ejecutarse tanto sobre CPU como sobre GPU.

9MatLab Executable10Interfaz de Programacion de Aplicaciones11Compute Unified Device Architecture

3

CAPITULO 1. INTRODUCCION

4


Capıtulo 2

Los algoritmos originales

Estos algoritmos surgieron como herramientas para poder calcular los niveles de sin-

cronizacion entre las ondas emitidas por el cerebro humano y ası tratar de comprender

mejor su funcionamiento, pudiendo llegar incluso a utilizarse para detectar en fases tem-

pranas ciertas ciertas enfermedades neurodegenerativas como pueden ser el Alzheimer o

el Parkinson, lo que permite controlarlas con un tratamiento adecuado y evitar que sigan

desarrollandose, o incluso curarlas.

En este capıtulo no se pretende explicar la base matematica que hay detras de ellos,

disponible en sus respectivos artıculos [1], [2], sino explicar los aspectos de implementa-

cion que es necesario conocer y que se mencionan a lo largo de todo el trabajo.

2.1. FSL

El algoritmo FSL [4] es una version optimizada tanto tanto en tiempo de ejecucion co-

mo en uso de memoria del algoritmo SL, que calcula la correlacion o sincronizacion entre

un conjunto de canales obtenidos como resultado de analisis de las ondas cerebrales de

un paciente mediante el uso de cascos de electroencefalografıa y magnetoencefalografıa.

Estos cascos estan equipados con multiples sensores que registran la actividad cerebral

del paciente. Cada sensor del casco produce informacion atribuida a un canal que luego

sera comparada contra el resto de canales dentro de la ventana de tiempo que se le indique

para ası poder comprobar tanto efecto de distintos estımulos sobre el paciente como que

areas del cerebro se estimulan.

2.2. HSLMN

De manera similar al algoritmo FSL, el algoritmo HSLMN permite calcular 5 ındices

de sincronizacion generalizada que proporcionan distintas medidas de sincronizacion o

correlacion entre cada par de canales de entrada.

5

CAPITULO 2. LOS ALGORITMOS ORIGINALES

Este algoritmo permite calcular los 5 ındices a la vez procesando cada experimen-

to una unica vez, que facilita la labor a los investigadores al proporcionarles un mayor

numero de medidas de correlacion sin que el tiempo que se necesita para calcularlas se

vea gravemente impactado.

2.3. Aspectos comunes

Ambos algoritmos tienen una estructura similar, ya que estan formados por un nucleo

que se encarga de procesar los datos leıdos desde un fichero y de calcular el valor pro-

medio de los ındices y por un conector que permite que el usuario interactue con este

nucleo bien desde MatLab o bien desde consola de mandatos. Otra caracterıstica comun

a ambos algoritmos es una division logica en tres fases, lectura de los datos, parametros

de configuracion y comprobaciones sobre los mismos, analisis de los datos y calculo de

los valores promedio de los ındices.

Como se ha mencionado anteriormente, tanto el algoritmo FSL como el algoritmo

HSLMN han pasado por varias iteraciones desde que fueron creados. La version que

existıa en la fecha de comienzo de este trabajo y que se ha utilizado como base para

la unificacion y la creacion del algoritmo de tiempo real es la version C optimizada y

paralelizada sobre CPU con OpenMP.

En los siguientes apartados se detallan las caracterısticas que comparten ambos algo-

ritmos relevantes en este trabajo.

2.3.1. Parametros de entrada

Ambos algoritmos reciben diversos parametros de entrada que definen su comporta-

miento y como deben procesar los datos. Estos parametros, junto con otros que se obtienen

de ellos son:

l Tambien conocido como τ , que se usa junto con el parametro m para representar el

estado de una senal en un instante de tiempo.

m Se usa junto con el parametro l y que representa la dimension del vector que se utiliza

en en cada instante para representar el estado de una senal.

x Indica el tamano de la ventana de exclusion. Esta ventana de exclusion se utiliza para

descartar los x vecinos mas cercanos a la hora de calcular el valor de los ındices y

ası evitar la auto-correlacion entre datos cercanos.

w Indica el tamano de la ventana de inclusion. Esta ventana limita el numero de vecinos

cercanos al punto que se esta procesando que se estudian para calcular el valor de

los ındices, ya que aquellas muestras muy alejadas de la que se esta procesando

pueden no ser relevantes para esta.

6


Ventana Numero de vecinos que se estudian para procesar cada muestra y que equivale

a 2 ∗ (w − x). Cabe destacar que en los extremos de los datos puede no existir un

numero suficiente de vecinos para hacer el calculo completo y sea necesario realizar

el calculo con un numero menor de vecinos.

c Numero de canales de los datos. Es posible indicarle este valor al algoritmo, pero si no

se indica, se calcula automaticamente al recibir los datos de entrada.

d Numero de muestras de los datos. Al igual que sucede para el parametro c, es posible

indicarle este valor al algoritmo, pero si no se indica, se calcula automaticamente al

recibir los datos de entrada.

trigger Indica cada cuantas muestras se van a a volcar los resultados parciales. No es un

parametro propio del algoritmo, sino que indica al programa que se debe realizar

un volcado de datos parcial tras procesar un bloque de trigger muestras.

2.3.2. Datos de entrada

Ambos algoritmos reciben como entrada un fichero de texto plano con los datos pro-

ducidos por un experimento de una longitud determinada.

Estos datos estan organizado de tal manera que existen tantas filas como muestras se

hayan recogido durante ese experimento y en cada fila aparece un valor por cada canal

que se quiera estudiar.

Ası, si se ha realizado un experimento de 10 segundos de duracion, con un a velocidad

de muestreo de 250Hz, en el que se muestrea la informacion procedente de 4 sensores, el

fichero de entrada asociado a ese experimento estara formado por 2500 filas y 4 columnas,

almacenando la informacion de 10000 datos.

Es de estos ficheros de entrada de donde el algoritmo obtiene el numero de canales y

de muestras del experimento que se esta procesando. Es importante tener en cuenta que

el numero de canales permanece constante a lo largo de todo el experimento, por lo que

los algoritmos comprueban que permanezca constante mientras leen los datos de entrada

y emiten un error si no es ası.

2.4. Diferencias

Aunque las diferencias entre ambos algoritmos no son significativas (fuera de la parte

relativa al calculo de los ındices), existen algunos factores que aunque son similares, no

es posible realizar una equivalencia entre uno y otro.

7

CAPITULO 2. LOS ALGORITMOS ORIGINALES

2.4.1. pref vs k

Ambos algoritmos calculan la distancia euclıdea de un vector definido por los parame-

tros m y l entre el dato que se esta estudiando y cada uno de los datos dentro de la ventana

que rodea a ese dato. No obstante, cada algoritmo determina de manera distinta cuantos

de los vecinos cercanos se consideran a la hora de calcular el valor del ındice.

Mientras que algoritmo FSL utiliza el concepto pref, indicando que porcentaje de

los vecinos mas cercanos se utiliza a la hora de calcular el valor de los ındices para cada

dato, el algoritmo HSLMN se basa en un numero, conocido como k, que indica que se

utilizan los k vecinos mas cercanos para calcular el valor de los ındices.

A la hora de introducir el calculo del ındice SL dentro del algoritmo SL es necesario

recordar que el valor de los ındices se ve ligeramente modificado en los extremos, pues

el concepto de pref escala si no se dispone de la ventana completa para calcular los

ındices, mientras que el concepto de k no lo hace.

2.4.2. Varianza

Con el algoritmo HSLMN se calcula no solo el valor promedio de cada ındice, sino

tambien la varianza de este que permite estimar como de fiable es el ındice calculado.

Contrastando con esto, algoritmo FSL no implementa ningun tipo de medida de dispersion

que permita estimar la fiabilidad de los resultado obtenidos.

2.5. Conclusiones

Debido a estas similitudes, se planteo como paso previo a la adaptacion a tiempo real

unificar los algoritmos para ası reducir el esfuerzo necesario para adaptarlos a tiempo real

al tener que realizar la labor con un unico algoritmo en lugar de con dos.

Al unificar los algoritmo no solamente se consigue simplificar y agilizar la adaptacion

a tiempo real, sino que tambien se consigue reducir el tiempo necesario para conocer el

valor de todos los ındices, pues el usuario puede disponer de un algoritmo que procese

calcula todos los ındices procesando el fichero una unica vez.

8


Capıtulo 3

Unificacion de algoritmos

Para adaptar el calculo de los ındices a tiempo real era conveniente disponer de un

unico algoritmo en el que se realiza de manera simultanea el calculo de los 6 ındices (H,

S, L, M, N y SL), en lugar de tener que utilizar dos algoritmos distintos. Este algoritmo

unificado permite eliminar la necesidad de procesar un fichero varias veces y la redun-

dancia que introducen operaciones ajenas al calculo de los ındices como tal, tales como

la lectura de los datos o la ordenacion de las distancias entre canales, comunes a ambos

algoritmos.

Puesto que el algoritmo HSLMN calcula los 5 ındices en una unica ejecucion, se

opto por anadir el calculo del ındice SL al algoritmo HSLMN, que ya calcula de manera

simultanea varios ındices y dispone de opciones relacionadas con este aspecto, como por

ejemplo, excluir los ındices que no se quieran calcular y ası acelerar reducir el tiempo

necesario para calcular los otros.

A la hora de incluir el calculo del ındice SL dentro del algoritmo HSLMN fue nece-

sario adaptar el concepto de pref, al concepto de k, originario del HSLMN. Como se

ha explicado en el capıtulo anterior, aunque ambos conceptos representan lo mismo en

los extremos de la senal donde no se dispone de suficientes datos para llenar la ventana,

la densidad de datos con la que se calculan los ındices es distinta, lo que se traduce en

pequenas variaciones en el resultado final.

Para poder comprobar que la unificacion de los algoritmos se ha realizado de manera

satisfactoria, disponemos de una baterıa de pruebas con unos datos de entrada y un resulta-

do conocido. Estas pruebas se dividen en dos tipos, aquellas que utilizan datos sinteticos,

conocidas como da, “4x4000” o simplemente “data” y aquellas que utilizan los datos de

una prueba real, conocidas como “pt”, “148x50863” o “paciente test”.

3.1. Limpieza de los algoritmos

El primer paso antes de unificar los algoritmos consiste en reorganizar y refactorizar

el codigo del algoritmo HSLMN, pues aunque originalmente el algoritmo HSLMN se

9

CAPITULO 3. UNIFICACION DE ALGORITMOS

diseno para poder incluir el calculo de mas ındices en el algoritmo, el modo en el que este

se programo originalmente no permite incluir un ındice mas sin tener modificar la gran

parte del codigo.

El principal impedimento lo encontramos en las variables utilizadas para almacenar

los resultados de los ındices, pues el algoritmo disponıa de variables distintas variables

sobre las que se realizaban siempre las mismas operaciones, en lugar de agrupar las dichas

variables dentro de un mismo array, lo que se traduce en duplicidad de codigo cada vez

que que querıa realizar una accion sobre todos los ındices.

Al almacenar cada ındice como una entrada en un array es posible simplificar el codigo

eliminando en torno a un 1/3 del mismo, puesto que donde antes habıa varias lıneas de

codigo, una para cada ındice, ahora hay una unica operacion que se ejecuta sobre todos

los miembros de un array.

Esta limpieza del algoritmo HSLMN no ha tenido ningun impacto ni en las prestacio-

nes ni en la manera en la que se utiliza el algoritmo, ya que se trata de una refactorizacion

que solo afecta a la parte interna del mismo.

3.2. Estudio de prestaciones

Para estudiar las prestaciones del algoritmo unificado frente a los algoritmos origi-

nales, se han realizado 1000 ejecuciones de cada una de las pruebas, siempre sobre la

maquina Espino, con las mismas condiciones de carga de la maquina y las mismas opcio-

nes de compilacion, para tratar de minimizar la influencia que causas ajenas al algoritmo

puedan influir en los resultados.

Si lo que nos interesa es calcular el valor de todos los ındices, la opcion mas intere-

sante es sin duda utilizar el algoritmo unificado, indicando a la hora de ejecutarlo que

queremos el resultado de todos los ındices, ya que el tiempo de este es claramente infe-

rior al resultante de ejecutar el algoritmo HSLMN para calcular parte de los ındices y el

algoritmo FSL para calcular el restante.

Como se puede observar en la Figura 3.1 en la que aparecen ordenados los tiempos

de estas 1000 ejecuciones, al promediar los resultados realizados sobre los datos del ex-

perimento “4x4000”, podemos calcular que el tiempo necesario para calcular todos los

ındices es un 46 % mejor cuando se utiliza el algoritmo unificado. En el caso de los resul-

tados del experimento de datos reales, reflejada en la Figura 3.2, se obtiene el valor de los

6 ındices un 10 % mas rapido que utilizando ambos algoritmos por separado.

Aunque se muestra una clara disminucion del tiempo necesario para calcular todos

los llamados “Indices de Sincronizacion Generalizada” no todo son ventajas, ya que el

algoritmo HSLMN necesita realizar la ordenacion de todos los elementos cercanos al

cada punto estudiado para poder calcular el valor del ındice L, por lo que ordena mas

elementos de los que necesita el ındice SL.

Esta situacion que se ve reflejada en ambas figuras, al ser el tiempo de calcular uni-

10


camente el ındice SL muy similar al de calcular todos los ındices cuando se utiliza el

algoritmo unificado. Si nos fijamos en la Figura 3.1 asociada al experimento con datos

sinteticos, podemos observar como el tiempo necesario para calcular el ındice SL es apro-

ximadamente un 15 % mayor utilizando el algoritmo unificado. Para las pruebas con datos

reales de la Figura 3.2 el algoritmo unificado necesita el triple de tiempo que el algoritmo

FSL para calcular el unicamente ındice SL, ya que tiene que realizar la ordenacion que se

ha mencionado anteriormente.

Figura 3.1: Comparacion tiempos FSL y HSLMN(4x4000)

Figura 3.2: Comparacion tiempos FSL y HSLMN(148x50863)

11

CAPITULO 3. UNIFICACION DE ALGORITMOS

12


Capıtulo 4

Procesamiento de datos

Para estudiar como funcionara el algoritmo de tiempo real se han desarrollado una

serie de prototipos sencillos con un funcionamiento muy similar a la version MatLab del

algoritmo de tiempo real.

Estos prototipos reciben varios vectores columna desde MatLab, devolviendo en cada

llamada la suma de los datos que reciben y anadiendo este valor a un total, que persiste

entre llamadas y que contiene la suma de todos los datos recibidos hasta el momento.

Un aspecto que es necesario tener en cuenta tanto con estos prototipos con el algoritmo

de tiempo real es que tanto el tamano de los datos con los que se llama al algoritmo como

el numero de veces que se hace pueden.

Uno de los principales intereses es comprobar como se mantener el estado entre las

llamadas para estudiar si este estado iba a ser almacenado dentro de MatLab, lo que sim-

plificarıa el programa al recibir el estado en cada llamada, pero ralentizarıa cada llamada

al aumentar la transmision de informacion entre MatLab y el algoritmo, o si, por el con-

trario, es el propio algoritmo el que almacena el resultado de los datos procesados hasta

el momento.

4.1. Almacenamiento del estado en codigo C

4.1.1. Variables estaticas

La primera alternativa estudiada almacena la suma total entre llamadas mediante el

uso de variables estaticas declaradas dentro del codigo. Esta es una solucion valida para

el prototipo sencillo, sin embargo, la visibilidad de este estado almacenado queda limitada

al ambito en el que se define la variable, lo que complica trabajar con la aplicacion real

al ser necesario ir pasando el estado entre las distintas funciones de las que se preve que

este formada la misma.

13

CAPITULO 4. PROCESAMIENTO DE DATOS

sumaStatic.c

1 #include <mex.h>2

3 void mexFunction(int nlhs, mxArray *plhs[],4 int nrhs, const mxArray *prhs[]){5

6 static double sum = 0;7 /* Input matrix */8 double *data;9 data = mxGetPr(prhs[0]);

10 /* Input size */11 int M = mxGetM(prhs[0]);12

13 /* Output value */14 double *result;15 plhs[0] = mxCreateDoubleMatrix(1,1,mxREAL);16 result = mxGetPr(plhs[0]);17

18 /* Fill sum with the sum of the input */19 int i;20 for (i = 0; i < M; ++i) {21 sum += data[i];22 }23

24 *result = sum;25

26 }

4.1.2. Variables globales

Para solucionar el problema del ambito se modifico el primer prototipo, transforman-

do la variable que en un principio era estatica en una variable global. Este cambio permitıa

que, al igual que en el caso anterior, la variable conservara su valor entre llamadas, au-

mentando la el ambito de la variable, que ya no queda limitada a la seccion en la que se

define, sino que es accesible desde cualquier funcion que la necesite.

sumaGlobal.c

1 #include <mex.h>2 double sum = 0;3

4 void mexFunction(int nlhs, mxArray *plhs[],5 int nrhs, const mxArray *prhs[]){

14


6

7 /* Input matrix */8 double *data;9 data = mxGetPr(prhs[0]);

10 /* Input size */11 int M = mxGetM(prhs[0]);12


18 /* Fill sum with the sum of the input */19 int i;20 for (i = 0; i < M; ++i) {21 sum += data[i];22 }23

24 *result = sum;25

26 }

4.1.3. Variables globales dinamicas

El prototipo sencillo puede almacenar todo su estado en una variable tipo doublesin ningun problema, pero en el caso de una aplicacion real es necesario almacenar un

estado mucho mas complejo, que no es posible conocer completamente en tiempo de

compilacion. Para poder solventar este problema se convierte la variable global en un

puntero que la aplicacion se encargara de de manejar, inicializando la region de memoria

que sea necesaria para cada caso y trabajando con ella como necesite.

sumaMalloc.c

1 #include <mex.h>2

3 double *ptr = NULL;4

5 void* calloc(size_t n, size_t size){6 return mxCalloc(n,size);7 }8

9 void mexFunction(int nlhs, mxArray *plhs[],10 int nrhs, const mxArray *prhs[]){11

15


12 /* Input matrix */13 double *data;14 data = mxGetPr(prhs[0]);15 /* Input size */16 int M = mxGetM(prhs[0]);17


23 /* If this is the first call, initialize the memory space */24 if (ptr == NULL) {25 ptr = calloc(1, sizeof(int));26 }27

28 /* Fill sum with the sum of the input */29 int i;30 for (i = 0; i < M; ++i) {31 *ptr += data[i];32 }33

34 *result = *ptr;35

36 }

4.2. Almacenamiento del estado en codigo MatLab

Para el ultimo prototipo, en el que el estado se guarda en MatLab, se ha creado un

objeto de sistema MatLab (que hereda de la clase matlab.System). Este objeto dispo-

ne de una interfaz predefinida que se ejecutan con llamadas a setup(obj,<args>),

step(obj,<args>) y reset(obj,<args>), entre otras, y que proporcionan una

interfaz perfecta para procesar datos en tiempo real, al poder inicializar la aplicacion,

procesar un fragmento de los datos y reiniciar el estado de la aplicacion utilizando los

metodos estandar que se utilizan en otras aplicaciones de tiempo real en MatLab.

sumaSystem.m

1 classdef sumaSystem < matlab.System2

3 properties (Nontunable)4 data;5 end6

16


7 properties (Access = private)8 data_sum;9 end

10

11 methods12 % Constructor13 function obj = sumaSystem(data)14 obj.data = data;15 end16 end17

18 methods (Access = protected)19 %% Common functions20 function setupImpl(obj,u)21 obj.data_sum = 0;22 end23

24 function y = stepImpl(obj,i)25 obj.data_sum = obj.data_sum + sum(obj.data(:,i));26 y = obj.data_sum;27 end28

29 function z = getDiscreteStateImpl(obj)30 z = struct(’sum’, obj.data_sum );31 end32

33 end34 end

4.3. Conclusiones

Habiendo evaluado las distintas alternativas de las que disponemos para almacenar el

estado en el caso de la version MatLab, se ha optado por almacenar todo el estado dentro

del fichero mex, sobre las mismas variables globales que utiliza la version de linea de

mandatos. Se espera ası poder reducir al mınimo las diferencias a nivel de codigo entre

estas dos versiones.

Al observar la potencia que proporcionan los objetos de sistema de MatLab, se deci-

dio presentar la interfaz de MatLab como un objeto de estos, que enlace con el fichero

mex correspondiente, facilitandole los datos que se quieran procesar en cada momento,

que sera el que interactua con el nucleo de la aplicacion de manera similar a como harıa

la funcion main de la version desde lınea de mandatos..

17


18


Capıtulo 5

Diseno del algoritmo de tiempo real

A la hora de adaptar un algoritmo para su aplicacion en tiempo real es necesario

considerar las diferencias que existen entre el procesamiento de datos estandar, con un

tamano fijo frente al procesamiento de datos con tamano y velocidad de llegada variable.

En el caso de este algoritmo en concreto, al que hemos decidido llamar HSLMN RT1,

tambien se han tenido en cuenta una serie de factores propios del algoritmo que, en el

caso de ser descuidados, tendrıan un gran impacto en la eficiencia del mismo.

5.1. Naturaleza de los datos de entrada

El algoritmo debe estar preparado para recibir un numero variable de muestras por

la entrada, pues la informacion que recibe no tiene por que llegar de manera uniforme y

ni se pueden ni se deben hacer asumpciones sobre el tamano de la misma. Como se ha

mencionado anteriormente, lo que si que ha de permanecer constante es el tamano de cada

una de las muestras que se reciben en cada etapa.

5.2. Uso eficiente de la memoria

El algoritmo original necesita almacenar en memoria la totalidad de los datos que va a

procesar para luego procesarlos de principio a fin. Una las caracterısticas imprescindibles

del nuevo algoritmo es la capacidad para procesar los datos reteniendo unicamente los

datos necesarios para procesar el siguiente fragmento, descartando los datos que ya no le

sean de utilidad.

Gracias a esta caracterıstica el algoritmo es capaz de procesar cualquier cantidad de

datos sobre un espacio de memoria limitado, como se puede observar en el apartado 8.2.2,

donde se estudia la memoria que utiliza el algoritmo para una serie de datos de entrada

cada vez mayor.

1HSLMN Real Time

19

CAPITULO 5. DISENO DEL ALGORITMO DE TIEMPO REAL

5.3. Disposicion de los datos en memoria

El algoritmo recorre los datos para procesarlos, primero procesando todos los instantes

de un canal y luego procesando el resto de canales, por lo que debemos de procurar que

reciba los datos ası dispuestos en memoria para que los accesos a datos se realicen a traves

de las memorias caches, minimizando ası el tiempo que se pierde cuando el sistema tiene

que traer los datos de memoria principal.

A la hora de trabajar con matrices podemos verlas como un conjunto de filas con

varios elementos en cada fila o como un conjunto de columnas con varios elementos en

cada columna.

Si consideramos las matrices como un conjunto de filas, estamos ante lo que se conoce

como matrices row-major, en las que 2 elementos consecutivos de la misma fila, aparecen

contiguos en memoria.

En el otro caso, en el que vemos las matrices como un conjunto de columnas, se habla

de matrices column-major, ya que los elementos que aparecen contiguos en memoria son

los de la misma columna.

Para referirnos a un elemento en concreto de un a matriz lo haremos indicando primero

el numero de la fila y luego el numero de columna de la matriz. El ındice del primer

elemento de cada fila o columna puede variar de un lenguaje a otro, pues hay algunos que

empiezan a indexar en 0 y otros que lo hacen en 1.

5.3.1. Matrices C

El lenguaje de programacion C no conoce el concepto de matriz, pero si conoce el

concepto de vector o array, definido por una una direccion de memoria que considera el

origen y un desplazamiento mediante el cual accede a los elementos del mismo.

Este concepto de vector fuerza que el primer elemento del vector sea el elemento

numero 0, pues el primer elemento del vector es el que se encuentra en la direccion donde

comienza el vector, con desplazamiento de 0 elementos.

Jugando con este concepto de vector y/o con varios de los mismos, en C se puede

trabajar con matrices de diferentes maneras. En los siguientes apartados se mencionan

algunas formas que se utilizan dentro del algoritmo, junto con sus ventajas e inconvenien-

tes.

Matrices compactas

Este tipo de matriz esta almacenada en memoria como un bloque de memoria con-

secutivo, de tal manera que en dos direcciones de memoria consecutivas aparecen dos

elementos consecutivos. Al llegar al final de una fila, el siguiente elemento que aparece

es el primero de la fila siguiente.

20


Con estas matrices el acceso a los datos de la misma es bastante rapido, pues todos los

elementos estan en la misma region, por lo que al acceder a un dato se lleva a memoria

cache un bloque de memoria que contiene toda o gran parte de la matriz.

Sin embargo, no todo son ventajas, pues su uso de cara al usuario es bastante molesto,

ya que al estar considerando la matriz como un vector es este el que debe calcular la

posicion del elemento multiplicando el ındice de la fila a la que desea acceder por el

numero de columnas y sumandole el ındice de la columna que desea.

M(i, j) → M [i ∗ nColumnas+ j]

Figura 5.1: Matriz compacta almacenada por filas

Multiples vectores

En este tipo de matriz se realiza el acceso a los datos utilizando dos tipos de vectores

distintos, por un lado vectores que contienen a las filas y por otro lado un vector que

contiene cada una de las filas que forman la matriz. En este tipo de matrices no es posible

asegurar que los vectores que contienen los valores de las filas aparezcan consecutivos

en memoria, ya que al realizar la reserva de espacio, estos pueden quedar alojados en

cualquier parte del heap.

Almacenar una matriz de esta manera hace los accesos a los elementos mas lentos, ya

que es necesario acceder primero al vector de la fila que queremos consultar y luego a la

columna que nos interese, aunque facilita la labor del programador ya que simplemente

ha de indicar los ındices de la fila y la columna a la que desea acceder.

M(i, j) → M [i][j]

21


Figura 5.2: Matriz formada por multiples vectores

Como este tipo de matrices se suele almacenar en el heap del programa acceder a los

datos de una misma fila es relativamente rapido (aunque mas lento que el caso anterior por

la necesidad de pasar antes por el vector de filas), pero acceder a dos filas distintas muy

lento, ya que, como se ha explicado antes, al reservar espacio para la matriz esta puede

estar distribuida por toda la memoria.

VLA

Una solucion intermedia entre los dos tipos anteriores la encontramos en los VLA2,

vectores n-dimensionales para los que el compilador reserva en tiempo de ejecucion un

espacio de memoria compacto donde almacenarlos. Este espacio, a pesar de ser compacto,

puede ser accedido utilizando la misma sintaxis que en el ejemplo anterior.

M(i, j) → M [i][j]

Figura 5.3: Matriz VLA almacenada por filas

La principal ventaja de este tipo la encontramos a la hora de acceder a los datos,

pues al tratarse de un bloque de memoria compacto no es necesario acceder primero al

vector intermedio para luego acceder al dato. La principal desventaja de este tipo aparece

al trabajar con matrices de muchos elementos, pues el programa reserva estas matrices

sobre la pila, un recurso limitado que terminara con la ejecucion del programa si se agota.

2Array de tamano variable (Variable Length Array)

22


M2D

Existe un tipo de matrices, que internamente denominamos M2D3 en la que se guardan

de manera compacta los elementos de cada fila, precedidos de una cabecera que indica

donde comienza cada una de las filas. Con esta configuracion todo lo necesario para acce-

der a la matriz esta en la misma region de memoria y el acceso a los elementos es sencillo

para el programador.

M(i, j) → M [i][j]

Figura 5.4: M2D almacenada por filas

Esta matriz no elimina el primer acceso para conocer la localizacion de la fila pero

sı que lo acelera al asegurar que toda la informacion necesaria esta en el mismo bloque

que los datos de la matriz.

El principal problema de estas matrices es su creacion, ya que es el programador el

que tiene que reservar el espacio de memoria correspondiente a los datos y a la cabecera,

que luego ha de rellenar con la posicion de memoria correspondiente al comienzo de cada

una de las filas.

5.3.2. Matrices Matlab

Matlab es un lenguaje de mas alto nivel y matematico, disenado para trabajar con

matrices. Sus operaciones sobre matrices son mucho mas potentes que las de C, ya que el

propio lenguaje incluye operadores para sumar, restar, multiplicar, trasponer... matrices.

Ya que matlab esta disenado para realizar operaciones con matrices, el primer elemen-

to de la matriz es el elemento numero 1, al igual que ocurre en las matrices en matemati-

cas.

Matrices dispersas

Este tipo de matrices solo almacenan aquellos elementos que no son nulos. MatLab

es capaz de trabajar con ellas sin ningun problema, pero tratar con ellas a bajo nivel es

complicado, por lo que no se tendran en cuenta de cara al algoritmo.

3Matriz 2D

23


Matrices completas

Son el principal tipo de matrices que se utilizan dentro de MatLab, matrices que al-

macenan todos los elementos que contienen, nulos o no. Ademas de todos estos datos,

las matrices almacenan una pequena cabecera indicando el numero de dimensiones de la

misma y la longitud de estas dimensiones, entre otros datos.

A la hora de trabajar con ellas desde una interfaz MEX la matriz aparece como un

bloque de memoria compacto y transpuesto. Esta transposicion es debida la manera en la

que MatLab almacena sus matrices, agrupando los valores por columnas en lugar de por

filas.

Figura 5.5: Matriz compacta almacenada por columnas

5.4. Almacenamiento de los datos leıdos

Como el algoritmo debe invertir la menor cantidad posible de tiempo en las fases de

lectura y almacenamiento de los datos se ha optado por utilizar un bloque de memoria

compacto para los datos todavıa sin procesar, que el algoritmo transpone y transforma en

una M2D antes de realizar el calculo de los ındices.

Aunque este metodo podrıa parecer poco optimo ya que es necesario transponer los

datos almacenados cada vez que se va a procesar un fragmento, si quisieramos guardar

los datos tal y como los recibe el algoritmo serıa necesario segmentar los datos de entrada

para copiarlos uno a uno a su lugar de destino correspondiente, anadiendo una logica y

una serie de calculos que habrıa que ejecutar cada vez que se lee un fragmento y que no

impide que luego sea necesario transformar la matriz en una M2D, ya que estas matrices

no pueden ser redimensionadas facilmente, por lo que no son apropiadas para un buffer

en el que el tamano varıa frecuentemente.

5.5. Informacion para almacenar globalmente

Junto con los datos que lee el algoritmo se deben almacenar tanto los parametros

necesarios para procesar un fragmento como las matrices sobre las que se calculan los

resultados parciales de cada etapa y el resultado final que genera el algoritmo una vez ha

leıdo todos los datos.

Ya que toda esta informacion debe estar disponible para el algoritmo desde el principio

del mismo se ha optado por reservar la memoria necesaria e inicializar todos los valores

que sea posible una unica vez al principio y reutilizarlos hasta que el algoritmo llegue a

su fin.

24


Capıtulo 6

Estructura HSLMN RT

Como ya se ha ido mencionado a lo largo de todo este documento, es necesario al-

macenar un estado global que mantenga tanto los datos que se han leıdo como cierta in-

formacion necesaria para procesarlos. Estos informacion se almacena dentro de un struct

llamado rt state.

Dada la naturaleza del algoritmo HSLMN RT podemos dividirlo en tres fases, una

de inicializacion, una de procesamiento, que se ejecuta multiples veces y una fase de

finalizacion y limpieza, que aparecen explicadas al lo largo de este capıtulo. Al final del

mismo se tambien incluye una version del algoritmo en pseudocodigo.

6.1. Inicializacion

Esta primera fase ha de ejecutarse antes de poder empezar a procesar, pues es el punto

donde se reserva toda la memoria que necesita el programa para su correcto funciona-

miento y donde se inicializan todas las variables globales que se van a utilizar.

En esta primera version se reserva espacio para las matrices que almacenan el valor

promedio de los ındices, para las que almacenan los resultados parciales y para el buffer

de memoria en el que almacenar el los datos que utiliza el algoritmo para calcular los

ındices. Es en este ultimo punto donde surgen la mayor parte de las dudas, pues debemos

decidir cuanto espacio hay que reservar.

Debemos tener en cuenta que, salvo en los extremos de los datos, donde la informacion

es mas limitada, el algoritmo necesita disponer de la informacion de 2*w muestras, wanteriores y w posteriores, para poder procesar correctamente una muestra concreta.

Para que el algoritmo pueda almacenar datos que aun no estan procesados, nece-

sitamos reservar una cantidad de espacio mayor, que para esta primera version es de

3*(2*w), que permite que se procesen un maximo de 2*(2*w) muestras en la si-

guiente iteracion.

Ademas de reservar los bloques de memoria que acabamos de mencionar, en esta fase

25

CAPITULO 6. ESTRUCTURA HSLMN RT

se inicializan los siguientes campos, que se utilizan durante todo el algoritmo:

first sample Primera muestra de los datos almacenados que el algoritmo debe procesar.

Es necesario disponer este campo ya que despues de la primera iteracion el buffer

con los datos leıdos contiene datos ya han sido procesados pero que todavıa son

necesarios para procesar las siguientes muestras.

last sample Ultima muestra de los datos almacenados que el algoritmo debe procesar.

Dado que el algoritmo necesita wmuestras posteriores a la que esta procesando, este

campo limita la ultima muestra que puede procesar, dejando todas aquellas muestras

posteriores sin procesar para que sean procesadas en siguiente etapa, cuando se

hayan leıdo mas.

total samples Numero total de muestras que se han leıdo desde el comienzo del algorit-

mo. Se utiliza para llevar una cuenta de las muestras leıdas y ası poder informar al

usuario.

samples processed Numero de muestras que ya han sido procesadas. Se utiliza para cal-

cular el valor promedio de los ındices, pues este depende del numero total de mues-

tras procesadas.

channels Numero de canales de los datos. Necesario para comprobar si el numero de ca-

nales cambia a lo largo del algoritmo y para poder reservar el buffer interno, ya que

como no es posible indicarle al lenguaje C que queremos reservar espacio para Xmuestras, debemos reservar espacio para X*num canales*sizeof(<tamanode una dato>).

size Numero de datos actualmente almacenados en el buffer. Se utiliza tanto para deter-

minar si es posible procesar un fragmento del tamano requerido por el usuario como

para saber si una lectura adicional desbordarıa el buffer.

max size Tamano maximo del buffer. Es el tamano del buffer en el que se almacenan los

datos y limita el numero maximo de datos que podemos almacenar.

Ya que para la fase de inicializacion es necesario reservar un bloque con un tamano

que varıa en funcion del numero de canales, es necesario conocer de antemano el numero

de estos, leyendo el primer fragmento antes de la fase de inicializacion.

6.2. Procesamiento

Esta fase, que podrıamos considerar el nucleo del algoritmo, se puede a su vez dividir

en otras cuatro fases, que se explicaran a continuacion y que anaden flexibilidad al algo-

ritmo, pues al separar la lectura y el almacenamiento del calculo de los ındices se pueden

utilizar diferentes enfoques a la hora de recibir los datos.

Aunque para esta primera version se ha optado por un enfoque basado en una ventana

deslizante donde se almacenan los datos, en la seccion 10.1 se mencionan otras posibles

alternativas.

26


6.2.1. Lectura

Como primer paso en la fase de procesamiento es necesario leer un fragmento de un

tamano al menos lo bastante grande como para poder procesar un fragmento del tamano

que indique el usuario mediante el parametro trigger.

Esta lectura del tamano que necesita el algoritmo se puede realizar en varias iteracio-

nes, siendo el propio algoritmo el que comprueba si ya dispone de bastantes datos o si

es necesario realizar otra iteracion para leer mas antes de empezar a procesar un nuevo

fragmento.

6.2.2. Almacenamiento

Tras realizar la lectura es necesario mover los datos leıdos del buffer temporal sobre

el que se han ido leyendo al buffer interno del algoritmo, ya que hasta este momento el

algoritmo no sabe que se han leıdo nuevos datos.

Para realizar esta operacion se copia la totalidad del bloque memoria en el que estan

almacenados los datos que se han leıdo en la ultima etapa justo a continuacion del ultimo

dato dato que estaba almacenado.

Recordamos que es posible hacer esta copia directamente ya que los datos se alma-

cenan de igual manera que se leen, por lo que, antes de poder procesarlos sera necesario

transponerlos y transformarlos al formato que necesita algoritmo para procesarlos correc-

tamente.

6.2.3. Procesamiento

En esta fase del algoritmo, a la que solo se puede acceder tras comprobar que se dispo-

ne de suficiente informacion para procesar al menos un fragmento de tamano trigger,

se procesan tantos fragmentos como sea posible con los datos que haya almacenados en

ese momento.

El primer paso consiste en convertir el bloque de memoria compacto que contiene los

datos a procesar en una M2D, que posteriormente se transpone, dejando los datos en la

configuracion idonea para el algoritmo.

Con los datos ya completamente preparados se establecen una serie de lımites para,

en las muestras alejadas de los extremos, no procesar aquella que no tengas al menos wmuestras posteriores, lo que desvirtuarıa tanto los resultados parciales de esa etapa como

el valor promedio de los ındices que se calcula al final.

Una vez se han definido los lımites, el algoritmo entra en un bucle para procesar estos

fragmentos de tamano trigger. Cada iteracion del bucle procesa trigger muestras

mediante una llamada a la funcion HSLMN delta, nucleo del algoritmo HSLMN origi-

nal que permite procesar un bloque datos de cualquier tamano.

27


Cuando el algoritmo retoma el control despues de la llamada a HSLMN delta se

anade el resultado a las matrices donde se va almacenando el resultado final y se calcula

el resultado parcial, para poder mostrarlo posteriormente.

Con el calculo de este resultado parcial se llega al final del bucle, que se repite tantas

veces como fragmentos de tamano trigger para procesar disponga el algoritmo.

6.2.4. Reempaquetado de los datos

Tras haber procesado todos los datos o no tener necesario para procesar otro fragmento

completo, el algoritmo procede a reempaquetar los datos en el buffer para poder volver a

pasar por las fases de lectura y almacenamiento.

Este reempaquetado de los datos se realiza deslizando la ventana de los datos que se

pueden procesar al principio del buffer, moviendo tanto los muestras que hayan queda-

do sin procesar como las ultimos w muestras, necesarias para realizar correctamente el

calculo de las proximas muestras.

Al realizar el reempaquetado es necesario modificar rt state.first sample y

rt state.last sample para reflejar cuales de los datos del buffer se pueden proce-

sar y cuales no.

6.3. Finalizacion

Una vez se han leıdo todos los datos del experimento que se esta estudiando, el al-

goritmo realiza dos funciones mas, el calculo final del valor promedio de los ındices,

con su correspondiente volcado donde corresponda y la liberacion de todos los recursos

asociados.

Para el calculo final de los ındices el algoritmo vuelve a ejecutar una fase de procesa-

miento en la que se terminan de procesar todos los datos que queden en el buffer, pues ya

sabemos que no vamos a recibir mas datos.

La parte de liberar los recursos asociados al algoritmo consiste en realizar las lla-

madas a la funcion free sobre los recursos que se hayan reservado y marcarlos como

no-inicializados.

6.4. Diferencias MatLab y lınea de mandatos

Aunque la base del algoritmo es la misma en ambos casos, existen algunas diferencias

entre ambos algoritmos. Estas diferencias, aunque no varıan el resultado que produce el

algoritmo, si que varıan ligeramente como se usa, ya que la version de lınea de mandatos

es auto-contenida que lee y procesa los datos mientras que la version MatLab se limita a

procesar los datos, recibiendolos como argumento.

28


6.4.1. Lectura de datos

Mientras que en la interfaz de lınea de mandatos el algoritmo recibe un descriptor de

fichero, la interfaz MatLab esta disenada para ser llamada repetidas veces recibiendo un

fragmento de datos. En el primer caso es el propio algoritmo el que lee todos hasta que

se queda sin, mientras que en el segundo caso es el usuario que llama al algoritmo el que

indica cuando se han acabado de leer los datos.

6.4.2. Recogida de resultados

La version de lınea de mandatos simplemente vuelca los resultados a un fichero, solu-

cion que no es valida para la version MatLab, pues los resultados han de recogerse desde

el entorno de MatLab, no sobre un fichero.

Es esta necesidad la que fuerza al algoritmo a no bloquear el entorno en el intervalo

de tiempo desde que se invoca el algoritmo hasta que este devuelve los resultados finales,

sino que tras cada una de las etapas en las que se procesan o se intentan procesar los

datos almacenados el algoritmo devuelve tanto el control como los resultados parciales al

entorno MatLab.

Aquı el usuario ha de tener en cuenta que el algoritmo solo es capaz de devolver

el resultado parcial del ultimo fragmento procesado, por lo que si alimenta el algoritmo

con bloques de datos mas grandes o mas pequenos que el tamano del fragmento que

desea procesar, se encontrara con que le falta informacion de fragmentos que han sido

procesados o que el algoritmo devuelve varias veces la informacion del mismo fragmento,

ya que no dispone de bastantes muestras para procesar uno nuevo

6.4.3. Deteccion del final de lectura

El algoritmo con interfaz para lınea de mandatos es capaz de detectar cuando no tiene

mas datos para leer en el descriptor que se le ha indicado, por lo que en ese momento

puede pasar a ejecutar la fase de finalizacion.

No ocurre lo mismo en el caso de MatLab, pues al realizarse la lectura fuera del

algoritmo este no es capaz de determinar cuando dejaran de llegar datos, por lo que la

responsabilidad de indicarle al algoritmo cuando debe calcular el resultado final recae

sobre el usuario, que debe indicarselo al algoritmo mediante la invocacion de una funcion.

6.5. Pseudocodigo

29


Algoritmo 1 Fase de inicializacion

if algoritmo no inicializado thenrt state.first sample = 0;rt state.last sample = 0;rt state.total samples = 0;rt state.channels = num canales;rt state.size = 0;rt state.max size = 3 ∗ (2 ∗ w) ∗ rt state.channels;rt state.data = reservar espacio(rt state.max size);reservar espacio para los indices();

end if

Algoritmo 2 Fase de procesamiento

while quedan datos por leer domuestras leidas = leer un fragmento();copiar datos leidos al buffer();rt state.last sample += num canales ∗muestras leidas;rt state.total samples += muestras leidas;rt state.channels += num canales;rt state.size = 0;if hay bastantes datos para procesar thendatos M2D = transformar en M2D(rt state.data);datos = transponer M2D(datos M2D);Il = ultimo fragmento procesable();for i = rt state.first stample to Il doIb = i;Ie = min(i+ trigger, Il);fragment size = Ie− Ib;if fragment size != trigger thenbreak;

end ifcnt = HSLMN delta();samples processed += cnt;acumular valor indices finales();calculo valor indices parciales();

end forrecompactar datos();

end ifend while

Algoritmo 3 Fase de finalizacion

if algoritmo inicializado thenprocesar datos restantes();liberar espacio(rt state.data);liberar espacio para los indices();

end if

30


Capıtulo 7

Visualizacion de los resultados

Con el algoritmo ya terminado el siguiente paso es crear una interfaz que permita vi-

sualizar los resultados parciales que devuelve el algoritmo. Como existe una version para

MatLab del algoritmo se ha optado por implementar la interfaz dentro de este entorno.

Para visualizar los resultados se utiliza una grafica que se actualiza con los valores

parciales que devuelve el algoritmo. Gracias a la potencia del entorno de MatLab existen

varias maneras de hacer esta actualizacion, que se exploraran en la siguiente seccion.

7.1. Opciones de visualizacion

7.1.1. Redibujar la grafica en cada iteracion

La primera opcion considerada consiste en borrar la grafica antigua redibujando la

nueva grafica encima mediante la funcion plot cada vez que el algoritmo produce nuevos

resultados.

% Crear graficax = 0:0.1:2*pi;y = sin(x);plot(x,y);% Actualizar datosy = sin(x.ˆ3);% Redibujar graficaplot(x,y);

Esta opcion aunque es la mas sencilla tambien la menos eficiente, ya que MatLab debe

destruir y volver a reconstruir todos los objeto asociados a la grafica (ejes, lıneas, textos,

divisiones...) cada vez que hay una modificacion en los datos. Como ventaja tambien cabe

destacar que esta es la opcion mas clara de cara al usuario, ya que cada vez que hay que

actualizar la grafica simplemente se dibuja una nueva.

31

CAPITULO 7. VISUALIZACION DE LOS RESULTADOS

7.1.2. Refreshdata

La siguiente opcion considerada es utilizar la funcion refreshdata que proporciona

MatLab. Esta funcion actualiza todas las graficas que conocen cual es el origen de sus

datos en el momento en el que se llama a la funcion.

1 % Crear grafica2 x = 0:0.1:2*pi;3 y = sin(x);4 h = plot(x,y);5 % Indicar el origen de los datos6 set(h,’YDataSource’,’y’)7 set(h,’XDataSource’,’x’)8 % Actualizar grafica9 y = sin(x.ˆ3);

10 refreshdata;

Sin embargo, debido al funcionamiento interno de la funcion, refreshdata explora

todos las graficas que existen en el programa aunque actualizar solo aquellas cuyo origen

de datos conoce. Aunque es posible indicarle que grafica se quiere actualizar su eficiencia

es menor que la de otras opciones.

A estos costes hay que anadir la existencia de un error en algunas versiones de MatLab

que impide que la funcion refreshdata actualice las graficas con mas de una funcion en

ellas, como es nuestro caso al querer mostrar simultaneamente los resultados de los 6

ındices (H, S, L, M, N y SL)

7.1.3. Modificar graficas

La ultima opcion consiste en modificar de manera manual la informacion de los datos

que se pintan en la grafica e indicarle a MatLab mediante la funcion drawnow que tiene

que redibujarla.

1 % Crear grafica2 x = 0:0.1:2*pi;3 y = sin(x);4 h = plot(x,y);5 % Actualizar datos6 y = sin(x.ˆ3);7 set(h,’YData’,y);8 % Actualizar grafica9 drawnow;

Esta ultima opcion es la mas rapida de las 3, pues solo se solo cambiamos la informa-

cion de la grafica que se ha modificado. Tampoco es difıcil de entender, pues se realiza

con una llamada a la funcion set, equivalente a realizar una asignacion.

32


7.2. Comparacion de tiempo

Para comprobar la eficiencia de las distintas opciones se ha medido el tiempo necesa-

rio para actualizar una misma grafica 10000 veces con las tres opciones mediante el uso

del siguiente programa:

1 x = 0:.1:2;2 y = sin(x);3 h = plot(x,y);4 set(h,’YDataSource’,’y’)5 set(h,’XDataSource’,’x’)6

7 % Redibujar grafica8 tic9 for i=1:10000

10 y = sin(x.ˆ3);11 delete(h);12 h = plot(x,y);13 end14 toc15

16 % Refreshdata17 tic18 for i=1:1000019 y = sin(x.ˆ3);20 refreshdata(h);21 end22 toc23

24 % Actualizar datos25 tic26 for i=1:1000027 y = sin(x.ˆ3);28 set(h,’YData’,y);29 drawnow;30 end31 toc

Como se puede comprobar en la figura 7.1, la ultima alternativa es 5 veces mas rapida

que dejarle a MatLab la actualizacion de los datos y en torno a 8 veces mas rapida que

borrar y redibujar la nueva grafica en el lugar de la anterior.

33

CAPITULO 7. VISUALIZACION DE LOS RESULTADOS

Figura 7.1: Comparacion entre los distintos metodos para actualizar una grafica

7.3. Opcion escogida y detalles de la implementacion

Tras este pequeno estudio de las distintas opciones se opto por implementar la interfaz

actualizando manualmente los datos de cada uno de los ındices manualmente para despues

llamar una unica vez a la funcion drawnow.

Antes de comenzar a procesar los datos es necesario inicializar las graficas que mues-

tran los ındices, almacenando sus handlers, indicar que canales se desean visualizar (cada

ındice devuelve el resultado de comparar los canales por parejas) y finalmente inicializar

los textos que acompanan a la grafica mostrando el valor numerico de los ındices.

Como se explico anteriormente, la version MatLab recibe los datos del propio progra-

ma y devuelve el control a MatLab una vez procesado el fragmento del tamano indicado.

Es al retomar el control tras procesar un fragmento de datos cuando se anaden al final

de los ındices el nuevo valor calculado, se actualizan las los ejes, para mostrar unicamente

el fragmento de los datos deseado (pues de otra manera tras unos segundos no serıa posible

distinguir claramente su valor) y se ordena a MatLab que redibuje la grafica.

34


Capıtulo 8

Resultados obtenidos

Uno de los principales objetivos de este proyecto ha sido siempre mantener la eficien-

cia que caracterizaba a los algoritmos HSLMN y FSL, bases del original, sin olvidar que

el objetivo principal es poder visualizar la evolucion de las distintas senales del experi-

mento a lo largo del mismo.

8.1. Visualizacion de resultados

Con los algoritmos originales es posible realizar una visualizacion a posteriori de los

resultados parciales. Esta visualizacion es muy costosa, pues es necesario procesar el fi-

chero original del experimento, indicando que se desean volcar los resultados parciales.

Una vez hecho esto es necesario procesar este nuevo fichero para transformar los resulta-

dos a un formato facil de visualizar que permita finalmente mostrarlo.

El nuevo algoritmo es mas rapido ya que muestra los resultado parciales a medida que

se van calculando, eliminando la necesidad de tener que procesar un segundo fichero, con

el coste que esto supone.

La figura 8.1, extraıda directamente del entorno MatLab, muestra el resultado del pro-

cesamiento y la visualizacion del experimento “da”, mientras que en la figura 8.1, obteni-

da de la misma manera que la anterior, se muestran los primeros instantes del experimento

“pt”. Con este nuevo algoritmo es posible ver la evolucion del valor del ındice en tiempo

real, pudiendo compararlo con el valor en instantes de tiempo anteriores.

35

CAPITULO 8. RESULTADOS OBTENIDOS

Figura 8.1: Resultados experimento “da”

Figura 8.2: Resultados experimento “pt”

36


Con los resultados de las dos figuras anteriores es complicado asegurar que el algo-

ritmo funciona correctamente, por lo que se han utilizado los datos de otro experimento

sintetico, al que hemos llamado “sin-cos”, con un comportamiento predecible.

Este experimento esta compuesto por 2 canales con 4000 muestras en cada canal,

obtenidos de los datos de un seno y de un coseno. El valor de sincronizacion sera maximo

en los puntos que el seno y el coseno coinciden, por lo que para un experimento de 1 solo

perıodo se espera encontrar dos picos que indiquen esto.

Figura 8.3: Datos del experimento sin-cos

37


La figura 8.4 nos da una confirmacion visual de que el algoritmo detecta los picos de

sincronizacion, primer paso para asegurar que el algoritmo funciona correctamente.

Al repetir el experimento alimentando al algoritmo una y otra vez con los mismos

datos observamos como estos picos que muestran la sincronizacion se repiten una y otra

vez sin cesar, prueba con la que podemos confirmar que el algoritmo es capaz de mantener

el bucle de lectura-procesamiento sin devolver datos erroneos, tal y como muestra la figura

8.5

Figura 8.4: Resultado experimento “sin-cos”(1 perıodo)

Figura 8.5: Resultado experimento “sin-cos”(varios perıodos)

38


8.2. Rendimiento

Los dos factores importantes a tener en cuenta de cara al procesamiento de las senales

son el tiempo necesario para procesar una senal y la cantidad de memoria necesaria para

hacerlo que en el caso de dispararse limitarıan la viabilidad del algoritmo.

8.2.1. Tiempo de ejecucion

Al realizar la comparacion entre el algoritmo unificado, con prestaciones similares a

los originales, y el algoritmo de tiempo real se ha observado que el coste de pintar en cada

etapa los es apenas apreciable.

Para esta comparacion se ha procesado el experimento “paciente test”, el experimento

mas largo de los que disponemos, con la version MatLab el algoritmo HSLMN unificado

y con el algoritmo HSLMN RT, indicando la opcion de volcar resultados parciales cada

100 muestras a ambos.

El algoritmo HSLMN RT es mas lento que el algoritmo original, pues tiene que en-

cargarse no solo de calcular el valor de los ındices sino que tambien tiene que mostrar

los datos. La principal diferencia que permite que el algoritmo HSLMN RT compita en

tiempo contra el algoritmo original la encontramos en la parte del mismo.

Las figuras 8.6 y 8.7 muestran una comparativa tanto del tiempo necesario para pro-

cesar el experimento como como del numero de muestras que es capaz de procesar el

algoritmo. Ambas graficas muestran que el algoritmo HSLMN RT es un 2 % mas lento

que el algoritmo original, un dato bastante impresionante teniendo en cuenta las dimen-

siones del experimento

Podemos atribuir que la diferencia sea tan pequena a que el original realiza el vol-

cado de los datos sobre el disco en cada etapa (una operacion muy lenta) mientras que

el algoritmo HSLMN RT devuelve los datos MatLab como variables, evitando todas las

operaciones de entrada/salida.

39


Figura 8.6: Tiempo promedio necesario para procesar el experimento “pt”

Figura 8.7: Capacidad de procesamiento de los algoritmos frente al experimento “pt”

40


8.2.2. Uso de memoria

El otro factor a considerar a la hora de evaluar el rendimiento de la funcion es la canti-

dad de memoria que necesita para procesar un experimento. El algoritmo original necesita

almacenar en memoria el 100 % de los datos que va a procesar, por lo que a medida que

aumenta el numero de datos a procesar, las necesidades de este son mayores. El nuevo

algoritmo HSLMN RT utiliza un buffer de un tamano finito, que reutiliza completamen-

te, por lo que la cantidad maxima de memoria que necesita el algoritmo depende de los

parametros del algoritmo, no del numero de muestras que se procesen.

En la figura 8.8 encontramos el resultado de aplicar ambos algoritmos a una serie de

experimentos creados a concatenando varias veces seguidas los datos del experimento

“sin-cos”. En ella se muestra el maximo de memoria que ha necesitado el algoritmo para

procesar los distintos experimentos. Esta cantidad varıa mucho en el caso del algoritmo

HSLMN unificado pero se mantiene constante en el caso del algoritmo HSLMN RT.

Figura 8.8: Uso maximo de memoria durante el procesamiento de distintos experimentos

41


42


Capıtulo 9

Conclusiones

A lo largo de este proyecto se han transformado dos algoritmos, cuyo funcionamiento

era bastante similar, en un unico algoritmo bien optimizado con un objetivo muy concreto.

Examinando punto a punto los distintos pasos que debıan darse para llegar al objetivo final

es posible identificar cuales son los componentes claves del mismo, aquellos en los que

dependen tanto su efectividad como su eficiencia.

Aunque el algoritmo queda lejos de ser perfecto, pues existen varios aspectos mejora-

bles que se tratan en el capıtulo 10, si que es un algoritmo robusto que permite procesar

un conjunto de gran tamano en un tiempo razonable. La robustez del algoritmo es uno

de sus puntos claves, ya que lucha contra el principal problema del analisis de datos en

tiempo real, la incertidumbre frente a la naturaleza de la entrada.

Es esta incertidumbre la que ha marcado el desarrollo de casi todo el proyecto, pues

es la que ha determinado que el algoritmo debe poder leer cualquier cantidad de datos,

que ha de ser reentrante para no bloquear el entorno desde el que se utiliza y la necesidad

de desacoplar lectura, almacenamiento y procesamiento de los datos.

En la parte de unificacion de los algoritmos se ha visto como un mal diseno a la hora de

desarrollar un algoritmo puede aumentar dramaticamente el tamano del codigo del mismo

y dificultar enormemente tanto la legibilidad como la facilidad de realizar modificaciones

sobre el.

Tambien quiero hacer hacer notar la importancia de tener una buena planificacion que

detalle claramente los pasos que se han de seguir desde el principio hasta el final de un

proyecto. En un proyecto mal planificado es muy complicado saber que tareas hay que

llevar a cabo y que tareas estan ya terminadas, pudiendo llegar incluso a situaciones en

las que, debido a esto, se realiza el trabajo por duplicado.

Para concluir, me gustarıa realizar una valoracion de lo que a mi me ha supuesto este

proyecto. Gracias a el he podido trabajar siguiendo una buena planificacion en un entorno

en el que he sido capaz de integrarme muy facilmente. Tambien me ha permitido profun-

dizar en el uso de herramientas y tecnologıas de profiling y depuracion, imprescindibles

para realizar trabajos serios. Puedo afirmar que estoy orgulloso de haber realizado este

trabajo y de pensar que puede llegar a ayudar a muchas personas en el dıa de manana.

43

CAPITULO 9. CONCLUSIONES

44


Capıtulo 10

Trabajos futuros

A lo largo del trabajo se han explorado varias alternativas en diferentes aspectos del

diseno y desarrollo tanto del algoritmo HSLMN RT como de la interfaz de visualizacion

de los resultados.

En esta seccion se van a exponer algunos posibles aspectos que aunque quedan fuera

del ambito del proyecto, podrıan revisarse en otros futuros proyectos tanto como para

mejorar el algoritmo como para encontrar nuevos usos para el.

10.1. Alternativas en la lectura y el almacenamiento delos datos

Actualmente el algoritmo procesa los datos almacenados en un buffer que actua como

ventana deslizante sobre los datos del experimento que esta procesando. Esta solucion,

aunque perfectamente valida, no permite realizar de manera simultanea las fases de lectura

y procesamiento de los datos, ya que solo se dispone de un unico buffer del que puede

leer el algoritmo.

El diseno actual del algoritmo facilita la modificacion de la fase de lectura y almace-

namiento de los datos para que los almacene dentro de una estructura mas compleja, como

podrıa ser un doble o triple buffer o hasta un buffer circular, que permita el algoritmo siga

recibiendo datos mientras procesa los mismos.

Otro aspecto a estudiar es la modificacion del algoritmo o de la manera en la que se

almacenan los datos para ver si es posible evitar las transformaciones y transposiciones

que hay que realizar sobre los datos antes de poder procesarlos correctamente.

45

CAPITULO 10. TRABAJOS FUTUROS

10.2. Recogida de resultados en MatLab

Como ya se ha comentado anteriormente, la interfaz MatLab puede devolver varias

veces el mismo resultado parcial u omitir el resultado de alguna iteracion, dependiendo

de los parametros con los que ha sido configurado.

Para evitar que sea necesario una configuracion muy minuciosa a la hora de llamar al

algoritmo para poder visualizar comodamente los resultados, se podrıa incluir un modulo

que almacene todos los resultados parciales que se han calculado y no han sido devueltos

a MatLab, devolviendolos como una matriz n-dimensional.

10.3. Integracion con HERMES

No hay que olvidar que los algoritmos HSLMN y SL, padres del algoritmo HSLMN RT,

estan disponibles para ser utilizados dentro de la herramienta HERMES. Aunque el nue-

vo algoritmo dispone de una interfaz para ser utilizado desde MatLab, la integracion total

con la herramienta HERMES podrıa facilitar aun mas la labor de aquellos investigadores

interesados.

10.4. Paralelizacion usando CUDA

Como se especifico al principio del documento, el algoritmo HSLMN RT tiene como

base la version paralela utilizando OpenMP del algoritmo HSLMN unificado, capaz de

calcular tanto los ındices HSLMN como el ındice SL. Junto a esta version existe otra

version paralela utilizando OpenMP y CUDA que puede dar incluso mejores resultados.

Paralelizar el algoritmo sobre GPU no es una labor complicada, ya que realmente es

el nucleo de computo HSLMN delta el que unico que lanza varios hilos para realizar

los calculos necesarios, la parte interesante de este punto reside en un estudio de las

prestaciones de esta version pues es posible que al no procesar todos los datos de golpe la

version GPU del algoritmo HSLMN rt sea incluso mas lenta debido al coste de transferir

informacion entre la CPU y la GPU.

10.5. Usos alternativos

Aunque el algoritmo se crea con el objetivo de poder facilitar las labores de estudio

del cerebro a los investigadores su uso no tiene por que quedar limitado a ese ambito.

Cabe estudiar como se pueden utilizar estos ındices de sincronizacion para observar la

correlacion entre senales con otros orıgenes completamente distintos, como podrıan ser

varios canales de audio o los datos de la bolsa de valores de un paıs.

46


Acronimos

API Interfaz de Programacion de Aplicaciones

CTB Centro de Tecnologıa Biomedica

CUDA Compute Unified Device Architecture

DATSI Departamento de Arquitectura y Tecnologıa de Sistemas Informaticos

FSL Fast Synchronization Likelihood

HERMES HERramientas de MEdida de la Sincronizacion

HSLMN Indices H, S, L, M y N

SL Synchronization Likelihood

MEX MatLab Executable

EEG Electroencefalogramas

MEG Magnetoencefalogramas

VLA Array de tamano variable (Variable Length Array)

M2D Matriz 2D

HSLMN RT HSLMN Real Time

47

CAPITULO 10. TRABAJOS FUTUROS

48


Bibliografıa

[1] C. Stam and B. van Dijk, “Synchronization likelihood: an unbiased measure of gene-

ralized synchronization in multivariate data sets,” Physica D: Nonlinear Phenomena,

vol. 163, no. 3–4, pp. 236 – 251, 2002.

[2] D. Chicharro and R. G. Andrzejak, “Reliable detection of directional couplings using

rank statistics,” Phys. Rev. E, vol. 80, p. 026217, Aug 2009.

[3] G. Niso et al., “Hermes: Towards an integrated toolbox to characterize functional and

effective brain connectivity,” Neuroinformatics, vol. 11, no. 4, pp. 405–434, 2013.

[4] F. Rosales et al., “An efficient implementation of the synchronization likelihood al-

gorithm for functional connectivity,” Neuroinformatics, vol. 13, no. 2, pp. 245–258,

2015.

[5] I. M. Cuquerella, “Optimizacion y paralelizacion de un algoritmo de sincronizacion

mediante el uso de GPUs y la tecnologıa CUDA,” Thesis, Universidad Politecnica de

Madrid, Jan 2013.

[6] S. S. Fernandez, “Optimizacion de ındices de sincronizacion generalizada para el

analisis de datos MEG,” Thesis, Universidad Politecnica de Madrid, Jan 2014.

[7] OpenMP Site. [Online] Available: http://openmp.org/wp/.

[8] CUDA Site. [Online] Available: https://developer.nvidia.com/cuda-zone.

[9] Thrust Site. [Online] Available: http://thrust.github.io/.

49

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Mon Jun 06 20:11:28 CEST 2016

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)

graduado en ingeniería informática - core.ac.uk · adaptacion a tiempo real de los´ ´ındices...

Documents