¿Qué es mejor para una aplicación web Java: más núcleos de CPU o una mayor velocidad de reloj?

Question 1

tldr;La verdadera respuesta es probablemente "más RAM", pero como usted hizo su pregunta, la respuesta es, por supuesto, que depende. Por otra parte, es casi seguro que 32 núcleos a 2,5 Ghz superarán a 8 núcleos a 3,8 Ghz: son 4 veces más núcleos frente a un reloj 1,5 veces más rápido. No fue una pelea muy justa.

Algunos factores que debes considerar son el tiempo de respuesta de las transacciones, los usuarios simultáneos y la arquitectura de la aplicación.

Tiempo de respuesta de la transacción Si su aplicación Java responde a la mayoría de las solicitudes en unos pocos milisegundos, entonces probablemente el camino a seguir sea tener más núcleos para manejar más solicitudes simultáneas. Pero si su aplicación maneja principalmente transacciones más complejas y de mayor duración, podría beneficiarse de núcleos más rápidos. (o puede que no, ver más abajo)

Usuarios y solicitudes simultáneos Si su aplicación Java recibe una gran cantidad de solicitudes simultáneas, probablemente será útil disponer de más núcleos. Si no tiene tantas solicitudes simultáneas, es posible que esté pagando por un montón de núcleos inactivos adicionales.

Arquitectura de aplicaciones Esas solicitudes de larga duración que mencioné no se beneficiarán mucho de los núcleos más rápidos si el servidor de aplicaciones pasa la mayor parte del tiempo de la transacción esperando respuestas de servicios web, bases de datos, kafaka/mq/etc. He visto muchas aplicaciones con transacciones de 20 a 30 segundos que solo pasan una pequeña parte de su tiempo de respuesta procesándose en la aplicación misma, y el resto del tiempo esperando respuestas de bases de datos y servicios web.

También debe asegurarse de que las diferentes partes de su aplicación encajen bien. No le sirve de mucho tener 32 o 64 subprocesos, cada uno manejando una solicitud, todos en cola esperando una de las 10 conexiones en el grupo JDBC, también conocido como el cerdo en un problema de Python. Un poco de planificación y diseño ahora le ahorrará muchos problemas de rendimiento en el futuro.

Una última cosa: ¿qué CPU podrías comparar? La CPU de 32 núcleos a 2,5 GHz más barata que puedo encontrar cuesta al menos 3 o 4 veces más que cualquier CPU de 8 núcleos a 3,8 Ghz.

Answer

tldr;La verdadera respuesta es probablemente "más RAM", pero como usted hizo su pregunta, la respuesta es, por supuesto, que depende. Por otra parte, es casi seguro que 32 núcleos a 2,5 Ghz superarán a 8 núcleos a 3,8 Ghz: son 4 veces más núcleos frente a un reloj 1,5 veces más rápido. No fue una pelea muy justa.

Algunos factores que debes considerar son el tiempo de respuesta de las transacciones, los usuarios simultáneos y la arquitectura de la aplicación.

Tiempo de respuesta de la transacción Si su aplicación Java responde a la mayoría de las solicitudes en unos pocos milisegundos, entonces probablemente el camino a seguir sea tener más núcleos para manejar más solicitudes simultáneas. Pero si su aplicación maneja principalmente transacciones más complejas y de mayor duración, podría beneficiarse de núcleos más rápidos. (o puede que no, ver más abajo)

Usuarios y solicitudes simultáneos Si su aplicación Java recibe una gran cantidad de solicitudes simultáneas, probablemente será útil disponer de más núcleos. Si no tiene tantas solicitudes simultáneas, es posible que esté pagando por un montón de núcleos inactivos adicionales.

Arquitectura de aplicaciones Esas solicitudes de larga duración que mencioné no se beneficiarán mucho de los núcleos más rápidos si el servidor de aplicaciones pasa la mayor parte del tiempo de la transacción esperando respuestas de servicios web, bases de datos, kafaka/mq/etc. He visto muchas aplicaciones con transacciones de 20 a 30 segundos que solo pasan una pequeña parte de su tiempo de respuesta procesándose en la aplicación misma, y el resto del tiempo esperando respuestas de bases de datos y servicios web.

