Publicados por cdbular

En realidad la ventaja de dual channel en un A64 es bastante pequeña, máximo un 5% para procesadores equivalentes. Lo bueno de socket 939 es que AMD seguirá produciendo más procesadores para esta plataforma y tiene la opción de dual core sin cambio de placa. Socket 754 será olvidada por AMD y por los fabricantes de chipsets pronto.

Buena configuración pero tengo varias observaiciones:

-Necesitas una mejor tarjeta gráfica, al menos una Geforce 6600GT, para sacerle el potencial a tu sistema.

-Es una lástima que tu CPU no sea un 939 San Diego, esto limita las posibilidades de expansión a dual cores. y de OC.

-Tu placa no soporta PCIe, lo que es unproblema para futuras actualizaciones.

La geforce 5500 en este caso sería sólo un poco mejor aunque la diferencia no es gran cosa, ambas son poco potentes.

La FX5500 es una versión reducida de una 5600 y es sólo un poco más rápida que la 9200 aunque en realidad ninguna de las dos es recomendable para jugar.

@kynes:

Lo de que no la va a poder aprovechar… siempre tienes la opción de subir el antialiasing y el anisotrópico, cosa que con otros modelos inferiores no podrías. Además, depende mucho del juego, hay juegos en los que un P3 a 450 te vale más que de sobra, y hay juegos que por mucho micro que tengas, siempre van a ir mal.

Una Geforce 6600, sería una buena opción.

@FASerrano:

Pero es que el 80% de los usuarios tienen Intel y el 20% restante AMD, luego es rentable que corra más en Intel.

Pero no es así, los juegos no corren mejor en el pentium por mñas optimizaciones que se les hagan, simplemente la arquitectura es demasiado ineficiente.P Por esa razón corren mejor en A64 como lo demuestran los benchmarks.

Te recomiendo lo siguiente:

Te doy los precios en dólares ya que manejo el euro. creo que 1 euro=1.2 US$

un Venice 3000+ (US$150)

Placa: MSI K8N NEO4-F (Unos US$90)

Geforce 6600 PCI-e (US$140)

1GB de buena memoria Kingston, OCZ, corsair (US$140-150 dependiendo de la marca)

Un total de 530 dólares que en euros serían 442. Una muy buena configuración para tu presupuesto.

@Lepius:

Hola!

Vamos a ver, hoy he visto una de las tarifas de precios de estos 2 nuevos procesadores y hay una diferencia muy notable entre el precio de Intel y el del AMD.

Éstos son los precios: (son sin IVA)

INTEL
PentiumD 8202x2800Mhz. BOX EM64TDualC - 800 - 2x1MB - DualCore - 218,65 €
PentiumD 8302x3000Mhz. BOX EM64TDualC - 800 - 2x1MB - DualCore - 285,79 €
PentiumD 8402x3200Mhz. BOX EM64TDualC - 800 - 2x1MB - DualCore - 464,48 €

AMD
ATHLON64 X2- 4200+ - 2x2200Mhz BOX - Manchester - SSE3 - 2x512 - DualCore - 470,15 €
ATHLON64 X2- 4400+ - 2x2200Mhz BOX - Toledo –----- SSE3 - 2x1Mb - DualCore - 519,52 €
ATHLON64 X2- 4600+ - 2x2400Mhz BOX - Manchester - SSE3 - 2x512 - DualCore - 717,29 €
ATHLON64 X2- 4800+ - 2x2400Mhz BOX - Toledo –----- SSE3 - 2x1Mb - DualCore - 894,10 €

Como podeis ver, la versión mas cara de Intel es mas barata que la mas barata de AMD. ¿y eso?
¿será por rendimiento? ¿Intel se baja los pantalones para conseguir cuota de mercado?

Lo cierto es que son mucho mas asequibles a mitad de precio y no tendrán las mitad de rendimiento.

A ver que os parece y encuentro una explicación lógica al respecto.

Soy pro AMD y espero que los precios se igualen.

Saludos!!

Parece que has omitido el 840XE de intel que cuesta más que el 4800+ de AMD, y sin embargo rinde menos y com se encargo de mostrar THG es supremamente inestable, por el otro lado el dual core AMD presento estabilidad absoluta del 100%, yo creo que esta situación bien amerita la diferencia de precios aunque el 4800+ y 840XE cuestan casi lo mismo, pero me refiero al rango medio.

@Yosep:

en cuanto a edicion de video y actividades multimedias si le gana eso depende de lo que cada quien haga.

