Tema: ¿Porque no se usan normalmente 6 nucleos?

La pregunta es muy senzilla..he estado leyendo algunos articulos y resulta ser que estan creando procesadores de hasta 100 nucleos.. pero estos no se pueden aprovechar a uso domestico (solamente se aprovechan en servidores) y mi pregunta es.. porque no se pueden aprovechar a nivel domestico? no hay alguna manera de dividir las tareas entre todos los nucleos? o.. mas facil: porque habiendo ya procesadores de 6 nucleos no sacan todo el software optimizado para ellos?

Porque el programador debe implementar en la aplicación el trabajo multihilo. No sirve de nada tener seis u ocho cores si el software que ejecutas no está programado para usar más de uno o dos. Si la aplicación no tiene los procesos paralelizados, los cores extra se morirán de risa.

El problema fundamental es que es mucho más difícil programar para varios cores que para uno. el programa tiene que diseñarse de forma que varias funciones se ejecuten a la vez en distintos hilos. Y a menudo esto lleva mucho trabajo y tiempo (en definitiva, inversión de dinero en desarrollo).

A día de hoy, aunque la cosa va mejorando, sigue siendo más importante la frecuencia por core que la cantidad de cores. Por ese motivo Sandy Bridge es tan superior a los sixcores de AMD.

hmm interesante, veremos como se soluciona esto en un futuro

gracias!

En realidad los servidores utilizan el potencial de todos los núcleos que tengan disponibles porque trabajan con múltiples sistemas virtuales, multitud de tarjetas de red y con cientos, o incluso miles de conexiones. De este modo cada tarea se distribuye a un núcleo, u otro, dando este todo de si para sacar la tarea lo antes posible.

Tú puedes hacer lo mismo si sueles trabajar con múltiples programas a la vez. Me refiero a que desde el administrador de tareas de windows puedes asignar la afinidad de cada aplicación, vamos, que cores mueven una aplicación, y así dejar otros más libres para otras tareas.

Con esto puede que notes una mejoría general en multitarea, pues cada núcleo se encarga de una aplicación y estarás gastando este al 100% en el momento que se utilice. Lo que pasa es que normalmente no trabajas descomprimiendo 2 archivos rar, photoshop y firefox a la vez y de continuo para aplicar cada tarea a cada núcleo... Y se pierde más tiempo asignando una tarea a un núcleo cada vez que se abre la aplicación, que dejando todo para todos los núcleos.

Yo suelo utilizar esta técnica de asignación de aplicaciones a núcleos para cuando reproduzco una pelicula HD por streaming con vlc, asignando este al núcleo 1, mientras grabo un programa del tdt en el pc con otro núcleo, asignando la grabación al núcleo 2 y dejando el explorador de windows, el firefox y la aplicación que esté utilizando a los otros dos núcleos.( como descomprimir un rar). De este modo ninguna de las aplicaciones sufre retrasos, o posibles defectos en la grabación o reproducción streaming.

Esto de los multicores está claro que por mucho que nos esforcemos, muy pocas veces podremos acercarnos al 100% de su rendimiento mantenido. Pues pasa como con las personas y el trabajo, que 2 personas nunca hacen justo el doble de trabajo de 1, ni 3 el tríple, ni 4 el quádruple... siempre hay un momento en el que una persona se tiene que esperar a otra a que termine para continuar y en cambio 1 persona no para a esperar a nadie. Por eso vale la pena, siempre que haya suficiente potencia, asignar tareas individuales a cada núcleo, pues se aprovecha más el rendimiento general y el resto de núcleos quedan libres para otras cosas.

Pero es que tú estás hablando de múltiples aplicaciones corriendo en diferentes hilos. Y ésa no es la cuestión en el ámbito que nos atañe. Lo que debe mejorarse es que CADA aplicación (UNA) obtenga beneficio de una programación multihilo. En todos los ámbitos, incluido el PC doméstico, de PYMES o de grandes empresas.

No se puede mejorar por ahora, pues por construcción y arquitectura lo que se ha pretendido era mejorar el trabajo multitarea, no la monotarea. Para eso se van subiendo las frecuencias, acelerando memorias caché y buses, para que toda aplicación tenga una ejecución más rápida. Pero los ciclos, hay los que hay...

La programación multihilo es muy difícil de llevarse a cavo a nivel usuario, pues se necesita un gran desarrollo de la aplicación, vamos, mucho dinero que no van a recuperar pues a nivel usuario no se pueden pedir grandes cantidades de dinero, o no se vende. En cambio a nivel industrial no importa gastarse medio millón de euros en equipos de 100 núcleos y el desarrollo de un software que aproveche tantos núcleos como sea posible, pues van a obtener beneficio de esa inversión.

La única forma de que avance el desarrollo multihilo es con el ocio, con los videojuegos y multimedia, que es lo único que da dinero a nivel usuario, aparte del porno :lol: . Con esto del 3D visión se puede implementar el uso multihilo para aprovechar más los núcleos y además aprovechar el potencial de cálculo de las gpu para tareas que antes hacian los procesadores por software.