También debe asegurarse de que las diferentes partes de su aplicación encajen bien. No le sirve de mucho tener 32 o 64 subprocesos, cada uno manejando una solicitud, todos en cola esperando una de las 10 conexiones en el grupo JDBC, también conocido como el cerdo en un problema de Python. Un poco de planificación y diseño ahora le ahorrará muchos problemas de rendimiento en el futuro.

Una última cosa: ¿qué CPU podrías comparar? La CPU de 32 núcleos a 2,5 GHz más barata que puedo encontrar cuesta al menos 3 o 4 veces más que cualquier CPU de 8 núcleos a 3,8 Ghz.

Question 2

Suponiendo que su servidor web Java esté configurado correctamente, debería optar por más núcleos.

Todavía hay dependencias, como semáforos, accesos concurrentes que todavía tendrán algunos hilos en espera, sea cual sea el número de núcleos o la velocidad. Pero es mejor cuando lo administra la CPU (núcleos) que el sistema operativo (multiproceso).

Y de todos modos, 32 núcleos a 2,5 Ghz manejarán más subprocesos y mejor que 8 núcleos a 3,8 Ghz.

Además, el calor producido por la CPU depende de la frecuencia (entre otras cosas) y ésta no es lineal. Es decir, 3,8 Ghz generará más calor que 3,8/2,5 x (debe confirmarse según los tipos/marcas exactas de su CPU... muchos sitios ofrecen información detallada).

Answer

Suponiendo que su servidor web Java esté configurado correctamente, debería optar por más núcleos.

Todavía hay dependencias, como semáforos, accesos concurrentes que todavía tendrán algunos hilos en espera, sea cual sea el número de núcleos o la velocidad. Pero es mejor cuando lo administra la CPU (núcleos) que el sistema operativo (multiproceso).

Y de todos modos, 32 núcleos a 2,5 Ghz manejarán más subprocesos y mejor que 8 núcleos a 3,8 Ghz.

Además, el calor producido por la CPU depende de la frecuencia (entre otras cosas) y ésta no es lineal. Es decir, 3,8 Ghz generará más calor que 3,8/2,5 x (debe confirmarse según los tipos/marcas exactas de su CPU... muchos sitios ofrecen información detallada).

Question 3

Nos dice que una solicitud tarda entre 100 y 200 ms en ejecutarse, y que es principalmente tiempo de procesamiento (aunque es difícil separar lo que es la ejecución real de la CPU de lo que en realidad es acceso a la memoria), muy poca E/S, espera bases de datos, etcétera.

Tendría que comparar cuánto tiempo tarda realmente cada una de las dos CPU, pero supongamos que tarda 150 ms en la CPU más lenta (con 32 núcleos) y 100 ms en la más rápida (con sólo 8 núcleos).

Entonces, la primera CPU podría manejar hasta 32/0,15 = 213 solicitudes por segundo.

La segunda CPU podría manejar hasta 8/0,1 = 80 solicitudes por segundo.

Entonces la gran pregunta es: ¿cuántas solicitudes por segundo esperas? Si no tiene ni cerca de docenas de solicitudes por segundo, entonces no necesita la primera CPU y la segunda le brindará un tiempo de ejecución más rápido en cada solicitud. Si necesita más de 100 solicitudes por segundo, entonces la primera tiene sentido (o probablemente tenga aún más sentido tener más de un servidor).

Tenga en cuenta que se trata de estimaciones muy preliminares. La única forma de saberlo con seguridad es comparar cada uno de los servidores con una carga real. Como se indicó anteriormente, las CPU rápidas o las CPU con muchos núcleos pueden quedarse rápidamente sin acceso a la memoria. El tamaño de las distintas cachés de la CPU es muy importante aquí, así como el "conjunto de trabajo" de cada solicitud. Y eso considerando un trabajo verdaderamente vinculado a la CPU, sin llamadas al sistema, sin recursos compartidos, sin E/S...

Answer

Nos dice que una solicitud tarda entre 100 y 200 ms en ejecutarse, y que es principalmente tiempo de procesamiento (aunque es difícil separar lo que es la ejecución real de la CPU de lo que en realidad es acceso a la memoria), muy poca E/S, espera bases de datos, etcétera.

Tendría que comparar cuánto tiempo tarda realmente cada una de las dos CPU, pero supongamos que tarda 150 ms en la CPU más lenta (con 32 núcleos) y 100 ms en la más rápida (con sólo 8 núcleos).

Entonces, la primera CPU podría manejar hasta 32/0,15 = 213 solicitudes por segundo.

