He decidido sacar del cajón a dos portátiles del siglo pasado, ambos Compaq: un Pentium II Dixon a 333Mhz y un 486DX4 a 75MHz.
Al encenderlos he visto que ambos tenían Windows 98 SE de la última vez que estuve jugando con ellos. Lo primero que me ha apetecido hacer es pasarle el banco de pruebas de Hardlimit, como no.
Esta entrega se limitará a comparar sus procesadores con máquinas más modernas con HLBM y si gusta, habrá más capítulos en el futuro.
HLBM en máquinas antiguas
Desafortunadamente, es imposible instalar Windows Vista en ninguno de los dos (requisitos mínimos de HLBM), así que he decidido parchear el banco de pruebas para que funcione en Windows NT4.0/2000/XP, los NT de 32 bits que que no son compatibles. De momento esta versión «Legacy» se queda para uso interno.
Dos mundos que no se entienden entre sí
Aunque parezca una broma, una de las dificultades ha sido instalar el sistema operativo y pasar programas. En el Pentium II no ha habido mayores problemas porque cuenta con lector de CDROM desde el que se puede arrancar y dispone de USB. Pero para el 486 el tema ha sido algo más complicado.
Se han probado tres métodos para pasar archivos: disquetes de 3.5″, un adaptador USB a IDE portátil y un cable serie null-modem. Para el primer método han sido necesarios disquetes (no es tan fácil encontrar cajas nuevas a un precio razonable) y una disquetera USB. Esta forma es adecuada para pasar pequeñas cantidad (por ejemplo, el banco de pruebas en sí), pero es una tortura cuando se trata de instalar Windows.
El método del adaptador USB a IDE portátil es sin lugar a dudas el más eficiente. Se ha empleado para copiar los archivos del CDROM de instalación de Windows en una partición para tal efecto del disco duro. El principal inconveniente es que con cada transferencia, hay que desmontar el disco del ordenador y conectarlo y quieras o no, cada vez que se hace se deterioran los pines, se fuerzan piezas, etc. Es decir, en un PC tan usado y viejo no es lo más recomendable.
Y por último, la transmisión por cable serie null-model se ha mostrado bastante cómoda aunque es extremadamente lenta (115kbps). Pero como lo único que hay que hacer es esperar, ha resultado ser una forma eficaz de transportar cantidades importantes de datos. Evidentemente para esto ha sido necesario un cable serie con la configuración de cables correcta y buscar por ahí el ejecutable de HyperTerminal que afortunadamente funciona en Windows 7.
Reliquia 1: Pentium II
La primera reliquia es un Compaq Armada 1750 (ya lo he presentado con anterioridad). Se trata de un Pentium II Dixon a 333MHz con 192Mb de RAM y una tarjeta gráfica ATI de 4Mb. Para esta prueba se ha puesto un disco duro (IDE) de 20Gb y como el hardware lo ha permitido, le he instalado Windows XP con Service Pack 3.
El PC va bastante fluido en general y el banco de pruebas lo ha pasado sin problemas (a excepción de la detección de hardware, que ha fracasado miserablemente). Los resultados para el modo 0 los podéis ver aquí.
Bien, las puntuaciones son bastante bajas. Pero en ese resultado se ve algo sorprendente: la eficiencia por ciclo. Si cogemos un micro mucho más reciente (pero no completamente actual) como un Core 2 Duo E6600, vemos que el rendimiento por ciclo en coma flotante se mantiene en 1 mientras que en enteros tan solo se ha duplicado. Eso demuestra que la FPU ha sido un tema completamente abandonado por Intel en todo ese tiempo. Esto tiene cierto sentido si el software está optimizado para usar sets superiores y la realidad es que a día de hoy, es raro encontrar programas (principalmente multimedia y juegos) que usen microinstrucciones SIMD inferiores a SSE3.
Comparándolo con un procesador móvil actual, digamos un Core i7-6820HQ, este último es 37 veces más rápido que el Pentium II en el mismo modo. Y aquí sí, el rendimiento por ciclo el i7 se merienda al Pentium II (aunque no tanto en enteros que de hecho se mantiene al nivel del Core 2 Duo).
En general parece un procesador bastante competente. En operaciones aritméticas es sólo algo menos de la mitad de rápido que un Atom N270 que corre a 1.6GHz, aunque es 4 veces más lento en operaciones genéricas (test#4). Esto probablemente se debe a un bug de estos Atoms que por error, introducen una microinstrucción NOP (quedarse en reposo un ciclo) por cada operación aritmética. Eso se traduce en que estos procesadores hacen cálculos a la mitad de velocidad de la que realmente podrían alcanzar; una metedura de pata de las buenas por parte de Intel. Y esto deja a la primera generación de Atoms en muy mal lugar.
Reliquia 2: 486
Aquí nos adentramos en un mundo completamente diferente. Los 90 fueron unos años locos en la informática. La ley de Moore estaba en su máximo esplendor y todas las tecnologías que hoy damos por sentadas se estaban gestando en aquel momento. Eso hacía que en cuestión meses, un PC quedara obsoleto. Las diferencias de generación en generación eran abismales y no solo en rendimiento sino en funcionalidad. Los requisitos mínimos del software no estaban basados en que el programa funcionara a una velocidad razonable (como ahora) sino en que simplemente funcionara.
Los 486 supusieron un gran salto con respecto a los 386, entre otras razones porque era posible tener micros con coprocesador matemático integrado (en los 386 había que comprar el encapsulado a parte). Había dos familias: los SX (sin FPU) y los DX (con unidad de coma flotante). Y eso sin contar con los nuevos periféricos. El concepto de ordenador multimedia empezó con los 486.
La unidad de coma flotante fue evolucionando y con los Pentium apareció MMX, con los Pentium III SSE… y con los Ivybridge AVX2 que básicamente son coprocesadores matemáticos con funciones y registros extra. En la actualidad lo más avanzado en el cálculo de coma flotante en CPUs para PCs es AVX-512 que de momento sólo está disponible en algunos Xeons aunque ya está anunciada su llegada a los PCs domésticos. Pero todo eso es otro tema.
En este caso nos encontramos ante un Compaq Contura 420C. Tiene un 486DX4 a 75Mhz (uno de los últimos 486), 12Mb de RAM y un disco duro de 2Gb. Hay que destacar también que tiene pantalla a color de matriz pasiva de 640×480 píxels y 8 bits de profundidad de color (el color en portátiles no se daba ni mucho menos por hecho a mediados de los 90).
Su precio en la época eran «sólo» $2599 que teniendo en cuenta la inflación, son más de 3600€ de la actualidad. Para que nos hagamos una idea, sólo 4 años después se comercializó el Compaq Armada de arriba que como novedad incluía CDROM, tarjeta de sonido, aceleración gráfica 3D, pantalla de matriz activa (TFT) de 800×600 y 32 bits, 10 veces más de disco duro, 8 veces más de RAM y un procesador a 5 veces más frecuencia. Eran tiempos emocionantes.
En cuanto al software, lo normal para la época es que este PC viniera con Windows 3.11 o Windows 95 (que estaba recién estrenado). Como la familia 9x es incompatible con el banco de pruebas (habría que hacer demasiadas modificaciones al código), se ha optado por instalar Windows NT 4.0. Se trata de la primera versión NT de 32 bits que fue la base para Windows 2000 y posteriormente Windows XP, ambos padres del núcleo NT 10 que encontramos en el actual Windows 10 (arriesgando un poco se podría decir que Windows 10 no es más que Windows NT 4.0 Service Pack 38).
Se ha elegido la versión en inglés ya que me ha sido imposible encontrar el Service Pack 6 en español. Como tal, Windows NT 4.0 es un sistema operativo muy avanzado que necesita muchos más recursos que su homólogo para ámbito doméstico: Windows 95. Como se puede ver en la siguiente imagen, los recursos de hardware andan muy justos.
Nada más arrancado, Windows ya está consumiendo casi 14Mb de RAM. Si se abren las propiedades del sistema, vemos que esa cantidad sube a más 15Mb (recordemos que el PC tiene 12Mb de RAM) y hay un consumo continuado del 12% de CPU sólo por el hecho de tener el administrador de tareas en ejecución.
En este caso tenemos la posibilidad de ejecutar el banco de pruebas por una sencilla razón: el 486 es DX. Sin FPU hubiera sido imposible. El resultado se pueden consultar aquí.
Viendo las condiciones ante las que se ha ejecutado, no se puede considerar un resultado fiable ya que la falta de RAM por ejemplo, ha desvirtuado el banco de pruebas. De hecho, el resultado del rendimiento de la memoria (test#3) deja clara la situación.
En fin, se ha apurado demasiado el hardware. HLBM está pensado para máquinas modernas, con sets modernos y sin los problemas de antaño como tener libres unos cuantos Kbytes (o muy pocos Mb) de RAM. Así que de aquí no me atrevería a sacar ninguna conclusión.
Y con la presentación de estos viejos dinosaurios, doy por cerrada esta primera entrega.