redes14-alan.txt

jacobo Bien, bienvenidos a esta charla de UMEET jacobo hoy Alan Cox hablará de "Optimización para procesadores modernos" jacobo para mantener este canal legible lo hemos puesto +m jacobo para que sólo los ops puedan hablar jacobo si teneis perguntar durante la charla, podeis preguntar en #qc Ricardo (nota: los que quieran hacer preguntas, y no sepan inglés, háganlas directamente en #qc, que alguien las traducirá) jacobo seguramente conozcais ya a Alan Cox, que es una de las principales fuerzas tras el desarrollo del núcleo de Linux jacobo es un hombre de muchos talentos, sin embargo jacobo de hecho, incluso preparó transparencias para esta charla jacobo las podeis encontrar en: jacobo http://www.linux.org.uk/~alan/Slides/ jacobo Alan, empieza cuando estés listo jacobo <Alan> Vale jacobo Esta charla es en parte acerca de cómo funcionan los procesadores modernos jacobo En su mayor parte, sin embargo, trata de por qué cambia la forma en que teneis que programar para obtener el mejor rendimiento jacobo por procesadores modernos nos referimos a cualquier cosa del pentium en adelante - y de algunos modos del 486 en adelante jacobo Hace diez años un procesador de 40 MHz era bastante rápido. Hoy, la misma posición la ocupa un procesador de 3 GHz jacobo La memoria no ha aumentado de velocidad para equipararse a esto, y de modo más importante no ha mejorado en su latencia (el tiempo que pasa entre que se pide un trozo de memoria hasta que se obtiene) mucho jacobo Los nuevos procesadores también pueden ejecutar varias instrucciones en cada ciclo del reloj, así que en realidad el procesador podría intentar acceder a la memoria no 100 veces más rápido como podríais pensar del cambio en la velocidad del reloj, sino unas 500 veces más rápido jacobo Para tratar con esto los procesadores añadieron memoria caché. Es posible construir sistemas que sólo tienen memoria muy rápida, pero esto es increíblemente caro jacobo El tipo de ordenador que podeis encontraros en vuestra mesa hoy en día tiene un subsistema de memoria muy lento - cosas como SDRAM de 133MHz y ram DDR han mejorado la velocidad de los datos, pero no suficientemente, y han hecho poco por mejorar el tiempo de acceso para unos datos dados jacobo Para daros una idea de lo lenta que es la memoria principal comparada con la caché medí la velocidad de copia de datos de la caché del procesador (llamada caché L1 o de nivel 1) y la caché más grande y más lenta (la caché L2 o de nivel 2) jacobo En un Athlon la caché L2 era 6 veces más lenta para copiar que la caché L1 jacobo La memoria principal es 8 veces más lenta que la caché L2 jacobo Así que por cada dato que tenéis que obtener de la memoria principal podríais obtener 50 de la caché jacobo Esto hace que mantener las cosas correctas en la caché sea extremadamente importante, así como saber cómo funciona la caché para que entendáis lo que se necesita para hacer mejor uso de ella jacobo En términos del "mundo real", si vuestra caché L1 fuera vuestra mesa y llevara 1 segundo, acceder a la memoria principal (vuestro fichero, por ejemplo) llevaría 1 minuto por cada elemento que tuviérais que buscar jacobo Lo mismo es cierto en casi todos los procesadores modernos. Cuanto más reciente sea el procesador suele ser mayor el hueco porque el procesador es cada vez más rápido, de forma más veloz que la memoria jacobo Lo peor es que hay limitaciones físicas en la velocidad de la memoria, y en lo rápido que las señales pueden viajar por la placa base - la velocidad de la luz es demasiado lenta hoy en día jacobo La pregunta obvia entonces es qué hay en la caché. Si sabemos qué hay en la caché y qué datos almacenará tendremos alguna idea de cómo queremos escribir nuestros programas jacobo d33p] ¿la caché puede ser manipulada por un programador? yo creía que no... jacobo d33p: en los casos normales no puede controlarse directamente la caché, pero se puede entender cómo se comporta la caché jacobo d33p: hay instrucciones en los procesadores más recientes con las que puedes ayudar a la caché - pero esa es la última transparencia de la charla 8) jacobo La caché guarda los datos y código que se utilizaron más recientemente. Así que si ejecutas un bucle, éste terminará en la caché jacobo de modo similar, si sueles mirar en una lista, el contenido de la lista terminará en la caché jacobo Ya que la caché es bastante primitiva en varias formas, los datos reales que puede almacenar en cada segmento de la caché (cada línea de caché) están bastante restringidos jacobo El procesador no tiene tiempo de mirar en toda la caché para ver si un dato ya está en ella. En su lugar, divide la dirección en varios trozos jacobo Los bits superiores de la dirección (dirección & ~4095) van al hardware de gestión de memoria para convertir una dirección virtual en una dirección física jacobo Al mismo tiempo los bits inferires se pasan a la caché. La caché mira a los bits restantes (ignorando los 4-6 más bajos, dependiendo del procesador) jacobo y mira en dos o cuatro lugares para ver si los datos que necesita están presentes. Si lo están entonces los utiliza, y cancela el trabajo que está haciendo el hardware de gestión de memoria. jacobo Esta limitación tiene algunos efectos extraños que demostraré más tarde jacobo No toda la memoria entra en caché, por supusto - sería una mala idea si se metieran en caché datos dirigidos a la pantalla y no vierais el texto porque el procesador los tuviera jacobo init64] Alan_Q: otras cachés tienen otras formas de buscar líneas. Utilizan un "comparador" por línea de cache, pero supongo que es demasiado caro para cantidades grandes de caché jacobo init64: básicamente si - cuanto más complejo sea un algoritmo más tiempo llevará ejecutarlo - incluso en hardware jacobo Con un procesador de 3 GHz no tienes mucho tiempo para decidir si algo está en caché o no jacobo Ese es también otro motivo por el que es común tener una caché L1 pequeña y rápida y una caché L2 más grande y lenta (pero más inteligente) jacobo Los procesadores suelen tratar con la memoria en trozos de 16, 32 o 64 bytes jacobo Así que cada trozo de la caché guarda trozos de ese tamaño y alineados a ese tamaño. Los trozos son cada vez más grandes según las cachés L1 aumentan de tamaño, normalmente. jacobo Todo eso se carga al mismo tiempo. Cuando le pides a un Athlon un byte de datos cargará los 64 bytes que quiere. jacobo Esto significa varias cosas - una de ellas es que si vas a utilizar datos, pongas los datos que utilizas juntos jacobo El núcleo gasta mucho trabajo en poner las estructuras en un orden en el que los datos que se usan juntos estén juntos jacobo porque si cargaras un bit de esos datos ya tendrías el resto, de todos modos jacobo Bien, ahora una demostración de por qué importa saber cosas sobre las cachés, es demo1 (http://www.linux.org.uk/~alan/Slides/slide5.html) jacobo Es un programa muy simple que graba 4096 valores en la memoria jacobo (lo ejecutamos muchas veces para obtener números) jacobo Lo ejecutamos con los datos separados en límites de 1, 2, 4, 8, 16, 32 y 64 bytes jacobo igual que si se actualizara un array de estructuras de distintos tamaños jacobo tarzeau] ¿cómo se ejecuta demo1 en modo de simple-usuario? jacobo tarzeau: te dará respuestas razonablemente fiables si lo ejecutas sin muchas cosas ejecutándose al mismo tiempo jacobo incluso en multiusuario jacobo Así que lo que hace demo1 es muy parecido a un gran número de aplicaciones completamente normales. jacobo Notaréis que incluso en un Pentium IV con memoria muy buena y cachés grandes el rendimiento cae considerablemente jacobo ifvoid] ¿cómo de grandes son las cachés L1 y L2 del P4? jacobo Esto varía dependiendo de si es un Xeon o no jacobo Estos números proceden de un Xeon con 512K de caché L2 y creo que 64K de caché L1 jacobo Si ejecutas el programa en algo como un Celeron veréis una reducción de rendimiento mucho más rápida jacobo seguro que también querréis cambiar el bucle for para que haga 100000 no 1000000 o estaréis esperando por él toda la noche jacobo Realmente podéis utilizar técnicas como esta para hallar las propiedades de la caché de un procesador jacobo No lo hacemos en Linux porque el núcleo sabe cómo preguntarle correctamente al procesador los datos (y pone muchos de éstos en /proc/cpuinfo) jacobo Lo que esto nos dice es que si vas a pasar por grandes bloques de datos, queréis que los valores que leéis estén juntos en la memoria jacobo Si hacemos 4096 comparaciones de valores cercanos podríamos ser muchas veces más rápidos que si miráramos en un campo de cada elemento del array jacobo Esto demuestra lo importante que es una planificación cuidadosa. jacobo Por supuesto, en muchos casos podéis utilizar árboles, hashes u otras estructuras de datos inteligentes para obtener los mismos o mejores resultados jacobo La segunda demostración está diseñada para mostrar otra cosa jacobo En procesadores antiguos era muy común utilizar tablas precalculadas para cosas como la división en juegos 3D. Con un procesador moderno esto no está siempre tan claro jacobo Demo2 averigua lo que se tarda en hacer muchas divisiones, y luego lo compara con la utilización de una tabla precalculada para hacer lo mismo. jacobo En el pentium4 una vez que la tabla supera los 128K el rendimiento es mejor haciendo los cálculos - incluso cuando la división es una operación extremadamente costosa jacobo Esto es porque buscar datos en memoria es realmente más carao que hacer divisiones jacobo (lo mismo, en una máquina más lenta querréis hacer el bucle algo más pequeño) jacobo smesjz] Paso de 1 por 4K llevó 50 segundos. (p133/2.5.49) :) jacobo smesjz: Te da una idea de lo que cambió el rendimiento de los procesadores jacobo El de la división es bastante interesante porque depende mucho del procesador jacobo en algo como un pentium la tabla será muchísimo más barata jacobo pero cuando llegas a los athlons y PIII/PIV se hace mucho menos claro jacobo smesjz] Alan_Q: me sorprende que 5 de los tests de demo1 devuelvan 50 segundos de tiempo de ejecución (100k iteraciones) jacobo smesjz: Para averiguar por qué, tendrías que mirar más profu8ndamente a lo que ocurre - yo tampoco lo sé, a menos que el verdadero límite sea tu memoria jacobo rp] ¿alguien me puede explicar el significado exacto de 1024 tablesize? jacobo rp: las diferentes ejecuciones acceden a datos de tablas precalculadas de 64K, 128K y así jacobo así que una tabla de 1024K significa que el programa simula acceso aleatorios a 1Mbyte de datos precalculados jacobo si lo ejecutais con tamaños más y más grandes, al final el rendimiento se vuelve constante. Esto os da una idea de que la caché ya no ayuda jacobo Este test en particular es muy importante para cosas como procesado de imágenes. Compresión jpeg y similares jacobo uno de los motivos por los que MMX es una ayuda en procesamiento de imágenes es que os permite hacer mucho procesamiento al mismo tiempo, así que se pueden evitar las tablas al hacer cosas como conversión de colores jacobo ridiculum] ¿hay en Linux alguna herramienta como Vtune (intel) para depurar cosas como explica alan? jacobo ridiculum: Hay dos - hay una cosa open source llamada "oprofile", y hay el vtune de Intel, que es caro y requiere un segundo PC windows y otras cosas jacobo ridiculum: puedes mirar muchas de las estadísticas porque los procesadores más recientes tienen registros de depuración jacobo permiten que herramientas como oprofile le pregunten al procesador "¿cuántos fallos de caché?", "¿cuántas veces tuviste que esperar por los datos"? jacobo y otras preguntas similares jacobo http://oprofile.sourceforge.net/ es el "profiler" OProfile jacobo Así que tenemos algunas demostraciones simples de lo importante que es la caché jacobo avoozl] también podría ser interesante mirar valgrind, la última versión también puede hacer simulación de caché y mostrar en qué partes de un programa suceden fallos de caché jacobo avooz: si, me había olvidado de que valgrind puede hacer simulación de caché jacobo ¿hubo cpus sin caché? ¿intels 80286? jacobo tarzeau: hubo muchas. El 286 casi nunca era más rápido que la RAM a la que estaba conectado - de igual modo en el Amiga la RAM es casi dos veces más rápida que el procesador jacobo El amiga, de hecho, utilizaba ese truco para darle al procesador y chips de apoyo acceso compartido jacobo dándole acceso alternativo al procesador y juego de chips jacobo Así que, ¿qué hemos aprendido sobre la caché y hacer buen uso de ella? jacobo Bien - sabemos que cuando recibimos datos los recibimos en trozos, así que podemos poner las cosas que usamos en el mismo lugar. jacobo Esto ayuda al procesador y también, de paso, ayuda a la memoria virtual (cuando intercambias datos a disco se hace en trozos de 4K, así que también podríais mantener los datos juntos para ello, también) jacobo Hemos demostrado que queréis mantener vuestro procesamiento que quepa en la caché. Un motivo por el que Intel vende procesadores caros con cachés muy grandes es que las bases de datos encuentran gran dificultad en hacer esto jacobo así que los Xeons y los pentium-pro realmente caros con cachés de 1Mb eran buenas para trabajo con bases de datos jacobo También sabemos que sólo se puede meter en caché una cierta cantidad de datos en una alineación dada jacobo El núcleo utiliza localizadores de memoria especiales para dispersar los objetos que utiliza el núcle en diferentes alineaciones específicamente debido a ello jacobo tarzeau] esos chips de memoria edo eran de 60ns y 70ns, de cuántos ns son las cachés l1 y l2? jacobo tarz: en los procesadores modernos no estoy seguro - incluso en el 486 la caché L2 era de unos 16nS jacobo Si tenéis un array de objetos de tamaño que sea potencia de dos seguramente recibiréis casi el peor rendimiento posible de las cachés jacobo así que es un truco útil añadir un cierto espacio no utilizado en cada bloque de memoria para almohadillar los elementos del array para que entren mejor en caché jacobo Bien, es hora de la siguiente demostración jacobo http://www.linux.org.uk/~alan/Slides/slide7.html jacobo (no hay demo3... la saqué para que la charla se ajustara mejor al tiempo 8)) jacobo Está diseñada para mostrar cómo distintas formas de hacer algo pueden tener diferente rendimiento debido a las cachés jacobo lo que realmente hace (sumar números) es bastante trivial, pero no es distinta a ejemplos reales de programación jacobo La primera ejecución genera un conjunto grande de datos, y luego los suma. Generar conjuntos de datos y después procesarlos, y después procesar el resultado es una forma muy común de programar jacobo pero puede dar el peor rendimiento posible jacobo En la segunda ejecución sumamos los datos mientras lso generamos, y obtenemos mejor rendimiento jacobo Esto es mayormente debido a que en la primera ejecución terminamos vaciando todos los datos de la caché y luego volviéndolos a cargar jacobo En el segundo caso ya que sumamos al vuelo, los datos sólo dejan la caché una vez jacobo El caso final muestran qué parte de la operación es la que realmente nos absorbe el tiempo jacobo Lo que esto significa es que para cualquier cantidad grande de datos y cálculos es importante trabajar con ella en trozos jacobo Los ingenieros y gente de computación de alto rendimiento lo hacen todo el tiempo - GIMP también sabe esto jacobo Muchas cosas de las que hace GIMP en sus filtros las hace utilizando rectángulos de la imagen en lugar de aplicar cada cambio a la imagen completa, uno tras otro jacobo debUgo-] Alan_Q: cuánto afecta la "asociatividad" de la caché en el rendimiento general de la memoria? jacobo debUgo-: mantener los datos en la caché crea una gran diferencia en el rendimiento general - principalmente en sistemas SMP, que es adónde van las siguiente stransparencias jacobo Hay muchos algoritmos para esto y las mismas técnicas se utilizan en clusters y Beowulfs - sólo que tratan de minimizar el número de mensajes sobre ethernet, así que es mucho más importante que en un solo sistema jacobo Todas estas cosas sobre cachés importan mucho más con un PC multiprocesador jacobo Menos en las máquinas alpha y sparc más grandes porque tienen sistemas de memoria diseñados para varios procesadores jacobo Un athlon dual o pentium III/IV dual está formado por dos procesadores en el mismo bus de memoria jacobo Las tres demostraciones ya han mostrado que con un solo procesadore el rendimiento de la memoria no depende del procesador jacobo (no llega al de un procesador, perdón) jacobo Así que una máquina con dos procesadores nos da el doble del mismo problema jacobo Una de las demostraciones que podéis hacer es ejecutar una copia de memoria grande y continua en un procesador y medir el rendimiento de las copias en el otro - en algunas máquinas PC duales las copias que se miden se ejecutan a 1/3 de la velocidad a la que corren sin el otro bucle de copia jacobo ifvoid] Alan_Q: ¿esto no cambia en el Hammer e Itanium 3? jacobo ifvoid: hammer te permite conectar memoria a cada procesador, cuantos más procesadores añades más controladores de memoria puedes añadir jacobo ifvoid: depende del coste el si los vendedores lo harán jacobo rp] ¿esto significa que el rendimiento de la memoria no sólo depende del procesador sino también de la velocidad del bus? jacobo rp: yes jacobo rp: si jacobo unlevel0] <Alan> Así que una máquina de dos procesadores nos da el doble del problema: esto explica por qué no recibimos el doble del rendimiento de un procesador jacobo runlevel0: hay dos motivos por los que no se obtiene el doble de rendimiento jacobo el primero es que compartes memoria que no es suficientemente rápida jacobo el segundo es que hay un coste en detener el sistema por hacer las dos cosas incorrectas al mismo tiempo jacobo (impedir que haga dos cosas mal al mismo tiempo) jacobo el núcleo tiene que hacer trabajo real para evitar que dos personas reserven la misma memoria, utilicen el mismo bloque de disco y otras cosas que no queremos que pasen jacobo El único motivo por el que se puede utilizar un PC de dos procesadores es que la mayoría de lso accesos a memoria vienen de la caché en una utilización normal jacobo cada procesador tiene su propia caché (salvo algunas máquinas de dos pentium, que sólo hacen daño 8)) jacobo ridiculum] ¿y qué pasa con hyperthreading y coherencia caché? jacobo ridiculum: el hyperthreading comparte la caché entre las dos unidades de ejecución del procesador jacobo así que haces dos cosas a la vez pero cada aplicación sufrirá más fallos caché jacobo sh0nX] aquí es donde entran los spinlocks jacobo sh0nX: correcto - es la principal cosa que utiliza el núcleo para sincronizar las cosas internamente jacobo Una cosa que tienen que hacer los procesadores es asegurar que ambos procesadores no meten distintas versiones de los mismos datos en caché, o pierdan cambios que hace el otro procesador jacobo docelic] Me gustaría saber más sobre los spinlocks jacobo doc: hablaremos de ello tras la charla principal jacobo bzzz] Alan_Q: ¿cómo pueden los dispositivos pci ver datos que están sólo en caché? jacobo bzzz: los procesaodres, además de asegurarse de que ven los cambios de los demás hacen lo mismo con los dispositivos del bus PCI jacobo bzzz: la técnica de "cacheado" estándar es una cosa llamada MESI jacobo eso indica los cuatro estados en los que puede estar cada trozo del caché jacobo tenemos "M", o estado modificado. Significa que esa información es algo que el procesador ha cambiado y tenemos datos sobre los que no saben nada los otros procesadores jacobo Tenemos "E" - estado exclusivo - en el que sabemos que nadie más tiene estos datos pero nosotros sí jacobo Tenemos "S" o estado compartido (shared), en el que sabemos que tenemos una copia de los datos pero otros también tienen otra en estado compartido jacobo y tenemos "I" o no válido (invalid) - en que no sabemos qué ocurre pero sabemos que no tneemos los datos jacobo en cualquier momento dos procesadores no pueden tener los mismos datos salvo en estado compartido jacobo cuando modificamos datos cambiamos su estado - si es exclusivo se vuelve modificado jacobo si era compartido tenemos que patear a los demás procesadores y hacer que se deshagan de sus copias jacobo si no tenemos una copia (I) debemos pedirla - igual que moverse de compartido puede ser bastante caro jacobo si otro procesador tenía una copia en estado modificado tenemos que pedirle que la grabe en memoria y luego leerla nosotros jacobo lo que queremos evitar a toda cosa es tener dos procesasdores que modifiquen continuamente los mismos datos jacobo Esto se convierte en uan especie de pelea por comida en el bus de memoria jacobo y pasamos la mayor parte del tiempo pasando datos entre procesadores jacobo Esto no deja mucho tiempo para el trabajo de verdad -y cuando quieres pasar a ordenadores grandes se convierte en algo muy importante a evitar jacobo IBM ha hecho mucho trabajo en el código del núcleo en el que este tipo de luchas pueden suceder, ya que tienen sistemas de 16 procesadores jacobo lo que deja muy claro cuando has hecho esto mal jacobo sh0nX] Alan_Q: deberíamos utilizar la caché en procesadores SMP para guardar datos que no van a cambiar mucho y utilizar éstos para manejar datos que cambian mucho? jacobo shonx: hay sistemas en los que tiene sentido tener datos muy compartidos fuera de caché. La forma en que el hardware del PC funciona te impide hacerlo jacobo Incluso si la sacas de caché es lenta jacobo La mayor parte del tiempo no es un problema - las aplicaciones no comparten muchas cosas, de todas formas jacobo Las aplicaciones con hilos tienden a compartir muy pocos datos, gracias a Dios jacobo Cuando se diseñan aplicaciones con hilos y SMP es importante minimizar la cantidad de tiempo que pasan los datos botando entre procesadores jacobo Así, por ejemplo, si haces codificación JPEG en un sistema multiprocesador sería mejor utilizar un procesador para hacer la parte superior de la imagen y el segundo para hacer la parte inferior jacobo que hacer que un procesador haga conversión de colores y el otro el paso de compresión jacobo en cosas como codificación mpeg esto se vuelve complicado jacobo Además es posible tener lo que se llama "falsa compartición" jacobo h0nX] Alan_Q: así que queremos que ambos procesadores hagan cosas DISTINTAS jacobo sonx: exactamente jacobo shonx: igual que la gente, los procesadores funcionan mejor cuando no se están pisando unos a otros jacobo La compartición falsa ocurre porque la caché del procesador trabaja en trozos de 32 o 64 bytes Heimy Si pones dos datos sin relación en los mismos 64 bytes puedes acabar accidentalmente teniendo que cada procesador use una cosa en la misma línea de caché (y estalle una pelea) Heimy Por tanto la gente rellena tales estructuras para hacerlas mayores, y evitar esto Heimy o las mantienen separadas Heimy (rellenarlas con ceros - padding - evita compartirlas, pero implica usar más caché, por supuesto), de manera que estaremos haciendo lo que demo1 dice que no deberíamos Heimy sh0nX] Alan_Q: de manera que cuando diseñemos aplicaciones SMP, ¿cómo le decimos al procesador que gestione qué datos sin hacer que los procesadores trabajen con los mismos datos? Heimy shonx: el planificador intenta mantener un mismo thread ejecutándose en el mismo procesador siempre que sea posible Heimy de manera que es simplemente cosa de evitar acceder mucho a los mismos datos desde dos threads diferentes Heimy De forma similar, intentamos mantener una aplicación dada ejecutándose en el mismo procesador de manera que no tengamos que perder un montón de tiempo copiando cosas de un procesador al otro Heimy [14-Dec:19:25 yalu] Alan_Q: ¿Es el planificador suficientemente inteligente como para mantener hilos que comparten un montón de datos en el mismo procesador? Heimy yalu: intenta imaginarse un par de cosas sencillas Heimy pero en realidad es muy difícil medir de forma eficiente la cantidad real de datos compartidos Heimy especialmente ya que la compartición de sólo lectura (ej: código) es permisible Heimy zwane] Alan_Q: Todo esto debe volverse realmente interesante con CPU con hyperthread Heimy zwane: hay razones con las que Ingo está jugando para obtener el mejor rendimiento de tales procesadores 8) Heimy Con hyperthreading tienes algo así como dos procesadores por caché Heimy Y la caché tiene además algunos límites internos bastante tontes Heimy tontos Heimy zwane] Alan_Q: Crees entonces que bastaría sólo con el planificador? How about leveraging cpu affinity for say doing bias in interrupt handling? Heimy (lo siento, muy complicado para traducir ahora mismo) Heimy zwane: hay muy buenas razones en algunos casos para despertar un proceso en la CPU que controló una interrupción. En la mayoría de los casos, sin embargo, no es tan valioso como pudieras creer Heimy La mayoría de los datos del proceso está en caché en la CPU en la que se ejecutó por última vez Heimy La mayoría de los dispositivos de E/S buenos usan DMA (de manera que escriben a memoria ellos mismos y la memoria subre la que han escrito ha de ser eliminada de la caché de los procesadores (ya que la modificaron) Heimy Hay buenas razones para asignar interrupciones a procesadores específicos Heimy (si el procesador 1 tiene en caché todos los datos de la eth0, entonces por qué gestionar la interrupción con el procesador 2) Heimy sh0nX] de manera que, si un programa está escrito para UP (uniproceso), cómo controla el planificador del núcleo sus datos en dos CPU? o no puede? Heimy sh0nX: el planificador no puede dividir algo con un único thread de ejecución. Puede separar varias aplicaciones (de manera que ejecuta tu juego en un procesador, y el servidor X en otro) Heimy sarnold] Alan_Q: ¿Tiene Linux actualmente algún mecanismo para especificar que todas las interrupciones deberían ser gestionadas por una CPU específica? Heimy sarnold: tiene algo que hizo Ingo, en el lado oscuro y peligroso de los ajustes del kernel Heimy sh0nX] Ya veo, entonces tenemos que usar threads en el código para beneficiarnos de tener SMP Heimy sh0nX: usar dos programas a veces es igual o más sencillo Heimy Hay un último tema para esta charla, y entonces podremos pasar a las preguntas Heimy Alguien pregunto al principio al respecto de ayudar a la caché Heimy En los procesadores modernos, tenemos instrucciones como "prefetch" y "prefetchw" Heimy Permiten decirle al procesadore que necesitarás datos en el futuro Heimy De manera que en lugar de estar parados esperando a que los datos lleguen de la memoria, se le puede indicar al procesador con antelación Heimy El gran problema es que a menudo no sabemos bien con antelación qué memoria vamos a necesitar Heimy Una copia de memoria es fácil (y la copia de memoria en los Athlon en Linux realmente dice: "y prefetchéame 320 bytes antes de este punto") Heimy Cosas similares como el proceso de gráficos se benefician inmensamente de esto ya que los programas usan grandes cantidades de datos de forma predecible Heimy (fortran se comporta muy bien en esto, extrañamente) Heimy Usamos esto en el núcleo para hacer copias de memoria y algunas veces para listas Heimy es difícil de usar para listas porque la memoria es tan lenta que prefieres decir: "prefetchéame unos 5 o 6 elementos" Heimy <Alan> <espera por el traductor> [prefetchéame un traductor ;)] Heimy Ok. Parece que los dedos del traductor están al día Heimy Lo que necesitamos realmente para hacer que esto funcione es nuevas estructuras de datos Heimy uno de los enfoques comunes para esto es tener listas en que conozcamos siguiente/anterior, pero también 'cinco elementos por delante' y 'cinco elementos por detrás'. No hacemos esto actualmente en el núcleo Heimy pero podría ser algo a lo que mirásemos en el futuro según los procesadores se hagan aún más rápidos Heimy La última cosa útil para la que se usa prefetch en el núcleo hace uso del 'prefetchw' del Athlon que dice "quiero estos datos pronto, y escribiré en ellos" Heimy al contrario que prefetch, esto obtiene una copia exclusiva de los datos. Lo usamos para obtener cerrojos con antelación (lo que sería muy costoso si tenemos que hacerlo en memoria principal) Heimy Es muy común que una estructura de cerrojo perteneza a otro procesadore y a menudo sabemos cuándo va a usarse, de manera que podemos pedirlo con antelación Heimy sh0nX] Asumo que hay algún tipo de spinlock para evitar que otro proceso pida con antelación los mismos datos? Heimy En realidad no lo bloqueamos Heimy con muy poca frecuencia los pillamos con antelación y otra cpu los roba y los tenemos que coger otra vez Heimy pasa tan raramente que es menos costoso no preocuparse de esto Heimy También si quisieras un cerrojo para el cerrojo, también querrías anticipar la anticipación Heimy y así repetitivamente Heimy De manera que en el núcleo tratamos estas anticipaciones más como una ayuda Heimy Si hace lo correcto la mayor parte de las veces, ya está bien con eso... Heimy Ok. Hemos llegado al final de la parte principal de la charla Heimy espero que haya dado alguna idea a la gente de por qué las caché importan Heimy y un poco sobre programar teniéndolas en mente Heimy Si podemos empezar con preguntas sobre el tema antes de que nos vayamos por las ramas, sería mejor Heimy <riel> Creo que la gente debería hacer las preguntas sobre el tema en #qc Heimy <riel> así podremos tener el canal moderado unos minutos más Heimy sarnold:#qc] Alan2: me he estado preguntando si la peteición con antelación reduce significativamente el acceso a memoria Heimy ¿lo ha probado la gente sin configurar el prefetching? Heimy sarnold: hemos hecho una buena cantidad de pruebas. La mayoría de las veces, el prefetching ayuda realmente a la reducción del uso del ancho de banda de la memoria, que podría estarse usando para otras cosas Heimy El del Ahtlon estaba tan bien afinado que incluso destrozamos algunos chipset VIA debido bugs del hardware 8) Heimy rene:#qc] Alan2: la charla parece haber estado referida sólo a la caché. Hacen mucha diferencia en los procesadores modernos cosas como la alineación de las instrucciones? Heimy rene: importan un poco (depende del procesador cuánto). gcc sabe cómo hacerlo correctamente cuando le indicas el tipo de procesador. Sin embargo, normalmente está por debajo del 1% Heimy Arador:#qc] Alan2: cuales son los efectos de preempt sobre la caché? Heimy arador: cuanto más cambias entre tareas menos útil se hace la caché Heimy Pre-empt no representa realmente una gran diferencia Heimy Es por esto, sin embargo, por qué los sistemas diseñados para un montón de usuarios simultáneos tienen mucha caché Heimy [14-Dec:19:55 aka_mc2:#qc] ALAN: piensas que el procesador Crusoe, soportado por Linux, podría considerarse para todas estas técnicas de programación? Heimy aka_mc2: Es muy difícil tratar con el Crusoe: el sistema emula un x86 y ajusta su emulación de acuerdo a cosas que aprende durante la ejecución. Esto significaque puede averiguar lo que parece necesitar prefetching y muchas otras cosas que no puede hacer un procesador normal. Cuánto consigue realmente, no lo sé Heimy sklav:#qc] he notado grandes cargas tras usar un núcleo con -O3 o -O5 Heimy sklav: mucho de esto está relacionado con la caché en realidad (gcc -O3 y -O5 desenrolla bucles que le hacen usar mucha más memoria y en CPUs modernas esto es malo) Heimy en realidad es un fallo en algunos gcc que lo hace demasiado a menudo Heimy jmgv:#qc] Alan? no piensas que gran parte del trabajo del uso de los registros y otras cuestiones dependen del compilador y nos hacen perder algo de control sobre estos asunto? Heimy jmgv: cierto (pero querrías optimizar a mano un megabyte de codigo?) Heimy jmgv: para el núcleo, en realidad, escribimos pequeñas partes de código críticas en ensamblador, en algunos casos (cosas como memcpy, por ejemplo) Heimy hay otras partes en las que el C se escribe de manera que el compilador produzca el código correcto, en vez de a la manera obvia Heimy Rapiere: Si GCC mejora el uso de la caché de un thread, ¿no repercute esto en la interactividad en multi-threads? Heimy <jmgv> ya veo Heimy Rapiere: el planificador trata con esto a nivel mucho más alto (y las decisiones que hace que están diseñadas para un mejor rendimiento de la caché son, afortunadamente, las correctas, de todas maneras) Heimy sapan:#qc] Alan2: dijiste que "sabemos que sólo se puede cachear cierta cantidad de memoria y sólo ciertos desplazamientos". ¿Podrías explicarlo? Heimy El procesador usa partes de las direcciones para indicar en qué parte de la caché debe miar Heimy Para la CPU, una dirección realmente parece algo así como [Número de página][Línea de caché][índice dentro de la caché] Heimy De manera que la caché siempre almacena un área de unos 64 bytes en un athlon Heimy Además, si tenemos muchos datos con el mismo número de línea de caché, sólo podemos almacenar dos o cuatro de estos pedazos de datos Heimy la caché no puede almacenar cualquier bloque de datos en cualquier sitio Heimy Ok. Podemos pasar a preguntas más generales un rato (Rik, ¿para cuándo está planeada la siguiente charla?) Heimy coywolf!jack@210.83.202.168* ¿por qué piensas que los GUI de Windows son mucho más rápidos que los de Linux? Heimy coywolf: porque no asisitieron a mi conferencia 8) Heimy coywolf: pero podrías usar xfce/rox incluso en un PC de 32MB 8) Heimy erm... Heimy coywolf: pero deberías intentar usar xfce/rox incluso en un PC de 32MB 8) Heimy Eso :) Heimy sh0nX:#qc] ya que ahora estamos fuera de tema: Alan2: ¿Tienes un parche para el módulo amd76x_pm para 2.5xx? Heimy shonx: no sería muy difícil adaptarlo, pero no creo que nadie lo haya hecho aún Heimy shonx: cool Heimy :) Heimy (sh0nX:#qc] Alan2: estoy intentando adaptarlo ahora mismo) Heimy sapan:#qc] Alan2: tengo una iPAQ con familiar y 2.4.18-rmk. Si fuera a optimizar cosas en el núcleo o aplicaciones en general, ¿a qué debería mirar? Heimy sapan: Ahora mismo no estoy familiarizado con las tripas del ARM. Deberían aplicarse los mismos principios generales Heimy sapan: obviamente hay otras consideraciones en un handheld (falta de disco, ahorro de energía, etc) Heimy E0x:#qc] Alan2 ¿cual es tu procesador preferido? Heimy EOx: varía. Me encanta la velocidad bruta del Athlon, pero odio su fiabilidad y los problemas de calor Heimy En este momento estoy jugando con los procesadores VIA C3/VIA Eden (que son mucho más lentos, pero están diseñados para ser muy evicientes en cuanto a energía - no necesitan ventilador) Heimy esto les hace sistemas muy baratos y silenciosos Heimy además la gente puede hacer cosas realmente locas con placas pequeñas (como ponerlas en viajas carcasas de sparc o incluso en latas de gasolina) Heimy (www.mini-itx.com) Heimy ridiculum] ¿cual es tu opinión sobre itanium2? es mejor que hammer? Heimy ridiculum: ahora mismo me quedo firmemente con hammer Heimy Al respecto de por qué la fiabilidad de los athlon es un problema, no estoy seguro (tenemos verdaderos problemas obteniendo memoria fiable en los athlon duales, problemas de calor y mucha incompatibilidad de hardware) Heimy pero es asombrosamente rápido una vez funciona Heimy apuigsech:#qc] Alan, en la tabla GDT podemos encontrar algunos descriptores nulos (sin usar), ¿es esto para obtener optimizaciones en el uso de la memoria caché? Heimy apui: realemente muchos de esos huecos existen porque los solíamos usar para cosas y quisimos mantener los datos iguales, otros son valores fijos requeridos por los estándares, o para compatibilidad en bios con fallos de Windows (no tiene que ver con la caché) Heimy rene] (de manera que CPU no machaquen las líneas de caché de otros) Heimy rene: tenemos que espaciar algunas cosas para eso Heimy perdón Heimy rene: tenemos que dejar espacio eso Heimy rene: Un ejemplo es que el núcleo tiene una estructura que describe cada página de memoria Heimy Varias personas trabajaron realmente duro para hacer que las estructuras fueran exactamente de 64 bytes en PC Heimy sh0nX] Alan: ¿visitas #kernelnewbies? :) Heimy <Alan> shonx: no demasiado a menudo (es un proyecto realmente importante) Heimy <davej> la gente que esté interesada en las cosas de prefetching de que ha hablado Alan podrían encontrar interesante la presentación que hay en http://208.15.46.63/events/gdc2002.htm interesting Heimy <riel> vale, parece están habiendo menos preguntas Heimy <riel> supongo que es hora de cerrar la "parte oficial" de esta charla Heimy <jmgv> Sí, estoy de acuerdo Heimy <riel> me gustaría agradecer a Alan Cox esta interesante charla Heimy <riel> y me gustaría recordarle a todo el mundo que todavía tenemos otras charlas en UMEET Heimy <jmgv> agradecemos a alan sus esfuerzos Heimy <riel> pueden ver el programa completo en http://umeet.uninet.edu/umeet2002/spanish/prog.html jacobo supongo que ya no hace falta :) angelLuis plas plas plas plas plas plas plas plas plas angelLuis plas plas plas plas plas plas plas plas plas angelLuis plas plas plas plas plas plas plas plas plas angelLuis plas plas plas plas plas plas plas plas plas pancake :) angelLuis gracias por la traducción! thanks to the traduction! Ston_ clap clap clap clap clap Ston_ clap clap clap clap clap Ston_ clap clap clap clap clap Ston_ clap clap clap clap clap angelLuis plas plas plas plas plas plas plas plas plas Ston_ clap clap clap clap clap angelLuis plas plas plas plas plas plas plas plas plas angelLuis plas plas plas plas plas plas plas plas plas * Heimy señala a jacobo angelLuis :)))) Ston_ se perdio y atrazo pero gracias :) angelLuis plas plas plas plas plas plas plas plas plas angelLuis plas plas plas plas plas plas plas plas plas * jacobo levanta a Heimy en el aire :) bit0 plas plas plas plas angelLuis ;) bit0 graaaaaaaaaaaaaacias * Heimy se cae sobre jacobo, para gran dolor suyo angelLuis plas plas plas plas plas plas plas plas plas jacobo Heimy: la cuchara no existe bit0 plas plas plas plas bit0 plas plas plas plas bit0 plas plas plas plas bit0 plas plas plas plas bit0 plas plas plas plas BorZung gracias por la currada Heimy ;) Heimy gracias público, gracias, gracias Heimy jacobo: locualo? _Yep_ Heimy jacobo: ah, sí Heimy XD ^hulk-18 plas plas plas plas plas plas plas plas plas casanegra clap clap clap ^hulk-18 plas plas plas plas plas plas plas plas plas casanegra :-) ^hulk-18 plas plas plas plas plas plas plas plas plas [k] creo que lo mejor no fue alan si no la traduccion :P jacobo que esto es Matrix, todo es posible y para más, no me duele :D debUgo- felicitaciones y agradecimientos a todos los que colaboraron en la traducción... estuvo fabulantástica angelLuis plas plas plas plas plas plas plas plas plas angelLuis plas plas plas plas plas plas plas plas plas Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!