La segunda CPU podría manejar hasta 8/0,1 = 80 solicitudes por segundo.

Entonces la gran pregunta es: ¿cuántas solicitudes por segundo esperas? Si no tiene ni cerca de docenas de solicitudes por segundo, entonces no necesita la primera CPU y la segunda le brindará un tiempo de ejecución más rápido en cada solicitud. Si necesita más de 100 solicitudes por segundo, entonces la primera tiene sentido (o probablemente tenga aún más sentido tener más de un servidor).

Tenga en cuenta que se trata de estimaciones muy preliminares. La única forma de saberlo con seguridad es comparar cada uno de los servidores con una carga real. Como se indicó anteriormente, las CPU rápidas o las CPU con muchos núcleos pueden quedarse rápidamente sin acceso a la memoria. El tamaño de las distintas cachés de la CPU es muy importante aquí, así como el "conjunto de trabajo" de cada solicitud. Y eso considerando un trabajo verdaderamente vinculado a la CPU, sin llamadas al sistema, sin recursos compartidos, sin E/S...

Question 4

Nota preliminar
me gustaría segundo@PosiblementeútilProbablementeno'srespuesta definitivamente útil.

tldr; La verdadera respuesta es probablemente "más RAM".

Especialmente este punto.

Advertencia
No tanto un administrador per sé.
Quizás más desde una perspectiva de ingeniería de software.

No hay alternativa a la medición

Lo que sabemos
Entonces, la máquina es

¿Va a ejecutar una especie de aplicación backend basada en Java (¿Enterprise?)
exponer públicamente (dentro de un contexto considerable, de todos modos) una API HTTP que maneja las solicitudes de los clientes
presumiblemente con algún tipo de base de datos adjunta
de lo contrario se describe como no muy vinculado a E/S
no depende de la disponibilidad, latencia o rendimiento de servicios de terceros

No es una imagen tan vaga, el OP está pintando. Pero al mismo tiempo están lejos de ser datos suficientes para dar una respuesta.relativo a la situación individual de los PO.
Claro, 32 núcleos a 2/3 de la velocidad del reloj sonprobablepara funcionar mejor que 1/4 de los núcleos con una ventaja de velocidad comparativamente pequeña. Claro, el calor generado no se adapta bien a velocidades de reloj superiores al umbral de 4 GHz. Y claro, si tuviera que poner mis huevos en una sola canasta a ciegas, elegiría los 32 núcleos cualquier día de la semana.

lo que no sabemos
Demasiado, todavía.

Sin embargo,Más allá de estas simples verdades, sería muy escéptico ante un intento hipotético de una respuesta más concreta y objetiva.. sifSi es posible (y tiene muchas razones para seguir convencido de que las operaciones por unidad de tiempo son una preocupación válida), consiga el hardware en el que desea ejecutar el sistema.medirlo y probarlo, de extremo a extremo.
Undecisión informadaimplica relevanteydatos creíbles.

OP escribió: La RAM no es importante

En la gran mayoría de los casos, la memoriaesel cuello de botella.

Por supuesto, el OPpregunta principalmente sobreNúcleos de CPU versus velocidad de relojy así la memoria aparece al margen de estar fuera de tema.

Aunque no creo que lo sea. Para mí, parece mucho más probable que la pregunta se base en una premisa falsa. Ahora, no me malinterpretes, @OP, tu pregunta está relacionada con el tema, está bien formulada y tu preocupación es obviamente real. Simplemente no estoy convencido de que la respuesta sobre qué CPU funcionaría "mejor" en su caso de uso sea relevante (para usted).

Por qué es importante la memoria (para la CPU)

La memoria principal esterriblemente lento.
Históricamente, en comparación con el disco duro, tendemos a pensar en la RAM como "el tipo de almacenamiento rápido". En el contexto de esa comparación, sigue siendo cierto. Sin embargo, a lo largo de las últimas décadas, las velocidades de los procesadores han aumentado constantemente a un ritmo significativamente más rápido que el rendimiento de la DRAM. Este desarrollo a lo largo del tiempo ha dado lugar a lo que comúnmente se conoce como"Brecha de memoria del procesador".

La brecha entre las velocidades del procesador y de la memoria (fuente: Carlos Carvalho, Departamento de Informática, Universidade do Minho)

