Evolución de los procesadores Intel

[Tassadar]

Igualmente, ricardoyuyu!

Disfruta del 9700, que es un procesador excelente y te durará años

Un saludo

 

[ricardogayuyu]

Lo del hypertreading que es la tecnología de intel no influye mucho si se tiene las memorias funcionando a frecuencias altas como las tengo yo, y los juegos van muy deprisa. Eso tambien ayuda en edicion de video.

 

[Tassadar]

El HT en juegos teniendo un 8 cores no te va a ayudar nada, incluso te puede perjudicar. En aplicaciones, si están bien paralelizadas y se aprovechan los 16 hilos, ahí se puede haber mejora (de hasta un 33% con el HT de Intel y 40% con el SMT de AMD), pero ya te digo, aplicaciones muy concretas...

Yo ahora tengo un 3800x, pero los dos procesadores que tuve antes fueron i5 de Intel, serie K con OC, precisamente porque no me gustaba el HT, quería tener 4 núcleos rápidos sin HT, para así favorecer la potencia monocore, antes que tener HT (bueno, eso y también el precio, que los i7 costaban 100 y pico euros más por tener el HT).

La ram obviameten influye, en AMD influye más por las razones ya conocidas, pero eso no quiere decir que en intel no se note.

Un saludo

 

[makina69]

sinceramente el 10850k que me toco 90 grados a 5,2ghz no me parece para nada caliente ,30 minuros de test cinebench r23

 

[Pedropc]

El HT en juegos teniendo un 8 cores no te va a ayudar nada, incluso te puede perjudicar. En aplicaciones, si están bien paralelizadas y se aprovechan los 16 hilos, ahí se puede haber mejora (de hasta un 33% con el HT de Intel y 40% con el SMT de AMD), pero ya te digo, aplicaciones muy concretas...

Yo ahora tengo un 3800x, pero los dos procesadores que tuve antes fueron i5 de Intel, serie K con OC, precisamente porque no me gustaba el HT, quería tener 4 núcleos rápidos sin HT, para así favorecer la potencia monocore, antes que tener HT (bueno, eso y también el precio, que los i7 costaban 100 y pico euros más por tener el HT).

La ram obviameten influye, en AMD influye más por las razones ya conocidas, pero eso no quiere decir que en intel no se note.

Un saludo

OJO, que si el HT de Intel, no funciona del todo bien en los juegos por ejemplo, en AMD el SMT va muchisimo mejor. Yo en micros AMD, no recomiendo deshabilitar el SMT.

sinceramente el 10850k que me toco 90 grados a 5,2ghz no me parece para nada caliente ,30 minuros de test cinebench r23

Jode Makina, por que tienes delid hecho, si no es impensable esa velocidad y temperaturas. Mientras Intel no cambien de litografia, si se quiere sacar el maximo rendimiento a una CPU Intel, si o si, necesitas delid. No tiene nada que ver la calidad de la pasta interior, ni si van soldados o no. Es por los 14+++, es la mejor litografia de Intel posiblemente de su historia, pero ya hace tiempo que toco techo. Toca cambio.

Un saludo.

 

[ricardogayuyu]

Yo pienso que con el procesador tan potente como es un amd 3800x y el que tengo yo y el que tiene pedropc son procesadores muy potentes y cuando se comenta que se ha tocado techo tambien es por la calidad y la velocidad de los discos duros, cuando se hacen procesos pesados y muy intensos que requieren de controladoras y discos duros muy rapidos y tengo la impresion que se quedan cortos en velocidad por culpa de los fabricantes que los capan ya han capado los ssd.

 

[Pedropc]

Capar los SSDs ???, yo no tengo SSDs, tengo dos M2. Uno pasado por las lineas PCIe de la CPU, y otro pasado por las lineas PCIe del chipset. Ambos PCIe 4.0, y la velocidad que tengo ahora es algo mas del doble de la que tenia en x299. Una autentica maravilla.

Yo no le veo que esten capados por ningun lado. Eso esta como siempre reñido con el precio, si compras un M2 bueno, con buena controladora, pues aprobecharas la velocidad.

Si que es verdad y sabido, que las placas base x570 tienen un bug con los SSD y bajan su velocidad. Pero no es una bajada aproposito de los fabricantes, es un bug del chipset x570.

 

