Publicados por Pperezu

Ves como no lo habías entendido.

Pues te lo explico otra vez.

Cuando un programa de render hace una animación, lo único que hace es renderizar un montón de fotogramas, y cada fotográma es exactamente lo mismo que una imagen estática. Osea, que si tu le mandas a tu PC hacer una animación, calcula la geometría del frame 1 y hace el render, y cuando acaba, calcula la geometría del frame 2 y hace el render, y así sucesivamente.

No hay ninguna relación entre el frame 1 y el 2. De hecho, puedes mandarle hacer los frames 4, 23 y 57… no necesita hacerlos con ninguna relación entre ellos (menos mal, de lo contrario las granjas de render lo tendrían crudo para ponerse de acuerdo).

Vale, has comprendido que el proceso de creacción de una animación no es más que la repetición sistemática de un proceso de render ¿no?

Bien, pues ahora te explico porqué en los renders de frames cortos gana AMD y en los renders largos Intel. Simplemente, porque el render tiene dos partes diferenciadas (de tanto decirlo me fatigo) el cálculo de la geometría y el render en si. Es decir, cada fotograma de una animación hace un cálculo de la geometría y el render en si de la imagen. El tiempo que tarda en hacer el cálculo de la geometría es el mismo tanto si la imagen va a tener 400pixels o 400000000pixels, mientras que el render en si, evidentemente varía muchísimo.

Y resulta que el cálculo de la geometría no saca provecho del HT. Eso significa, que en el proceso de cálculo de la geometría gana el AMD.

Y resulta que en el render en si, se aprovecha, y muy bien el HT, luego en esa segunda parte del render de cada imagen, gana Intel.

Conclusión: Cuando al hacer un frame la mayor parte del tiempo de cálculo es cálculo de la geometría, gana AMD. Cuando al hacer un frame, la mayor parte del tiempo de cálculo es el render en si, gana Intel.

Y esto es absolutamente independiente del número de frames que hagas.

Te pongo ejemplos reales.

El cálculo de la geometría de una escena no muy compleja con varias luces puede ser 10-20 segundos. pongamos 20.

El render en si mismo de esa misma escena, puede ser de 30-40 segundos a 640x480 (pongamos 40), o de una hora a 4000x3000.

Esto significa, que en una animación a 640x480, el tiempo en el que los Intel no aprovechan el HT es un tercio del tiempo total. De cada minuto de render, 20 segundos no se aprovecha el HT y 40 segundos si.

Si haces esa misma animación a 4000x3000, el tiempo en el que los Intel no aprovechan el HT es despreciable ¿verdad?

Los dos casos son animaciones, y sin embargo en el primer caso un AMD64 puede batir a un Intel, mientras que en el segundo caso (a día de hoy) no puede.

No, barco no es un animal acuático (todavía).

Por cierto, en la rama que comentas, casi todo el mundo comprendió porqué Intel perdía en los benchs basados en animaciones, y tu mismo decías haberlo entendido. Ya veo que no.

No te mosquees, que yo no he dicho que estes equivocado, he dicho simplemente que los amd mejoran en renders en movimiento frente a los estaticos comparado con los P4, no he dicho ni que tu explicacion no sea validad ni que los AMD sean mejores.

Pero es que eso que dices es mentira. Los AMD no mejoran en renders en movimiento, mejoran en renders de baja resolución, o en renders cortos (de cada frame). Y si dices que me has entendido, y no dudas de mi explicación, no entiendo porqué te reafirmas.

Si un procesador hace más rápido un frame a una resolución, hace más rápido los 10000000000 siguientes a esa resolución, porque una animación no es más que la sucesión de renders "estáticos", y los procesadores no se fatigan, al menos hasta ahora…

Y no me mosqueo, simplemente no me apetece aceptar barco como animal acuático.