Obteniendo una línea de cachédesde la memoria principal a un registro de la CPU ocupa aproximadamente ~100 ciclos de relojde tiempo. Durante este tiempo, su sistema operativo informará que uno de los dos subprocesos de hardware en uno de los 4 (?) núcleos de su arquitectura x86 esocupado.
Tan lejos como eldisponibilidadEn lo que respecta a este hilo de hardware, su sistema operativo no miente,está ocupado esperando. Sin embargo, la propia unidad de procesamiento, sin tener en cuenta la línea de caché que se arrastra hacia ella, esde facto inactivo.
No se realizaron instrucciones/operaciones/cálculos durante este tiempo.

+----------+---------------+---------------------------------------------------------------------------------------------------+
|  Type of |    size of    |                                Latency due to fetching a cache line                               |
| mem / op |     cache     +--------+--------+------------+--------------------------------------------------------------------+
|          |   (register)  |  clock |  real  | normalized |                            now I feel it                           |
|          |               | cycles |  time  |            |                                                                    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|   tick   |      16KB     |    1   | 0.25ns |     1s     |             Dinner is already served. Sit down, enjoy.             |
|          | *the* 64 Bits |        |        |            |                                                                    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L1    |      64KB     |    4   |   1ns  |     4s     |               Preparations are done, food's cooking.               |
|          |               |        |        |            |                 Want a cold one to bridge the gap?                 |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L2    |     2048KB    |   11   |  ~3ns  |     12s    |        Would you be so kind as to help me dice the broccoli?       |
|          |               |        |        |            |    If you want a beer, you will have to go to the corner store.    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L3    |     8192KB    |   39   |  ~10ns |     40s    |    The car is in the shop, you'll have to get groceries by bike.   |
|          |               |        |        |            |             Also, food ain't gonna cook itself, buddy.             |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|   DRAM   |     ~20GB     |   107  |  ~30ns |    2min    |      First year of college. First day of the holiday weekend.      |
|          |               |        |        |            |         Snow storm. The roommate's are with their families.        |
|          |               |        |        |            | You have a piece of toast, two cigarettes and 3 days ahead of you. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+

Cifras de latencia de los Core-i7-9XXchips de la serie (fuente: Scott Meyers, 2010)

Línea de fondo Si la medición adecuada no es una opción, en lugar de debatir entre núcleos y velocidad de reloj, elLa inversión más segura para el exceso de presupuesto de hardware es el tamaño de la caché de la CPU..

Entonces, si la memoria mantiene inactivos los subprocesos de hardware individuales con regularidad, ¿seguramente la solución es tener más núcleos ~campana de vaca~?

En teoría, si el software estuviera listo, el multi/hiper-threadingpodríase rápido

Supongamos que está mirando sus declaraciones de impuestos (por ejemplo) de los últimos años, digamos 8 años de datos en total. Tiene 12 valores mensuales (columnas) por año (fila).