[jacosito]

El HT en juegos teniendo un 8 cores no te va a ayudar nada, incluso te puede perjudicar. En aplicaciones, si están bien paralelizadas y se aprovechan los 16 hilos, ahí se puede haber mejora (de hasta un 33% con el HT de Intel y 40% con el SMT de AMD), pero ya te digo, aplicaciones muy concretas...

Yo ahora tengo un 3800x, pero los dos procesadores que tuve antes fueron i5 de Intel, serie K con OC, precisamente porque no me gustaba el HT, quería tener 4 núcleos rápidos sin HT, para así favorecer la potencia monocore, antes que tener HT (bueno, eso y también el precio, que los i7 costaban 100 y pico euros más por tener el HT).

La ram obviameten influye, en AMD influye más por las razones ya conocidas, pero eso no quiere decir que en intel no se note.

Un saludo

Normalmente programo multi-hilo (programación paralela).
Te pongo un ejemplo para mostrarte el motivo del paralelismo.
Aplicación que lee datos desde un archivo y tiene que almacenarlo en una base de datos. Tiempo de proceso:
1. Aplicación original, más de 50min
2. Aplicación multi-hilo, menos de 15seg.

No se puede llegar y opinar sin tener conocimiento de causa.

Saludo

 

[Pedropc]

Normalmente programo multi-hilo (programación paralela).
Te pongo un ejemplo para mostrarte el motivo del paralelismo.
Aplicación que lee datos desde un archivo y tiene que almacenarlo en una base de datos. Tiempo de proceso:
1. Aplicación original, más de 50min
2. Aplicación multi-hilo, menos de 15seg.

No se puede llegar y opinar sin tener conocimiento de causa.

Saludo

Y tu por que no te paras a leer lo que ponen los Compis, antes de opinar sobre lo que han escrito ???

El HT en juegos teniendo un 8 cores no te va a ayudar nada, incluso te puede perjudicar. En aplicaciones, si están bien paralelizadas y se aprovechan los 16 hilos, ahí se puede haber mejora (de hasta un 33% con el HT de Intel y 40% con el SMT de AMD), pero ya te digo, aplicaciones muy concretas...

Lo ha dejado muy clarito; en juegos, aprobechamiento casi nulo. En aplicaciones que esten muy paralelizadas y aprobechen los nucleos/hilos, si hay aprobechamiento.

Me parece que vienes a este foro con el ego muy subidito, poco menos que te crees Bill Gates. Cuando menos, lo que tu deberias de hacer, es tratar a los Compis con mas respeto. Ya te lo he dicho alguna vez, que ya has sido baneado por lo mismo. No queras irte unos cuantos dias fuera de aqui, a ver si vienes mas relajadito ????

Como veo que eres de los que tiran la piedra y esconde la mano, no habra otra vez mas. Avisado estas.

 

[Tassadar]

Normalmente programo multi-hilo (programación paralela).
Te pongo un ejemplo para mostrarte el motivo del paralelismo.
Aplicación que lee datos desde un archivo y tiene que almacenarlo en una base de datos. Tiempo de proceso:
1. Aplicación original, más de 50min
2. Aplicación multi-hilo, menos de 15seg.

No se puede llegar y opinar sin tener conocimiento de causa.

Saludo

Hola Jacosito,

Resulta que aunque en mi vida laboral no me he dedicado apenas a la programación, estudié programación (eso sí, en los tiempos de los Pentium 2/3, no existían procesadores multihilo ni multinúcleo).

Cosas de la vida, tengo un proyecto personal que estoy programando en visual studio en C#, tirando de BD de SQL, y he usado programación multihilo, así que creo que puedo opinar al respecto si me lo permites. Este proyecto implica lectura de ficheros del disco duro, procesamiento de los mismos, OCR, escaneo de carpetas, lectura y escritura tanto en la BD como en ficheros excel, leer y crear nuevos PDFs, separarlos en páginas, unirlos, ordenarlos en un árbol de carpetas del disco duro según su contenido... etc.

Para empezar, que me digas que una aplicación original tarda 50 minutos y que la multihilo son 15 segundos es un absurdo total, más que nada porque suponiendo una eficiencia del multihilo del 100% (del todo irreal), necesitarías un procesador de:

50 minutos = 3000 segundos
3000/15 = 200 núcleos.