Pues si le sirve de ayuda a alguien con mi problema, resulta que si utilizas la conexión SSH a través del FTP normal, con un programa tipo cuteFTP Pro, en lugar de un programa específico de SFTP, la transferencia de archivos es similar a la del FTP clásico (tarda un pelín más en ver los archivos y carpetas y moverse por la estructura, pero poco más).

Así que ya no voy a tener que pasar de multipuesto a monopuesto cada vez…

Pperezu, yo entendi la explicacion entonces y la he entendido ahora, sin emabrgo me ciño a comentar los resultados que he visto en algunas webs y que demuestran que en animaciones mejoran los AMD.

Vale, lo que tu digas.

Pero no es esa la realidad, la realidad es que son mejores en renders a baja resolución, simplemente, independientemente del número de renders que hagas. Cuanto más pequeña sea la resolución del render (sea una imagen o una animación de 10 millones de imágenes) mejor parado saldrá el AMD y viceversa.

Te estoy ayudando a leer los resultados de los bench en lo poco que se, pero no te da la gana interpretarlos…

Voy a aprovechar este hilo que hemos llevado, para comentar algo sobre optimizaciones de las aplicaciones para distintas plataformas hardware, al menos desde el punto de vista que yo conozco.

Yo se de buena tinta, que Maxon, la empresa de Cinema4D, hace un esfuerzo muy grande por mantener optimizado el programa para los ordenadores de Apple. Ha sido así siempre, porque tiene una amplia gama de clientes en ese entorno (más de la mitad de sus clientes, siende el programa 3D mayoritario, con mucho, del entorno Apple). Y en los últimos tiempos, pese al esfuerzo de optimización, los PCs eran muy superiores a los Apple.

Bueno, pues salieron los G5, y en sus primeras apariciones, el rendimiento en render de los duales G5 era similar al de los duales MP de AMD. El paralelismo era casi de Mhz con Mhz, osea un dual MP a 2200 corria como un dual G5 2000 más o menos.

Vale, los chicos de Maxon han hecho un esfuerzo muy grande por optimizar el soft para los G5, y hoy, a 5 o 6 meses de la salida oficial de los G5, la nueva versión de Cinema, viene correctamente optimizada para los G5, y el aumento de rendimiento en render es del 20%… No se me ha escapado un 0, no, los numeros son esos, un 20% nada más y nada menos. De tal forma que han pasado de competir con los duales MP, a competir con los duales Xeon, a los que casi alcanzan...

Yo se, porque me lo han confirmado gente próxima a Maxon, que no se hace ninguna optimización especial ni para Intel ni para AMD, a día de hoy. Y tengo la sensación, de que si se hiciera un esfuerzo de optimización para la plataforma A64, incluso ahora con código de 32 bits, seguro que no se sacaba un 20%, pero el aumento de rendimiento permitiría (estoy casi seguro) sobrepasar a los P4.

Y os puedo asegurar, que hasta que salieron los P4 con HT, si mandabas un mail a Maxon preguntando la plataforma hardware más recomendable para trabajar con Cinema, te contestaban, por escrito, que AMD. Lo que indica, que entre AMD y Intel, al menos hoy por hoy, no se casan con nadie...

¿Cuando las empresas de soft harán ese esfuerzo por acomodar un poco sus programas a los nuevos AMD a 64bits...? Porque ese es el momento que todos estamos esperando.

Y bueno, ya que has dado el link, podrás observar hasta que punto el HT es lo que marca la diferencia cuando la aplicación es capaz de aprovecharlo…

En el programa SETI, que como es informática distribuida aprovecha los multiprocesadores, el Intel gana claramente a los AMD, puesto que hace dos unidades… Los AMD las hacen mucho más rápido, pero en la suma de dos unidades, ganan los Intel.

Nell'elaborazione della WU di test (maggiori informazioni a questo indirizzo) con il client testuale di Seti@home, i processori Intel Pentium 4 sfruttano appieno i benefici della tecnologia Hyper-Threading, con la quale possono elaborare 2 WU in contemporanea; per questo motivo è stato riportato il tempo necessario ad eseguire due WU identiche.