Ahora, un byte puede contener 256 valores individuales (ya que sus 8 dígitos binarios individuales pueden asumir 2 estados cada uno, lo que resulta en 8^2 = 256permutaciones de estados distintos. Independientemente de la moneda, 256 se siente un poco en el extremo inferior para poder representar el límite superior de las cifras salariales Además, en aras del argumento, supongamos que la denominación más pequeña ("centavos") no importa (todos ganan valores enteros de la denominación principal). Por último, supongamos que el empleador es consciente de la brecha salarial entre ellos. la alta dirección y la fuerza laboral regular y, por lo tanto, mantiene a los pocos seleccionados en un sistema contable completamente diferente.

Entonces, en este escenario simplificado, supongamos que el doble de la cantidad de espacio de memoria antes mencionada, es decir, 2 bytes (o una "media palabra"), cuando se usa en unsignedforma, es decir, representando el rango desde [0, 2^16 = 65536), es suficiente para expresar los valores salariales mensuales de todos los empleados.

Entonces, en el lenguaje/RDBS/OS de su elección, ahora tiene una matriz (alguna estructura de datos bidimensional, una "lista de listas") con valores de tamaño de datos uniforme (2 bytes/16 bits).
En, digamos, C++, eso sería un archivo std::vector<std::vector<uint16_t>>. Supongo que también usarías vectorof en Java.vectorshort

Ahora, aquí está elpregunta de premio:
Supongamos que desea ajustar los valores de esos 8 años por inflación (o alguna otra razón arbitraria para escribir en el espacio de direcciones). Estamos ante una distribución uniforme de valores de 16 bits. Deberá visitar cada valor de la matriz una vez, leerlo, modificarlo y luego escribirlo en el espacio de direcciones.
¿Importa cómo recorre los datos?

La respuesta es:sí mucho así. Si primero itera sobre las filas (la estructura de datos interna), obtendrá una escalabilidad casi perfecta en un entorno de ejecución concurrente. Aquí, un subproceso adicional y, por lo tanto, la mitad de los datos en uno y la otra mitad en el otro ejecutarán su trabajo dos veces más rápido. 4 hilos? 4 veces la ganancia de rendimiento.
Sin embargo, si eliges hacer las columnas primero, dos hilos ejecutarán tu tareasignificativamente más lento. Necesitará aproximadamente 10 subprocesos de ejecución paralelos solo para mitigar (!) el efecto negativo que acaba de tener la elección de la dirección transversal principal. Y mientras su código se ejecutara en un solo hilo de ejecución, no podría haber medido la diferencia.

+------+------+------+------+------+------+------+
| Year |  Jan |  Feb | Mar  | Apr  | ...  | Dec  |
+------+------+------+------+------+------+------+
| 2019 | 8500 | 9000 | 9000 | 9000 | 9000 | 9000 | <--- contiguous in memory
+------+------+------+------+------+------+------+
| 2018 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 12 * 16Bit (2Byte)
+------+------+------+------+------+------+------+
| 2017 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 3 * (4 * 16Bit = 64Bit (8Byte) 
+------+------+------+------+------+------+------+
| ...  | 8500 | 7500 | 7500 | 7500 | 7500 | 7500 | <--- 3 cache lines
+------+------+------+------+------+------+------+
| 2011 | 7500 | 7200 | 7200 | 7200 | 7200 | 7200 | <--- 3 lines, likely from the same
+------+------+------+------+------+------+------+      virtual memory page, described by 
                                                        the same page block.

El OP escribió: a) una CPU con 32 núcleos y una velocidad de reloj de 2,5 Ghz
o
b) una CPU con 8 núcleos pero una velocidad de reloj de 3,8 Ghz

En igualdad de condiciones:

-->Considere el tamaño de la caché, el tamaño de la memoria, las capacidades especulativas de búsqueda previa del hardware y el software en ejecución que realmente puede aprovechar la paralelización, todo lo cual es más importante que la velocidad del reloj.

--> Incluso sin depender de sistemas distribuidos de terceros,asegúrese de que realmente no esté vinculado a E/S en condiciones de producción.Si debe tener el hardware interno y no puede permitir que AWS/GCloud/Azure/Heroku/Whatever-XaaS-IsHipNow se ocupe de ese problema, gaste en los SSD en los que colocó su base de datos. mientras lo hacesnoSi desea que la base de datos esté activa en la misma máquina física que su aplicación, asegúrese de que la distancia de la red (mida la latencia aquí también) sea lo más corta posible.

--> La elección de una biblioteca de servidor HTTP de "nivel empresarial" reconocida, examinada y de primera línea que esté más allá de cualquier duda y diseñada para la concurrencia, no es suficiente por sí sola. Asegúrese de que las bibliotecas de terceros que ejecute en sus rutas lo estén. Asegúrese de que su código interno también lo sea.

Las máquinas virtuales o las soluciones en la nube no son una opción en este caso

Esto lo entiendo.
Existen varias razones válidas.

tiene que seramáquina física [...]
[...] CPU con 32 núcleos y velocidad de reloj de 2,5 Ghz

Pero esto no tanto.
Ni AWS ni Azure inventaron los sistemas distribuidos, los microclústeres o el equilibrio de carga. Es más complicado configurarlo en hardware básico y sin recursos estilo MegaCorp, peropoderEjecute una malla distribuida de grupos K8 directamente en su propia sala de estar. Y también existen herramientas para controles de estado recurrentes y aprovisionamiento automático en cargas máximas para proyectos autohospedados.

OP escribió: La RAM no es importante

Aquí hay un escenario ~hipotético~ reproducible: habilite zram como su espacio de intercambio, porque la RAM es barata y no es importante y todo eso. Ahora ejecute una tarea constante que requiera mucha memoria y que no resulte exactamente en paginaciones frecuentes. Cuando haya alcanzado el punto de inversión LRU grave, su ventilador hará ruido y los núcleos de su CPU se calentarán, porque está ocupado lidiando con la administración de la memoria (moviendo basura dentro y fuera del intercambio).

