MySQL x86 vs x64

En 7-Zip x86 vs x64, comparé las versiones de 32 y 64 bits del compresor 7-Zip. Una herramienta destinada a usuarios finales, en la que se concluía que el límite del benchmark en memoria, lo ponía el ancho de banda de momoria disponible, más que la velocidad de proceso de la CPU.

Ahora he decidido hacer algo similar, pero con software más particular, y en este caso, habitual de servidores, el MySQL Server 5.0.51a.

Primero de todo, un análisis estático de ambas distribuciones de MySQL una vez instaladas sobre Vista x64, y con el servicio corriendo:
– Tamaño del ejecutable principal: 5.616 Kb. (32 bits) / 8.215 Kb. (64 bits).
– Memoria RAM ocupada: 9.564 Kb. (32 bits) / 12.848 Kb. (64 bits).
– Espacio ocupado en disco: 163 Mb. (32 bits) / 209 Mb. (64 bits).

Hasta aquí, nada demasiado sorprendente, los ejecutables de 64 bits, requieren aproximadamente un 20% más de espacio en disco y memoria que los respectivos de 32 bits. Como es fácil imaginar, la causa estriba principalmente en el doble espacio que ocupan los punteros, y las constantes numéricas. Por otro, la madurez de los compiladores (Visual C++ en este caso), no es equiparable entre ambas arquitecturas.

A continuación, evaluemos las diferencias de rendimiento entre ambas plataformas. Para ello, he partido de una tabla sencilla con la siguiente estructura:

CREATE TABLE `t_mstr_test` (
`test_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`test_texto` text,
`test_fecha` datetime DEFAULT NULL,
PRIMARY KEY (`test_id`),
KEY `test_fecha` (`test_fecha`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

A esta tabla, le he añadido un único registro, donde además de la clave principal, se utiliza un índice sobre un campo de tipo fecha:

INSERT INTO `t_mstr_test` VALUES (1,'Fila 1','2001-01-01 01:01:01');

He dispuesto una segunda tabla, con idéntica estructura a la anterior:

CREATE TABLE `t_mstr_test2` (
`test2_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`test2_texto` text,
`test2_fecha` datetime DEFAULT NULL,
PRIMARY KEY (`test2_id`),
KEY `test2_fecha` (`test2_fecha`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

Y análoga información:

INSERT INTO `t_mstr_test2` VALUES (5,'Fila 5','2005-05-05 05:05:05');

Las pruebas de rendimiento, realizan una simple (y no demasiado útil) consulta SQL, que gracias a la función BENCHMARK, nos permite obtener el tiempo empleado en realizar 10 mil millones de repeticiones. Está pensada para tener un mínimo impacto en el acceso a disco y memoria, de manera que se obtenga un valor más aproximado de la mejora de eficiencia dependiendo de la CPU:

SELECT BENCHMARK(10000000000, 'SELECT test2_id FROM t_mstr_test2 WHERE test2_id NOT IN (SELECT test_id FROM t_mstr_test) LIMIT 1')

La ejecución ha tardado 12,90s en la versión de 32 bits, y 10,51s en la de 64 bits. Es decir, la mejora de rendimiento es de aproximadamente el 20% en la edición x64 si la comparamos con la tradicional x86.

Aunque más adelante escribiré en más detalle sobre ello, la mejora de velocidad no viene unicamente por la diferencia del ancho de palabra como podría parecer, sino que además, se beneficia de la disponibilidad de juegos de instrucciones extendidos como SSEx, disponibles en todos los procesadores x86-64; la disponibilidad de registros adicionales; y un convenio de llamada a funcionas, tanto en el propio sistema operativo, como en las aplicaciones que se aprovecha de ellos.