Cosa del pasado ahora que los Athlon 64 X2 están en el mercado. En general poseen mejor rendimiento en codificación de video, excepto por una que otra aplicación, que los dual core de intel.

@Wargreymon:

Por que??

No tienen por que funcionar todos los juegos mejor en un Athlon 64. Hay mas factores que intervienen en el rendimiento: La memoria, la velocidad de la unidad de cd-rom, la tarjeta grafica…

cdbular, no es por meterme donde no me llaman, pero se nota lo pro amd athlon 64 que eres (que no digo que sea malo ni nada parecido)

Evidentemente cuando hablo de que funciona mejor en un athlon 64 que en un P4 me refiero a un configuración similar. misma Tarjeta de vídeo, disco, memoria, buena placa base. Casi en todos los juegos el Athlon 64 con configuración similar destruye a un P4. Mira los benchmarks. Hasta un A64 3400+ derrota a los P4 de mas alto rango y costosos en los juegos. Cuando se hacen pruebas de CPUs para juegos, se corren los juegos en baja resolución de tal forma que la tarjeta gráfica no sea una limitante y se observe más claramente el efecto de la CPU sobre el rendimiento del juego.

Si , y soy pro A64, es la mejor arquitectura en el momento. No puedo dar crédito a una arquitectura tan ineficiente y que tiene sus dias contado como la netburst de intel. En el momento que AMD posea un mal chip y no justificable por el precio, lo diré, y el día que intel tenga una CPU decente a un buen precio, lo diré, pero este no es el caso en el momento.

@Wargreymon:

Lo he visto en el Medal of Honor european assault.
Puede ser publicidad o no pero solo dice que funciona en un pentium 4. pero no pone que no funciona en un athlon 64.

Si funciona en un P4, funciona en un Athlon 64 o visceversa, bueno excepto que la aplicación sea de 64 bits funcionará en cualquier A64, pero no en todos los P4. Lo que sucede es que seguro intel ha patrocinado o colaborado de alguna forma con el desarrollo del juego y la empresa creadora del juego se ven forzados a colocar la etiqueta del P4 en la caja del mismo, pero de todas formas el correrá mejor en A64.

…es un presshot, se calientan bastante, es posible que el abanico del disipador se haya estropeado, debes cambiarlo y reaplicar buena pasta térmica para ver si logras bajar esas temperaturas, lo cual es poco probable a menos que cambies todo y disiipador por otro más especializado y costoso como un Zalman.

@PiCoTTo:

Lo que le sucede a cualquier circuito electrónico de alta frecuencia cuando se le aporta menos de la corriente o tensión nominal para la que fué diseñado es que los tiempos de las puertas lógicas de los integrados aumentan y si que se podría notar algo menos de rendimiento (e inestabilidad por descontado). El ejemplo más claro lo teneis cuando queremos hacer un OC importante, se hace necesario subir la tensión para suministrar mayor corriente al componente en cuestión para que así pueda funcionar a frecuencias más elevadas. Pensad que a mayor frecuencia/velocidad mayor consumo.

Entonces, en conclusión, en casos concretos en los que la fuente de alimentación anda demasiado justa para nuestro equipo y, por tanto, gráfica, se pueden dar perfectamente situaciones en las que no hay suficiente corriente o tensión con lo que el rendimiento baja. Las fuentes de alimentación tienen mucha más importancia de la que se les dá y, más aun, como ya digo, en cicuitos de alta frecuencia. Siempre hay un margen para que suceda un bajon de rendimiento, luego no quiere decir que a todo aquel que tenga una fuente algo justa le vaya a pasar. Lo que si está claro es que, adquiriendo una buena fuente nos garantizamos en todo momento que por temas de alimentación no vedrán los problemas que puedan surgir.

Si no hay suficiente protencia para la tarjeta en algún momento dado, no se bajará el rendimiento gráfico, lo que sucedería es seguramente un bloqueo o reincio del PC. La calidad de la fuente influye de manera determinante en la estabilidad (lo que es aún peor) más no tiene por que afectar el rendimiento. Una tarjeta gráfica posee relojes supremamente precisos que determinan la velocidad de trabajo tanto de la memoria como de la GPU, estos relojes continuarán funcionando a la misma frecuencia independientemente de si no es posible proporcionar suficiente potencia a la tarjeta, pero la deficiencia en potencia no causará una baja en el rendimiento sino inevitable bloqueo del sistema, debido a que los componentes de la tarjeta siguen requiriendo de mayor potencia para funcionar al ritmo que el reloj impone y que no se modifica automáticamente. Hasta ahora que yo sepa las tarjetas no tienen ningún sistema que permita bajar la velocidad de reloj automáticamente cuando los niveles de potencia suministrada son bajos, lo cual sería muy bueno para la estabilidad pero a la vez un poco molesto y díficil de implementar.