OP escribió: La RAM no es importante

Por si no me he expresado con suficiente claridad: creo que deberías reconsiderar esta opinión.

TL;DR?
32 núcleos.
Másesmejor.

Answer

Nota preliminar
me gustaría segundo@PosiblementeútilProbablementeno'srespuesta definitivamente útil.

tldr; La verdadera respuesta es probablemente "más RAM".

Especialmente este punto.

Advertencia
No tanto un administrador per sé.
Quizás más desde una perspectiva de ingeniería de software.

No hay alternativa a la medición

Lo que sabemos
Entonces, la máquina es

¿Va a ejecutar una especie de aplicación backend basada en Java (¿Enterprise?)
exponer públicamente (dentro de un contexto considerable, de todos modos) una API HTTP que maneja las solicitudes de los clientes
presumiblemente con algún tipo de base de datos adjunta
de lo contrario se describe como no muy vinculado a E/S
no depende de la disponibilidad, latencia o rendimiento de servicios de terceros

No es una imagen tan vaga, el OP está pintando. Pero al mismo tiempo están lejos de ser datos suficientes para dar una respuesta.relativo a la situación individual de los PO.
Claro, 32 núcleos a 2/3 de la velocidad del reloj sonprobablepara funcionar mejor que 1/4 de los núcleos con una ventaja de velocidad comparativamente pequeña. Claro, el calor generado no se adapta bien a velocidades de reloj superiores al umbral de 4 GHz. Y claro, si tuviera que poner mis huevos en una sola canasta a ciegas, elegiría los 32 núcleos cualquier día de la semana.

lo que no sabemos
Demasiado, todavía.

Sin embargo,Más allá de estas simples verdades, sería muy escéptico ante un intento hipotético de una respuesta más concreta y objetiva.. sifSi es posible (y tiene muchas razones para seguir convencido de que las operaciones por unidad de tiempo son una preocupación válida), consiga el hardware en el que desea ejecutar el sistema.medirlo y probarlo, de extremo a extremo.
Undecisión informadaimplica relevanteydatos creíbles.

OP escribió: La RAM no es importante

En la gran mayoría de los casos, la memoriaesel cuello de botella.

Por supuesto, el OPpregunta principalmente sobreNúcleos de CPU versus velocidad de relojy así la memoria aparece al margen de estar fuera de tema.

Aunque no creo que lo sea. Para mí, parece mucho más probable que la pregunta se base en una premisa falsa. Ahora, no me malinterpretes, @OP, tu pregunta está relacionada con el tema, está bien formulada y tu preocupación es obviamente real. Simplemente no estoy convencido de que la respuesta sobre qué CPU funcionaría "mejor" en su caso de uso sea relevante (para usted).

Por qué es importante la memoria (para la CPU)

La memoria principal esterriblemente lento.
Históricamente, en comparación con el disco duro, tendemos a pensar en la RAM como "el tipo de almacenamiento rápido". En el contexto de esa comparación, sigue siendo cierto. Sin embargo, a lo largo de las últimas décadas, las velocidades de los procesadores han aumentado constantemente a un ritmo significativamente más rápido que el rendimiento de la DRAM. Este desarrollo a lo largo del tiempo ha dado lugar a lo que comúnmente se conoce como"Brecha de memoria del procesador".

La brecha entre las velocidades del procesador y de la memoria (fuente: Carlos Carvalho, Departamento de Informática, Universidade do Minho)

Obteniendo una línea de cachédesde la memoria principal a un registro de la CPU ocupa aproximadamente ~100 ciclos de relojde tiempo. Durante este tiempo, su sistema operativo informará que uno de los dos subprocesos de hardware en uno de los 4 (?) núcleos de su arquitectura x86 esocupado.
Tan lejos como eldisponibilidadEn lo que respecta a este hilo de hardware, su sistema operativo no miente,está ocupado esperando. Sin embargo, la propia unidad de procesamiento, sin tener en cuenta la línea de caché que se arrastra hacia ella, esde facto inactivo.
No se realizaron instrucciones/operaciones/cálculos durante este tiempo.

