Hola :) El Monday 15 December 2008, Shinji Ikari escribió:
On Monday 15 December 2008 10:43:09 Rafa Grimán wrote:
Hola :)
Saludos, ;)
<snip>
Bueno, el punto de vista es variable, depende de la compañía, algunas dependen de R&D para avanzar, otras siguen usando Pentium II o menos. Van a postergar algunos lanzamientos, la cosa se va a poner lenta. Aunque tampoco se que creer. Algunos ya están utilizando los últimos procesadores de Intel (cuyo nombre no recuerdo). Verdad, ¿ya hay aplicaciones que utilicen efectivamente multicores?
Eso es cierto, me había puesto más de parte del fabricante que del cliente. Es cierto lo que dices que hay clientes con =< PII.
Y es que las máquinas todavía andan. ¿Todavía hay thin clients? o ¿fue una moda?
Depende del cliente. En entornos "seguros" sí se usan porque evitan que los usuarios puedan robar datos.
En cuanto a aplicaciones que corren efectivamente en multicore, las que estén bien desarrolladas usando threads (y que además son paralelas o están paralelizadas), sí corren bien. Las demás no.
Apple está trabajando en eso, al menos ese es el objetivo de Jobs para Snowleopard, no he leído noticias de eso últimamente.
En el caso de Linux hay bastante código desarrollado con hebras/threads (incluso a nivel de escritorio). En el tema de paralelización o multihilo o SMP o como se quiera llamar es complejo por varias razones: - no es fácil de programar ya que hay que controlar muy bien las variables (y sus valores), evitar race conditions, bucles infinitos, los workflows son muy complejos, ... - no es fácil depurar Por eso mucha gente le tiene miedo o cuesta tanto, salen aplicaciones muy de vez en cuando, ...
Lo mismo ocurre con 64 bits. Tenemos Partners en España que siguen desarrollando en 32 bits y que además su sw NO corre en plataformas 64 bits (me refiero a aplicaciones MS-Windows) !!! Dos cosas me alertan mucho: - son aplicaciones 32 bits AÚN !!!! - una aplicacción 32 bits Windows NO corre en MS-Windows 64 bits !!!
Que estamos en el Siglo XXI señores !!!
Y es que con las máquinas antigüitas, ¿necesitan software de 64 bits? ¿En las aplicaciones cotidianas actuales se necesita 64 bits?
Lo de "necesitar" es algo muy subjetivo. Por ejemplo, yo en mi casa no "necesito" los 64 bits, pero mi hermano sí (3D, edición de vídeo y audio, postproducción y esas cosas) porque le viene bien eso de acceder a mucha memoria (entre otras cosas), de ahí que tenga un Mac ;) En el caso de clientes con grandes bases de datos, CAD/CAM/CAE, CFD, simulaciones, investigaciones científicas, ... Hoy en día _SÍ_ lo necesitan ya que el volumen de datos que se manejan son inmensos y los tiempos de respuesta esperados tienden a cero. Otro ejemplo es en el mundo de los juegos: cuanta más RAM tengas, mejor que mejor y si la CPU es potente ... mejor qu emejor :) Pra atrabajo ofimático no es necesario, para navegar por Inet tampoco, pero sí hay determinados mercados que lo necesitan porque no puedes conseguir resultados en el tiempo esperado sin la tecnología de 64 bits: requieren grandes cantidades de memoria, el número de variables es ingente, el volumen de datos en disco es abismal (acabo de ver un correo de un cliente que tiene más de 300 millones de ficheros, por ejemplo) y eso no se mueve con 32 bits. De 6 años hacia aquí, los 64 bits han creado una dependencia en muchos entornos porque pedimos una calidad y un tiempo de respuesta determinado habiendo un incremento exponencial en el volumen de dlos datos. Un ejemplo de esto son los clientes del mundo del diseño de automóviles. Cuando se empezaron a simular choques con coches, se simulaba lo que le ocurría a una parte muy concreta del parachoques ... pasó el tiempo y hoy se simula lo que les ocurre a tus órganos en caso de un choque. Imagínate el volumen de datos que se manejan en tiempo real para simular todo ese sistema: coche + persona + órganos.
Tal vez los fabricantes de chips se han adelantado demasiado. Ya han pasado tantos años desde que se introdujo.. ya van ¿4? ¿5? (Digo actividades de oficina y domésticas)
Usan Cobol, piden Cobol... .net tiene una gran cola con el pasado (a diferencia de lo que usa Apple). No hay juegos 64 bits. Los marcianos nos van a encontrar con software de 32 bits todavía. =P
No estoy tan de acuerdo contigo. En el caso de los juegos (y del mundo 3D), hay parte del código que se ejecuta en CPU y otra parte en GPU, cada vez se usan más polígonos para "dibujar" los objetos, cada vez se pide más realismo (tanto de imagen como de física: caída de objetos, trayectorias de balas, saltos, pesos, ...) y cada vez se requiere más RAM. Los 32 bits en ese tipo de escenarios (mundos/juegos 3D) se quedan muy limitados. Otro ejemplo dentro del mundo de 3D es el tema de ray traycing, el renderizado de una escena no es más que ray traycing: CPU puro y duro. [...]
En cierto artículo recomendaban netbooks con los discos tradicionales (SATA). las netbook puede que se vuelvan más populares para algunos curros.
Para comerciales, la verdad es que son muy cómodas.
Se estarán preparando para ofrecer soluciones con ellas ¿no? ;)
Nosotros concretamente no, nuestro mundo no son los netbooks y si los hiciésemos ... serían muy grandes ;) [...]
Definitivamente es el mundo de los clusters. =P
No te creas, los clusters son buenos cuando tienes una tarea que se puede dividir en tareas más pequeñas "independientes" unas de otras, por ejemplo: un render farm. En otras ocasiones no porque las latencias y/o cuellos de botella en la red te pueden suponer una eternidad (BBDD, por ejemplo).
O.O? desconozco como está organizada Google o la Wikipedia. O miento y tengo una idea muy vaga. No me acuerdo y ya es medio día y es hora de comer. ;P
En el caso de servidores web, un cluster es muy sencillo ya que lo que se ofrece es balanceo de carga y alta disponibilidad, luego no hay paso de mensajes, no se transfieren datos necesarios de unos a otros. En el caos de sus bases de datos, lo que se está usando es BBDD basados en columnas y no en registros (filas). Es mucho más eficiente y hay menos paso de mensajes entre una máquina y otra. Un cluster de BBDD es útil hasta unos 8 nodos más o menos. En el caso de estas BBDD funcionan bien porque no hay mucho paso de mensajes (si las comparamos con RDBMS tradicionales). Pero (y lo dicen los propios fabricantes y admins de estas BBDD), lo ideal es que que se ejecute en una única máquina ya que toda la comunicación se hace en RAM y no en Ethernet o Infiniband. En el caso de un rederfarm lo del cluster es la mejor solución, no hay prácticamente paso de mensajes ya que: 1.- el nodo de render se comunica con el head node y le dice que está libre 2.- el head node le pasa una escena/trabajo/... a renderizar al nodo de render 3.- el nodo de render se pone a renderizar (dependiendo de la escena, calidad, ...) puede estar hasta varias horas renderizando 4.- el nodo de render le envía al head node el fotograma El paso 3 puede ser muy largo por lo que no hay casi tráfico de red, aquí un render farm es algo maravilloso :) Otros escenarios son los clusters de alta disponibilidad y de balanceo de carga (suelen ir juntos aunque no necesariamente), como es el caso de servidores web, correo, ftp, servidores de ficheros (si alguien tiene interés y quiere ir preparándose para el futuro, que se ponga a estudiar pNFS). Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org