Ya me dirás que procesador tienes de 200 núcleos.

Después, decir que la programación multihilo es un dolor de huevos total, requiere un nivel de abstracción mucho mayor, control enorme de los datos para la separación de las tareas y que ninguna acceda a un dato que ha podido ser modicado por otra de las tareas, etc. Seguro que para ti es muy sencillo, que eres un crack, pero para las personas normales como yo, imagino que incrementa bastante la complejidad de la programación. A veces es simplemente imposible paralelizar porque necesitas que un proceso "cocine" unos datos antes de que otro haga otra cosa con ellos.

Pero vamos, obviando eso, digamos que un buen programador a estas alturas debe saber hacer eso y hacerlo, porque programar para un núcleo a estas alturas es una "catetez" y una chapuza.

Basándome en mi experiencia te puedo decir:

En cuanto al rendimiento, todo lo que sea acceder a datos del disco duro NO es realmente paralelizable, y si lo haces en el mejor de los casos te quedarás con el mismo rendimiento, pero es posible que hasta pierdas si te pones a leer diferentes ficheros del mismo disco a la vez (me ha pasado). Yo tengo partes del programa así, preparadas para lanzar tantos procesos como hilos lógicos tenga la CPU, y funciona y gana rendimiento, pero porque además de leer el fichero realizo operaciones con esos datos, y en ese caso cada núcleo o hilo procesa en paralelo esos datos.

Tampoco puedes ponerte por ejemplo a escribir/acceder a en un mismo fichero con varios hilos, aunque sí que puedes hacer el tratamiento de datos en memoria y una vez tengas el resultado a escribir, escribirlo todo mas rápido.

Si mal no recuerdo, leyendo datos de un excel enorme, procesándolos y volcándolos a SQL, en multinúcleo tenía una mejora de rendimiento de 4x (pasar de 10 minutos a 2,5 por ejemplo), el problema es que esto escala bien de un núcleo a dos o cuatro, pero a partir de ahí... te lo digo porque cambié por aquel entonces mi 6600k@4,5Ghz por un 3800x, y los tiempos de proceso eran muy similares.

En otras tareas mas o menos lo mismo, de las cosas que hacía mi programa, lo más paralelizable era el OCR de ficheros, donde la librería que encontré para hacerlo era monohilo, así que con el 3800x puedo hacer OCR a 16 imágenes a la vez, pero ni de coña era 16x mas rápido (tendía que recordar tiempos de test), pero es que ni 8x (por no contar con el SMT).

En los demás procesos, diseñados totalmente por mí y con código mio, a pesar de currarme procesos que descomponían el procesado de datos en tantos hilos como disponía el procesador, diría que la mejora máxima que vi fué de 5x.

También había procesos que al tirar de SMT (16 hilos en mi caso) tardaban más que al no usarlo (8 hilos), de ahí que estos procesos los limitase a tantos como núcleos físicos de la CPU (no lógicos).

Programar en multihilo supone que tanto disco duro como RAM se pueden convertir en un importante cuello de botella, sin olvidar por supuesto el procesamiento "extra" que se llevan los procesos orientados a ordenar y descomponer los datos de forma que se puedan procear en paralelo (multithread overhead creo que lo llaman).

Por cierto, todas estas pruebas que hice eran con un SSD nmve Samsung 970 Evo Plus, o sea, que no te hablo de un disco "malo", con un disco mecánico sería un puto desastre.

En fin, que yo soy el defensor Nº 1 de la programación multinúcleo, pero que la he llevado a cabo y aprovechar más de 4 núcleos es complicado en mi experiencia, a no ser que tengas varios procesos prácticamente independientes que no necesiten estar comunicados y que dependan únicamente de potencia de CPU.

Un saludo

 

[KsK]

bueno, cuando se habla de programación multihilo no necesariamente se obliga a que cada hilo de ejecución del programa tenga que tener equivalente en los hilos lógicos del procesador ..
lo que esta haciendo es paralelizar las tareas de modo que no todas se queden bloqueadas por la espera a que finalice una de las tareas a realizar
de este modo consigues realizar mas cosas simultáneamente dependiendo de las restricciones de uso del hardware que tengas por detrás
puedes dejar un hilo esperando la llegada de datos de lectura del dispositivo de almacenamiento mientras estas procesando otros datos y estas por otro lado preparando algo para depositarlo donde toque sin tener que bloquearse tareas mientras otras acaban, multihilo.
por poder podrías programar multihilo sobre un procesador mononucleo y funcionaria (dentro de sus lógicas limitaciones)

 