Shappire es muy buen fabricante de tarjetas ATI, de hecho la fábrica de sapphire pertenece a ATI.

AMD sacará los procesadores semprom con soporte para 64 bits en Julio.
http://www.theinquirer.net/?article=23845

No hace falta decir que un celeron no tiene nada que hacer contra un semprom 754. La movida de intel al parecer no cambiará mucho las cosas.

Si he diseñado hardware a muy alto nivel. Incluso he contribuido con el diseño de microprocesadores RISC de complejidad media en VHLD. Quizás algún día intel o AMD me contraten. Quién sabe?

No soy poseedor de la verdad absoluta, sólo me remito a los hechos y a artículos especializados que avalan especificamente las razones expuestas. Es posible que la baja en rendimiento dependa en menor grado del código, pero los factores que realmente afectan el rendimiento ya los he mencionado y son puramente inherentes al diseño del harware implementado en el P4, como ya he mencionado la arquitectura más ineficiente precisamente por su gran cantidad de pipeline stages. Y una vez mas, no son mis ideas pues me remito a las fuentes, no estoy inventando nada.

Bueno , pero en fin ya nos hemos desviado un poco del tema original.

@Sergiman:

Bueno pues tu sigue pensando lo que quieras que yo haré lo mismo.

Por cierto, de donde has sacado eso de que "las etapas mas rapidas deben matenerse en idle", a que te refieres con idle?? No querras decir con poca carga de trabajo porque eso no es asi. La etapa de operaciones ALU en concreto las operaciones en punto flotante realizan sumas, multiplicaciones, etc..en punto flotante; por lo que la unidad trabaja o no hace nada porque los que si es seguro es que no hace "sumas normales".

No sabes que es IDLE???!!!! IDLE es que no hacen nada… Y si es ciert. Crees que al incrementar las etapas todas van a funcionar de forma ideal. Que equivocado estas! Veo que no tienes ningún concepto de lo que es diseñar hardware . Es supremamente complicado la implementación el mismo pues trabaja con señales físicas que inevitablemente sufren retrasos que penalizan el rendimiento y estos retrasos se incrementan cada vez que la lógica necesaria para impementar cada vez más etapas puede volverse estremada mente compleja y larga. Alguna vez has diseñado hardware? y visto las consecuencias de implementar multiples etapas en un sistema? Pués yo sí y por eso hablo con conocimiento de causa.

Ejemplo. El P4 sin HT utiliza la unidad de ejecución sólo el 30% del tiempo, con HT(que es una optimización hardware) puede llegar a utilizarla el 40%, el resto del tiempo la unidad de ejecución se mantiene en IDLE ya que debe esperar a que las demás etapas realicen su trabajo y tengan lista la instrucción para ser ejecutadas. Esto es un ejemplo claro de como afectan el gran número de pipelines el rendimiento, absolutamente independiente del software que ejecute.

Tiendes a contradecir mucho, pero no veo argumentos que fundamenten lo que dicen ,por otra parte he logrado demostrar con argumentos supremamente contundentes y ejemplos la realidad, quisiera que hicieras lo mismo, porque hasta ahora he visto incoherencias supremamente graves en tus respuestas.

No es lo que yo pienso , es como son las cosas, si quieres seguir manteniendo tus conceptos equivocados esta bien.

Por otra parte tu ejemplo de la ALU esta muy mal hecho ya que la ALU es una unidad aparte que en cualquier arquitectura se encuetra aparte del núcleo básico de ejecución(No es ninguna etapa intermedia de la CPU por que deban pasar todas las instrucciones) de las etapas absolutamente necesarias para realizar todas las instrucciones, evidentemente la CPU utiliza la ALU solo cuando se refiere a operaciones aritmético lógicas, pero si es una operación de carga a registro o de movimiento de memoria no será necesario utilizar la ALU. Pero las otras etapas como FETCH, decode, execute, write, ect (y que podrían subdividirse on otras etapas de igual forma que la FPU y la IU) deben procesar todas las instrucciones todo el tiempo. Al subdividir cada vez mas estas etapas se produce una complejidad inimaginableí y resultan etapas que son invevitablemente más complejas que otras, complejidad que causa retrasos puramente físicos y demoras en operaciones específicas. Desde el 486 la FPU siempre ha sido una unidad aparte del núcleo básico de ejecución y se sigue menteniendo así y con mucho más razón debido a que estas unidades estan a su vez compuestas por muchas etapas.