Sin embargo, en el Super PI, que no puede ser multihilo puesto que es un cálculo lineal, los intel ya no despuntan, aunque tampoco hacen el ridículo. Simplemente confirma lo que os vengo contando, que cuando la aplicación es capaz de sacarle partido al multihilo del HT, los P4 ganan.

.

señalas resumiendo (lo mismo lo simplifico demasiado) que a mayor tiempo de render la ventaja de los P4 gracias al HT se agranda. Es decir, si una escena consta de 500 frames y se renderizan todos, osea toda la escena, el P4 con HT tira mejor que si lo que se renderiza de esa escena es un solo frame, que lógicamente tarda mucho menos.

Efectivamente, estos resultados confirman lo que te explico, que por cierto, volveré a hacer porque veo no has entendido completamente.

Verás, en el proceso de render de una imagen, tanto de una imagen suelta como de un frame de una animación hay dos partes claramente diferenciadas. Una primera parte, es el cálculo de la geometría y otra parte el render propiamente dicho. Eso pasa en todos los renders, y cuando es una animación en todos y cada uno de los frames de la animación.

El cálculo de la geometría, lo hace un procesador, y no admite multihilo, es decir, que mientras se hace el cálculo de la geometría, el P4 no saca partido al HT.

Y da la casualidad de el tiempo de cálculo de la geometría es el mismo tanto si vas a sacar la imagen a 4000x3000 como si la vas a sacar a 400x300.

Por eso el Intel gana cuando se hace la imagen a 800x600 y pierde cuando se hace a 640x480. Da igual el número de frames, lo que marca la diferencia entre un caso y otro es la resolución de la imagen. Si a eso añadimos, que con casi total seguridad, la transición entre fotogramas tampoco aprovecha el HT comprendemos rápidamente porqué son resultados diferentes. Cuando hablo de tiempo de render, me refiero a tiempo de cada frame.

Y con esto vamos aclarando el tema. Con una animación a 640x480 gana por poco el A64, pero si la animación fuera a 800x600 ganaría el P4. Y si la animación fuera a 2000x1500 el P4 ganaría con un poco más de claridad. Si la animación fuera a 320x240, ten por seguro que los AMD le daban un repaso a los Intel…

En cuanto a lo de los dos cores de los AMD, me parece fantástico que se confirme, porque como lo leí el 28 de diciembre, me quedé con la mosca detrás de la oreja...

Vamos a ver. Voy a aclarar algunas cosas, al menos las que yo conozco.

En primer lugar, el cinebench no es que lo conozca, es que es mi "bench" puesto que yo trabajo con Cinema, y para mi es la referencia. Y los resultados del Cinebench, como ya he comentado no hace mucho en el foro de Benchs, demuestran que en render el Pentium gana claramente, mientras que en OpenGL, los A64 le dan un repaso, lo que significa que el camino llevado por el AMD es mejor cara al futuro, osea, que la plataforma es mejor…

En cuanto a la diferencia de rendimiento entre un solo frame y una animación de los P4 me he cansado de explicarlo (lo hice ya una vez y no me hicisteis ni pastelero caso). Es muy simple, pero lo volveré a explicar.

Cuando un programa 3D, y todos funcionan igual, va a renderizar una imagen, primero hace un cálculo de la geometría y las luces. Este cálculo primero, es el mismo para una imagen a 4000x3000 que para una imagen a 400x300. Tarda lo mismo en hacer este cálculo para cualquier tamaño de imagen. Y resulta, que este cálculo, lo realiza un solo procesador.

En el caso de Intel, sucede que este cálculo de la geometría, no se beneficia del HT, simplemente.

La conclusión es muy simple. Si tu haces un render de una frame a 400x300 puntos, el tiempo que lleva el cálculo de la geometría puede ser la mitad del tiempo total, mientras que en un render a 4000x3000 ese tiempo es casi despreciable.

