muchas CPU son necesarios antes de Erlang es más rápido que un solo hilo de Java

Question

Actualmente estoy usando Java, he leído mucho acerca de Erlang en la red, y tengo 2 grandes preguntas:

1. Cómo Mucho más lento (si hay alguno), ¿será Erlang más simple que Java?
   Supongo que Java va a ser más rápido desde el shootout benchmarks en la red (a Erlang no le va tan bien). Entonces, ¿cuántas CPU más voy a necesitar para hacer que Erlang brille sobre un único subproceso Java (en mi situación particular, que figura a continuación)?

2. Después de leer acerca de Erlang por un tiempo, he llegado a una serie de comentarios/publicaciones que dicen que la mayoría de los grandes sistemas Erlang contienen una buena cantidad de C/C++.
   ¿Esto es por razones de velocidad (mi suposición) o algo más? es decir, ¿por qué se requiere esto?

He leído sobre el número de procesadores en la mayoría de las máquinas que suben y roscar modelos siendo duro (estoy de acuerdo) pero estoy en busca de encontrar a cabo cuando la "línea" va a ser cruzado de modo que pueda cambiar el lenguaje/paradigma en el momento correcto.

Un poco de historia/contexto:
estoy trabajando en el servidor de servicios de Java que son muy limitados por CPU y fácilmente hecho paralelo. Esto se debe, por lo general, a una única actualización entrante (a través de TCP) que activa un cambio a múltiples (100s de) salidas.

Los cálculos suelen ser bastante simples (pocos bucles, solo mucha aritmética) y las entradas están llegando bastante rápido (100/s).

Actualmente corremos en 4 máquinas CPU y ejecutamos múltiples servicios en cada una de ellas (por lo que el multi-threading es bastante inútil y parece que Java funciona más rápido sin los bloques de sincronización necesarios para hacerlo de subprocesos múltiples). Ahora hay un fuerte impulso para la velocidad y ahora tenemos acceso a 24 procesadores (por proceso si es necesario), así que me pregunto cuál es la mejor manera de proceder: Java de múltiples hilos o algo más fácil de codificar, como Erlang.

Answer 1

Dado que se trata de una gran carga de trabajo aritmética y que ya ha hecho el trabajo de dividir el código en procesos de servicio independientes, no obtendría mucho de Erlang. Tu trabajo parece ajustarse a Java cómodamente. Erlang es bueno en pequeñas transacciones, como el cambio de mensajes o el servicio de páginas web estáticas o dinámicas simples. Sin embargo, no es el caso de la carga de trabajo de la base de datos o del número de empresas.

Sin embargo, se podría construir en bibliotecas numéricas externos y bases de datos y el uso de Erlang como un interruptor MSG: D eso es lo que hace sofá-db: P

- editar -

1. Si mueva sus operaciones aritméticas a un Erlang async-IO driver erlang será tan bueno como el material para el tiroteo en el lenguaje, pero con 24 cpu quizás no importe tanto; la base de datos erlang es procesal y bastante rápida, esto se puede aprovechar en su aplicación actualizando 100 entidades en cada transacción.

2. El sistema de tiempo de ejecución de erlang necesita ser una mezcla de C y C++ porque (a) el emulador de erlang está escrito en C/C++ (debe comenzar en alguna parte), (b) tiene que hablar con el núcleo hacer el archivo asíncrono y la red io, y (c) ciertas partes del sistema deben ser ampollas rápidas, por ejemplo, el backend del sistema de la base de datos (amnesia).

- discusión -

con 24 CPUs en una topología de 6 * 4 núcleo de la CPU mediante un bus de memoria compartida - que tiene 4 NUMA entidades (la CPU) y una memoria central. Debe ser sabio sobre el paradigma, el enfoque de multiprocesos compartidos podría matar su bus de memoria.

Para evitar esto, debe crear 4 procesos con 6 subprocesos de procesamiento y vincular cada subproceso de procesamiento el núcleo correspondiente en la CPU correspondiente. Estos 6 hilos necesitan un multihilo colaborativo (Erlang y Lua lo tienen de forma innata). Erlang lo hace de manera rigurosa ya que tiene un programador completo como parte de su tiempo de ejecución, que puede usar para crear tantos procesos como quieras

Ahora, si dividiera sus tareas en los 4 procesos (1 por CPU física) sería un hombre feliz, sin embargo está ejecutando 4 máquinas virtuales Java (probablemente) trabajo serio (puaj, por muchas razones). El problema debe ser resuelto con una mejor capacidad para cortar y cortar el problema.

