sábado, 26 de julio de 2008

Trabajo final

Buenas!
Aquí dejo el trabajo final:


Éste es el final del curso y probablemente el final de este blog.
Quisiera dejar como últimas anotaciones mis impresiones sobre la asignatura.
Ésta es una asignatura que se hace entretenida, que no resulta difícil y que tiene un objetivo práctico y para la vida real.
Yo no me he tenido que esforzar quizá tanto como otros alumnos porque siempre me han gustado los temas que se han tratado en la asignatura y por ello con poco más de 3 horas a la semana (más las de clase) he podido sacar una buena nota (de hecho he obtenido mi primera matrícula de honor en la carrera y el primer 10 que saco desde hace mucho tiempo :D ); lo que quiero decir es que si se lleva más o menos con constancia, por poco que se haga, es fácil de aprobar (siempre que vayas a clase).
Mención especial a JJ, que ha sido de los mejores profesores con los que me he encontrado en esta facultad, sobre todo por su enfoque práctico y directo de las cosas. Ojalá siga muchos años en la docencia ;).

Un saludo a todos, presentes y futuros alumnos, y espero que todo lo que aquí está colgado pueda serviros para cualquier cosa (mientras no hagáis una copia descarada o al menos me deis algo de crédito! xD)

jueves, 22 de mayo de 2008

Directrices generales para la asignatura

Voy a hacer un resumen de lo que hay que tener claro para la asignatura, ya que no vamos a tener más clases (aunque en verdad casi que lo hago más por los que no han pisado la clase).

Algunos parece que todavía no tienen claro de qué va todo esto. La asignatura no tiene un examen final, sino que hay que entregar un trabajo. El trabajo tiene tema libre, a elegir entre los que se nos proponen aquí. Incluso, si se te ocurre alguna otra cosa, puedes mandarle un mail al profesor y sugerirle que ponga uno nuevo. Además de por mail, se puede contactar con el profesor en Google Talk (nick jjmerelo) o en tutorías.

Lo primero de todo, si todavía no lo has hecho, es que te registres en la BD de la asignatura, te suscribas a la lista de mail, y crees una bitácora para la asignatura. Incluso, para los ya registrados, echad un ojo a vuestros datos personales: es importante que tengáis claro y bien identificado vuestro nick con vuestra bitácora de la asignatura, es decir, en el recuadro donde se pide vuestra página personal, poned la dirección de la blog de la asignatura.

El trabajo final no es toda la nota de la asignatura, por supuesto: Hay una parte que son prácticas (Se han hecho 6 a través del curso) y otra parte que es participación en la asignatura, mediante el blog, el wiki, la asistencia a clase e intervención, etc.
Respecto a las prácticas, todavía hay que entregar la sexta práctica. La fecha límite para ello es el 2 de junio.
Incluso, si no has entregado las prácticas 4 y 5, o quieres mejorar nota en ellas (y esto también va para la sexta práctica), puedes hacerlo: habrá un plazo de "repesca" de las 3 últimas prácticas (4, 5, 6) hasta el día 6 de julio. Este plazo se abrirá pocos días después de la entrega de la sexta práctica (es decir, para cuando le haya dado tiempo a JJ de corregirla), aproximadamente para el 4 de junio.
Nota: En las repescas de las prácticas, la máxima nota posible que se puede sacar es un 8.

Por último, la fecha de entrega para el trabajo final es el 6 de julio. Hay que elegir un trabajo en la página, de no hacerlo, aún entregando el trabajo, se está suspenso. Aproximadamente, para el día 11 de julio, se darán las notas del trabajo, y habrá un plazo de reclamaciones de unos días (se nos avisará de todo por e-mail).

Para subir nota, es recomendable que hagáis un puñado de ejercicios de autoevaluación. Los podéis encontrar repartidos en el temario (que podemos ver en la página de la asignatura).

En concreto, la nota final de la asignatura se calculará a partir de:
1/6 de la nota de clase (participación en clase, wiki, bitácora, etc)
2/6 de la nota de prácticas (media ponderada por sesiones de la nota obtenida en prácticas)
3/6 de la nota del trabajo final

