Roscado vs hilo simple

Mi opinión

No, no se garantiza que una aplicación multihilo se ejecute más rápido que una aplicación de un solo subproceso. El problema principal es distribuir correctamente la carga de trabajo a todos los núcleos disponibles y minimizar el bloqueo y el cambio de contexto.

Creo que algunas de las peores cosas que la gente puede hacer es ir y tratar de multiproceso cada poco de sus tareas intensivas en CPU. A veces terminan creando cientos de hilos y cada hilo está intentando para realizar una gran cantidad de cálculos de uso intensivo de CPU. Lo mejor que se puede hacer en esa situación es crear uno (o tal vez dos) hilos por núcleo.

En los casos en los que hay una interfaz de usuario involucrada, casi siempre se prefiere delegar todo el trabajo intensivo de la CPU en subprocesos para mantener la interfaz de usuario sensible. Este es probablemente el uso más popular para hilos.

...parece una versión de rosca única de la aplicación se está ejecutando más rápido que la versión con dos hilo.

¿Ha realizado algún análisis de rendimiento? Si no lo has hecho, entonces lo que has observado es algo irrelevante.

¿Cuáles son las mejores prácticas para jack la CPU y utilizarlo plenamente?

Dada la descripción de su problema, no parece que sus problemas de rendimiento estén vinculados a la CPU, sino a la E/S... su comunicación con la base de datos es mucho más lenta que su caché de procesador y si se trata de una base de datos de red, es incluso más lenta que su disco duro. Su cuello de botella de rendimiento está con su base de datos, por lo que todo lo que necesita hacer es crear suficientes subprocesos para maximizar el rendimiento de su conexión a la base de datos.

Directamente desde Wikipedia:

Ventajas

Algunas ventajas incluyen:

• Si un subproceso recibe muchos errores de caché, el otro subproceso puede continuar, aprovechando los recursos informáticos no utilizados, lo que puede conducir a una ejecución general más rápida, ya que estos recursos habría estado inactivo si solo se ejecutara un solo subproceso.
• Si un subproceso no puede utilizar todos los recursos informáticos de la CPU (porque las instrucciones dependen del resultado del otro), ejecutar otro subproceso permite no dejarlos inactivos.
• Si varios subprocesos funcionan en el mismo conjunto de datos, pueden compartir su caché, lo que lleva a un mejor uso de la caché o sincronización de sus valores.

Desventajas

Algunas críticas al multihilo incluir:

• Múltiples subprocesos pueden interferir entre sí cuando se comparten recursos de hardware como cachés o buffers de lookaside de traducción (TLBs).
• Los tiempos de ejecución de un solo subproceso no se mejoran, pero se pueden degradar, incluso cuando solo se ejecuta un subproceso. Esto se debe a frecuencias más lentas y/o etapas de tubería adicionales que son necesarias para acomodar el hardware de conmutación de hilo.
• El soporte de hardware para Multihilo es más visible para el software, por lo tanto requiere más cambios tanto en los programas de aplicación como en los sistemas operativos que el Multiprocesamiento.

Actualizar

Además, el servidor de base de datos está en el la misma máquina que el código está ejecutando. no es un servidor sql. es un nosql dbms. así que por favor no asumas nada acerca del servidor de base de datos.

Algunos sistemas NoSQL están basados en disco y la lectura desde disco de múltiples subprocesos está casi garantizada para disminuir el rendimiento. El disco duro puede tener que mover el dirígete a diferentes sectores del disco al saltar entre hilos y eso es malo!

Entiendo el punto que quería make es la velocidad IO. pero aún así es la misma máquina. ¿Por qué IO es tan lento ?

Su sistema NoSQL puede estar basado en disco, por lo tanto, todos sus datos se almacenan en el disco en lugar de cargarse en la memoria (como SQL Server). Además, piense en la arquitectura: el disco es una caché para la RAM, la RAM es el almacenamiento en caché para la caché de la CPU, y la caché de la CPU es para la CPU se registra. Así que Disco - > Ram - > Caché de CPU - > Registros, hay 3 niveles de almacenamiento en caché antes de llegar a los registros. Dependiendo de la cantidad de datos que está utilizando, es posible que obtenga una gran cantidad de errores de caché para ambos hilos en cada uno de esos niveles... una falta de caché en la caché de la CPU cargará más datos de la RAM, una falta de caché en la RAM cargará más datos del disco, todo esto se traduce en rendimiento reducido.

En otros críticos " crear lo suficiente hilos a utilizar .."la creación de muchos los hilos también tomarán tiempo. ¿verdad?

En realidad no... sólo tienes dos hilos. ¿Cuántas veces estás creando los hilos? ¿Con qué frecuencia los estás creando? Si solo está creando dos subprocesos y está haciendo todo su trabajo en esos dos subprocesos durante toda la vida útil de la aplicación, entonces prácticamente no hay sobrecarga de rendimiento desde la creación de los subprocesos que debería preocuparle.

Si su programa es pesado E/S y pasa la mayor parte del tiempo esperando E/S (como la operación de la base de datos), por lo que el subproceso no se ejecutaría más rápido.

Si hace mucho cálculo en CPU, por lo que tendrá beneficio o no, dependerá de cómo lo escribas.

Por supuesto que no. El enhebrado impone una sobrecarga, por lo que si los beneficios de la aplicación dependen de cómo paralelo es.

No, no lo es. Porque cuando haces multi-threading, tu CPU tiene que cambiar entre hilo, memoria, registro, y eso cuesta. Hay algunas tareas que son divisibles como merge sort, pero hay algunas tareas que pueden no ser divisibles para sub tareas como verificar si un número es primo o no (es solo mi ejemplo repentino), y luego si intentas separarlo, simplemente se ejecuta como un problema de subproceso único.

La sobrecarga de cambio de contexto no es un problema hasta que tenga cientos de subprocesos. El problema del cambio de contexto se sobrestima a menudo (ejecute el administrador de tareas y notifique cuántos hilos ya se han iniciado). Los picos que se observan dependen de las comunicaciones de red que son bastante inestables en comparación con los cálculos de cpu locales.

Sugeriría escribir aplicaciones escalables en SEDA (Staged Event Driven Architecture) cuando el sistema está compuesto de varios (5-15) componentes y cada componente tiene su propia cola de mensajes con grupo de subprocesos delimitado. Puede ajustar el tamaño de los grupos e incluso aplicar algoritmos que cambian el tamaño de los grupos de subprocesos para hacer que algunos componentes sean más productivos que otros (ya que todos los componentes comparten las mismas CPU). Puede ajustar el tamaño de los grupos para hardware específico que hace que las aplicaciones SEDA sean extremadamente sintonizables.

He visto ejemplos del mundo real donde el código se ha desempeñado tan mal con más procesadores añadidos (horrible contención de bloqueo entre subprocesos) que el sistema necesitaba tener procesadores eliminados para restaurar el rendimiento; así que sí, es posible hacer que el código funcione peor agregando más subprocesos de ejecución.

IO aplicaciones restringidas son otro buen ejemplo, mencionado anteriormente.

De acuerdo con la ley de Amdahl la velocidad máxima depende de la proporción del algoritmo que puede ser paralelizado. Si el algoritmo es altamente paralelo al aumento de la cantidad de CPU y subprocesos tendrá un gran aumento. Si el algoritmo no es paralelo (hay mucho control de flujo de código o contención de datos), entonces no hay ganancia o incluso puede suceder que exista disminución del rendimiento.