En definitiva, por mucho que digan que los juegos aprovechan los 4 núcleos, es falso, pues solo se ponen al 100% los procesadores que van justos de potencia para un juego. Vale que se repartan mejor las cargas por núcleo, pero es muy, muy difícil que las plataformas actuales corran más de lo que lo hace ahora.

De todos modos, creo que en estos momentos estamos en gracia con el hardware, pues hace no tanto tiempo el hardware avanzaba más despacio que el software y muchas aplicaciones exigían unos mínimos brutales para un usuario, que si quería jugar al crysis tenia que comprarse la última gráfica que valía 500€ para moverlo solo "decentemente". Ahora con un procesador de 100€, una placa de 50€ y una gráfica de 150€ puedes jugar a lo que quieras y que te dure así como mínimo 2 años.

Yo creo que bori se refiere a lo que dice Willhelm, que una aplicacion use varios nucleos. Hay aplicaciones que ya lo hacen pero la verdad es que no suelen usar mas de dos nucleos...

Y la razon por la que no programan para varios nucleos es la que ha apuntado Wilhelm, algo puramente economico. Aparte de que si las aplicaciones utilizaran mas nucleos, los procesadores tardarian mas en quedarse obsoletos, y eso es algo que las empresas no quieren. Aparte de que, queramos o no, los nucleos se venden muy bien, aunque no se aprovechen. Es decir, las empresas juegan a "cuantos mas nucleos, mejor. Aunque no se aprovechen". Inconscientemente tendemos a pensar que es asi.

Por cierto, BOSKYMAN, desconocia que se pudiera asignar nucleos a diferentes tareas. Me podrias decir como se hace? Cada vez que se abre un programa habria que configurar las asignaciones o se guardan?

Saludos!

Investigando un poco ya he descubierto como se asignan los nucleos. Parece que no guarda la configuracion...

La asignación de tareas a los núcleos se llama "afinidad" a un núcleo en el administrador de tareas de windows. Te pones en la lista de procesos abiertos y clicas con el botón derecho sobre el proceso en cuestión y clicas en afinidad. Te saldrá un cuadro con los núcleos seleccionados que procesan esa tarea. Este método vale mientras no cierres el proceso, o mientras no reinicies sistema y por tanto, no es permanente.

Sé que se pueden asignar permanentemente tareas a uno, u otro núcleo, pero nunca lo he hecho, pues como he dicho antes, no siempre se necesita tener asignado un proceso a un núcleo concreto, exceptuando casos contados donde no quieres que sufra retraso alguno una aplicación concreta(como en un benchmark).

Grácias a esta asignación podéis adivinar que núcleo de vuestro procesador es más rápido y cual más perro... solo tenéis que pasar un benchmark como el superpi y asignar el proceso abierto a un núcleo cada vez y comparáis los resultados. Hay veces que sorprende la diferencia de rendimiento de un núcleo a los demás y esto lo podéis utilizar en vuestro beneficio, quitando la asignación del núcleo más lento a ese proceso en aplicaciones monotarea, pues el núcleo más lento retrasa el trabajo de los demás.

Fijaos bien que para este tipo de asignaciones, en plataformas amd vale la pena configurar las memorias como "unganged mode", donde, al contrario que en "ganged mode", cada núcleo trabaja con un bloque, o sector de memoria determinado, dejando siempre una parte del búfer de transferencia y sector de memoria para cada núcleo, sin mezclar datos en las memorias, ni en el búfer con las tareas de otros núcleos.

En tiempos usaba un programa que se llamaba Prioaff.exe que permitía editar y guardar perfiles para programas y asignación de núcleos. Cada vez que ejecutabas ese programa, Prioaff asignaba el núcleo/núcleos establecidos en el perfil.

Desconozco si hoy existe algo parecido.

Iniciado por Wilhelm

El problema fundamental es que es mucho más difícil programar para varios cores que para uno. el programa tiene que diseñarse de forma que varias funciones se ejecuten a la vez en distintos hilos. Y a menudo esto lleva mucho trabajo y tiempo (en definitiva, inversión de dinero en desarrollo).

La parte más difícil es coordinar los procesos. Si lanzas a ejecutar dos funciones a la vez, en procesos independientes, y la primera función necesita para empezar el resultado de la segunda, se tendrá que quedar esperando a que la otra termine, con lo que no ganas nada en rendimiento por tener varios núcleos.

Windows de por sí distribuye la carga de tareas entre los núcleos, para no usar solamente uno y tener el resto muerto de risa, pero no es perfecto (el XP menos aún que el Vista y el 7), aunque se nota (os dejaría mi portátil para que vierais lo que es tener que parar todo para ver un vídeo en youtube. Una vez sacaron el primer procesador con HyperThreading, deberían haberlo mantenido para todos los siguientes, que si bien no es lo mismo que un doble núcleo "puro", evita en muchas ocasiones que el sistema se "ahogue").