Por otra parte, a lo mejor cuando leas los posibles enunciados de los trabajos a hacer pienses "qué fácil, comparativas, o esta otra cosa, que estoy harto de leer todos los días en tom's hardware o en no sé qué página o revista", pues no, no te dejes llevar y creas que todo es tan fácil, porque de lo que se trata la asignatura es de hacer todo este tipo de "estas otras cosas" bien, y siguiendo una metodología correcta, que a lo mejor tu página o revista favorita incumple en un par de puntos, que a ti sí podrían costarte más de un par de puntos en la nota final. Así que antes de ponerte con el trabajo, echa un buen ojo al temario, y al wiki para ver los apuntes que hemos hecho los compañeros de los días que ha habido clase y no has venido.

Dicho esto, mucha suerte a todos.
Elogios, correcciones, cosas que se me olviden, tomatazos, puñalás, o lo que queráis, en los comentarios.
Igualmente, si os queda alguna duda, en los comentarios os contesto.

Un saludo

Apuntes del día 20 de Mayo

Hoy, para variar, JJ ha pasado lista, porque venir a clase cuenta positivamente para la nota final (en sus palabras, los que estamos aquí viniendo físicamente a clase debemos tener algún tipo de recompensa) (estamos 16 en clase hoy).

Vemos el resumen de la clase anterior, de M. Ángel Medina.

Vemos un artículo que trata de razones para usar kernels precompilados. El interés que tenemos en este artículo es que comete un error básico: hablar de porcentaje de cpu usada para hacer comparaciones. CRASO ERROR!! (como se dijo el otro día en clase, seguro que a pesar de que nos hartamos de repetirlo luego habrá algún “espabilao” que la pinte en el trabajo final).

FECHAS:
Fijamos la fecha de entrega del trabajo final el 6 de julio.
La fecha de entrega de la práctica 6 es el 2 de junio.
Para el día 11 (más o menos) estarán corregidas las prácticas y se abrirá un plazo para reclamaciones. Pocos días después estarán las notas finales de la asignatura.
La repesca de las prácticas 4,5, y 6 serán el mismo día, el 6 de julio.
Las notas de clase se darán a principios de julio.

Es importante tener bien claro y asociado el nick, ID, y bitácora. Hay que echar un ojo a http://geneura.ugr.es/~jmerelo/DyEC/cgi/update.cgi para comprobar que tenemos bien puesto el nick e incluida la dirección de la bitácora como nuestra página web.

Hay gente que parece que todavía no tiene claro ni de lo que va la asignatura (es lo que tiene no venir a clase nunca, ni prestar atención a los blogs o al wiki, será que no lo ponemos fácil... y a pesar de todo algunos todavía se piensan que había examen en vez de trabajo final), en vista de ello escribo la siguiente entrada para aclarar todo lo posible el funcionamiento de lo que queda de curso.

Pasamos a ver ejercicios de autoevaluación. Vemos el de “el blog de josele” aquí.

Criticamos los gráficos que pueden verse en el enlace que nos muestra josele, tiene errores como por ejemplo el fondo en gris, líneas de guía innecesarias, no poner los nombres de las categorías debajo de su barra correspondiente, usar tipos de gráficos mezclados (unos horizontales y otros verticales) para las mismas cosas… pero va mas allá! Usa gráficos de líneas donde no corresponde, y hace comparaciones con el % de CPU usado… (lo digo otra vez? venga no, que me estoy haciendo cansino)

El benchmark tiene una parte buena que es que se ha definido bien el objetivo, pero también tiene todas estas partes malas que comentamos (o más).

Pasamos al siguiente ejercicio, ya del tema 4, de davis87.

Vemos comparativas de gráficas en tomshardware. Os recomiendo encarecidamente el siguiente enlace para comparativas de gráficas, el vga charts 2007, completísimo.

Volvemos al temario: 4.2.6 Engañando a los benchmarks

Hablamos de los juegos, que no son benchmarks del todo correctos.
Hablamos de las trampas de ati y nvidia en benchmarks como 3dmark, o los de sun en caffeinemark.
Hablamos del funcionamiento de los compiladores, y en particular del gcc.
Volvemos al benchmark que comentamos el otro día, el SPEC, tambien el TPC, útil para bases de datos.

