Banco de pruebas Hardlimit

[cobito]

Ya está todo migrado a la versión 3. Los detalles los podéis vez en el primer post de este hilo. A parte de la migración, el cambio más importante es que se ha añadido la sección "Arquitecturas" donde aparece una lista de todas las arquitecturas para las que tenemos resultados. En general, ha habido muchos cambios. Seguramente la página con más novedades con respecto a la anterior versión es la de las comparativas, donde sale información adicional y mejor ordenada.

A partir de ahora, se irán añadiendo poco a poco las cosillas que van faltando, principalmente algunos rankings, informaciones adicionales en las distintas páginas y algunas descripciones.

Próximamente se anunciará otro cambio mayor que vendrá de la mano de las firmas. Pero para ese abriré un hilo nuevo.

[whoololon]

Menuda pasada.
Guarda todo eso con siete llaves, que esa base de datos vale su peso en oro.

Estaría bien que, una vez que entras y validas los datos, la elección del estilo para la firma fuese automático, quiero decir que en lugar de copiar, abrir tu perfil, editarlo y pegarlo en la firma, lo hiciese del tirón.

Aparte, si eliges lo del ranking, directamente te sales del parchís.

Pero a lo que voy, gracias por el curro que te estás pegando.

[cobito]

Gracias @whoololon. En realidad esto funciona gracias a los que participáis.

Lo de actualizar la firma automáticamente es algo que me da un poco de miedo por razones de seguridad.

Sobre lo del ranking, en realidad no está pensado como firma sino para compartir resultados por ahí. Es decir, pasas el banco de pruebas, quieres presumir de resultados y en vez de poner un enlace soso, pones una imagen molona.,

[whoololon]

Ah, asíposí.

Gracias por la aclaración.

Para la próxima versión, en el mensaje final cuando recopila datos, corrige lo de "Retriving data".

[cobito]

Tengo una duda sobre unos resultados. A ver si alguien sabe por qué podría pasar esto.

El otro día, @krampak subió unos resultados del Ryzen 7 2700x. En concreto, me llamó la atención este ejecutado con 32 hilos. Este modelo tiene 8 núcleos con SMT. Mirando los resultados de una validación a 16 hilos subida por el mismo @krampak el mismo día, presumiblemente desde la misma máquina, se ven unos resultados comparativamente curiosos.

Dejando de lado los tests de memoria, en los tests monohilo, la validación a 32 hilos saca un 1.2% más que la de 16 hilos. Con eso sabemos que las condiciones han sido las mismas (mismas cargas en segundo plano) y además sabemos que ambos tests se han corrido a frecuencia de stock.

En cambio, en los tests multihilo, la validación a 32 hilos saca un 5.3% más de rendimiento que la de 16 hilos. La forma en que funciona el banco de pruebas en multihilo es muy sencilla: se lanza un proceso por hilo, hace sus operaciones, calcula sus puntuaciones y por último se suman las puntuaciones de todos los procesos. Es decir, que si ha sacado más puntos, es porque ha podido hacer más operaciones en el mismo tiempo.

A mi sólo se me ocurren dos posibilidades:

1. Que al ejecutar 32 hilos, el banco de pruebas esté acaparando un mayor porcentaje de CPU, quitando tiempo de proceso a programas en segundo plano.
2. Que se esté aprovechando mejor la segmentación del procesador.

Si no recuerdo mal, este comportamiento también lo apreció @kynes hace tiempo. Una tercera posibilidad es un fallo en el programa, pero revisando el código, no se me ocurre de qué forma podría estar ocurriendo porque, además, el resultado del test de enteros es prácticamente igual en ambos casos; con un fallo en el programa, se tendría que haber reproducido el comportamiento en todos los tests.

En fin, ahí lo dejo por si os apetece cavilar un rato.

[whoololon]

Yo lo que digo es que, con la que se ha montado con el pufo de UserBenchmark, se necesita un sitio serio para comparar procesadores... ahí lo dejo.

