Apuntes del día 11 de Marzo

Aquí van los apuntes del día 11 de Marzo.

Empezamos hablando de las prácticas (La práctica 1). Han estado bien, hay un gran número de dieces (yo mismo! :D).

Hay enlaces comunes a todas las prácticas, por ejemplo pc-actual, o la asignatura de la UNED, que no están bien, bien porque las páginas no funcionan, o porque no tienen mucho que ver con la asignatura.

http://dyec-ugr.wikispaces.com/2008-3-11

Por cierto, JJ comenta que la página de Noticias3D no es muy adecuada, lo cual me parece discutible. Un par de entradas más abajo encontraréis mi opinión completa.

Luego vemos la página de slashdot, muy interesante aunque ninguno la hemos incluido. Lo hacemos porque hay un artículo interesante sobre multicores, que es de lo que hablamos. Actualmente hay máquinas de dos o 4 cores…

Hablamos de la ley de moore, que ahora ha cambiado para multiplicar los cores en vez de el rendimiento.

Un compañero nos habla de una gráfica con 128 CORES! Eso me descuadra un poco, así que entramos en un pequeño debate. Para aclararlo todo, podéis ir a la misma entrada de mis comentarios del 11 de marzo. Resumidamente, la gráfica lo que tiene son 128 stream processors (que sería la evolución de la antigua arquitectura con pipelines), no 128 cores. Algunas webs lo venden como 128 cores aunque esto no sea cierto, simplemente para captar atención (una estrategia más de marketing).

Luego vemos el ejercicio de autoevaluación de un compañero, de sistemas operativos. Hablamos de lindows, reactos, belenix, haiku…

También de BeOS, que nació como una posible alternativa a mac, pero resultó ser un fracaso.

El ejercicio de autoevaluación de otra compañera habla del citado BeOS, Symbian y Windows Mobile.

Un compañero habla de una página donde se puede ver información sobre los procesos que podamos tener corriendo en el sistema. No recuerda el nombre, pero yo sí ;), es www.processlibrary.com , muy útil a veces (añadidla a vuestra memoria o a los marcadores del zorro de fuego, lo que queráis (que no me entere que usáis el Internet Explorer…) (Antes de que salga el Pro-Opera de turno o cualquier otro operador: Mientras no uséis ni Netscape ni IE, me doy por satisfecho :P).

Se mide siempre la influencia del consumo de recursos en el rendimiento, no directamente el consumo de recursos, porque por ejemplo entre dos servidores web el consumo de recursos puede ser algo muy distinto. Los recursos consumidos, por otra parte, suelen ser del tipo nominal es mejor, porque si consumimos muy poco puede significar que tenemos una máquina que no es adecuada.

Aquí me gustaría hacer un apunte, porque esta afirmación que nos ha hecho JJ en más de una ocasión me parece interesante. No creo que la mayoría de nuestros PCs ni muchos otros ordenadores más complejos estén por encima del 1-5% de uso de CPU la gran mayoría del tiempo, pero lo importante es que cuando los tenemos al 100% se hace el trabajo indicado en el menor tiempo posible. Por ejemplo, si yo edito vídeo, excepto cuando renderizo, voy a hacer poco uso de la CPU, y eso va a ser la mayoría del tiempo, pero cuando sí renderizo, no me da igual que tarde en hacer una escena un minuto que que tarde una hora.

Volviendo a por donde íbamos de la clase, JJ comenta que normalmente cuando medimos prestaciones no medimos precio. A menos que hagamos algo del tipo “Precio por página impresa”.

Continuamos con los monitores. El otro día vimos los monitores en Windows, hoy los vamos a ver en Linux.

Qué es lo que te dice la carga del sistema? Te dice el número de procesos en media que están esperando a ejecutarse por unidad de tiempo. Lo que estamos viendo no es exactamente un monitor pero puede hacer las funciones de uno.

Hablamos de los filesystem, sistemas de archivo virtuales que se mantienen dentro de ficheros.

Vemos distintos monitores en Linux.

Los profilers son un “cacho de chisme que son muy útil”. Un poco más en serio, un profiler es un fragmento de código que te mide el uso de diferentes partes de un programa, a nivel de subrutina, de clase, incluso de línea… Hay muchos tipos de profilers.

Hoy en día es imposible programar cosas serias en código máquina.

Vemos el uso de un profiler y lo que están haciendo los distintos procesos (por ejemplo uno que se tira el 14% del tiempo clonando vectores)

Hablamos de la segunda y tercera prácticas.

La segunda práctica hay que entregarla antes del 31 de marzo.

Hablamos de las métricas de la carga de trabajo más comunes.

Throughput o número de peticiones procesadas en la unidad de tiempo; se puede aplicar tanto a procesadores como a unidades de entrada salida, como, por ejemplo, a tarjetas gráficas (triángulos dibujados en la unidad de tiempo).

Tiempo de respuesta: opuesto del throughput (para un solo elemento), es el tiempo que se tarda en procesar una petición.

Eficiencia es la tasa del throughput máximo al throughput que se consigue de forma efectiva.

Ancho de banda: bits por segundo que es capaz de procesar el sistema. No confundir con baudios.

Porcentaje de utilización de diversos componentes y solapamiento entre los mismos, es decir, la proporción de tiempo que cada uno de los dispositivos está funcionando y la proporción de tiempo durante la cual están funcionando simultáneamente. Cuanto mayor sea el solapamiento, mayor será la eficiencia del sistema, pues ningún dispositivo estará esperando a que otro acabe sus tareas para funcionar.

Overhead: es decir, tiempo usado en tareas que no son directamente del usuario.

Factores relacionados con la multiprogramación: tales como el tiempo usado en cambiar de contexto.

Factores relacionados con la memoria virtual: fallos de página, número de veces que se ha hecho swapping.

Factores relacionados con la memoria caché de CPU: similares a lo dicho con la memoria virtual, y aparte veces que se vacían los buffers TLB, por ejemplo.

Otros subsistemas: red, gráficos (que tienen mucha importancia últimamente).

Vimos (o lo intentamos, porque resulta ser un poco largo) durante clase el vídeo de la semana: un profiler de una aplicación web con Visual C++.

Ha vuelto a ejecutar el monitor de antes y podemos ver que tiempo de usuario + tiempo de sistema no es igual al tiempo de ejecución ya que tenemos más programas ejecutándose en nuestro sistema. El tiempo invertido era más del doble de la suma del tiempo de usuario y el tiempo de sistema

- Tiempo de usuario: Tiempo en código de usuario
- Tiempo de sistema: Tiempo en ejecutar llamadas al sistema, funciones kernel, tiempo dentro de la API...
- Tiempo de E/S: Tiempo que el proceso espera a que se produzca una E/S

Finalizamos hablando de los DNS (Cuando se pide a un explorador que abra una página, se pide al servidor DNS más cercano la dirección de esa página) y de cómo al acceder a una página puede ser que dentro de la misma haya objetos ubicados en otras páginas de las que también tendremos que ver su dirección.

Un saludo a todos.