Este martes pasado comenzamos el tema 2: "Representación gráfica aplicada a la evaluación de prestaciones".
Concretamente, este martes vimos un conjunto de recomendaciones para realizar gráficos relativos a la evaluación de los sistemas informáticos. Resumidas, vienen a ser:
Minimización del esfuerzo por parte del lector
Maximizar información para hacerlo autosuficiente
Presentar el máximo de información con el mínimo de tinta
Usar el eje X para la variable independiente, el y para la dependiente, el origen en el 0,0, las abscisas y ordenadas en orden creciente, etc.
Mostrar los ejes, las subdivisiones, las medidas, escalas, etc.
Además, se comentaron los principales errores que se suelen cometer cuando se están preparando gráficas, y mostramos algunos ejemplos de gráficas con errores evidentes sacadas de la prensa escrita y TV.
Tras Semana Santa veremos que algunos de esos errores no son fortuitos, y se comenten premeditadamente para malinterpretar la información (Unidad 3). También se presentarán los tipos de gráficos más utilizados en la evaluación de sistemas informáticos (Gannt y Kiviat).
Ejercicio: En esta clase, como ejercicio se propuso partir del gráfico por defecto de algún programa de gráficos (Excel o LibreOffice, p.ej.), y convertirlo en uno que cumpla las recomendaciones anteriores estudiadas.
Esta semana comenzamos la práctica 3. En esta práctica, vamos a partir de un código fuente que compilaremos usando las opciones de profiling para analizar en qué funciones se gasta más tiempo durante la ejecución de nuestro programa.
Como ejemplo, tomemos el siguiente programa C++ en el que tenemos dos funciones que se llaman desde el main:
#include <iostream>
using namespace std;
#define MAX 1000000
int a[MAX];
int i = 0;
void rellenar(int i) {
//operaciones aritméticas incluidas para perder tiempo
double x = 0.7;
double y = (x*0.2+0.5)*(x-0.1);
x = x*(x*0.2+0.5)*(x+0.1);
y = y/x;
if (i % 2 == 0){
a[i] = (i / 2);
}else{
a[i] = (3 * i + 1);
}
}
int sumar(void) {
int suma = 0;
for(i=0; i<MAX; i++) {
suma = suma + a[i];
}
return suma;
}
int main() {
for(i=0; i<MAX; i++) {
rellenar(i);
}
int total = sumar();
cout << total << endl;
return 0;
}
Hay dos detalles que hacen muy ineficiente este programa: (1) poner el for en el main para llamar 1000000 de veces a rellenar supone un gasto de tiempo muy grande (las llamadas a subrutinas son operaciones muy costosas); (2) hemos incluido unas operaciones aritméticas que no hacen nada.
Veamos el resultado de pasar el profiler. Para ello, usamos las siguientes órdenes:
g++ -o p3a p3a.cc -g -pg
./p3a
gprof p3a
La salida es.
$ g++ -o p3a p3a.cc -g -pg
$ time ./p3a -1173078384
real 0m0.060s user 0m0.052s sys 0m0.008s
$ gprof p3a Flat profile:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 75.00 0.03 0.03 1000000 0.00 0.00 rellenar(int) 25.00 0.04 0.01 1 10.00 10.00 sumar() 0.00 0.04 0.00 1 0.00 0.00 global constructors keyed to a 0.00 0.04 0.00 1 0.00 0.00 __static_initialization_and_destruction_0(int, int)
Vemos que el 75% del tiempo se gasta en la función rellenar (ya que se hacen muchas llamadas). El 25% del tiempo se gasta en la función suma.
¿Se puede mejorar?
Quitemos las operaciones aritméticas de la función rellenar (no hacen nada realmente) y además pongamos el bucle for dentro de la función (así sólo haremos una llamada a esta función). Esto debería darnos alguna mejora:
#include <iostream>
using namespace std;
#define MAX 1000000
int a[MAX];
int i = 0;
void rellenar(void) {
for(i=0; i<MAX; i++) {
if (i % 2 == 0){
a[i] = (i / 2);
}else{
a[i] = (3 * i + 1);
}
}
}
int sumar(void) {
int suma = 0;
for(i=0; i<MAX; i++) {
suma = suma + a[i];
}
return suma;
}
int main() {
//una sola llamada a cada función
rellenar();
int total = sumar();
cout << total << endl;
return 0;
}
Como antes, para pasarle el profiler usamos las órdenes:
g++ -o p3b p3b.cc -g -pg
./p3b
gprof p3b
La salida del profiler en este caso es:
$ g++ -o p3b p3b.cc -g -pg
$ time ./p3b -1173078384
real 0m0.021s user 0m0.008s sys 0m0.012s
$ gprof p3b Flat profile:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 100.00 0.01 0.01 1 10.00 10.00 sumar() 0.00 0.01 0.00 1 0.00 0.00 global constructors keyed to a 0.00 0.01 0.00 1 0.00 0.00 __static_initialization_and_destruction_0(int, int) 0.00 0.01 0.00 1 0.00 0.00 rellenar()
Ahora casi todo el tiempo se gasta en la llamada a la función suma, y muy poco en la llamada a rellenar (sólo hacemos una llamada a cada una de las funciones, lo que hace que el tiempo empleado sea mucho menor).
A partir de este programa, se propone como práctica que tomeis un programa propio (del que tengáis el código fuente), le apliqueis el profiler y analiceis en qué funciones se gasta más tiempo. A partir del análisis, intentad mejorarlo (optimizar el cuello de botella detectado) y volved a pasarle el profiler para comprobar que lo habeis optimizado.
Se valorará que se haga con programas propios (en lugar de partir de esos ejemplos que hemos usado) y que se haga con otros compiladores distintos al gcc (p.ej. VC++, Perl, PHP, Java, etc).
El martes de esta semana dedicamos la clase de teoría a comentar el avance de las prácticas 1 y 2: cosas que se están haciendo bien y cosas con las que hay que tener cuidado al entregar prácticas.
Por ahora todas las prácticas están bastante bien (en general). Como detalles a cuidar para las siguientes entregas, cabe destacar la mejora en la expresión de la redacción y las faltas de ortografía.
Comentamos (recordamos) que quien quisiera, podía publicar en su propio blog las respuestas a las preguntas de clase o a las prácticas. Sólo tendría que enviar la URL para enlazar en el blog de la asignatura.
Por último, describimos varios posibles trabajos, mostrando qué secciones se deberían hacer, etc. En cuanto a las temáticas, en el swad está la lista de posibles trabajos. Es sólo una relación inicial, por lo que se pueden proponer nuevos trabajos.
En la clase de ayer martes día 13 se planteó el siguiente ejercicio de clase: ¿has usado monitores para comprobar tus sistemas? (sin contar con la práctica 2 de DyEC) ¿cuáles? ¿con qué objeto?
Tras ver en la primera clase en qué momentos de la vida de un S.I. hay que llevar a cabo diversas evaluaciones (y las fases en que se divide una evaluación), ayer vimos qué métricas existen, qué son los programas de monitorización y cómo medir tiempos. También vimos algunas herramientas de línea de comandos para Linux y para Windows.
En las clases de prácticas de esta semana comenzamos la práctica 2.
La semana que viene dedicaremos la clase de teoría a detallar los trabajos, y en lo posible, a que todos tengamos definido cuál vamos a hacer.
Esta semana comenzamos la práctica 2, que durará dos sesiones de prácticas.
Esta práctica la vamos a dedicar a al búsqueda, instalación y configuración de programas de monitorización para diversos S.O. Concretamente queremos medir prestaciones en los subsistemas de CPU, disco, memoria y red.
Como ejemplos de monitores, se proponen los siguientes:
Windows: monitor de windows, Aida64, gpu-z, GPU Monitor, CPUMon, Microsoft Process Explorer
OS X: iStat Pro, Net Monitor, Hardware Monitor, Activity Monitor
Por otro lado, y puesto que no sólo existen estos S.O., propongo que quien quiera, haga la práctica en otros sistemas: Android, iOS, etc. Esto será como una alternativa opcional (y conviene consultar al profesor).
¿Qué hay que entregar como resultado de hacer la práctica? Debemos hacer un documento en el que describamos cada programa encontrado/usado. Para ello, y para cada programa, vamos a dar el enlace (o la forma en que podemos encontrarlo e instalarlo); el sistema operativo bajo el que funciona ese programa; describiremos cómo se instala y configura; mostraremos alguna captura de pantalla del programa en funcionamiento; y por último diremos si las medidas observadas reflejan algún problema en la máquina (falta de memoria, cpu o disco).
Al finalizar la clase, hemos proyectado dos vídeos sobre la obsolescencia programada. Se pueden encontrar en http://bit.ly/zWBA5K
Como ejercicio se propone buscar ejemplos reales y claros de obsolescencia programada: cómo algunos fabricantes o desarrolladores ponen fecha de caducidad a sus productos o sistemas.
Al final de la primera unidad (tema 1), hemos planteado un ejercicio de clase en relación con los sistemas operativos que normalmente utilizamos en nuestras máquinas.
Se pide que busqueis información sobre los S.O. que llevan otros dispositivos diferentes a los ordenadores corrientes. Indicar las características principales, hardware en que funcionan, y qué nicho de mercado cubren.
En la clase de teoría (2h) de esta semana comenzamos el tema 1, completando las unidades 1 y 2.
Concretamente, la clase se ha dedicado a la definición de un sistema informático y los niveles de estudio de los mismos, a justificar la necesidad de la evaluación de los sistemas (a cualquier nivel), y por último, a presentar las diferentes fases en la evaluación de un sistema.
Resumidamente, estas fases son:
Especificar los objetivos y definir el sistema
Listar los servicios que ofrece el sistema y sus posibles resultados
Seleccionar las métricas
Listar los parámetros que pueden afectar a las prestaciones
Factores a estudiar
Seleccionar las técnicas de evaluación
Seleccionar la carga de trabajo
Diseñar los experimentos
Analizar e interpretar los datos
Presentar los resultados
Por último, hemos visto ejemplos de trabajos (de años anteriores) en los que siguiendo dichas fases, se evalúan varios elementos de un sistema.
Tanto las transparencias del tema como los tres ejemplos vistos están disponibles para su descarga en http://swad.ugr.es
Esta primera práctica consiste en buscar recursos relacionados con la temática de la asignatura. El PDF del guión está en el swad. En el guión falta que indicar que la entrega se hará enviando por email el documento realizado (un PDF, normalmente) en el que habrás recopilado varios enlaces, con su descripción y una puntuación que indique cómo de actualizada y objetiva es la información que hay en dicho enlace. No olvides incluir en el cuerpo del email tu nombre y apellidos. Puedes entregar la práctica cuando la tengas terminada. Cuanto antes, mejor, ya que te la quitas de enmedio. En principio, espero que todos la hagáis sin problemas a lo largo de esta semana.
Mañana día 5 comenzamos con la primera práctica de DyEC. Explicaremos sucintamente qué prácticas vamos a hacer este curso, y en detalle veremos (y comenzaremos) la primera.
Además, el martes 6 comenzamos con la teoría (veremos la mitad del tema 1).