En un respiro de hablar de benchmark, comentamos los ataques a xataka y a la página de la SGAE. Y por cierto… SÓLO 6 PERSONAS EN LA CLASE CONOCEMOS MENÉAME!! OMFG

Seguimos con los benchmarks, hablamos de Doombench.
Comento que Doom no es un juego en “tres dimensiones reales”, son más bien “dos dimensiones y media”.
Aquí se puede leer un artículo sobre el engine que utilizaba Doom (creado por John Carmack, también conocido como “el puto master of the universe”).

Frase del día: “Lo peor de los benchmarks es que a veces las prestaciones no lo son todo”… (Después vino lo de la frase dedicada con cariño a los Apple “estilizados” xD).

Todo esto de lo que hemos hablado se puede encontrar a partir de aquí.

Criticamos a las tiendas UPI un ratejo, a cuento de la frase de antes, ya que también tenemos que mirar cosas como la garantía de un producto cuando lo queremos comprar/comparar. Además, las tiendas UPI son carísimas! XD

Acabamos esta última clase viendo el vídeo del día! (Al final no hemos visto ninguno de Enjuto, bueno, supongo que se los estará guardando todos para el año que viene).

JJ Quotes - Octava Entrega -

Las últimas frases de JJ este curso, (a menos que recopilemos unas cuantas de e-mails xD):

"Por cierto, me han regalao 5 cajas de pastillas de café, pero se me ha olvidao traerlas. Al que saque mayor nota en el trabajo final le doy alguna"

"Acabaremos la clase este año sin resolver el misterio de por qué cantan en la clase de al lado?"

"Joé, se descuida uno y sacan versiones a cascoporro" (frase del pan nuestro de cada día xD)

"A veces no te interesa que sea más o menos rápido, sino que tenga una manzanita pintada..."

martes, 13 de mayo de 2008

JJ Quotes - Séptima entrega -

Situación surrealista del día: Hay algún tipo de celebración extraña en la clase de al lado. Ello provocó que JJ dijera cosas como:

Será un cumpleaños? Habrá piscina de bolas?

(Tras sonar una trompeta) A ver si es que es un marciano o algo y tenemos que desalojar, o luchar, o...


Random phrases:

Hay aquí algún aficionado a los coches? No? Sólo gta?

Los ejecutivos son tontos, ya lo sabéis! Es que no veis cuestión de sexo, o camera cafe?

Un sistema es el conjunto que cumple su cometido, no tiene por qué ser una sola cosa, puede ser un ordenador, dos ordenadores, un pc y un portátil, un portátil y un pollo... (No puede evitar pensar constantemente en el pollo bicéfalo de la universidad)

Reducir el tiempo de carga del marca en 0.2 segundos, pues no es un gran objetivo. Además, qué podría pensar el ministerio de defensa!

Apuntes del día 13 de Mayo

Comenzamos la clase hablando de la práctica 5.

La ha entregado aún menos gente, y las notas son peores. A pesar de ello, hay más dieces (yo tengo uno! :D).

FRASE DEL DÍA, por enésima vez: para comparaciones y evaluaciones, sobre todo en el trabajo final, ni se nos ocurra hacerlo con tasas de utilización!! No vale comparar el % de ancho de banda de lectura de disco usado, no vale comparar % de CPU usada, etc.

Hay que evaluar cargas del sistema relevantes. Arrancar el sistema no es un buen ejemplo, porque no es para lo que destinamos el sistema. Cosas simples como comprimir un fichero pues es demasiado tonto y tiene poca chicha.

Nuestro compañero Fran (LP) nos muestra su práctica. Ha hecho una pequeña pirulilla, su práctica quizá no es del todo correcta: casi ha cambiado el sistema, porque al principio servía con un ordenador y ha llegado a la conclusión de que es mejor servir con otro. De todos modos JJ se lo ha dado por bueno aunque algunos alumnos no están muy de acuerdo (yo personalmente creo que no está mal, pero hay que reconocer que es una pequeña trampa ;) )

Vemos el resumen de la clase anterior de saramggh.

Vemos un ejercicio de autoevaluación de davis (estamos tímidos hoy, ni Sara ni davis han querido explicar sus correspondientes entradas), que trae una interesante tabla que compara los distintos filesystem que han existido en Windows.

