Banco de pruebas Hardlimit

[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.

[whoololon]

A ver si lo he entendido bien: el programa ejecutado por defecto muestra resultados fiables, pero al ajustar el parámetro de cuántos hilos queremos que use, es propenso a mostrar resultados "inusuales"...

Si es así, personalmente sólo dejaría validar los resultados obtenidos por defecto, al menos hasta que se solvente la incidencia... sólo nos faltaba un ejército de pollagorders haciéndose trampas al solitario y de paso, adulterando la clasificación (ésto para mí es lo más grave, al fin y al cabo, creo que lo que se pretende es que la tabla sea fiable).

La opción de elegir el número de hilos se puede mantener, avisando que puede dar resultados erroneos y que no sirven de manera "oficial", para los que les guste el cacharreo.

[cobito]

Seguramente, para mañana o pasado (a partir de ahí, lo que tarden en certificar los de Microsoft) esté lista la versión 1.4, que vendrá con el tema de las puntuaciones falseadas solucionado entre otros cambios.

Si alguno tenéis algún procesador actual y potente, me vendría bien una captura de la pestaña CPU para ponerla en la página de la Store, que por aquí sólo tengo PCs un poco viejunos.

[whoololon]

Esto es lo más potente que tengo en mi casa, no sé si es lo que buscas.

[cobito]

@whoololon Gracias por la imagen. Al final no la he puesto porque parece que está muy comprimida y no se ve bien en la Store.

Sobre el programa, ya está disponible la versión 1.4. Los detalles los tenéis en el primer mensaje de este hilo. En esencia, entre otras cosas se ha corregido el tema de las puntuaciones falseadas y se han hecho algunos cambios en la interfaz.

De momento, se sigue pudiendo elegir el doble de hilos de los máximos del procesador sólo en modelos sin HT/SMT.

[krampak]

Muy chula la última versión !! se ve más profesional y se nota muchísimo el reducido tiempo de carga.

[whoololon]

Y para celebrarlo, lo inauguramos con un radiante i3-3120M.

Edito: Por cierto, sigue saltando el Smart Screen, al menos en W8.1.

[cobito]

@krampak dijo en Banco de pruebas Hardlimit:

Muy chula la última versión !! se ve más profesional y se nota muchísimo el reducido tiempo de carga.

Gracias. Me alegra que se aprecie la diferencia en el arranque.

@whoololon dijo en Banco de pruebas Hardlimit:

Y para celebrarlo, lo inauguramos con un radiante i3-3120M.

Edito: Por cierto, sigue saltando el Smart Screen, al menos en W8.1.

Perfecto, hacía tiempo que no entraba nada nuevo.

Lo del Smart Screen también sigue pasando en Windows 10. La verdad es que está tardando más de lo que he leído por ahí. Quizás todavía no se ha descargado las veces suficientes o puede que al final sí que sea importante descargarlo desde Internet Explorer o Edge. Espero que en los próximos días acabe desapareciendo.

[Xevipiu]

Nuevo micro

[url=https://bm.hardlimit.com/result.php?bm=0f38c8bc44c5faeaa7a1f2038f2a2b492134] [img]https://bm.hardlimit.com/screenshot.php?bm=0f38c8bc44c5faeaa7a1f2038f2a2b492134&style=1[/img] [/url]

https://bm.hardlimit.com/screenshot.php?bm=0f38c8bc44c5faeaa7a1f2038f2a2b492134

[cobito]

@Xevipiu ¿Es una muestra de ingeniería? ¿Quizás de un Core i9-9900K/S?