En resumen, si tu haces un render a alta resolución, gana el Intel, puesto que aprovecha el HT. Mientras que si tu haces una animación, que obviamente tiene poca resolución, el tiempo empleado en cada frame para el cálculo de la geometría, es decir, cuando no se aprovecha el HT, es muy alto, luego el Intel pierde.

Además he de avisarte, que estas pruebas de animaciones se hacen a resoluciones extremadamente pequeñas (no son las que vas a usar en tu trabajo nunca) precisamente para que el bench no se tire una semana trabajando. Evidentemente una animación que se tarda en hacer entre 10 y 15 minutos es imposible que aproveche el HT de Intel, puesto que más de la mitad del tiempo es cálculo de geometría seguro. Y cuanto mayor es la resolución de una imagen, mayor es la diferencia en tiempo a favor de Intel, te lo aseguro. Una vez más, un render de 3 minutos no es en absoluto favorable a Intel, luego la prueba de render normal tampoco le favorece... Donde gana por mucho es en renders largos.

Pero esta es la misma disyuntiva que tiene un tío cuando se plantea montarse un dual para trabajar 3D. Ahora mismo, el rendimiento OpenGL de un monoprocesador es mejor que el de un dual, a igualdad de gráfica, luego para el trabajo de modelado es mejor un monoprocesador (y el A64 el mejor con mucho). Y mientras haces renders cortos de prueba, la mejora que obtienes con un dual es poco significativa, puesto que el tiempo de cálculo de la geometría se lleva buena parte del tiempo total.

Pero sin embargo, todos entendeis que sea mejor un dual para hacer 3D, ¿verdad? Entonces, ¿porqué os extraña que pueda ser mejor (todavía) el P4 para estos menesteres? Pues muy sencillo, porque al final uno se pasa dias enteros haciendo renders de prueba que llevan en torno a 15 minutos cada uno, y ahí si que se nota la diferencia...

Gracias Bleom:

He estado leyendo mucho al respecto, y al parecer el problema no existe cuando el router está configurado como monopuesto. El tema, es que he leido en un post del foro, de hace un par de meses, que alguien tenía este mismo problema, y que le aconsejabas un programa que te permitía cambiar de monopuesto a multipuesto en un par de clicks…

Eso es lo que necesito.

¿Podrías indicarme de donde bajarlo? Porque juraría haber leido algo sobre esa utilidad, pero ya no recuerdo donde.

Vale, acabo de encontrarlo en ADSL4ever. Muchas gracias de todos modos...

Yo creo que afirmar que el A64 rinde más que los P4 es generalizar, puesto que hay muchas aplicaciones, sobre todo aquellas que aprovechan convenientemente el HT de los Intel, en las que los Intel ganan claramente todavía.

Y no es por dar la paliza, pero son precisamente aquellas aplicaciones donde el tener más rendimiento es muy importante (me refiero al render, que es lo que a mi me preocupa). En el 90% de las aplicaciones a mi me da igual tener un procesador u otro. Diría que me vale cualquiera desde hace un año o más.

El A64 tirunfará realmente cuando sea capaz de darle caña a los P4 precisamente en esas aplicaciones.

Acabo de cambiar de proveedor de servicios de internet y me he llevado un palo tremendo. Resulta que el maldito router 3Com que tengo, que me dio telefónica hace un par de añitos, tiene una incompatibilidad con el programa de FTP ProFTP, que es uno de los más empleados en los servers de todo el mundo. Esta incompatibilidad se da sólo a partir de la última versión de este programa, de tal manera que según se van actualizando los servers, la gente como yo, que tenemos este router, no podemos conectar correctamente mediante FTP… Sólo pasa con la versión de router que dio telefónica.

El resultado, es que me veo obligado a conectar mediante SFTP (ftp-ssh segura a través del puerto 22) y aunque va bien, la velocidad de subida y bajada no tiene nada que ver con el FTP clásico (yo creo que el rendimiento no es ni la mitad). Estoy trasladando una web entera hecha con nuke (un webo y parte de otro de megas) y es desesperante, con una media de subida de menos de 3Kb...