[Miembro eliminado 62353]

por poder podrías programar multihilo sobre un procesador mononucleo y funcionaria (dentro de sus lógicas limitaciones)

Efectivamente, es lo que se conoce como paralelismo logico

 

[Tassadar]

bueno, cuando se habla de programación multihilo no necesariamente se obliga a que cada hilo de ejecución del programa tenga que tener equivalente en los hilos lógicos del procesador ..
lo que esta haciendo es paralelizar las tareas de modo que no todas se queden bloqueadas por la espera a que finalice una de las tareas a realizar
de este modo consigues realizar mas cosas simultáneamente dependiendo de las restricciones de uso del hardware que tengas por detrás
puedes dejar un hilo esperando la llegada de datos de lectura del dispositivo de almacenamiento mientras estas procesando otros datos y estas por otro lado preparando algo para depositarlo donde toque sin tener que bloquearse tareas mientras otras acaban, multihilo.
por poder podrías programar multihilo sobre un procesador mononucleo y funcionaria (dentro de sus lógicas limitaciones)

Por supuesto, puedes lanzar los procesos que quieras independientemente de los núcleos o hilos del procesador.

Lo que yo comentaba es que el programa que yo creé detectaba los núcleos y hilos del equipo donde corría, para así lanzar tantos procesos como hilos/núcleos en ciertas tareas.

Pero vamos, que lo importante que quería señalar era que procesando un conjunto de datos almacenado en un objeto preparado para acceso multithread, y guardando esos datos en una BD de SQL server, a partir de 4 procesos paralelos el rendimiento casi no aumentaba.

Un saludo

 

[Miembro eliminado 62353]

Por curiosidad, supongo que cuando te refieres al procesamiento que hace tu programa, usas programacion paralela o multihilo (paralela me refiero a programa donde no hay memoria compartida)

 

[Tassadar]

Por curiosidad, supongo que cuando te refieres al procesamiento que hace tu programa, usas programacion paralela o multihilo (paralela me refiero a programa donde no hay memoria compartida)

Multihilo, uso variables aptas para procesamiento en multihilo (thread-safe creo que se llamaba), a partir de ahí me creo clases complejas para almacenar datos y manejarlos.

Despues uso parallel.for, parallel.foreach para lanzar los diferentes procesos

Saludos

 

[Miembro eliminado 62353]

Multihilo, uso variables aptas para procesamiento en multihilo (thread-safe creo que se llamaba), a partir de ahí me creo clases complejas para almacenar datos y manejarlos.

Despues uso parallel.for, parallel.foreach para lanzar los diferentes procesos

Saludos

Te lo preguntava mas que nada por que en temas de eficiencia es mejor tener mas hilos en marcha que varios procesos, al so le cuesta menos crear/destruir hilos que procesos
Un saludo

 

[Tassadar]

Te lo preguntava mas que nada por que en temas de eficiencia es mejor tener mas hilos en marcha que varios procesos, al so le cuesta menos crear/destruir hilos que procesos
Un saludo

Pues eso no lo sabía, la verdad. Cuando el año pasado me puse con ese tema me hizo muha ilusión porque nunca había programado para multihilo, todo lo que aprendí fue de forma totalmente autodidacta buscando en google.

Pero vamos, que sé lo suficiente y he probado bastante como para saber que salvo tareas muy muy concretas, el aumento de rendimiento conforme el número de hilos/nucleos no es ni de coña lineal, y como ya comentaba a partir de 4-5 núcleos se estanca. Lo que no sé es si será ya porque hace cuello la RAM o qué leches, ahí ni idea, pero hice pruebas con muchos procesos diferentes y en el 3800x ninguno llegó a acercarse a multiplicar el rendimiento por 8 al lanzar 8 procesos.

Un salud

 

[Miembro eliminado 62353]

el aumento de rendimiento conforme el número de hilos/nucleos no es ni de coña lineal

