Exploit en Zelda abre la puerta al homebrew de Wii

Gracias.

Te apunto, que tus post suelen tener buen contenido. Siempre se aprenden cosas, si no qué aburrimiento...

Un saludo

Todo esto es un primer paso, no hay que emocionarse, pero tampoco creer que esto no avanza, demosle un poco de tiempo a la scene de Wii, al final lo que buscamos la mayoria es regionfree y ejecutar backups.

-MasMe- escribió:
+1

¿Sería posible un isoloader?

Algún día será respondida...

Hmmmmmmmm

Ira Wii de Camino de PS2?
De lujo lo que estan sacando todos estos cracks

Desde aqui me inclino ante ellos

Y sacad algo pronto JIJI

alkaitz escribió:Gracias por la comparativa.

Imagino que la harían con equipos similares en prestaciones. Echo en falta un benchmark de los specINT y los FLOAT, ya que los dhrystone y los whetstone pecan por varios motivos. Aún así, y contrario a la sensación que me ha dado usarlo, parece que tiene muy malas prestaciones. Es curioso...

Gracias de nuevo, y un saludo.

PD: No entiendo muy bien lo de los PC Mark... ¿es un convenio o una empresa? Porque que se utilicen aplicaciones no consensuadas en mercado es algo extraño. Al final pasa como con los LINPACK, que las empresas se esfuerzan en que corran mejor las aplicaciones del benchmark y luego pasa lo que pasa.

PCMark es, según tengo entendido, un conjunto de kernels sintéticos que hacen pruebas del rendimiento de CPU, RAM y discos duros con cargas de trabajo típicas y máximas. Es tan representativo (o tan poco representativo) como el 3D Mark. No es que sea literal, pero es orientativo. A mi no me parece un mal benchmark si sabes leer los resultados.

Y respecto a LINPACK, es un benchmark de los más válidos que te puedes encontrar, utilizan cargas de trabajo reales. Si hacen el hardware para que LINPACK corra más, pues cojonudo. LINPACK no es en absoluto sintético, es un conjunto de problemas algebraicos de alto rendimiento. Si tu máquina los resuelve más rápido que ninguna otra, resolverá más rápido que ninguna otra las aplicaciones de cálculo numérico. Por eso se utiliza LINPACK para hacer el top500. El truco que creo que se ha utilizado alguna vez, era en los compiladores. Cuando detectaban que se compilaba LINPACK, se escupía un LINPACK optimizado a mano. Pero vamos, creo que eso se controla ya.

DyV escribió:
PCMark es, según tengo entendido, un conjunto de kernels sintéticos que hacen pruebas del rendimiento de CPU, RAM y discos duros con cargas de trabajo típicas y máximas. Es tan representativo (o tan poco representativo) como el 3D Mark. No es que sea literal, pero es orientativo. A mi no me parece un mal benchmark si sabes leer los resultados.

Y respecto a LINPACK, es un benchmark de los más válidos que te puedes encontrar, utilizan cargas de trabajo reales. Si hacen el hardware para que LINPACK corra más, pues cojonudo. LINPACK no es en absoluto sintético, es un conjunto de problemas algebraicos de alto rendimiento. Si tu máquina los resuelve más rápido que ninguna otra, resolverá más rápido que ninguna otra las aplicaciones de cálculo numérico. Por eso se utiliza LINPACK para hacer el top500. El truco que creo que se ha utilizado alguna vez, era en los compiladores. Cuando detectaban que se compilaba LINPACK, se escupía un LINPACK optimizado a mano. Pero vamos, creo que eso se controla ya.

Sip, DyV, sé lo que es el TOP500, el LINPACK y demás, jejejeje. Básicamente son aplicaciones que usan la FPU (especialmente operaciones con matrices y ecuaciones gaussianas).

Eso depende mucho de la arquitectura. No siempre los ordenadores con mejor valor LINPACK serán los más óptimos. Simplemente son los que mejor orientación a la alta productividad poseen, pero no al alto rendimiento. Hay computadores que tienen arquitectura en constelación que probablemente den mejores resultados para casi todas las aplicaciones, ya que mezclan los paradigmas de memoria distribuida y compartida.

Lo que me refería del LINPACK es precisamente eso, que ha habido mucho trucaje (y no sé si sigue habiéndolo), porque todas las empresas quieren tener sus equipos en la lista. Obviamente, estamos hablando de supercomputadores (aunque no dejan de ser clusters con buena comunicación). Si hablamos de pc's comúnes y tienen una buena puntuación de LINPACK es que tenemos buenos cacharritos en casa... jejeje.

Un saludo

alkaitz escribió:
Sip, DyV, sé lo que es el TOP500, el LINPACK y demás, jejejeje. Básicamente son aplicaciones que usan la FPU (especialmente operaciones con matrices y ecuaciones gaussianas).

Ese es el problema del LINPACK, que favorece exclusivamente el cálculo en coma flotante, cuando éste es bastante despreciable para el uso general.

Usando LINPACK, la ps3 sería un pedazo de ordenador que te cagas, cuando la realidad es que para uso general es bastante limitadita. Por eso no se usa apenas para equipos domésticos, porque no refleja la realidad con la que se encontrará el usuario.