No se que hacer, porque por lo que he leido en los foros, ni los autores de proFTP piensan hacer nada (les importa un pepino los pocos payaos hispanos que tenemos este router) y los de 3Com también se hacen los locos, puesto que para ellos es un modelo obsoleto, y que Telefónica modificó, con lo que no hay garantía ni interés en solventar el problema. De timofónica ya ni os cuento...

Así que no se que hacer, si esperar y confiar que alguien descubra la manera de solventar el problema (hace ya un par de meses que salió la última versión de ProFTP). O pillarme un router nuevo... Una ruina.

¿Alguien conoce un router ADSL bueno, bonito y barato? No necesito muchas salidas eternet, ya que tengo un switch.

En los foros de adsl4ever.com hay gente que se queja de esta conexión de Arsys, pero me imagino que es como todo, a unos les irá bien y a otros no tanto. De todas formas, daros una vuelta por estos foros a ver que se comenta.

Es que en un foro como este comentar la posibilidad de pillar un Barton y que no lo vas a poner al menos a 11x200, que lo admite sin tocar nada… es un poco inapropiado.

El Barton 2500 admite sin pestañear 11x200. Por eso, cualquier pensamiento sobre rendimiento, debería hacerse con esa premisa. Al menos en este foro, creo yo ¿verdad?

Pues si, tienes razón. Ahí te pongo la captura…

No se corresponde del todo con las estimaciones, sobre todo por el "parón" de Packo y sobre todo de DaRkSiDe… junto al abandono de algunos, como Krampak, NaKaToN, etc, por irse al nuevo BOINC... Pero bueno, era divertido especular.

Pues eso, felicidades, que con el nuevo año has alcanzado la mítica cifra de 10.000 unidades…

Es una cifra que muy pocos han visto, y muy pocos verán ya, dado lo poco que queda para que desaparezca este SETI y se de paso al nuevo BOINC.

FELICIDADES.

Muchas gracias Krampak, lo vi ayer precisamente, y me ha confirmado lo que ya he comentado. El HT de los Intel es definitivo a la hora del render, y por ahora, nadie le mete mano a los P4 y Xeon en tiempos de render (pasa igual con Max y con Lightwave).

Sin embargo, la plataforma AMD64, osea el conjunto placa/chipset/memoria es infinitamente superior, hasta el punto de que el rendimiento OpenGL con la misma gráfica es sustancialmente superior, lo que indica que el camino seguido por AMD es el correcto, y que si no fuera por el HT…

No se, hace poco leí la noticia de los dos cores AMD, pero como fue el 28 de diciembre...

Since Athlon 64 3000+ processors are based on absolutely identical cores as Athlon 64 3200+…

Extraido del link que nos ha dado Juande...

Yo tengo esa placa, y tengo el multi por defecto, pero estoy en contacto con una persona que también tiene esa placa, y por lo que me comentó en su momento, los multis no funcionan correctamente. Algunos van, otros no, y ni siquiera se corresponden exactamente con lo que indican en la BIOS. El en concreto no ha conseguido que le rule con el multi a 16, que es el que le interesa, y lo tiene ahora con el multi a 15 que era el multi por defecto. Por lo que me comentó el valor más próximo con el que le arrancó el ordenador era poniendo en la BIOS el 9, y le salió el multi 17…

Así que tendrás que probar multis, y confiar en que alguno sea el que deseas.

¿Seguro que el 2400 está desbloqueado?

Porque pone claramente que es de la semana 40…

La verdad es que los dos primeros son los famosos pata negra, así que esos fijos deberías quedártelos, a medio foro les gustaría tener uno.

En cuanto a los dos restantes, el 2600 no está ni en la lista de los steppings del foro, pero por las siglas podría ser que subiera mucho mucho, con la ventaja de partir de una velocidad muy respetable… Pero el 2200 parece un thorton por el stepping...