Efectivamente. El caso donde se aprovecha al 100% se llama caso lineal, donde se aprovechan al 100% los hilos extra, tambien es digamos un caso un poco dificil de conseguir, ya sea por la tarea en si o por el algoritmo usado. Por contra esta el caso "speed-down" donde la paralelizacion es peor que el programa seqüencial. Y por ultimo el caso sublineal, el más comun, que es donde te encuentras tu, asi que si no llegas al caso lineal no te preocupes, a veces es imposible

 

[Tassadar]

Efectivamente. El caso donde se aprovecha al 100% se llama caso lineal, donde se aprovechan al 100% los hilos extra, tambien es digamos un caso un poco dificil de conseguir, ya sea por la tarea en si o por el algoritmo usado. Por contra esta el caso "speed-down" donde la paralelizacion es peor que el programa seqüencial. Y por ultimo el caso sublineal, el más comun, que es donde te encuentras tu, asi que si no llegas al caso lineal no te preocupes, a veces es imposible

Sin entrar en detalle, en líneas generales mi programa lo que hace es procesar n archivos del disco duro, extraer información de los mismos, ordenar esa información y compararla con la de la BD en SQL y unas reglas definidas en ficheros excel que se cargan al iniciar al aplicación y cuya información se vuelca en una especie de hojas excel virtuales que me creé, preparadas para ser accedidas de forma paralela, con posibilidad de indizar campos, etc. Una vez analizado todo, actuar en consecuencia procesando esos archivos y organizándolos en un árbol de directorios en base a la información de esos archivos y la de dicho arbol de directorios.

La forma mas "fácil" de paralelizar es que en cada fase del proceso se lance una tarea, un hilo para cada fichero a procesar, aunque esto no siempre es posible, y también a veces conviene procesar un fichero en paralelo, por ejemplo si tengo un documento de 10 páginas y quiero hacer OCR a las 10. Más complejidad aún cuando dependiendo del contenido de las dos primeras páginas es posible que no sea necesario hacer OCR a la 3 y siguientes. Para esto me creé un complejo sistema en cascada que tomaba todos los archivos a pasar por el OCR y los ordenaba de forma que el OCR y el análisis NO lo hacía fichero por fichero, sino a todos a la vez y avanzando en número de páginas. De esta forma garantizo que todos los núcleos están "ocupados" haciendo OCR hasta que no haya que hacerlo a más páginas.

Esto me llevó MUCHO tiempo de hacer, de hacerlo bien, claro, porque aquí lo fácil es decir "tengo n archivos? pues nada, un thread para cada archivo", o bien, la otra opción, "tengo un documento con n páginas? un thread para cada página hasta que las acabe o no tenga que seguir analizando este archivo". Pero ambas resultaban ineficientes, o bien porque podía tener muchos archivos de una sola página, o porque podía tener pocos archivos con muchas páginas, unido al hecho de que en base a lo encontrado en las primeras páginas podía ser necesario no seguir analizando más allá. Por eso creé una forma híbrida que unía lo mejor de las dos formas.

También hay partes donde intenté no solo desmenuzar una tarea, sino hacer dos cosas diferentes a la vez, pero en mi caso es complicado porque cada paso que doy depende completamente del resultado del anterior.

La verdad es que me obsesioné con optimizar la ganancia de rendimiento multinúcleo, pero irónicamente, las mejoras más grandes que conseguí al hacerlo fueron a base de optimizar procesos, o sea, de mejorar rendimiento del proceso en sí, algo que se benefician hasta los procesadores de un solo núcleo, claro xD.

Pero bueno, no quiero enrollarme más, la cosa es que como bien dices, es muy complicado o imposible esa "linealidad", y concretamente al volcar datos en la BD de SQL, en multinúcleo la mejora era de 4x o 5x si no recuerdo mal, y esto contando que en este proceso no solo vuelco datos, sino que hago comprobaciones de los mismos para asegurarme de que cumplen el formato requerido para ser almacenados. Sin esas comprobaciones, si fuesen solo queries "insert into" estoy seguro de que bajaría ese 4x-5x, porque se vería más la limitación del propio SQL al procesar peticiones de insertar datos.

Esto está lejos del 200x que consigue el compañero jacosito , estaría bien que nos contara como lo hace, porque yo opino "sin tener conocimiento de causa".

Saludos

 

[Aarón Marcos]

Entonces, ¿por qué hay juegos que son cpu dependientes mas que gpu dependientes?