Johny27, creo que ahí tienes toda la razón.

Normalmente la capacidad computacional se mide en MFlops (o GFlops/TFlops si se da el caso), y ahí cpu's como el Cell parecen bestias pardas.

El problema es que el 99% de las aplicaciones que comúnmente se usan, a excepción de juegos claro, son aplicaciones de números enteros. Ahí se hace necesario un buen predictor de saltos y un buen algoritmo de ejecución fuera de orden (cosas que por ejemplo la cpu de la ps3-xbox360 no tienen, o eso leí).

Intentan potenciar la ejecución paralela de aplicaciones, pero como sean de enteros... malamente. De hecho, la cpu de la ps3 no se comporta demasiado bien con aplicaciones enteras. La muestra fué cuando Jade Raymond (productora de Assassins Creed) dijo que la Inteligencia Artificial (aplicación de enteros, donde las haya) correría mejor en la xbox360 que en la ps3. A la media hora dijeron que fué una confusión, pero pareció más bien un "silenciar bocas, que no necesitamos enemigos".

Hay que tener ojo con las arquitecturas, porque las saben vender muy bien y luego no son cosas con las que exagerar tanto.

Un saludo

Pero vamos a ver, es que LINPACK nunca ha sido un benchmark de propósito general, sino un benchmark de alto rendimiento (no de alta productividad). Y si una máquina está más arriba en el top500, es porque es más rápida resolviendo problemas de cálculo numérico, sin más. Y las máquinas del top500 son máquinas destinadas precisamente a eso. Por eso LINPACK es un benchmark tan bueno, tiene un área de aplicación concreto y lo cubre perfectamente. LINPACK no tiene sentido fuera del área de alto rendimiento, pero es que se hacen computadores específicamente para ese área y son los más caros, así que a la hora de gastarse los cuartos es conveniente saber si tu máquina es mejor o peor que otra y cuánto mejor o peor es para poder evaluar el gasto. Y para eso LINPACK está perfectamente diseñado.

Cuando estudiaba evaluación del rendimiento, LINPACK era el ejemplo de benchmark bien hecho.

DyV, ¿estás seguro que LINPACK está diseñado para alto rendimiento? Te lo digo porque la mayoría de equipos del TOP500 son clusters, y por lo tanto son equipos de memoria distribuida -> malos para el alto rendimiento pero buenos para alta productividad. Te lo digo por eso.

A lo mejor estamos hablando de los mismos conceptos pero con distinto significado, aunque lo dudo...

Todo lo demás no te lo discuto.

Un saludo

alkaitz escribió:DyV, ¿estás seguro que LINPACK está diseñado para alto rendimiento? Te lo digo porque la mayoría de equipos del TOP500 son clusters, y por lo tanto son equipos de memoria distribuida -> malos para el alto rendimiento pero buenos para alta productividad. Te lo digo por eso.

A lo mejor estamos hablando de los mismos conceptos pero con distinto significado, aunque lo dudo...

Todo lo demás no te lo discuto.

Un saludo

Los clusters los hay de alto rendimiento y de alta productividad. Incluso ahora hay procesadores de alto rendimiento (como Cell) y procesadores de alta productividad (como el Niagara, creo que lo llaman T1 (y T2) ahora). Que sea memoria distribuida no implica que no valga para alto rendimiento. Te estarías dejando por el camino como 15 o 20 años de trabajo en división del trabajo, paralelización y comunicación entre procesos (multigrid o MPI, por ejemplo). La razón de utilizar clusters (que aunque sean clusters, no son clusters beowulf; tienes una redes de comunicación del copón bendito y una organización de la leche) es que pueden escalar mucho mejor que los sistemas NUMA. Con lo que al final puedes alcanzar rendimientos muy superiores a los sistemas de memoria compartida. La contrapartida es que son mucho más difíciles de programar (hablo desde la experiencia).

Si el top500 fuese una lista de computadores de alta productividad, no medirían el rendimiento el MFLOPS, sino en MTs o lo que se estile ahora en alta productividad. Si te fijas para qué los utilizan (lo puedes leer en las descripciones) son todas tareas de alto rendimiento: predicción meteorológica o de terremotos, simulación de procesos biológicos, simulación de fluídos, simulaciones de física de altas energías, etc.

Y sí, yo creo que entendemos los dos lo mismo por alta productividad y alto rendimiento. Alta productividad (high throughput computing): terminar el mayor número de trabajos por unidad de tiempo. El tiempo que tarda un trabajo individual no es importante, lo importante es que acaben muchos por unidad de tiempo. Alto rendimiento (high performance computing): terminar un trabajo en el menor tiempo posible. Lo más importante aquí es que la predicción del clima de mañana esté terminada antes de mañana. O que la simulación de la aerodinámica de mi ala esté terminada, si puede ser en 3 días, mejor que en 3 semanas.