+----------+---------------+---------------------------------------------------------------------------------------------------+
|  Type of |    size of    |                                Latency due to fetching a cache line                               |
| mem / op |     cache     +--------+--------+------------+--------------------------------------------------------------------+
|          |   (register)  |  clock |  real  | normalized |                            now I feel it                           |
|          |               | cycles |  time  |            |                                                                    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|   tick   |      16KB     |    1   | 0.25ns |     1s     |             Dinner is already served. Sit down, enjoy.             |
|          | *the* 64 Bits |        |        |            |                                                                    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L1    |      64KB     |    4   |   1ns  |     4s     |               Preparations are done, food's cooking.               |
|          |               |        |        |            |                 Want a cold one to bridge the gap?                 |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L2    |     2048KB    |   11   |  ~3ns  |     12s    |        Would you be so kind as to help me dice the broccoli?       |
|          |               |        |        |            |    If you want a beer, you will have to go to the corner store.    |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|    L3    |     8192KB    |   39   |  ~10ns |     40s    |    The car is in the shop, you'll have to get groceries by bike.   |
|          |               |        |        |            |             Also, food ain't gonna cook itself, buddy.             |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
|   DRAM   |     ~20GB     |   107  |  ~30ns |    2min    |      First year of college. First day of the holiday weekend.      |
|          |               |        |        |            |         Snow storm. The roommate's are with their families.        |
|          |               |        |        |            | You have a piece of toast, two cigarettes and 3 days ahead of you. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+

Cifras de latencia de los Core-i7-9XXchips de la serie (fuente: Scott Meyers, 2010)

Línea de fondo Si la medición adecuada no es una opción, en lugar de debatir entre núcleos y velocidad de reloj, elLa inversión más segura para el exceso de presupuesto de hardware es el tamaño de la caché de la CPU..

Entonces, si la memoria mantiene inactivos los subprocesos de hardware individuales con regularidad, ¿seguramente la solución es tener más núcleos ~campana de vaca~?

En teoría, si el software estuviera listo, el multi/hiper-threadingpodríase rápido

Supongamos que está mirando sus declaraciones de impuestos (por ejemplo) de los últimos años, digamos 8 años de datos en total. Tiene 12 valores mensuales (columnas) por año (fila).

Ahora, un byte puede contener 256 valores individuales (ya que sus 8 dígitos binarios individuales pueden asumir 2 estados cada uno, lo que resulta en 8^2 = 256permutaciones de estados distintos. Independientemente de la moneda, 256 se siente un poco en el extremo inferior para poder representar el límite superior de las cifras salariales Además, en aras del argumento, supongamos que la denominación más pequeña ("centavos") no importa (todos ganan valores enteros de la denominación principal). Por último, supongamos que el empleador es consciente de la brecha salarial entre ellos. la alta dirección y la fuerza laboral regular y, por lo tanto, mantiene a los pocos seleccionados en un sistema contable completamente diferente.

Entonces, en este escenario simplificado, supongamos que el doble de la cantidad de espacio de memoria antes mencionada, es decir, 2 bytes (o una "media palabra"), cuando se usa en unsignedforma, es decir, representando el rango desde [0, 2^16 = 65536), es suficiente para expresar los valores salariales mensuales de todos los empleados.

Entonces, en el lenguaje/RDBS/OS de su elección, ahora tiene una matriz (alguna estructura de datos bidimensional, una "lista de listas") con valores de tamaño de datos uniforme (2 bytes/16 bits).
En, digamos, C++, eso sería un archivo std::vector<std::vector<uint16_t>>. Supongo que también usarías vectorof en Java.vectorshort

Ahora, aquí está elpregunta de premio:
Supongamos que desea ajustar los valores de esos 8 años por inflación (o alguna otra razón arbitraria para escribir en el espacio de direcciones). Estamos ante una distribución uniforme de valores de 16 bits. Deberá visitar cada valor de la matriz una vez, leerlo, modificarlo y luego escribirlo en el espacio de direcciones.
¿Importa cómo recorre los datos?

La respuesta es:sí mucho así. Si primero itera sobre las filas (la estructura de datos interna), obtendrá una escalabilidad casi perfecta en un entorno de ejecución concurrente. Aquí, un subproceso adicional y, por lo tanto, la mitad de los datos en uno y la otra mitad en el otro ejecutarán su trabajo dos veces más rápido. 4 hilos? 4 veces la ganancia de rendimiento.
Sin embargo, si eliges hacer las columnas primero, dos hilos ejecutarán tu tareasignificativamente más lento. Necesitará aproximadamente 10 subprocesos de ejecución paralelos solo para mitigar (!) el efecto negativo que acaba de tener la elección de la dirección transversal principal. Y mientras su código se ejecutara en un solo hilo de ejecución, no podría haber medido la diferencia.

+------+------+------+------+------+------+------+
| Year |  Jan |  Feb | Mar  | Apr  | ...  | Dec  |
+------+------+------+------+------+------+------+
| 2019 | 8500 | 9000 | 9000 | 9000 | 9000 | 9000 | <--- contiguous in memory
+------+------+------+------+------+------+------+
| 2018 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 12 * 16Bit (2Byte)
+------+------+------+------+------+------+------+
| 2017 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 3 * (4 * 16Bit = 64Bit (8Byte) 
+------+------+------+------+------+------+------+
| ...  | 8500 | 7500 | 7500 | 7500 | 7500 | 7500 | <--- 3 cache lines
+------+------+------+------+------+------+------+
| 2011 | 7500 | 7200 | 7200 | 7200 | 7200 | 7200 | <--- 3 lines, likely from the same
+------+------+------+------+------+------+------+      virtual memory page, described by 
                                                        the same page block.

El OP escribió: a) una CPU con 32 núcleos y una velocidad de reloj de 2,5 Ghz
o
b) una CPU con 8 núcleos pero una velocidad de reloj de 3,8 Ghz

