De todas formas… en full sí que superará los 45º ¿no?.
Un saludo.
Si, seguramente…pero no al extremo de 72 grados....El problema es que el celeron de kairon siempre esta en 61 grados sin poner prime95 ni nada de eso, cuando se refiere a siempre entiendo que aun sin hacer nada esta a esa temperatura, no me parece normal en ese caso, aunque podria obedecer a que como ya dije el celeron M no soporta SpeedStep.
La temperatura tambien depende de la solucion de refrigeracion utilzada por el fabricante, ademas no olvides que de todas formas el Turion se calienta mas que el Semprom…Otra cosa no ha de ser muy buena la refrigeracion del ACER 5020 para alcanzar tal temperatura tan excesiva. Ademas no estoy hablando de un test de tortura como S&M o prime95 sino del uso normal, como jugar un juego, ver peliculas , etc, lo que me llamaba a la atencion es que el celeron de nuestro amigo simpre muestra 61 grados, claro tambien creo que es porque el celeron M no soporta SpeedStep (si no estoy mal) siempre esta trabajando a la maxima frecuencia.
Pues los 45 no pareen ser optimistas para un semprom 3000+ en uso normal y con PowerNow activado me parece perfectamente normal, ademas porque si pasara de 60 grados no podria colocarmelo en las piernas y quemaria pero no es as,i se siente muy fresco.
Para solo 5 puestos de trabajo no necesitas un opteron ni un Xeon y mucho menos 2GB de RAM! (a menos que la carga de transacciones sea muy alta y estes usando Gigabit ethernet en todos los PCs) un Semprom 3000+ con una buena placa y 1GB de RAM , con un par de discos SATA para el RAID en imagen y por supuesto una buena fuente de poder seria mucho mas que suficiente para tu aplicacion. He visto un servidor Pentium pro a 200MHz con 128MB de RAM manejar a mas de 20 PCs Pentium 4 a 2.4GHz.
Hola quisiera saber la temperatura de un Celeron M. El mio siempre esta en 61° en mi Presario M2015LA
Es normal.
Que temperatura tiene el sempreon en estos modelos de laptop.
saludos
Es bastante alta, quizas sea una mala lectura del sensor…
Tengo un presario V5000 con un semprom 3000+ (1.8GHz) y rara vez sobrepasa los 45 grados, excepto que haga mucho calor.
Pues en realidad el pentium D 950 lo he visto en 345 dolares y el SD 3700+ en 215…asi que el nivel de precios es muy diferente... El A64 X2 AM2 cuesta 324 (USD) y el X2 3800+ 939 297USD...No veo mucho caso en comprar un 950 cuando hay mejores de AMD por menos o igual precio y menos con lo cerca que esta el conroe. Mi consejo es: Espera el conroe...no es momento para comprar dual cores, cuando el conroe salga los precios de los 9xx y de los X2 iran al suelo...
Pues como dice barton la diferencia en rendimientoa stock podra no ser demasiado, pero ciertamente el semprom 754 ofrece muchas otras ventajas como la gran oveclockeabilidad (he puesto unos hasta a 2.6GHz!!!) y se calientan realmente nada, no he visto un palermo mas caliente que 35 o 36 grados a stock por mas que lo torture.
Anandtech da mas detalles sobre los planes de AMD
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2768
Me parece que no has leido este post anterior de esta misma rama:
http://www.hardlimit.com/forum/showpost.php?p=358040&postcount=175
:fumeta:
Me confundi…Pense que se estaba refiriendo al K8L...
Esos "ases" que han mostrado no me parecen ases en absoluto. Por una parte en el tema de usar un par de procesadores me parece una "solucion" desesperada para instentar no perder el liderazgo; poner dos procesadores sin tener que montar memoria registrada suena muy bonito, pero a ver quien es el guapo que se gasta ese dineral en montarse un equipo de esas caracteristicas.
Y en cuanto a las otras mejoras como el aumento del nivel de integracion: se van a producir dentro de demasiado tiempo, periodo en el cual Intel no se va a quedar parada.
Quien ha hablado de multiples procesadores?? Estamos hablando de QUAD CORE o sea 4 nucleos en un mismo chip. Ademas las mejoras individuales de cada nucleo tambien son importantes y no hay que dejarlas de lado.
Si AMD quiere ser superior definitivamente va a tener que mejorar mucho mas que los Mhz.
Pero la estacion de reserva de que unidad funcional??? Cada unidad tiene su propia estacion de reserva y teoricamente esta es "mas pequeña" que la cache y por consiguiente vas a tener que sobreescribirla por otra mas rapidamente que en el caso de la cahe por lo que seguramente la misma instruccion producira mayor numero de errrores.
Si observas la arquitectura P6 y del conroe, entre el "front end" y "execution core" existe un buffer llamado RS o estacion de reserva , a esa me refiero. En cuanto a los errores no entiendo a que te refieres, si te refieres a errores por ramas, estos errores se producen muy rara vez en el conroe debido a su potente BPU con una efectividad del 97% , es decir que solo un 3% de los saltos causaria un error, no es significativo y mucho menos impacto tendria entonces ahorrarse en el mejor de los casos un 3% de decodificacion en un conroe, ademas de que una mala prediccion no afectaria de manera catastrofica al conroe, pues sus pipelines son cortas, bueno eso en el caso de misprediction.
El trace cache como tu dices es mucho mas grande que la RS puede gurdar hasta 12Kuops y la probabilidad de que la instruccion requerida en un programa estre en el trace cache es entre 75 y 95% en un programa promedio, si no la encuentra tendria que decodificarla en el acto y gastar hasta 30 ciclos de la CPU, el trace cache se hace necesario porque debido a todas las etapas del P4 la decodificacion de una instruccion dura entre 15 y 30 ciclos!!!!!!, en este caso el trace cache es vital y un buffer relativamente pequeño como una RS no seria suficiente. P6 y conroe no tienen este problema, ademas porque muchas instrucciones complejas son decodificadas por los fast decoders del conroe gracias la micro y macro op fusion, esto hace que RS siempre tenga instrucciones para ejecutar y que un trace cache no sea necesario.
Ahora que lo pienso, lo que quieres decir es que la instruccion se almacena sin decodificar en la cache pero lo que mete en la estacion de reserva es la microinstruccion, no???
Si, es lo que estoy diciendo.
Si decodificar tienes que decodificar todas las instrucciones, pero utilizando la cache de traza lo que consigues es decodificar 1 sola vez la instruccion: cuando dio error y tuviste que traerla. Si por el contrario la instruccion pridujo un acierto la instruccion ya esta decodificada, mientras que con una cache normal aunque sea un acierto tienes que volver a decodificarla para poder meterla en el back end.
Siempre que buscas la instruccion la buscas en la cache de traza, si da error te la traes de MP decodificandola pero si produjo un acierto ya la tienes decodificada por lo que no tienes que volver a decodificarla.
Si eso es cierto en ese caso te ahorrarias la decoficacion, solo que parecia que lo decias como si siempre te ahorraras la decodificacion, es posible que te ahorres en ciertas ocasiones algo de decodificacion, despues de todo el Trace cache es limitado y las instrucciones decodificadas no van a permanecer para siempre alli.
A lo que me refiero es que la RS en conroe cumple el mismo objetivo del trace cache en netbusrt, la RS es capaz de proporcionar instrucciones siempre en sucesion suficientemente rapida al nucleo de ejecucion, de esta manera no importa que tenga que volver a decodificar la instruccion porque como las pipelines son cortas la demora entre decodificacion de la instruccion y el momento en que las microoperaciones alcanzan la RS no es tan grande como en netburst y RS siempre tendra instrucciones para ejecutar, es por eso que trace cache no es necesario. Si las instrucciones viajaran directamente del la etapa de decodificacion al nucleo de ejecucion si habria un problema de flujo de instrucciones en P6 pero par eso esta RS igual que para el P4 esta trace cache en el que un esquema de RS no seria suficiente.
Porque??? Seguirias ahorrandote la decodificacion de las instrucciones. En lugar de almacenar la instruccion "tal cual" en cache la almacenas decodificada y así no tienes que decodificar cada vez.
En las imagenes que has puesto sigue habiendo una etapa para pasar de codigo X86 a instrucciones maquina (decodificar la instruccion vamos) asiq ue no entiendo porque no se van ha beneficiar
Bueno empecemos por cual es el objetivo del trace cache?
El objetivo del trace cache es poder proporcionar al nucleo de ejecucion del P4 una sucesion suficientemente rapida de microoperaciones, sucesion que no seria suficientemente rapida con un esquema de estacion de reserva debido a lo que tardaria las microoperaciones decodificadas en llegar al nucleo de ejecucion en una CPU de tantas etapas.
Igual la instruccion antes de ser almacenada si es decodificada y luego almacenada en trace cache, o sea que tecnicamente no te estas ahorrando ninguna decodificacion. La funcion del trace cache es almacenar las microoperaciones ya previamente decodificadas de tal manera que pasen directamente del trace cache al nucleo de ejecucion.
Microarquitectura netburst
Si observas la microarquitectura netburst ves que la etapa de decodificacion esta antes del trace cache , es decir, que todas las microinstrucciones almacenadas en el trace cache pasan por la etapa de decoficacion. Tecnicamente no se esta ahorrando ninguna decodificacion. Simplemente se esta haciendo decodificacion previa de varias microinstrucciones antes de que sea requerido ejecutarlas.
La diferencia con P6 y conroe es que las instrucciones en P6 y conroe son tomadas directamente del cache L1 sin decodificar y decodificadas para ser almacenadas en la estacion de reserva, de esta manera el nucleo de ejecucion siempre tendra instrucciones para ejecutar en la estacion de reserva asi que no necesita cosas como trace cache. Por su parte el P4 decodifica las instrucciones con anterioridad y las guarda decoficadas en trace cache (pero si esta decodificando) entonces pasan directamente del cache al nucleo de ejecucion de forma suficientemente rapida, si se utilizara en el P4 el mismo esquema que P6 llegaria un momento en que la RS quedaria vacia debido a lo que tarda la decodificacion al pasar por tantas etapas no se podria proporcional instrucciones al nucleo de ejecucion en una sucecion suficientemente rapida, esto no pasa en P6 o conroe y por eso un esquema de trace cache no es necesario ni tendria un efecto adicional.
Asi que la RS siempre tiene instrucciones listas para despachar al nucleo de ejecucion, daria lo mismo si las tomara de un trace cache o de RS. Si intel ha decidido no utilizar el esquema de trace cache en conroe es porque sus ingenieros han considerado que no iba a ser necesario y despues de todo ellos saben mas que nosotros sobre su diseño.
Bueno espero haberme hecho entender.
Pues creo que la cahce de traza es o fue una idea muy buena y no se porque habran decidido no incorporarla :vayatela: ; si te puedes ahorrar la decodificacion de las instrucciones que producen aciertos de cache bien venido sea.
El SuperPi no es mas que un benchmarks, no es que haya que fijarse solo en el para dictar sentencia de cual es mejor o peor; pero sinceramente me ha llamado mucho la atencion la enorme diferrencia que ha obtenido el conroe.
El trace cache fue algo necesario para el P4, en arquitecturas como P6 y conroe no tendria practicamente ningun efecto en relacione con las modificaciones que habria que hacer al nucleo. En P6 y conroe la RS o estacion de reserva cumple eficientemnete su labor, en netburst simplemnete colocar una RS no era suficiente debido al efecto de tener tantos pipelines (era uy dañino esperar la decodificacion de una instruccion a traves de tantas etapas) entonces intel debio diseñar algo como en trace cache.
http://arstechnica.com/articles/paedia/cpu/pentium-2.ars/2
Los Conroe tiene un rendimiento acojonate, eso esta claro y no hay mas que ver que por ejemplo el recor en SuperPi esta en manos de uno de estos "bichos" y la diferencia con el primer AMD es de casi 10 seg; si si 10 seg. Sinceramente no se que modificaciones han echo en la arquitectura de estos procesador con respecto a los P4 para que tenga tanta repercusion, aunque me da la impresion de que sea causa de esos 4Mb de chache de nivel 2. Que tenga menos tamaño en la L1 da igual porque supongo que seguiran utilizando la cache de traza de los P4 y esta no se caracteriza por el tamaño en Kb sino por el numero de lineas decodificadas que sea capaz de almacenar (con esta cache de traza te ahorras el tener que volver a decodificar una instruccion que prodijo un acierto en cache, es más inteligente almacenarla decodificada y si aciertas no tienes que volver a decodificarla).
En cuanto al AS que supuestamente tiene AMD, supongo que al disminuir la tecnologia de integracion hasta los 65 nm les permitira incluir mas cosas en el chip y como primera opcion deberia pensar en aumentar el tamaño de la L2 por lo menos hasta los 2 Mb
Bueno lo del superpi ya habiamos dicho que no tiene mucho sentido comprar estos resultados entre arquitecturas distintas, pues la diferencia en superpi no es necesariamente la diferencia en rendimiento real. Es por eso que en este foro hay records de superpi separados para AMD e intel lo cual tiene mucho sentido. En cuanto al la diferencia en rendimiento del P4 al conroe ya barton lo ha explicado y en realidad la gran ganancia en rendimiento tiene NO se debe en gran parte al cache de 4MB. El Conroe no utiliza el cahce de traza del P4, de hecho conroe (afortunadamente) hereda muy poco o nada del P4.
Esta es la microarquitectura P6/PM
Esta es la micro arquitectura del conroe
Como se puede observar los esquemas son bastante similares. El conroe es un"overhauling" total de PM/P6, la evolucion mas grande se observa en el back end: un nucleo de ejecucion mas ancho, con capacdad de ejecutar mas instrucciones en paralelo, que ovbiamente resquiere una estacion de reseva (RS) mas grande (32 entradas). Las unidades de vector del conroe son mucho mas potentes (capaces de realizar operaciones SSE de 128 bits) y estan conectadas mediante 3 puertos distintos. Igualmente las ALUs escalares son mas potentes y tienen un puerto mas a su disposicion.Las unidades de Aceso a memoria son mejoradas. En P6 el rendimiento SSE sufre un cuello de botella debido a que estas funciones se agregaron a traves de los puertos 0 y 1, entonces las funciones escalares compiten con las vectoriales para la utilizacion de estos dos puertos no aprovechando adecuadamente los recursos. El conroe agrega un puerto adicional a estas unidades ademas de que se mejora el desempeño de los mismos ya que tres de ellos son dedicados exclusivamenta a operaciones aritmeticas y logicas.(netburst solo posee 4 puertos).
De nada vale tener un nucleo de ejecucion potente si no se mejora el front end para obtencion de las instrucciones por lo tanto se aumenta la logica de decoficacion, el buffer de reordenamiento (se aumento de 40 a 96 entradas). Las tecnicas que mejoran el desempeño del front end son. Micro ops y Macro ops fusion, Unidad de prediccion de ramas mas robusta y obviamente mejoras en el cache, no solo en tamaño sino tambien en eficiencia y velocidad.
En cuanto a las mejoras que AMD piensa hacer al nucleo (que ya las he posteado en otra rama) se encuentran la inclusion de un cache de tercer nivel, mejora del front ent (con esquema similar desambiguacion de memoria), Mejora de la potencia de calculo FP entre otras… La evolucion de K8 a K8L se puede ver de forma analoga a la Evolucion de P6/PM al conroe, si se observan detenidamente las mejoras parece ser similares, pero bueno habra que esperar por mas informacion por parte de AMD.
Me alegro que te guste. Vuelves a confundir el tocino con la velocidad. No dudo de que sepas de lo que hablas, dudo de tu educación y de tu humildad.
Debido a que no puedo enviarte un mensaje privado. Debo hacerlo aqui.
Acepto tus observaciones y acepto que algunas veces me he excedido con mis comentarios, en algunas de las ocasiones solo trataba de aclarar mantendidos, pero simplemente algunos no aceptan razones (no me estoy refieriendo a ti y creo que sabes de lo que hablo). Quiero disculparme con todos los usuarios que se han sentido ofendidos con mis comentarios se a cual fueren… Y dos ultimos comentarios que aprendi de mis padres...
-Es de humanos equivocarse... reconozco que en algunos casos mi actitud no ha sido la mejor, Acepto mi error.
-El hombre mas arrogante es aquel que no reconoce que esta equivocado asi sus errores sean evidentes y grasos.
Y un ultimo pedido... No hay necesidas de que me menciones en tu firma... Te pido el favor de que remuevas el comentario sobre mi en tu firma...Bueno creo que eso va mucho mas lejos de cualquier comentario que yo haya hecho contra alguien... Estas tomando precisamente esa misma actitud que tanto criticas de mi.
No quiero continuar con guerras sin sentido y personales en este foro... PAZ...
Lo que quiero decir es que hay arquitecturas en las que es mejor tener un ancho de banda elevado, importando menos el tiempo de respuesta, y hay otras en las que es mejor tener un tiempo de respuesta bajo, importando menos el tener un ancho de banda elevado. En el caso del P4 es mejor tener el fsb lo más alto posible, sin importar apenas las latencias, mientras que en el A64 es mejor tener las latencias lo más bajas posibles, sin importar tanto el fsb.
Es exactamente a lo que me referia con mi comentario…
PD:
Y gracias por lo de tu firma...en realidad muchos usuarios agradecen mis aportes...y mis explicaciones detalladas y precisas con soporte.
Espinetenbolas esta en lo cierto aunque el ancho de banda es bastante grande, la arquitectura K8 no se beneficia mucho del mismo, la latencia en K8 es mucho mas importante que el ancho de banda. Si, el ancho de banda de DDR2 es espectacular pero las latencias no y eso lastima el rendimiento de K8.
