Programar en Linux

[Horst H. von Brand]

Germán Poó Caamaño <gpoo en ubiobio.cl> wrote:
> On Mon, 2006-10-23 at 14:00 -0300, Horst H. von Brand wrote:
> > Juan Martínez <jeugenio en umcervantes.cl> wrote:
> > [...]
> > > Un lenguaje compilado, en general, siempre (o casi siempre) sera la
> > > mejor alternativa a usar.
> > [...]
> > >                           Sobre todo si es para un sistema complejo
> > > (un SIA por ejemplo), dado que será mas rapido que un lenguaje
> > > interpretado.
> > 
> > Lo cual es totalmente irrelevante. Que el SIA se demore 0,5s o 0,01s en
> > responder, si el perejil en la pagina web al otro lado de Chile luego pasa
> > 5s pensando que hacer a continuacion no hace particular diferencia. Si, si
> > tienes decenas de miles de usuarios simultaneos es vital, pero eso se da
> > solo cuando muestran los resultados de las elecciones ;-)

> > [Si, /hay/ casos en los cuales el rendimiento realmente es crucial, pero
> >  son muchisisimos menos de lo que uno cree. Ve y mira la carga en tu
> >  "servidor" vecino, rara vez pasa del 40% en mi experiencia, tipicamente
> >  mucho menos...]

> Esa postura, que si bien comparto en parte, es peligrosa.  Sobre todo en
> manos inexpertas que pueden creerte a ojos cerrado todo lo que dices.

Tienes razon con eso tambien...

> Bajo esa lógica, hay muchos /ingenieros de software/ que los problemas
> de rendimiento se lo achacan a la máquina, al sistema operativo, al
> motor de base de datos o a lo "complejo del sistema".  Jamás al mal
> diseño de sus algoritmos o de la lógica retorcida de sus propios
> programas.

Si, /vivamente/ recuerdo un caso de una generacion de listados que se
demoraba horas (literalmente!), y eso /despues/ de multiplicar por 4 la
maquina seguia en las mismas; una reestructuracion de las consultas a la BD
bajo eso a cosa de un minuto. Tiempo invertido: Una media tarde...

[...]

> Eso escapa al lenguaje, escapa incluso si es compilado o interpretado.
> Y aunque las HH sean más caras, cuando esas HH te exigen aumentar el
> HW una vez al año a una potencia 4 veces mayor... 

Lamentablemente no hay ley de Moore para las HH... mas bien parece que lo
contrario :-(


El punto final de "mejorar rendimiento" es:

- Es suficiente? Si es asi, OK. Salir a carretear... [Mejorar rendimiento
  si ya es suficiente no tiene particular chiste...]
- No es suficiente? Estudiar el problema, /a todo lo ancho/: Considerar mas
  maquina, cambio de lenguaje, distribuir datos entre varios discos, ... La
  experiencia muestra que /lejos/ lo que mas influye es eleccion cuidadosa
  de los algoritmos y estructuras de datos (representaciones). Lo que se
  puede ganar por otras vias suele ser mas bien menor (aunque un factor de
  2 tampoco es despreciable, pero no es trivial de conseguir en ninguna de
  las areas...). Ver donde se obtiene el maximo aumento con minimo costo
  [Si, hay que sentarse a /medir/ donde se va el tiempo/memoria/lo que
  falte!], mejorar eso.
- Enjuagar, repetir.

Ojo, las mediciones hay que hacerlas con "datos reales", los "casos de
prueba" /no/ sirven, porque precisamente estan cocinados para revisar
detalladamente (incluso) lo que pasa en situaciones anomalas e
infrecuentes, mientras nos interesa un rabano el funcionamiento en casos
extraordinarios, aca nos interesan las situaciones tipicas.

[Se ve que en ninguna parte dice "la solucion es un lenguaje compilado"? Se
 ve que no hay una unica solucion al problema, cierto?]
[[Si, toda esa challa que les ensen~an /es/ importante. Desde la
  organizacion general del sistema (via monitos varios) hasta llegar a su
  implementacion en programas.]]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513