[cobito]

Como ya he comentado en el otro hilo, el programa está firmado con una CA aprobada por Microsoft. Así que a partir de ahora, esto se convierte en algo serio.

Todavía aparece la Smartscreen de Windows. La teoría dice que el programa (pero sobre todo el certificado), tienen que ganar reputación. Hay tres formas de ganar reputación:
· Dejar el ejecutable en un lugar público. Con el tiempo, irá ganando puntos. Esto está hecho.
· Descargándolo desde distintos sitios. Cuanto más se descargue y ejecute, más puntos ganará. Por ahí leo que si se hace desde Internet Explorer o Edge será mejor. Pero en realidad creo que da un poco igual. La cuestión es sencillamente descargarlo y ejecutarlo (no hace falta pasarlo ni validar). Aquí es donde podéis echar una mano.
· Dejando el ejecutable en cualquier carpeta (como la de descargas) para que el programa de Telemetría de Windows lo vea.

De esa forma, en cuestión de días, desaparecerá el mensaje de advetencia.

@whoololon dijo en Banco de pruebas Hardlimit:

Yo lo que digo es que, con la que se ha montado con el pufo de UserBenchmark, se necesita un sitio serio para comparar procesadores... ahí lo dejo.

Pues sí, es posible que sea un buen momento para mover el asunto. Tengo algunas ideas...
Por cierto, la errata en el texto que comentaste ya está corregida.

Sobre la central, ha habido un par de actualizaciones menores. Las más importantes (los detalles en el primer post del hilo):
· Ahora se muestra ranking de OC en cada ficha.
· Ahora se muestra la versión en castellano si se detecta un navegador en catalán, gallego, vasco, asturleonés u occitano.

[whoololon]

Le he estado echando un vistazo, y no me queda claro si los resultados que se muestran, tanto en la descripción del micro como en la tabla de clasificación, son las mejores puntuaciones (micro con OC hasta las trancas en configuración específica para pruebas estilo Xevipiu), o el promedio de todos los resultados validados para el micro, o sólo los que van con la frecuencia de serie...

Gracias de antemano.

[cobito]

@whoololon Tanto en la descripción del micro (cpu.php) como los distintos rankings de procesadores y arquitecturas, se tienen en consideración para hacer la media sólo resultados sin OC (frecuencia de stock). Los resultados oceados aparecen en una tabla a parte dentro de la ficha de cada modelo (si es que hay resultados oceados).

En los resultados de una validación (result.php), los datos son los correspondientes a la validación en cuestión, sin tener en cuenta otras validaciones. La tabla de clasificación de usuarios que aparece tanto en portada como en el resultado de la validación tienen en cuenta validaciones individuales, incluyendo procesadores oceados y sin hacer medias.

En resumen: las fichas y los rankings calculan una media de las validaciones a frecuencia de stock. Si hay resultados oceados para un modelo, se muestran en la ficha a parte. Los rankings de usuarios muestran resultados individuales (sin media) incluyendo validaciones oceadas.

No sé si era eso lo que preguntabas.

[whoololon]

Sí, era eso; gracias por la aclaración.

[kynes]

@cobito Hay algo que me tiene mosqueado. El micro de mi portátil tiene 4 nucleos 4 hilos, pero gana unos 25000 puntos en multihilo si pongo 8 hilos en vez de 4. Entiendo que debe ser que así acapara más tiempo del procesador, pero entonces no serían totalmente consistentes los resultados si no se utilizan el máximo de hilos posibles. ¿Habría alguna forma de probar más de 8 hilos, para ver qué resultado da? Si es marginalmente superior o similar, es una cuestión de uso de micro. Si es muy superior, debe ser un bug del banco de pruebas.

[cobito]

