[ot] procesador para servidor

[Rodrigo Fuentealba]

felix perez wrote:
> 2006/5/11, Rodrigo Fuentealba <darkprox en gmail.com>:
>> felix perez wrote:
>> [...]
>> >> Debian sarge instalado desde cero, sin entorno grafico, robusto y
>> >> estable.
>> >> Ubuntu server (basado en Debian) tambien sin entorno, muy similar a
>> >> Debian.
>> Me da lo mismo, prefiero Slackware... Mi respuesta en este caso se basa
>> en el soporte que el kernel da. Tampoco tengo ninguna intención de armar
>> una nueva guerra santa, sobretodo sobre algo que es OT
>
> De ninguna manera, me gusta preguntar y aprender.
;) por lo demás, a mí también.

>> >> >
>> >> > Ahora, mi recomendación es la siguiente: Si utilizas bases de
>> >> datos, la
>> >> > información debe mantenerse guardada de manera precisa, pero si
>> >> utilizas un
>> >> > servidor web, no importa cómo esté la información en el disco, son
>> >> sólo
>> >> > archivos secuenciales que se interpretan en el caso de PHP y se
>> >> envían por
>> >> > el cable, ordenados.
>> >> Esto no tiene sentido, las bases de datos todas deben "guardarse" de
>> >> manera precisa al igual que cualquier archivo almacenado en un
>> >> servidor.  Un servidor web procesa archivos en texto plano (html,
>> >> javascript, php, etc) eso es lo que procesa si el archivo tiene algun
>> >> problema no se procesa correctamente y la aplicación se cae.
>> A ver... vamos por punto para aclarar mejor:
>>
>> - Para guardar datos, no hay gracia: los estándares están para que todos
>> los datos se guarden igual, a la velocidad que permita el cablecito de
>> 40-1 conectado al disco IDE (o el de SCSI, SATA, USB, Firewire, etc...).
>>
>> - Un servidor web procesa archivos de texto plano, como el javascript y
>> el html (salvo excepciones como PHP en las que se ejecuta un binario que
>> redirige la salida a la salida de Apache), que más encima son
>> secuenciales (vuelvo a repetir: salvo en el caso de PHP que hace un
>> índice de las clases, y no importa el orden en que éstas se definen) y
>> de sólo lectura para quien lo visita (y si fueran de escritura,
>> pasaríamos hackeando sitios web, ¿no?). Por tanto, si son archivos
>> planos, secuenciales y de sólo lectura, no me interesa la concurrencia,
>> me interesa hacerles un sólo proceso: enviar por el cable.
>>
>> Aún cuando sí se hagan operaciones sobre archivos de texto plano, éstas
>> casi nunca son operaciones matemáticas, sino movimientos de información
>> dentro de la memoria (cuando pones echo($_SESSION['valor']); lo único
>> que hace el PHP internamente es copiar el valor de $_SESSION['valor']
>> dentro de la salida que mostrará) y las que sí lo son, son comparaciones
>> (nada más fácil para un procesador que utilizar un campo booleano
>> conforme se verifica cada uno de los bits que comprenden las dos
>> variables que comparamos: el caso de preg_match(), por ejemplo), y muy
>> pocas operaciones de coma flotante.
>>
>> En el caso de las bases de datos, esto cambia: Primero, existe un
>> esquema de perfiles reales, y no construidos como los de las páginas
>> web. Segundo, los archivos no son secuenciales, de sólo lectura para
>> todos los usuarios externos, sino que son archivos de lectura y
>> escritura, para los usuarios que tengan permiso para leer y escribir. En
>> este caso, las operaciones de movimiento de información son más, pero
>> también lo son, con mucho, las operaciones matemáticas de comparación,
>> validación, producto cruzado, en el que si quieres optimizar, debes
>> aprovechar al 100% la coma flotante. Aquí, más que la rapidez está la
>> precisión del control de concurrencia, el manejo de la memoria no para
>> entregar datos, sino para hacer pequeñas operaciones de coma flotante
>> entre ellos.
>> > nota: javascript es del lado del cliente.
>> Y HTML también, y nadie te ha dicho nada.
> Quise precisar.
OK :) la cosa es que se entendía.
>> >> > Para las bases de datos (sobretodo con Oracle y PostgreSQL) 
>> siempre es
>> >> > recomendable un Intel por sobre un AMD pues si bien no es más
>> >> rápido, sí es
>> >> > más preciso. Para los servidores web, la información no debe ser
>> >> manejada de
>> >> > manera tan precisa, pero se requiere mover toneladas de
>> >> información... para
>> >> > eso un AMD es mejor.
>> >> En que te basas para decir esto?
>> Me baso en varios puntos, que para mí son demasiado coincidentes como
>> para ser mentira.
>>
>> ¿Personas que trabajan con AutoCAD y Mechanical Desktop? Precisión: 
>> Intel.
>> ¿...DIseño Web? Rapidez: AMD.
>> ¿...MatLab? Precisión: Intel.
>> ¿...Juegos? Rapidez: AMD.
>> ¿...Edición de Vídeo? Precisión: Intel.
>> ¿...Servidores Web? Rapidez:  AMD.
>> ¿...Servidores de Bases de Datos? Precisión: Intel.
>> ¿...Aplicaciones de Multimedia? Rapidez: AMD.
>> ¿...Interfaces industriales críticas (Léase NI LabView y otros)?
>> Precisión: Intel.
> No se,  creo que esta es una apreciación mas bien personal de acuerdo
> a tu experencia.  Si es asi conozoco una empresa de proyectos de
> ingenieria, con autocad, mathlab y demases y ocupan solo AMD no me
> atrevería a generalizar.
A las velocidades de hoy en día, claro que no se va a notar la 
diferencia en desempeño, es imperceptible al ojo humano, salvo en 
condiciones de estrés, en las cuales AMD se comporta mejor moviendo 
datos (las tareas más comunes) que en estrés matemático (las menos, al 
menos en el área web).
>> >> > Ahora es tu decisión, yo no soy ningún experto tampoco :P
>> >> Mayor razon para no hacer comentarios como el del parrafo anterior.
> No eres experto y has dado una pequeña clase. :-)
Pues sí, la verdad me gusta mucho el tema, y como arquitecto de 
sistemas, debo saber de todo. Solía estudiar las especificaciones de los 
procesadores, y hace poco me llegaron las de Turion y Core 2 Duo (el 
nuevo chiche de Intel)
>> ¿Y a ti quién te hizo el ramo de Sistemas Operativos? ¿Y te aprobó?
> No lo hice, llevo 20 años trabajando en esto :-)
Pues, entonces ya existía el Windows, yo hace 20 años todavía no sabía 
leer :S
>> Bien... Pues debo decirte que el que sean clones no significa que
>> implementan las mismas funciones de la misma forma,
>
> Completamente de acuerdo, ejemplo 3dnow para AMD y mmx para intel.
OK, lo explicaré en PHP:

class x86
{
funcion1();
funcion2();
}

class mmx extends x86
{
funcionmmx1();
funcionmmx2();
}

class 3dnow extends x86
{
funcion3dnow1();
funcion3dnow2();
}

me referia a la implementacion propia de las funciones de la 
arquitectura x86, que no se implementan igual en ambos procesadores.
>> <?php function sumar($a,$b) { return ($a+$b); } ?> contra <?php function
>> sumar($a,$b) { $c = $a + $b; return $c } ?>. Ambas funciones hacen lo
>> mismo, pero de distinta forma. Aparte, los juegos de funciones
>> específicas de AMD son para rapidez y los juegos de funciones
>> específicas para Intel son para precisión. Basta ver que el Sempron
>> Mobile 3000+ anda a 1800 y el Pentium 4 de 3.0 anda a 3 GHz, pero hacen
>> lo mismo... ¿será porque AMD está retrasado en cuanto a crear
>> procesadores de alta velocidad real, pero lo compensa con funciones
>> reducidas que permiten que con menor velocidad se pueda hacer gran
>> cantidad de movimientos de datos? ¿O es porque Intel es tan malo
>> desarrollando algoritmos rápidos y óptimos, que aumenta las frecuencias
>> de sus procesadores para tapar el que sean tan lentos?
>
> Es probable, recuerda lo que paso con el prescott con socket 478?,
> freias un huevo cuando se le aplicaba carga. Acabo de ver un P4 de 3,2
> a 95 grados.
Sí, pero eso no es generalizado para el comportamiento de Intel y ya, 
afortunadamente para los que somos usuarios de AMD también está dejando 
de serlo aquí.
>> >> Tanto Intel como AMD son opciones parejas (mayor performance en un
>> >> amd),
>> ¿Y después que me rebates todo lo que yo puse en el correo, afirmas lo
>> que yo digo? Ohhh el borrachito porfiado este ohhh... :P Claro que Intel
>> y AMD son opciones parejas, lo que uno tiene de rápido, el otro lo tiene
>> de preciso (a nivel de funciones de procesador... si hablamos de MHz,
>> los papeles se invierten e Intel es más rápido que AMD)
>
> He visto muchos benchmarks en la red y todavia no veo un predominio de
> intel sobre AMD en cuanto a velocidad, a nivel de funciones de
> procesador debo confesar que no me manejo mucho con el tema.
Intel es más rápido que AMD en velocidad real, por decirle así. Digamos 
que Intel da 300 vueltas donde AMD da 180 vueltas. Pero las funciones 
implementadas por Intel (arquitectura x86) son mucho más complejas que 
las de AMD (x86 traducido a RISC) por lo que demoran más en iniciar, y 
hacen algunos chequeos sobre la memoria. Esto es transparente al que usa 
el sistema. Los benchmarks miden por lo general el rendimiento con 
movimientos de datos, lo cual siempre indicará que AMD es mas rapido y 
de mejor desempeño...
>> precisamente esa la razón por la cual hay que saber escoger con pinzas
>> qué máquina destinar para qué cosa. Basta ver la ecuación
>>
>> lento + funciones de procesador optimizadas para rapidez = rápido +
>> funciones de procesador optimizadas para precisión (sacrificando 
>> rapidez).
>>
>> Y comprobar que no es cierta pero que las diferencias entre ambos lados
>> de la misma no pasan del 3% al 6%.
>> >> pero debes considerar otras cosas, T madre, T red, discos duros,
>> >> cantidad de Ram?, uso del servidor?, cantidad de usuarios?.
>> La tarjeta madre también es importante, pero debo comunicarte que el
>> chipset de ésta no es más que una extensión de las funciones del
>> procesador, por lo que las reglas dictadas para los procesadores también
>> se aplican a los chipsets.
>>
>> Pasando a risas, ¿las tarjetas de red no son estándares? ¿O sea que usas
>> una marca para Intel y otra distinta para AMD? Tengo una tarjeta de red
>> Realtek 8139C en mi Pentium 3 de oficina, y tengo el mismo modelo en el
>> notebook que es un Sempron 3000+ Mobile... Bueno, es un notebook, no le
>> puedo sacar la tarjeta para hacer las pruebas (ni es mi interés
>> investigar cosas que se dan por sentado que son así).
> No me refería a T de red para un procesador u otro, me refería a que
> debes ver la velocidad de la tarjeta (10/100, 10/100/1000, etc), otro
> punto es la marca y calidad de tarjetas, he visto algunas hasta sin
> marca y creeme que las pones y la red se arrastra.
> Tambien muy importante  es la calidad del tendido de cables, ruido
> electrico, y otras interferencias.
>
Ahhh, habia entendido otra cosa...
>>
>> Hablando en serio: la cantidad y la calidad de la RAM son
>> importantísimas... también su velocidad...
> gran punto.
kingston no más... lo mejorcito
>> Hablando de manera crítica: ¿volviste a considerar lo que puse arriba?
>> ¿Un servidor se puede usar para bases de datos o para servidor web?
>> ¿cierto que sí?... Entonces sí estaba considerando el uso del servidor
>> (o te refieres a la carga que tendrá el servidor?
> No son lo mismo pero una afecta a la otra.
Depende, la carga del servidor afecta uniformemente al procesador, por 
lo que no cuenta mucho el uso del servidor, sino que la constancia con 
el que este servidor se usa. Definamos uso como destinación: "este está 
destinado a servir databases". y constancia de uso (o trabajo) "este 
server debe soportar las consultas de 7000 usuarios".
>> porque hasta donde yo
>> sé, no son lo mismo). Sobre la cantidad de usuarios, pues ahí mi socio
>> verá, pero nunca es malo considerar optimizar.
> Como el cualquier área.
Claro, mis recomendaciones tienen un cierto estudio anterior, tampoco 
fue por disparar algo al aire y ojalá que se lo trague. No señor, no es 
esa la idea. Por cierto, gracias por las críticas, pues me permitieron 
poner en el tapete algunas consideraciones para su discusión.
>> Y como dijo Patrick Volkerding (Slackware maintainer),
>>
>> All the best, and don't forget to keep breathing.
>>
>> Rodrigo.
salu2