-
Yo no comprendo esos tiempos, porque aunque sea un dual que envíe 2 unidades cada 3 horas y poco, la media sería 3 horas y poco, puesto que cada procesador lo hace de forma independiente…y su tiempo se mide de forma independiente, ¿o no es así?
Lo único que se me ocurre, es que haya conseguido poner a trabajar varios procesadores en una sola unidad... O que sea un dual Xeon y que como tienen lo del Hipertreading (o como se escriba) y que cada procesador haga dos unidades y los tiempos los considere de una... Yo que se...
La otra cosa que se me ocurre, aunque pueda parecer disparatada, es que tenga tan al límite overclockeado el ordenador que sistemáticamente le de errores al procesar unidades y las envíe todas sin terminar...
Uf... nadie sabe quien es para que lo explique, porfa?
-
es ke estamos pensndo ke usa procesadores e la gama mas normalita.tal vez el pavo curre en una superempresa y tenga estaciones de trabajo alpha, o algo parecido.vete tu a saber
-
Hola como bien dice Pperezu cun dual envia 2 unidades a la vez pero el tiempo medio no es la mitad de cada una si no la media de cada unidad, en mi caso 2 cada 8 horas +-, y +- pues el micro principal procesa mas lento por que tiene que sostener el sistema aunque este consuma pocos recurso se nota la diferencia.
Seguro que tiene algun Mac o micro de 64 bit para poder conseguir eso.
Saludox: Rolling.
-
Los Mac hoy por hoy son más lentos que los AMD y Pentium4… Claramente más lentos.
-
Depende en que cosas … en programas optimizados, Photoshop y demas, es más rapido que un PIV optimizado ...
Y no hablo de igualdad de megahercios
Postee una noticia en la web princioal al respecto ... Un PIV a 2Ghz contra un PowerPC a 1.2Ghz creo ... y ganaba el MAC, por poquito ...
En Seti , no tengo ni idea de como ira, pero no esta optimizado ... Creo que AMD es el lider a igual frecuencia de reloj ...
Siempre Aprendiendo
www.namiga.es
-
Y digo que es más que discutible por la sencilla razón de que esa comparación es a todas luces injusta, puesto que el procesador Motorola para Mac más rápido del momento va a 1,25Ghz, mientras que el PIV es de 2,5… luego la comparativa no es del procesador más rápido... Y en duales ya ni te cuento la diferencia entre un Xeon 2,8 y los Mac 1,25...
Además olvidas comentar con que versión de Photoshop... porque la última ya se encargó Intel de que la optimizaran para los PIV (para distanciarse de AMD) y el resultado es que los chicos de la manzana ya no hacen comparaciones de rendimiento con el fotochop...
Además Apple ya sólo vende sistemas con doble procesador (porqué será?)
Respecto al SETI, la diferencia es palpable, puesto que el rendimiento es un poco menor a igualdad de frecuencia... y ya sabemos que la frecuencia que manejan es la mitad.
http://www.teamlambchop.com/comp1.htm
Creo que los chicos de la manzana tienen un problema con Motorola…
-
Y no se os a ocurrido pensar que usa un cliente de seti "hackeado"? hace algun tiempo hubo bastante lio con eso por que las unidades las procesaba cagando leches pero sin ninguna utilidad para el proyecto….no se tal vez sea el caso, lo cierto es que ningun cojopc es capaz de procesar en el tiempo de correcaminos una uw....sino mirad lo que tarda vuestros equipos y la frecuencia a la que estan trabajando...yo tengo un xp a 1941 reales y me tarda 3 horas y poco a veces 2 y mucho....cuanto tendra el correcaminos ¿mas del doble de mi maquina? no lo creo...por mucho overclock que tenga no creo que haya un micro que pueda llegar a eso ni usando una vapochill....
si usamos clientes hackeados seguro que en dos semanas subimos hasta el top 5 del ranking mundial....pero no sirve de nada
-
Pero como han dicho por ahi Darkside, puede ser que no tenga un pc normal, tal vez trabaje en alguna empresa con sistemas alpha o algo por el estilo, ahi ya no solo dependen de la frecuencia del micro sino de las MFLOPS y demas.
-
ya se que el powerPC más rapido va a 1.2 … lo que comentaba es que en el Photoshop los tiempos no son tan dispares ...
El mac con 1.2 rinde tanto, o mejor, que un PIV a 2.4 ... y es la mitad de frecuencia ...
De ahi que yo sea un fan tan descarado de la Optimización de programas para procesadores especificos ...
Cosa que NUNCA haran los señores de MicroChoff ... que el Windows este hecho generico para codigo 386 ... es deprimente
Ahora , nos cojemos un PC con un PIV, memoria Rambus y todo eso y gana al mac en el Photoshop ... pero es que si no lo hace se demostraría que es un procesador malo ... pero muchos MHz, que es lo que defiende Windos-Intel ...
VIVA LA OPTIMIZACION
Siempre Aprendiendo
www.namiga.es
-
Sinceramente no se de que os extrañáis, si vais a esta página
http://pages.tca.net/roelof/setispy/ veréis que un simple K6-2 a 9GHz con memoria PC100 lo haría en esos tiempos, incluso menos
Saludos
Lister -
He estado mirando en http://www.teamlambchop.com y he visto que un procesador Alpha 21264A a 667Mhz hace las unidades en 2:27… Con el cliente 3.0, con el cliente 3.03 no hay nadie tan rápido... Pero me imagino que los datos serán parecidos.
Teniendo en cuenta que los últimos Alpha corren a 1,25Mhz es posible que estos hagan las unidades a 1:30... ¿no?
He mirado y hay configuraciones de hasta 32 Alphas de estos... La bomba...
Si mirais bien por la web, vereis que hay procesadores que hacían las unidades mucho más rápido con el cliente 2 y el cliente 1... Por lo que dice la web, parece ser que las unidades no tienen el mismo tamaño ahora que hace un tiempo, de hecho para hacer el benchmark tienes que hacerlo con una unidad que tienen ellos, (dicen que no todas las unidades son iguales). Osea, que las unidades se han ido agrandando en función del progreso de los ordenadores (esto si que no lo sabía)...
Uf. Mas dudas.
-
De la version 2.70 a la 3.0 se doblo aproximadamente el tiempo de proceso.
El principal problema es que el SETI consumia el 30% del ancho de banda de Berkley, y claro eso era mucho… el cambio de la 2.7 a la 3.0 se hizo cuando los Athlon entorno a 1Ghz empezaban a generalizarse y las unidades tardaban menos de 4h.
Por eso y como ya comento Namiga, todo hace indicar que en breve sacaran una nueva versión del cliente, que duplicará el tiempo de proceso como minimo... espero que realmente se deba al aumento de cálculos realizados sobre la unidad y no a un "sleep" metido a pelo en el código por eso aprovechar ahora a quemar unidades que en breve volveremos a las 8-10h por cada una de ellas.
Saludos
Lister