@kynes Antes de nada, hay una discrepancia entre los resultados del programa y la central que no está corregida todavía porque estoy pensando cómo dar el resultado más fidedigno posible: el programa usa el método antiguo que consiste en tener el cuenta el máximo resultado de cada test. En la central se hace una media de las 10 muestras por test. De esa forma, desde el programa se aprecian variaciones superiores entre ejecuciones mientras que en la central, esas diferencias (que pueden estar provocadas por procesos en segundo plano), se filtran y se aprecian menos.

Una vez dicho eso, de los 4 resultados que has enviado (2 con 4 hilos y 2 con 8 hilos), he escogido los extremos para tener el peor caso posible: el que ha dado menor puntuación en 4 hilos y el que ha dado más puntuación en 8 hilos. La diferencia en la puntuación total multihilo es de un 4.7%. Para tener una referencia, las diferencias entre los dos resultados a 4 hilos y a 8 hilos son de un 1.3% y un 1.2% respectivamente.

A mi, personalmente, que haya un 4.7% de diferencia entre los extremos vs que haya un 1.2% de diferencia en validaciones con mismo número de hilos, me parece normal viendo cómo Windows 10 tiene cien cosas en segundo plano.

Pero algo que sí podría ser un fallo del programa (y que además sería bastante difícil de diagnosticar como de corregir si realmente fuera un fallo), es el hecho de que en las pruebas con 8 hilos, haya un pico de puntuaciones en la primera muestra. Seguramente por eso has medido una diferencia tan grande en los resultados del programa donde se han tomado esos picos a la vez que en los resultados de la central, esa diferencia es mucho menor, por haberse calculado la media.

Voy a ver si tengo un ratillo y preparo la versión sin límite de hilos que comentas para que puedas probar eso.

[cobito]

@kynes Aquí hay una versión modificada sin límite de hilos. En general, parece que el resultado multihilo es porporcional al número de núcleos independientemente del exceso de hilos, a pesar de que existe una pequeña mejoría cuando el número de hilos es superior al del procesador. Pero hay una máquina donde la sincronización de hilos ha fallado y no se ha detectado, generando un resultado sin sentido. El PC tiene 4 núcleos con HT y a partir de 32 hilos parece que falla.

Esta versión sólo funciona en modo FPU y AVX 2 y los resultados no son validables.

[kynes]

Entiendo que si se hiciera la media de los hilos, el resultado sería coherente, pero hay uno que se va de madre. Voy a probar con 128 a ver qué pasa.

[kynes]

Con 128 hilos creo que tengo el record mundial en multihilo:

Bueno, y si no lo tengo, lo pruebo en 256 hilos a ver qué pasa

[cobito]

@kynes Ahí es evidente la diferencia. En mi caso también lo estoy viendo. Supongo que al final tendré que aplicar una especie de media truncada: algo así como eliminar los dos valores más altos, los dos más bajos y hacer una media de los 6 restantes. Porque está claro que los espúrios del inicio falsean la medida.

También voy a revisar el mecanismo de sincronización, a ver si estuviera por ahí el fallo.

Por cierto, cuidado con los 256 hilos, porque si el sistema se peta y los procesos pierden la comunicación entre sí, se pueden quedar permanentemente a la espera consumiendo el 100% de todos los núcleos y necesitarás, o bien cerrar cada proceso manualmente o reiniciar el PC.

[cobito]

@kynes dijo en Banco de pruebas Hardlimit:

Con 128 hilos creo que tengo el record mundial en multihilo:

Bueno, y si no lo tengo, lo pruebo en 256 hilos a ver qué pasa

Ahí ha fallado la sincronización. Básicamente estás pasando un puñado de hilos en tiempos diferentes y se están sumando las puntuaciones como si se hubieran pasado todos a la vez.

[cobito]

Algunas conclusiones que saco de esto:

1. Cuando el banco de pruebas se ejecuta con una cantidad 4 veces superior al número de hilos del procesador, el programa falla y da resultados absurdos. Esto no me preocupa porque va a estar limitado al doble de hilos.