Esta es una de las fuentes de todo lo que he explicado...
http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars/4

@Sergiman:

¿Que no tiene nada que ver con el software???

Si el programa que se ejecuta no tuviera ningun tipo de dependencias (WAW, WAR y RAW) directamente no se utilizarian los registros de segmentacion para almacenar los datos producidos por las etapas. Como he dicho antes, los compiladores juegan un papel fundamental ya que la reorganizacion de codigo puede eliminar los retasos producidos por dichas dependencias.

No estoy hablando de dependencias ni nada relacionado con el software, sino del IPC, instrucciones por ciclo de reloj, parámetro que depende exclusivamente de la arquitectura y efieciencia de la CPU. El IPC se ve reducido de forma inexorable al aumentar el número de etapas en una arquitectura dada. Y así el software fuese ideal iy perfectamente eficiente, de todas maneras seguiría ejecutandose más lentamente si a una CPU dada se le incrementan la pipelines y se conserva la velocidad de reloj simplemente porque ejecuta menor número de instrucciones por cliclo sea cual fueren las instucciones que se ejecuten así sean simples instrucciones de carga en registros.

-Algunas etapas son de forma inherente más complejas y son más lentas que otras Pero cada etapa debe (o debería) tomar el mismo tiempo para realizar su trabajo, pero esto no ocurre!, en lugar de esto las etapas más rápidas deben mantenerse en idle hasta que la etapa más lenta termine su trabajo, en otras palabras, la cantidad de tiempo que toma a la etapa más lenta realizar su trabajo es la que determina la tasa de instrucciones y se constituye en un desperdicio de recursos. Y esto es absolutamente independiente del software, pués, las etapas del microprocesador y las tareas que se realizan dentro de ellas de forma independiente son transparentes para cualquier compilador o ensamblador, pues estos solo se encargan de entregar las instrucciones a la CPU para que las ejecute. Entre más se subdivida la CPU en etapas, las
pipelines individuales se vuelven cada vez menos uniformes entre en longitud y complejidad el resultado de esto es que los tiempos de ejecución de instrucción (independietemente del software) se hacen más y más largos. Es muy díficil para los diseñadores de hardware hacer que las etapas sean uniformes consuman la menor cantidad de tiempo.Un ejemplo claro de estas falencias: EL P4, que sólo alcanza rendimiento aceptable al utilizar instrucciones SIMD, que realizan varias operaciones en una sola instrucción, que igual pueden implementarse en CPUs con pipelines más cortas y sin demasiado esfuerzo.

-Otro problema al utilizar mayor número de pipelines algunas instrucciones podrían quedarse "colgadas"
en alguna etapa durante varios ciclos por un número razones concernientes exclusivemente al hardware.
Cuando este cuelgue ocurre todas las instrucciones que vienen de las etapas anteriores a la que se colgó
avanzan normalmente, mientras que la instrucción colgada avanza pero genera un vacío en la etapa que acaba de dejar. Cuando éste vació (llamado burbuja de pipeline) llega a la unidad de ejecución el procesador no ejecuta nada y la tasa máxima de instrucciones se ve reducida también por esta causa.

Entonces ya hay tres rezones por las cuales incrementar las pipelines en una arquitectura específica penaliza el rendimiento gravemente.

-Fallas en predicción, que podría ser dependiente del software, pero en menor grado ya que las unidades de predicciín tienen una efectividad del 98%, entonces en CPUs actuales la penalización no se produce muy a menudo por fallas en predicción si por la complejidad que implica la necesidad del aumento de complejidad de la unidad de predicción y la cantidad de cilclos que la misma podría desperdiciar.

-No uniformidad exacta en el rendimiento de las etapas individuales, que independientemente del software reduce el IPC de forma importante al de una CPU ideal.

-Introducción de vacios en por cuelgue de pipelines que ocurre de forma independiente al software, y que también dsiminuye el IPC de su máximo teórico.

El ejemplo de estos tres efectos se hace evidente el el P4, la CPU más ineficiente que existe actualmente, y que es efectivamente el que mayor número de pipelines posee.

@Sergiman:

El aumentar el numero de etapas sin incrementar la frecuencia de trabajo del procesador puede que produzca una pequeña perdiada de rendimiento; pero no tiene porque. Depende mucho del codigo que se este ejecutando y de lo buenos que sean los compiladores reordenando las instrucciones para asi disminuir las dependencias.