En igualdad de condiciones:

-->Considere el tamaño de la caché, el tamaño de la memoria, las capacidades especulativas de búsqueda previa del hardware y el software en ejecución que realmente puede aprovechar la paralelización, todo lo cual es más importante que la velocidad del reloj.

--> Incluso sin depender de sistemas distribuidos de terceros,asegúrese de que realmente no esté vinculado a E/S en condiciones de producción.Si debe tener el hardware interno y no puede permitir que AWS/GCloud/Azure/Heroku/Whatever-XaaS-IsHipNow se ocupe de ese problema, gaste en los SSD en los que colocó su base de datos. mientras lo hacesnoSi desea que la base de datos esté activa en la misma máquina física que su aplicación, asegúrese de que la distancia de la red (mida la latencia aquí también) sea lo más corta posible.

--> La elección de una biblioteca de servidor HTTP de "nivel empresarial" reconocida, examinada y de primera línea que esté más allá de cualquier duda y diseñada para la concurrencia, no es suficiente por sí sola. Asegúrese de que las bibliotecas de terceros que ejecute en sus rutas lo estén. Asegúrese de que su código interno también lo sea.

Las máquinas virtuales o las soluciones en la nube no son una opción en este caso

Esto lo entiendo.
Existen varias razones válidas.

tiene que seramáquina física [...]
[...] CPU con 32 núcleos y velocidad de reloj de 2,5 Ghz

Pero esto no tanto.
Ni AWS ni Azure inventaron los sistemas distribuidos, los microclústeres o el equilibrio de carga. Es más complicado configurarlo en hardware básico y sin recursos estilo MegaCorp, peropoderEjecute una malla distribuida de grupos K8 directamente en su propia sala de estar. Y también existen herramientas para controles de estado recurrentes y aprovisionamiento automático en cargas máximas para proyectos autohospedados.

OP escribió: La RAM no es importante

Aquí hay un escenario ~hipotético~ reproducible: habilite zram como su espacio de intercambio, porque la RAM es barata y no es importante y todo eso. Ahora ejecute una tarea constante que requiera mucha memoria y que no resulte exactamente en paginaciones frecuentes. Cuando haya alcanzado el punto de inversión LRU grave, su ventilador hará ruido y los núcleos de su CPU se calentarán, porque está ocupado lidiando con la administración de la memoria (moviendo basura dentro y fuera del intercambio).

OP escribió: La RAM no es importante

Por si no me he expresado con suficiente claridad: creo que deberías reconsiderar esta opinión.

TL;DR?
32 núcleos.
Másesmejor.

¿Qué es mejor para una aplicación web Java: más núcleos de CPU o una mayor velocidad de reloj?

Respuesta1

Respuesta2

Respuesta3

Respuesta4

No hay alternativa a la medición

En la gran mayoría de los casos, la memoriaesel cuello de botella.

Por qué es importante la memoria (para la CPU)

En teoría, si el software estuviera listo, el multi/hiper-threadingpodríase rápido

información relacionada