2. Cuando se ejecuta una cantidad superior al número de hilos del procesador (pero por debajo de una cantidad absurda), se suelen producir espurios en la primera muestra. Aquí resultados al doble de hilos de tres modelos diferentes:

Core i7-6820HQ

Pentium N3540

Core i5-7300HQ

Que esto suceda en tres modelos diferentes, deja claro que es un comportamiento generalizado. Curiosamente, estos picos se ven en los tests#1, 2 y 4, pero no en el 3. Que no se reproduzca ese comportamiento en el 3, hace que me resulte complicando pensar en un fallo del programa, pero no se puede descartar todavía.

A continuación, los mismos modelos con un número de hilos igual a los de la CPU:
Core i7-6820HQ

Pentium N3540

Core i5-7300HQ

Si hay picos, son prácticamente inapreciables.

3. En los i5 e i7, se aprecia una mejora sostenida durante toda la prueba. Aquí sólo hay dos opciones: que se esté acaparando una mayor cantidad de CPU o que se esté aprovechando mejor la segmentación. En el caso del Core i7-6820HQ, es un PC con bastantes programas en segundo plano junto a un antivirus. El Pentium N3540 lleva Windows 10 sin más, sin nada en segundo plano y sin antivirus. Quizás por esto, el duplicar el número de hilos no mejora el rendimiento de una forma sostenida.

En general

Lo que distorsiona el resultado mostrado en el programa con el doble de hilos es el pico inicial. El problema es que no sé por qué se produce. Si fuera el programa, esperaría un pico en todos los tests o un pico al principio y otro al final, pero no se produce así. ¿Puede ser una jugarreta de la caché? La verdad es que ni idea. Pero raro es y al programa habrá que darle un repaso.

[krampak]

¿Y por qué no quitamos la opción de especificar nº de hilos y forzamos a que siempre corra con el nº de núcleos de que disponga la CPU? Lo digo para evitar diferencias innecesarias entre usuarios.

[cobito]

@krampak Inicialmente, la razón de tener la libertad de especificar el número de hilos fue por si fallaba la detección del HT/SMT. De momento, eso no ha pasado ninguna vez. Así que por ahí, no hay razones para mantenerlo.

Desde el punto de vista de medir el rendimiento de un procesador, elegir el número de hilos sirve para ver cómo rinde un micro a media carga, algo que sería bastante interesante de cara a evaluar procesadores a media carga, que en realidad es como se usan buena parte del tiempo. Pero si ya es difícil recibir validaciones con la configuración por defecto, mucho más lo es con configuraciones un poco exóticas.

Aquí una solución, como dices, es, o bien quitar la posibilidad de elegir el número de hilos o quizás limitar el máximo al número de hilos del procesador para dejar abierta esa posibilidad.

Otra posibilidad (que es complementaria) es hacer una media truncada, algo que se acabará aplicando porque eso corregiría todos los resultados que se han enviado hasta ahora.

Y otra posibilidad es ignorar directamente la primera muestra; una solución sencilla pero poco elegante.

El método sobre cómo calcular la puntuación final es algo a lo que llevo tiempo dándole vueltas (de ahí que el programa y la central usen criterios diferentes). La media truncada es la que lleva las de ganar porque evita este tipo de problemas de origen desconocido y porque filtra el resultado en PCs con carga moderada de fondo.

El banco de pruebas tiene varios mecanismos para evitar trucar resultados y en el inicio del desarrollo, fue la parte a la que se le dedicó más horas. Afortunadamente, este fallo tiene solución con carácter retroactivo. Una cosa clara es que uno de los objetivos es que se mida el rendimiento real de la máquina, sin que una configuración determinada del programa ofrezca una superioridad de rendimiento que no existe.

Esto último lo digo para que quede claro que este no es un fallo baladí y que se va a solucionar. Hasta entonces, sigo abierto a sugerencias.