On Tue, Feb 25, 2003 at 09:03:03PM -0600, Victor Perez wrote: > > Ya que estamos tan complacientes, �ser�a posible que entienda lo > > que est� cortando y pegando? > > Bueno si no sabes si yo entiendo o no, talvez esta informacion te > pueda ayudar. Al frente de la Pops de San Pedro que queda cerca del > Mall San Pedro hay un centro de estudios universitarios. Este tiene > un centro administrativo de 4 pisos creo yo. En alguna de las > oficinas podes preguntar por el folio 2148-02. Titulitis... lo �nico que hac�a falta. Lo siento, realmente no me importa cu�ntos t�tulos con su nombre pueda presentar. Lo que me resulta relevante es que est� a todas luces cortando y pegando informaci�n, y de camino la est� "resumiendo". Comienza con un art�culo razonablemente bien escrito y lo convierte en algo donde la mitad de la informaci�n falta, cambiando de paso el sentido del texto. Eso a mi me dice que no entiende lo que est� cortando y pegando.
> Ademas por lo visto usted hace lo mismo, o me equivoco? �D�nde perd�n? > Porque si me equivoco, me imagino que vos producis investigacion ya > sea en [alg�n] centro universitario del mundo. Porque sino, > recuerde, nadie es buen profeta en su propia tienda. Esto est� totalmente fuera de tema, pero d�jeme entender lo que dice ah�: �si tengo un t�tulo y trabajo en una Universidad ... entonces puedo ir a predicarle a la congregaci�n sobre las bondades de aquello que ellos favorecen? �Y si no no? Honestamente no s� que est� tratando de decir. > > Uhm... Java tiene tantos o m�s problemas corriendo bajo Solaris > > como corriendo bajo Linux. Java corre m�s r�pido bajo Windows, y > > en Windows un cambio de contexto dura 10 veces m�s que en Linux. > > Supongo yo entonces que el problema con Java viene de otra parte. > > Un parentesis, alguien menciono Windows? Yo sinceramente hasta ahora > lo oigo. Por favor limitemonos al tema original y no hagamos un arroz > con mango. Ademas la referencia es muy clara al establecer el > conflicto que tiene linux con los lenguajes altamente orientado a los > hilos. A ver... la premisa seg�n entend� es que Java en Linux apesta como lo hace porque Java gusta de trabajar con unas cu�ntas docenas de threads, y dado que los threads en Linux son, para fines de esta discusi�n, procesos comunes y corrientes, entonces hay una cierta sobrecarga que conduce al tipo de rendimiento observado. Yo le estoy diciendo que un cambio de contexto en Linux es diez veces m�s r�pido que la misma operaci�n en Windows NT. A�n as�, Java es m�s r�pido en Windows que en Linux. Eso a mi me dice que el problema no est� en la forma de implementar threads, sino en la implementaci�n de Java. �Y c�mo se si estoy sobre la pista correcta? Simplemente cambio la implementaci�n de Java que uso en Linux. Y bingo... de pronto Java se comienza a comportar mejor. Lo cual me lleva directamente a: > > Nota para los espectadores: "muchos" == "orden de magnitud: 100 mil" > > Mejor seamos mucho mas especificos. Ya que hablamos de orden, mejor > digamos que el rendimiento esta dado por: O(n), n [...] numeros de > procesos ocupados. [...] La demostracion la puede encontrar en casi > todos los libros de estructura de datos. �La demostraci�n de qu� perd�n? �Del "gran impacto de desempe�o de [el kernel de Linux] si hay muchos procesos ejecut�ndose"? Lo �nico que Vd. est� diciendo es que la b�squeda exhaustiva es un algoritmo que depende linealmente del n�mero de objetos en una lista. Agua tibia. El algoritmo que usa(ba) Linux es O(n), s�. La constante de la que estamos hablando aqu� es tan peque�a, que en cualquier m�quina razonablemente moderna, eso comienza a ser relevante cuando n se acerca a 10^5. Para n por debajo de 10^4, es una discusi�n enteramente correcta y puramente acad�mica -- que es la raz�n por la que ese algoritmo vivi� tanto tiempo en el kernel :-P Hay parches bastante conocidos para 2.4 que convierten eso en O(1). Comparar O(n) y O(1) en diversas situaciones queda como ejercicio para el lector. Y de vuelta a Java... cualquiera que quiera usar Java en un contexto donde esta constante se hace significativa, deber�a considerar buscar trabajo en otra �rea. > > Aparte de eso, si es correcto. Fue resuelto en... �setiembre > > pasado? Hasta donde me da la memoria, hay un parche para el 2.4 > > -- tal vez en la p�gina de Ingo. > > Fue resuelto? En parte si en parte no, como usted lo dice: hay un > parche. Dicho parche est� incluido por defecto en m�s de una distribuci�n y cualquiera para el que el parche sea de importancia, sabe que el parche existe o es capaz de encontrarlo. �Est� el parche inclu�do en el 2.4.20? No. �Importa? IMO, no. �Si parcho el kernel, va a prender fuego mi m�quina? Poco probable. �Si el parche funciona, por qu� no est� inclu�do? Porque estamos hablando de 2.*4*.x, �no? Hay una cantidad considerable de parches para el 2.4.x que tienen que ver la eficiencia del scheduler, latencia, I/O y no s� que otro tanto de cosas, y ninguno de esos ser� inclu�do en un 2.4.x. Esa es la forma en la que el desarrollo del kernel estable funciona. > Lamentablemente estamos callendo en la misma situacion que > Microsoft(ya que usted lo trajo al tema). Bah. > Seria importante que usted le mencionara a los presentes el problema > de estar parchando cualquier software Presiento que Vd. nos va a iluminar al respecto... > me imagino que usted ya leyo algo al respecto en slashdot.com No leo slashdot as� que no tengo idea de que me est� hablando. > No solo eso, sino que se sacaron de la manga la funcion clone(). Ah... comienzo a ver cual es su problema. �Qu� *exactamente* tiene de malo clone(2)? El kernel tiene que exportar _algo_ que permita la duplicaci�n de procesos (o creaci�n de LWPs o lo que sea que necesita para implementar threads de POSIX). En Linux eso es clone(2). En otros kernels se llama diferente. Gran cosa. Es una interface limpia. Es _tan_ limpia, que dentro del kernel fork(2) es simplemente una llamada a la implementaci�n de clone(2) con algo de limpieza y contabilidad alrededor. En tanto exista pthread_create(3) y que funcione de acuerdo con SUSv2... > Claro como vos mismo decis, la falta de siguimiento de los estandares > ha hecho que este problema haya sido muy dificil de corregir. A ver... yo dije que el problema en Linux est� en que no implementa el �ltimo punto y la �ltima coma del est�ndar. En particular, �qu� pasa cuando ocurre una llamada a fork(2) en un thread? �y qu� pasa cuando ese nuevo proceso llama exec(2)? �Cu�l es el pid de un thread? si tengo un �nico pid, �c�mo hago para mandar se�ales a un thread? �qu� hago con ptrace(2)? �c�mo se maneja la entrega de se�ales de una forma eficiente y que est� de acuerdo con el est�ndard? En particular, �qu� quiere decir entregar una se�al a un programa con threads? �se maneja SIGSTOP de la misma forma que SIGPIPE? A otra gente le preocupa un problema m�s mundano: la salida de ps(3) se ve fea. Curiosamente hace unos d�as alguien propuso una soluci�n para eso exactamente. Dicho eso, no tengo idea de a qu� problema particular se est� refiriendo. La falta de seguimiento de _el_ est�ndard ha sido conciente e intencional. El est�ndar est� implementado hasta donde es sano implementar el est�ndar y de una forma en la que no se perjudica la portabilidad. A quien le preocupe extraordinariamente la portabilidad en esta �rea, puede recurrir a la biblioteca de threads de Mozilla o Apache. > Ademas la terquedad de algunos desarrolladores de Linux que prefieren > un codigo ultra eficiente(el cual obviamente no lo es porque vos > mismo me decis que lo cambiaron) ha hecho que la solucion se haya > pospuesto por tanto tiempo. El problema del c�digo actual no est� en la eficiencia -- lo que el c�digo actual hace, lo hace eficientemente. El problema est� en lo que el c�digo no hace. El c�digo ha sido cambiado para que lo que ya es eficiente, siga siendo eficiente, y lo que no hace ahora, lo pueda hacer eficientemente. De rebote, el c�digo es a�n m�s eficiente que antes :-) Marcelo -- Desuscripci�n: escriba a [EMAIL PROTECTED], tema 'unsubscribe' Problemas a: [EMAIL PROTECTED] http://www.linux.or.cr/listas