Comentamos, a partir de la página que ha puesto JJ en el wiki, procesadores: de wii, de ps3, de mi EEE… es un artículo interesante el de la página, leedlo.

Volvemos al temario. Estamos en el 4.2: utilización de un benchmark.

Todavía hay gente que no tiene clara la diferencia entre un monitor y un benchmark, así que la re-explicamos. Básica y rápidamente: Monitor, para ver la carga del sistema, benchmark, para cargar al sistema y ver los resultados.

Quién produce los benchmark?

- O bien son evaluados por una empresa externa, a la que se le paga por ello.
- O bien los benchmarks son propuestos por un conjunto de empresas o instituciones que acepten los resultados que arrojen.

Qué tipos de benchmark hay?
- Programas reales: Son un trabajo real, con una carga real.
- Núcleos, kernel: Son las operaciones fundamentales de una carga de trabajo.
- Benchmarks de juguete: Programas muy sencillos que miden parámetros básicos.
- Sintéticos: Son operaciones estadísticas que miden la carga de trabajo usada con una serie de programas y resume la carga.

Uno de los benchmark más conocidos es el SPEC. Vemos un ejemplo del SPEC.

Vemos errores comunes en los benchmark. REPETIMOS DE NUEVO LO DE LAS TASAS (más de uno y más de dos (entre 20 y 30 según JJ) no lo tendrán en cuenta para el trabajo final y luego pasará lo que pasará)

  • Representar solamente comportamiento medio en la carga de trabajo.
  • Ignorar la distribución desigual de las peticiones de dispositivos. Provoca que los resultados no sean muy realistas.
  • No controlar el nivel de carga de forma apropiada.
  • Ignorar los efectos de la cache. Puede falsear los resultados. Para evitarlo hay que hacer benchmark que no quepan en la caché o repitiendolo varias veces.
  • Ignorar el overhead del monitor.
  • No validar las medidas. Hacerlas varias veces. (Muy importante).
  • No asegurarse de las mismas condiciones iniciales, es decir, de que el estado de la cache sea el mismo, el de los procesos que se están ejecutando también, incluso, si es posible, la fragmentación del disco duro y el espacio que queda libre, pues, como se sabe, estos son dos factores que influyen en la velocidad del mismo. (Muy importante). Por ejemplo: ejecutar el benchmark con el ordenador recién arrancado.
  • No medir las prestaciones del transitorio, ya que la mayoría de los experimentos están diseñados para predecir las prestaciones bajo condiciones estables. Por ejemplo: en un sistema recién arrancado, la temperatura no va a ser la misma que la que tendrá pasado un rato.
  • Utilizar los porcentajes de uso de los dispositivos para comparar prestaciones. Por ejemplo el uso de CPU. (Muy importante).
  • Recoger demasiados datos con muy poco análisis. (Muy importante).

Hablamos del benchmarketing. El benchmarketing es sencillamente eso: hacer marketing utilizando los resultados de un benchmark. Pongo el ejemplo en clase de nVidia con 3DMark: cuando se detectaba que el benchmark corría, se baja la calidad gráfica para así conseguir más rendimiento y luego poder decir “nuestra gráfica es más rápida”.

Otras posibilidades son:

- Usar configuraciones diferentes para ejecutar la misma carga de trabajo
- Elegir las especificaciones de forma que favorezcan a una máquina determinada
- Usar una secuencia de trabajos sincronizada, de forma que el solapamiento entre el trabajo de la CPU y del subsistema de E/S produzcan mejores prestaciones
- Elegir una carga de trabajo arbitraria, que puede dar buenas prestaciones para una máquina determinada
- Usar benchmarks demasiado pequeños
- Proyectar o interpolar resultados de un benchmark, es decir, medir las prestaciones de un ordenador con un procesador determinado, y proyectar los resultados a otro ordenador con un número de procesadores diferente
- Elegir el sistema base de normalización de forma arbitraria

Acabamos la clase viendo el vídeo del día: Temperatura y benchmarking

Por cierto, veo que no quedó claro la otra vez cuando lo dije en el blog: El vídeo del día de hace unas sesiones, el del extreme overclocking y el Duron "volando", era un fake.