En el sistema Erlang OTP, se diseñó para sistemas redundantes robustos en red, pero ahora se está moviendo hacia la misma máquina de CPU NUMA-esque. Ya tiene un emulador SMP kick-ass, y pronto se volverá muy consciente de NUMA. Con este paradigma de programación, tienes muchas más posibilidades de saturar tus potentes servidores sin matar tu bus.

Quizás esta discusión haya sido teórica; sin embargo, cuando obtenga una topología de 8x8 o 16x8, también estará preparado para ello. Así que mi respuesta es que cuando tienes más de 2 CPUs modernas en tu placa madre, probablemente debas considerar un mejor paradigma de programación.

Como ejemplo de un producto importante siguiendo la discusión aquí: Microsoft's SQL Server is CPU-Level NUMA-aware in the SQL-OS layer en el que se basa el motor de la base de datos.

Answer 2

¿Ha comparado el costo del nuevo hardware con el costo del entrenamiento del personal en Erlang y la reorganización de su software en un nuevo idioma?

No me gustaría subestimar el gasto de volver a capacitarse (u otros) y el costo de contratar personas con experiencia en Erlang (que van a ser un lote más difícil de encontrar que las personas de Java). Los servidores obviamente cuestan en términos de sus costos de almacenamiento/energía/mantenimiento, etc., pero todavía son mucho más baratos que el personal calificado. Si puede progresar y seguir siendo escalable mientras usa sus conjuntos de habilidades actuales, sospecho que ese es el enfoque más pragmático.

Answer 3

Si obtiene 100 por segundo pero toman 100 cada uno, ¿cómo puede mantenerse? Tal vez estoy malinterpretando esa parte, pero de todos modos, a menos que sean miles o millones de solicitudes por segundo, su código de sincronización no debería demorarse. Si es así, estás haciendo algo mal, posiblemente bloqueando mientras ejecutas el trabajo completo o algo así.

Para código multiproceso, ir a un lenguaje de nivel aún mayor es probablemente un error. Incluso si escribe la parte de la aplicación en erlang o lo que sea, el multihilo probablemente debería estar en Java o pasar a C++ si el rendimiento realmente se convierte en un problema.

Answer 4

La cuestión de la velocidad cuando se trata de lenguajes de programación es tan compleja como una pregunta. Los defensores de Java pueden señalar muchas áreas y afirmar que son las más rápidas y que serían 100% correctas. Los defensores de Ruby/Python apuntan a un conjunto diferente de parámetros y afirman ser más rápidos y también serían correctos. Los defensores de Erlang apuntan a conexiones concurrentes y afirman ser más rápidos cuando se trata de cientos o miles de conexiones o cálculos simultáneos y tampoco estaría mal.

Mirando la descripción básica del proyecto en cuestión, me parece que Erlang sería el complemento perfecto para sus necesidades. Sin saber los detalles, diría que esto sería en realidad un programa de Erlang bastante simple y podría hacerse en muy poco tiempo.

Answer 5

Depende de varios factores. La respuesta rápida es que tendrá que comparar cada programa para entender dónde está esa marca de agua de quiescencia.

Éstos son algunos de los aspectos relevantes que podrían afectar esa relación de beneficio:

1) Dependencias Computacional: si el flujo lógico tiene muchas dependencias a los recursos externos (DBMS, el acceso al disco, creación de redes). Cuanto mayor sea la cantidad de dependencias computacionales que son divisibles en el procesamiento concurrente, mayor será el beneficio de adoptar una plataforma de computación distribuida como erlang.

2) Atomicidad de flujo lógico: si su programa tiene que gastar una gran cantidad de tiempo de cálculo en un solo control de flujo síncrono secuencial y que no se puede desglosar en segmentos lógicos de código más pequeños. Cuanto mayor sea la atomicidad de su código, menos se puede descomponer en flujos de dispersión de la CPU.

3) Sobrecarga compartida estatal: cuanto mayor sea la cantidad de datos que se deben distribuir entre varias funciones, mayor será la sobrecarga que requiere el marco para simplemente transmitir y recibir el estado. En otras palabras, si envía grandes cantidades de datos repetitivamente sin un área común de caché compartida, los beneficios disminuirán, aunque esto tiene diferentes enfoques dependiendo de los patrones de programación adoptados.

Por lo tanto, dadas las amplias posibilidades y variaciones basadas en criterios como los anteriores, no es posible tener una estimación común que sea aceptable para todos los escenarios.