Estamos en lo de siempre, aunque tengas la mejor arquitectura sino tiene un soprte software bueno…....no tienes nada.

Además de las fallas en predicción existen otras razones inherentes al hardware por las cuales aumentar las pipelines se causa inevitablemente una disminución en el IPC, echale una leída a los artículos de arstechnica. No tiene nada que ver con el software.

@Sergiman:

Yo no estoy de acuerdo totalmente. Lo primero es que el echo de aumentar las etapas de segmentacion conlleva la disminucion de el numero de ciclos de reloj por etapa y de esta manera se puede aumentar la frecuencia de trabajo del procesador. Si la prediccion falla, debemos vaciar los registros de segmentacion que estan entra las etapas; pero el echo de tener mas etapas no quiere decir que forzosamente tengamos que tener mas registros de segmantacion. Estas registros de utilizan en aquellas etapas donde la anticipacion de datos es necesaria para no perder ciclos de reloj en esperas que producen las dependencias de datos. Por lo tanto ante un caso de dos etapas, por ejemplo la etapa de escritura en registros y la etapa de escritura en memoria no es necesario colocar ningun registro de segmentacion porque no hay dependencias. Despues de todo este rollo, quiero decir que el echo de aumentar el numero de etapas no implica necesariamente una perdida de tiempo extra resultante del fallo en la prediccion; y tampoco quiere decir que por tener mas etapas nuestra BTB (es la unidad funcional encargada de las predicciones) sea mejor o peor.

Bueno segun artículos especilizados de arstechnica, además de otras razones, el aumento de etapas penaliza el rendimiento debido a las fallas en la predicción que llegan a causar desperdicios de cilcos de reloj importantes. Para la muestra la arquitectura netburst. No esoy diciendo que la efectividad de la unidad de predicción dependa del número de pipelines, sino que al aumentar el numero de pipelines se requiere una mejor unidad de predicción.

"I talked above about how the P4's greatly-enlarged and more-complex instruction window is one place where the P4 pays a price for its deep pipeline and high clock speed. The other place where the P4 spends a ton of resources to cover the costs of deep pipelining is in its branch prediction unit. For reasons which will become even more clear in the section below, the P4's deep pipelines mean that a mispredicted branch will cost many more wasted cycles than it would on the P6."

"Following the execute stage on the P4 are the flags, branch check, and drive stages. In the flags stage any flags that the need to be set as a byproduct of the instruction's execution (i.e., a division by zero flag, overflow flag, etc.) are set in the x86's flag register. The branch check stage, stage 19, is where branch conditions are evaluated, which means that in the case of a mispredict you have to flush 19 stages (en el caso del willamete y northwood, en caso del presscot este numero asciende a 31) worth of work out of the pipeline. That's a lot of wasted cycles. Finally, there's a final drive stage dedicated to sending the results of the execution back to the ROB where they'll wait to be written back to the register file at retirement time."

http://arstechnica.com/articles/paedia/cpu/pentium-2.ars/4
http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars

@Javisoft2004:

Se t agradece el esfuerzo, gracias, me va quedando mas clara la cosa, entonces segun e entendido, a mas segmentos tenga el micro mas frecuencia de reloj se consigue, en ese caso amd iria en desventaja, que la subsana por otro lado con lo que tu comentabas, pero entonces, no deveria un P4 tirar mas que un K8? En la practica la mayoria de las veces no es asi, suele ganar en multimedia pero por lo que e visto poco mas. No sera mejor tener menos mhz y utilizarlos mejor como hacen los Amds? Parece el cuento de nunca acabar pero es k no m keda todavia claro el pk en la practica no se refleja lo que ay en el papel. Saludossssss

Utilizar mas pipelines o etapas permite aumentar la velocidad de reloj, pero al mismo tiempo existe una gran penalización ya que si en un momento dado existe un error de predicción (frecuentemente) en una rama la CPU debe descartar todos los datos que había estado procesando, vaciar o limpiar todas las pipelines y volver a empezar. Esto reduce la eficiencia enormemente ccomo sucede en un P4. Un K8 por su parte posee muchas menos etapas y la penalización es mucho menor, además porque el K8 posee algoritmos de predicción mucho más eficientes que el de el P4. Es por esta razón que en forma efectiva un K8 puede realizar más intrcciones por ciclo de reloj, al menos un un 30% más, el presscot posee más de 30 etapas, el K8 sólo posee 13.