Creo que lo que te falla es que no tienes práctica con estos sistemas y te has perdido en algún concepto teórico (es complicado saber cómo funcionan estas máquinas si no intentas programarlas; según mi opinión, es lo más complejo que se puede hacer en programación). Si te motiva el tema, te recomiendo alguna lectura sobre paralelización de algoritmos numéricos. Me da la sensación de que tienes base de sobra para entenderlo y te despejará las dudas que puedas tener sobre los clusters de alto rendimiento.

DyV (divide y vencerás?¿?¿ jeje), gracias por la información.

Precisamente no es que sea un erudito del tema, en absoluto, pero me llama la atención porque he cursado una asignatura en la facultad (Procesamiento Paralelo) en la que nos han explicado las bases de todo esto. Obviamente, hasta que uno no se mete no vé las diferencias que describes, pero leyéndolas creo que tienes toda la razón (me están dando en este post por todas partes, si lo sé no digo ná... jeje, es broma. No podría mantenerme callado).

De todas formas me he debido liar yo sólo (o no me habré detenido a pensar) porque lo que has dicho coincide con lo que creía saber.

Por cierto, paradigmas como OpenMP son muy interesantes. Sobre todo cuando lo más que se suele enseñar a nivel "standard" son hilos POSIX (o Win32 en su caso...). MPI ya es más jaleoso...jeje, mucho mensajito dando vueltas.

Un saludo

alkaitz escribió:DyV (divide y vencerás?¿?¿ jeje), gracias por la información.

Jeje, no se te escapa nada

alkaitz escribió:Por cierto, paradigmas como OpenMP son muy interesantes. Sobre todo cuando lo más que se suele enseñar a nivel "standard" son hilos POSIX (o Win32 en su caso...). MPI ya es más jaleoso...jeje, mucho mensajito dando vueltas.

Un saludo

El problema con OpenMP es que, además de que tienes que localizarte tú el bucle paralelo de todas formas, solo funciona con memoria compartida (se limita a lanzar un hilo por cada iteración (o bloque de iteraciones) de un bucle). Y el MPI, si te pones alguna vez con ello, no es simplemente el problema de tener que sincronizar a base de mensajes los hilos (que esencialmente es tedioso), son todos los problemas derivados de la sincronización. El desequilibrado, la compartición de fronteras, la planificación, el problema de la construcción del mensaje (que se vuelve crítico en la etapa de comunicación)... en fin, es un tema muy extenso y muy complejo que ha dado fruto a muchas investigaciones durante los últimos 20 años. Hacía unos cuantos que la cosa estaba bajando, pero ahora que están apareciendo a tutiplén los procesadores multicore y amenazan con los manycore, muchos de esos temas están resurgiendo.

Si te interesa el tema, te recomiendo que no te quedes con la asignatura de PP. Está muy bien para ver un poco todo lo que se mueve (que es eso del Grid, OMP, MPI, PVM, problemas básicos de paralelización, etc), pero el procesamiento en paralelo, como digo, es de los temas más complejos. Y hay mucha miga por debajo que no se queda en meros detallitos, sino que es el grueso del problema. Normalmente, en otros temas el grueso está en las nociones que te suelen contar. En el tema del procesamiento paralelo y la computación de alto rendimiento, el grueso está en lo que subyace.

En fin, no quiero enrollarme porque esto ya está fuera del tema de la noticia. Es solo que me apasionan estos temas y tampoco yo podía quedarme callado xD

¡Un saludo!

MÁS OFFTOPIC: ON

El verdadero meollo del procesamiento en paralelo en clusters y demás son la gestión y el soporte.

Cada cluster es un mundo aparte, con su arquitectura propia y su idiosincrasia. Por experiencia puedo decir que da igual que 2 instalaciones estén formadas por el mismo tipo de máquinas conectadas con los mismos medios, siempre hay algún detallito en alguna parte que hace que algo que funciona a las mil maravillas en una no sirva de nada en la otra. Aparte de eso, las arquitecturas que utilizan no suelen ser las habituales, sino más específicas y orientadas al uso que se va a hacer de la máquina, por lo que no encontrarás una versión de ningún software lista para instalar... Así, instalar cualquier aplicación en el sistema se convierte en una pequeña aventura: la mayoría de las veces te toca retocar mil cosas y, por descontado, recompilarlo probando mil combinaciones porque las que supuestamente deberían funcionar, no funciona. En resumen: el soporte es el equipo que gestiona la máquina, que se lo tiene que guisar y comer todo (el proveedor de los equipos te da 3 cositas contadas).

Con la gestión pasa otro tanto: tener miles de CPUs trabajando a la vez, con sistemas de ficheros distribuidos, sistemas de balanceo de carga, centenares de usuarios perreando por ahí, comunicaciones vía fibra óptica, etc, etc, etc es un auténtico puzzle en el que nunca consigues que tooooooodo funcione al 100%. Siempre hay un proceso dando guerra en alguna CPU, algún disco que falla, una fibra que se parte...


Pero, eso sí, ¡es una pasada!

MÁS OFFTOPIC: OFF

Alguien tiene alguna noticia nueva de todo esto? Siguen investigando o todo se queda en saco roto como lo del juego del Lego, que una vez mostrado no se supo más de él?