POO vs PE

Depende. Hay muchos lenguajes orientados a objetos y muchos procedurales. El hecho de escribir código en un lenguaje que no tiene orientación a objetos no se traduce en mayor rendimiento per se.

Yo no creo que en la práctica se note la diferencia de rendimiento, si es que la hay... Pero a mi me es más fácil entener la PE que la POO... No sé, debo ser un bicho raro.

En cualquier caso sería cuestión de con un debugger hacer pruebas de un programa programado con objetos y el mismo de forma estructurada... Aunque creo que hay tantas variables, y que la diferencia será mínima.

un saludo

La diferencia no está en el lenguaje sino en el compilador.

Yo opino que siempre es mejor tirar hacia la POO. Si el programa es pequeño, la diferencia de rendimiento sería impercitible, si el programa es grande, la escalabilidad y facilidad de la orientación a objetos compensa la mínima diferencia de rendimiento.

Lo que realmente determina el rendimiento del programa es el lenguaje y compilador usado, así como la optimización del mismo.

Es evidente que un programa en C++ con QT va a ir mucho mejor que un Java con Swing...

Tambien depende de que quieras hacer. Hay cosas que son claramente más sencillas con PE que con POO y dan mucho mejor rendimiento. Todo depende del tipo de programa.

lovechii5 escribió:Tambien depende de que quieras hacer. Hay cosas que son claramente más sencillas con PE que con POO y dan mucho mejor rendimiento. Todo depende del tipo de programa.

Simple y llanamente

Guantanamera escribió:Yo no creo que en la práctica se note la diferencia de rendimiento, si es que la hay... Pero a mi me es más fácil entener la PE que la POO... No sé, debo ser un bicho raro.

Tranquilo no eres el unico (ays como añoro "C" xD).

Por otra parte todo depende del lenguaje no de lal sintaxis o si es Prog Estructural/Orientada a Objetos sino mas bien depende de si el lenguaje es interpretado, semi-interpretado, totalmente compilado, el compilador....

Es decir... No es lo mismo correr un codigo python o javascript que algo ya compilado como C, C++...

Tampoco es lo mismo algo semi-interpretado, es decir codigo en bytecode y luego pasado por una maquina virtual interpretadora, vease "Java", "Dalvik", "Mono" y ".Net"

Y ya por ultimo en caso de codigo compilado vs codigo compilado (ambos nativos) no es lo mismo un compilador que otro .

Asi que intervienen muchas cosas como estas viendo....

El nivel de Menor rendimiento a mas rendimiento teoricamente seria este:
Intepretado (Javascript, Python....)
ByteCode (Java, JSP/JSF, .Net, Mono...)
Compilados NATIVOS.

Hago incapie en lo de nativos en los compilados con eso me refiero compilado para tu arquitectura no cojer un binario cualquiera y decir ostras pues va... pero alomejor tienes un am64 y esta hecho para un intel32, ir te va a ir pero poco rendimiento le vas a sacar... Y mucho menos si es une ejecutable simulando las apis (wine).

Hay que notar que como no siempre puedes acceder a un binario compilado en tu maquina para tu arquitectura exacta, sino binarios ya precompilados, aveces por culpa de esos los programas en Bytecode llegan a sacar rendimiento igual o superior.

No es por joder... pero lo más determinante son los algoritmos y las estructuras de datos. No los lenguajes, paradigmas, compiladores; que son solo las herramientas.

Os estais perdiendo el bosque de tanto mirar las hojas que caen de ese árbol.

HTH, HAND.

Ferdy escribió:No es por joder... pero lo más determinante son los algoritmos y las estructuras de datos. No los lenguajes, paradigmas, compiladores; que son solo las herramientas.

Os estais perdiendo el bosque de tanto mirar las hojas que caen de ese árbol.

HTH, HAND.

+1 La PE y POO son paradigmas para diseñar tu programa. Dependiendo del caso eliges el paradigma que más te facilite la vida. El rendimiento dependerá de que tan bien hecho sea tu algoritmo, que se el diseño sea bueno y optimizado. Después vendrá todo lo demás, al final de cuentas si sabes diseñar en papel tu programa será bueno independientemente del lenguaje o de si usaste PE POO.

ok me queda claro, todo depende de la arquitectura sobre la que correo tu programa y no del paradigma elegido, gracias a todos por su ayuda.

saludos.

En los lenguajes en los que hay orientación a objeto como PHP, Python, etc... Sí hay diferencia de rendimiento.

Échale un ojo: http://hentenaar.com/serendipity/index. ... -Ruby.html

Las conclusiones aclaran algunas cosillas (hello world no es el tipo de aplicación para la que se usa POO, entre otras aclaraciones), y también mencionan que lo que más lastrará a un programa es un mal estilo de programación. Mala estructura de clases, no entender bien el funcionamiento de la POO, usar mal las herramientas del lenguaje, malas prácticas... Todo eso va sumando. Una linea lenta no hace lento a un programa, pero un programa mal hecho... Pues eso, mal hecho.

Por cierto, para los que no la entendéis, no sé si os servirá, pero hace tiempo escribí en mi blog tres artículos sobre la POO, de nivel muy, muy básico. Por si os ayuda en algo: http://omega2093.wordpress.com/2011/01/ ... a-objetos/ ese es el primero de tres, echadle un ojo más bien a los dos últimos.

oMega_2093 escribió:En los lenguajes en los que hay orientación a objeto como PHP, Python, etc... Sí hay diferencia de rendimiento.

Si quieres rendimiento en POO no usas un lenguaje interpretado como los que dices, usas C++. Cualquier algoritmo que uses que no esté bien optimizado te va a penalizar mucho más que el hecho de usar o no POO. Por mi parte a estas alturas me cuesta pensar en proyectos grandes que no estén orientados a objetos, deformación profesional supongo...

tMK escribió:

oMega_2093 escribió:En los lenguajes en los que hay orientación a objeto como PHP, Python, etc... Sí hay diferencia de rendimiento.

Si quieres rendimiento en POO no usas un lenguaje interpretado como los que dices, usas C++. Cualquier algoritmo que uses que no esté bien optimizado te va a penalizar mucho más que el hecho de usar o no POO. Por mi parte a estas alturas me cuesta pensar en proyectos grandes que no estén orientados a objetos, deformación profesional supongo...

Yo lo dejaría en: "Si quieres rendimiento no usas un lenguaje interpretado". Pero esos lenguajes son para lo que son, claro, y se ve que POO sí penaliza. Es absurdo pero está ahí.

Claro que, la absurda diferencia no justifica perder las ventajas de POO

Yo lo dejaría en: "Si quieres rendimiento no usas un lenguaje interpretado". Pero esos lenguajes son para lo que son, claro, y se ve que POO sí penaliza. Es absurdo pero está ahí.

Y estarías MUY equivocado.

No obstante, lo digo una vez más, más importante es un buen diseño y algoritmos que un paradigma. El paradigma solo es una de las muchas herramientas que hay que usar.

- ferdy

Ferdy escribió:

Yo lo dejaría en: "Si quieres rendimiento no usas un lenguaje interpretado". Pero esos lenguajes son para lo que son, claro, y se ve que POO sí penaliza. Es absurdo pero está ahí.

Y estarías MUY equivocado.

No obstante, lo digo una vez más, más importante es un buen diseño y algoritmos que un paradigma. El paradigma solo es una de las muchas herramientas que hay que usar.

- ferdy

Cada cosa para lo que es, un cañón no esta hecho para matar moscas, pero si para hundir barcos pero aun así es eficaz y sirve pero consume demasiado y es lento para lo que se necesita, y desde luego hundir barcos con un matamoscas..., es una tarea titanica .

A la hora de la verdad..., el que hace la diferencia es el programador que puede hacer todo tan rapido o lento como entre en sus posibilidades .

Ferdy escribió:

Yo lo dejaría en: "Si quieres rendimiento no usas un lenguaje interpretado". Pero esos lenguajes son para lo que son, claro, y se ve que POO sí penaliza. Es absurdo pero está ahí.

Y estarías MUY equivocado.

¿Y en qué me equivoco?

Me parece que no habéis leído mi otro mensaje, os habéis lanzado a decir que me equivoco, porque lo que estáis diciendo ya lo dije yo en el primer mensaje

asi es la verdad es que PHP me a estado decepcionando un poco ya que soy entusiasta de este lenguaje que me parece magnifico, el benchmark que por ahi mencionan ya lo habia visto, pero bueno supongo que no se le puede pedir a un lenguaje interpretado hacer lo que uno compilado, dependiendo el sapo es la pedrada.

ya estare metiendome a jsp para cosas mas rudas ya que segun su arquitectura me parece mas optimizado ya que no interpreta sino que semi compila lo cual a mi parecer no es tan optimo pero si mas que interpretar, de echo para sincerarme realmente soy detractor de como manejan las cosas en java, pero bueno todo sea por la "portabilidad" y no me queda de otra que acoplarme a la mayor cantidad posible de tecnologias.

Pues a mi en la carrera me han dicho que si existe diferencia entre ambos paradigmas, y esta reside principalmente en el principio de cercanía. Este principio de cercanía en el que tan ciegamente cree y se basa nuestro hardware. La orientación a objetos no lo "respeta" al pie de la letra, provocando un uso más ineficiente de los recursos: Fallo de página, voy al disco... ¿Qué marco escogo para eliminar de memoria principal en el peor de los casos?¿debo copiar alguna página de memoria principal a disco? Bueno y todo la teoría que podemos esconder detrás. Un ejemplo clásico de esto que os estoy comentado lo podéis encontrar en cualquier interfaz gráfica, donde la ejecución del modelo se entrelaza con la de la vista, y no precisamente en el orden secuencial de un lenguaje estructurado.


Ir al disco es un par de órdenes de magnitud más lento que ir a memoria principal y eso en las aplicaciones si que puede llegar a notarse. Sin embargo, estoy de acuerdo que para que este principio deje de cumplirse, la aplicación debe ser algo elaborada, y probablemente se noten más otros aspectos como los compiladores empleados, o el lenguaje de programación. Sin ir más lejos la anécdota de estos lenguajes orientados objetos venía acompañada de como la máquina virtual de java se demoraba bastante más en realizar unas operaciones no demasiado costosas sobre una gran cantidad de objetos, si en lugar de utilizar arrays (Object[]) se empleaba la clase ArrayList.

kek_500 escribió:Pues a mi en la carrera me han dicho que si existe diferencia entre ambos paradigmas, y esta reside principalmente en el principio de cercanía. Este principio de cercanía en el que tan ciegamente cree y se basa nuestro hardware. La orientación a objetos no lo "respeta" al pie de la letra, provocando un uso más ineficiente de los recursos: Fallo de página, voy al disco... ¿Qué marco escogo para eliminar de memoria principal en el peor de los casos?¿debo copiar alguna página de memoria principal a disco? Bueno y todo la teoría que podemos esconder detrás. Un ejemplo clásico de esto que os estoy comentado lo podéis encontrar en cualquier interfaz gráfica, donde la ejecución del modelo se entrelaza con la de la vista, y no precisamente en el orden secuencial de un lenguaje estructurado.


Ir al disco es un par de órdenes de magnitud más lento que ir a memoria principal y eso en las aplicaciones si que puede llegar a notarse. Sin embargo, estoy de acuerdo que para que este principio deje de cumplirse, la aplicación debe ser algo elaborada, y probablemente se noten más otros aspectos como los compiladores empleados, o el lenguaje de programación. Sin ir más lejos la anécdota de estos lenguajes orientados objetos venía acompañada de como la máquina virtual de java se demoraba bastante más en realizar unas operaciones no demasiado costosas sobre una gran cantidad de objetos, si en lugar de utilizar arrays (Object[]) se empleaba la clase ArrayList.

¿Que la POO no respeta el principio de localidad? ¿ein?

Si en la carrera te han dicho eso, te han engañado. Si lo has deducido tu, estás muy confundido.

Que una implementación respete más o menos el principio de localidad depende tanto del paradigma como de la fase de la luna.

- ferdy

No lo he deducido yo, es lo que el profesor nos ha explicado y como he dicho con matices.

¿Por qué ese debe ser una farsa? Ni siquiera me has dado un argumento que refute la idea que te he dicho. ¿Por qué debería aceptar tu idea y pensar que lo que me dice un profesor competente (para uno que tenemos) es mentira?

En un programa en C (como referente de PE) se suele decir que invertimos el 80% del tiempo en el 20% del código. Esto no me importa para nada, pero si está claro que el mayor tiempo se pasa ejecutando las mismas regiones de código.

¿En la programación orientada a objetos esto se cumple? Con matices insisto nuevamente. En el ejemplo de la interfaz gráfica, ¿qué es lo que se repite?¿dónde pasamos mayor cantidad del tiempo? Cuando se carga la misma efectivamente será como siempre, cuando esperamos que un evento ocurra ¿qué hay detrás? Cuando se dispare cargaremos la función manejadora para que esa función probablemente no nos vuelva a interesar. Ejemplo: En un menú el botón cargar tiene pocos usos, probablemente cuando se pulse no tengamos esa página en memoria, y no sólo nos traeremos la que necesitamos por el principio del que veníamos hablando.

Al igual que el ejemplo anterior: un asistente para iniciar un documento, o las clásicas sugerencias del día.

Y ferdi, si tienes algo más que añadir insisto que el argumento que proporciones sea más profundo que mi idea tiene lo mismo que ver que las fases lunares. Porque yo no se de todo. Por eso pregunto y aporto mi pequeño grano de arena.

No sé si alguien de aquí se dedica al desarrollo de aplicaciones y posterior mantenimiento, yo sí, antes a escala bastante grande y ahora más proyectos pequeños, pero os aseguro que os la va a pelar tres pitos que vuestra aplicación tarde un minuto de más en hacer algo a cambio de usar un buen diseño orientado a objetos, el mantenimiento de la aplicación una vez terminada es años luz más sencillo y no hablemos ya si al cliente le da por añadir nuevas funcionalidades no previstas en un principio (el cliente manda y vosotros pringais). Os aseguro que a largo plazo el tiempo invertido en el mantenimiento de una aplicación es mucho mayor que el tiempo empleado en el desarrollo inicial, así que mejor que os faciliteis la vida desde el principio, y si tarda un minuto entero en sacar una consulta compleja no se acaba el mundo.

tMK, no creo que te vaya a discutir nadie sobre lo que dices porque considero que es cierto.

Ahora, estábamos hablando de una hipotética diferencia de rendimiento al cambiar de paradigma y esa diferencia está ahí, dejando aparte el hecho de que merezca o no la pena considerarla, que coincido con que NO vale la pena.

Por otro lado, "Ferdy", has indicado en dos ocasiones que alguien se equivoca, que le han engañado o que no tiene claras las cosas. Podrías indicar por qué, por lo menos en mi caso, porque me quedo con la duda de si es que lo has hecho por tocar las pelotas o si había algo en lo que de verdad estaba equivocado, en cuyo caso me gustaría saberlo, para dejar de estar equivocado más que nada.

oMega_2093 escribió:tMK, no creo que te vaya a discutir nadie sobre lo que dices porque considero que es cierto.

Ahora, estábamos hablando de una hipotética diferencia de rendimiento al cambiar de paradigma y esa diferencia está ahí, dejando aparte el hecho de que merezca o no la pena considerarla, que coincido con que NO vale la pena.

Por otro lado, "Ferdy", has indicado en dos ocasiones que alguien se equivoca, que le han engañado o que no tiene claras las cosas. Podrías indicar por qué, por lo menos en mi caso, porque me quedo con la duda de si es que lo has hecho por tocar las pelotas o si había algo en lo que de verdad estaba equivocado, en cuyo caso me gustaría saberlo, para dejar de estar equivocado más que nada.

+1

También pensar que todo depende de que hagas. En mi caso hago cálculos que pueden durar varios días. Si se pueden ahorrar un día de los 8 que puede durar un calculo, pues mejor.

Me parece a mi que mas de uno confunde la programación orientada a objetos con programacion GUI, cosas no necesariamente relacionadas.

Ok, por partes.

Sobre lo que dice tMK, nada que objetar. Solo una puntualización: él asume que un buen diseño orientado a objetos es más lento. Yo digo justo lo contrario, un buen diseño (ya sea funcional, orientado a objetos, estructurado, ...) va a ser RÁPIDO. Es decir, la clave del buen diseño es que se puede mantener la aplicación fácilmente a la vez que la aplicación hace lo que debe en el tiempo que debe. En caso de que haya que sacrificar mantenimiento frente a rendimiento, dependerá mucho del tipo de proyecto.

Cuando dije que oMega_2093 estaba MUY equivocado es por esto: 'Si quieres rendimiento no usas un lenguaje interpretado'. Realmente no tiene mucho sentido la frase. Hay lenguajes interpretados como prolog o Erlang que pueden proporcionarte mucho rendimiento en ciertas tareas. Incluso los lenguajes que a veces se llaman semi-interpretados como Java utilizan técnicas de compilación Just-In-Time que pueden llegar a ofrecer rendimientos superiores a otras aplicaciones según qué casos.

Y sobre lo de kek_500: Realmente creo que estás confundiéndote mucho. Entiendo que te refieres al principio de localidad de la información relacionada con los conceptos de caché y memoria virtual. Bien, aquí hay dos cosas: datos y código. La parte de código es interesante que esté cerca pero, siendo prácticos, está todo muy cerca. El código de un software es interrumpido por el planificador para ejecutar otras tareas muchas veces por segundo así que esto no es un gran problema. La localidad de los datos es una cosa completamente distinta. Aquí si que es importante que los datos estén bien colocados; pero el cómo estén colocados no depende ni del paradigma ni, en principio, del lenguaje. Es todo, o casi todo, tarea del diseño/implementación.

Como veo que haces algunas preguntas, te voy a contestar a las que pueda:

En el ejemplo de la interfaz gráfica, ¿qué es lo que se repite?¿dónde pasamos mayor cantidad del tiempo?

Depende. Te voy a poner el caso de los dos programas que más conozco y que más frescos tengo. Los dos tienen un diseño OO y utilizan técnicas de programación genérica:

- El simulador: Pasa el 49% del tiempo ejecutando una función llamada 'step' (que hace unos cálculos), el 50% del tiempo escribiendo ficheros de texto y el resto es interacción con el usuario, render 3d, .... (< 1%).

- La estación de control: Se pasa >80% del tiempo esperando datos de un puerto serie. Más del 19% del tiempo representando esa información (pintando gráficas, actualizando un mapa, ...). El resto (< 0.5%) se lo pasa atendiendo las peticiones del usuario.

Cuando se carga la misma efectivamente será como siempre, cuando esperamos que un evento ocurra ¿qué hay detrás?

Hay algo como:



si no te convence, mírate el código de gtk_main(), en esencia, hace eso.

Cuando se dispare cargaremos la función manejadora para que esa función probablemente no nos vuelva a interesar.

Realmente la función se 'carga' en memoria en cuanto ejecutas la aplicación. (Bueno no, pero si.[1])
Y si no se vuelve a usar, pues ocupa lo que ocupe (poco) en memoria y listo.

Ejemplo: En un menú el botón cargar tiene pocos usos, probablemente cuando se pulse no tengamos esa página en memoria, y no sólo nos traeremos la que necesitamos por el principio del que veníamos hablando.

Cuando se pulse, lo normal es que SI tengamos esa página en memoria. Lo normal es que tengamos TODO el código de la aplicación en RAM.

Como puedes ver, NADA de lo que te he dicho está relacionado con el paradigma de programación o con el lenguaje utilizado... son temas ortogonales.

Espero que todo haya quedado más o menos claro... por supuesto puedo haber metido la pata hasta el corvejón, pero lo he revisado más o menos todo.

- ferdy

[1] - realmente no porque hay que resolver la dirección algunas funciones de librerías dinámicas. A efectos prácticos, en este caso, esto se puede despreciar.

Ferdy escribió:Y sobre lo de kek_500: Realmente creo que estás confundiéndote mucho. Entiendo que te refieres al principio de localidad de la información relacionada con los conceptos de caché y memoria virtual. Bien, aquí hay dos cosas: datos y código. La parte de código es interesante que esté cerca pero, siendo prácticos, está todo muy cerca. El código de un software es interrumpido por el planificador para ejecutar otras tareas muchas veces por segundo así que esto no es un gran problema. La localidad de los datos es una cosa completamente distinta. Aquí si que es importante que los datos estén bien colocados; pero el cómo estén colocados no depende ni del paradigma ni, en principio, del lenguaje. Es todo, o casi todo, tarea del diseño/implementación.

Como veo que haces algunas preguntas, te voy a contestar a las que pueda:

[...]

- ferdy

Lamento no haber podido contestar antes. Ya de vuelta a la rutina, vuelvo a dar la brasa. Primero un ejemplo concreto: el lenguaje de programación java.

Como bien mencionas los programas constan de una serie de segmentos. Me interesan principalmente dos: datos y código. Quién controla todo es el sistema operativo (aunque no entiendo muy bien a que venía la actuación del mismo en tu comentario...). Bien, ¿qué es lo que ve entonces el SO cuando ejecuta una aplicación de este tipo?

Java es un lenguaje en parte compilado (a bytecode), parte interpretado por la JVM. Para el SO, el código es la JVM y los datos nuestros propios programas. ¿Esto se encuentra relativamente cerca (los datos)? No. Si por ejemplo "almacenamos" una base de datos ( los índices que precisemos ), por poner un ejemplo distinto, ¿estará realmente cerca el punto de entrada de mi aplicación a estos datos?¿O a la siguiente rutina que queramos invocar? Pues probablemente no.

¿En C pueden ocurrir estas cosas? No puesto que diferenciamos entre datos y código.

Ahora antes de que me digáis nada, me diréis: "Java ha sido pensado para ser multiplataforma. Existe más orientación a objetos fuera, es un paradigma no un lenguaje concreto". Perfecto, entiendo esa preocupación. Pongamos un segundo caso C++, como referente de POO, compilado, con todas las características de estos lenguajes: polimorfismo, herencia múltiple, etc, aunque podéis escoger el que más os guste.

C++ efectivamente realiza esa distinción entre código y datos. Por un lado tenemos código, por otro los datos, y como bien apuntas ferdy el código está relativamente cerca. ¡OJO! Nadie nos asegura que todas las páginas estén en memoria. ¿Acaso sabemos cómo están implementados los SO's? De linux algo de información podemos tener pero del resto... Sin embargo, pensemos que todos ellos usan esa filosofía de "memoria no usada, memoria desperdiciada".

Mi aplicación en C++ probablemente tenga diversas clases que representen mi minimundo (con seguridad más que probablemente). Una llamada a una función, desencadenará en llamadas a otras clases distintas seguramente.

Un ejemplo sencillo, perdonad si no me he dignado en hacer un diagrama UML en condiciones, o no he representado las composiciones adecuadamente:
...........................Dibujo
...........................======
.........................+.void.dibujar();
....................../......................\...
..................../..........................\.............................................................
................../..............................\...........................................................
................/..................................\.........................................................
Figuras.Geométricas..................Título
.............^..................................======
..............|..................................-.String.texto;
..............|..................................-.int.TAMANO_FUENTE;
..............|..................................-.int.COLOR_FUENTE;
.................................................+.void.dibujar();
..........Círculo.....................................................Coordenada
..........====.................................................==========
.....-.int.radio;.....................................................-.int.x;
.....-.Coordenada.centro;...................................-.int.y;
....-----------------------------
.....+.void.dibujar();

Pensemos que operaciones realiza la función dibujar de la clase "Dibujo". Tenemos un objeto del tipo dibujo que consta de un círculo y de un título, e invoco a dibujar sobre la primera clase:

- Accedemos al objeto círculo. Dado que el objeto no se almacena en la propia clase dibujo, sino que únicamente tenemos un puntero, vamos a buscar nuestra instancia. ¡Aquí no tenemos certeza de que esté en memoria! Peor de los casos (y probable): Fallo de página. Si a lo que intentamos acceder son a variables estáticas de una clase, tendremos que cargar la información relativa a esa clase. Y en el peor de los casos si el código de esa clase no está cargado peor suerte aún. Tras estas operaciones a bajo nivel, ya estamos listos para ejecutar nuestro método.

Podemos proceder igual con el título.

¿Y si lo único que necesito es mi variable TAMANO_FUENTE porque decido ignorar el color? ¿No he tirado mi tiempo yendo a buscar información que no quería? Porque de estos campos no se realiza una copia en cada objeto, son comunes a todos las instancias y he necesitado cargar en memoria la página con la información de esa clase. Podríamos crear una copia de TAMANO_FUENTE en cada instancia, como solución chapucera. Pero, ¿qué ocurre si esa variable estática es la base de datos antes mencionada? Es inviable.

¿Qué ocurre en la programación estructurada? Evidentemente el problema de acceder a un dato que no tenemos en memoria puede ocurrir (queremos acceder al círculo). Pero todos esos fallos por acceder a los datos de una clase en particular no se producen. Nuevamente vuelvo al caso de mi interfaz gráfica pese a que algunos insistan en que puedo confundir cosas. Si tengo una ventana cualquiera, es bastante probable que tenga ciertas constantes definidas sobre como los objetos se distribuyen en pantalla. Si en un determinado momento debo repintar la memoria tengo que acceder a las clases involucradas en dicha acción (posibles botones, tablas, o widget en general), obtener los datos de sus respectivas clases, además de conseguir tales objetos.

No se si te habré convencido ferdy, la verdad creo que mi idea no te hacía demasiada gracia. Una última mención:

"Aquí si que es importante que los datos estén bien colocados; pero el cómo estén colocados no depende ni del paradigma ni, en principio, del lenguaje. Es todo, o casi todo, tarea del diseño/implementación."

El cómo estén colocados si que depende o más bien el qué se coloca, pues no estará en el mismo punto los datos de un objeto concreto, que el de la propia clase (que es un ente nuevo que aparece con la programación orientada a objetos). De hecho heurísticamente (y te diría que casi empíricamente) se puede comprobar que la pila de llamadas/accesos a clases en un lenguaje OO es mayor que la pila de llamadas a funciones en la programación estructurada. Hablando hoy en clase sobre este tema, me han dicho que hay investigaciones al respecto de este asunto, que en algún momento libre que tenga no tendría mayores problemas en buscar.

Para el SO, el código es la JVM y los datos nuestros propios programas. ¿Esto se encuentra relativamente cerca (los datos)? No.

No es un problema, tienes memoria suficiente como para tener el intérprete y todo tu programa en memoria. En la práctica, no es ningún problema.

Si indagas un poco en el mundo de los intérpretes y las máquinas virtuales, verás que los cuellos de botella NO están ahí.

- Accedemos al objeto círculo. Dado que el objeto no se almacena en la propia clase dibujo, sino que únicamente tenemos un puntero, vamos a buscar nuestra instancia. ¡Aquí no tenemos certeza de que esté en memoria! Peor de los casos (y probable): Fallo de página. Si a lo que intentamos acceder son a variables estáticas de una clase, tendremos que cargar la información relativa a esa clase. Y en el peor de los casos si el código de esa clase no está cargado peor suerte aún. Tras estas operaciones a bajo nivel, ya estamos listos para ejecutar nuestro método.

No se si has mirado cómo se implementa un lenguaje tipo C++, tienes algunos conceptos medio mal. Por ejemplo, no tendremos 'únicamente' un puntero, podemos tener ahí mismo los datos del objeto. Aunque esto es medio irrelevante para la discusión

No se por qué te preocupan tantísimo los fallos de página. Si tu software 'cabe' en memoria, lo normal es que tu código y tus datos SIEMPRE estén en memoria. En serio, mi máquina tiene ahora mismo 0 bytes usados en SWAP. Y le doy muchísima caña. Si estás preocupado por los fallos de página, lo que tienes que hacer es comprar más RAM.

No es un problema de lenguajes o paradigmas, es otro asunto.

Realmente te estás preocupando de cosas que son microoptimizaciones y asociándolas a conceptos de alto nivel como los paradigmas de programación.

¿Y si lo único que necesito es mi variable TAMANO_FUENTE porque decido ignorar el color? ¿No he tirado mi tiempo yendo a buscar información que no quería? Porque de estos campos no se realiza una copia en cada objeto, son comunes a todos las instancias y he necesitado cargar en memoria la página con la información de esa clase. Podríamos crear una copia de TAMANO_FUENTE en cada instancia, como solución chapucera. Pero, ¿qué ocurre si esa variable estática es la base de datos antes mencionada? Es inviable.

Si esa variable es estática y es la base de datos es que eres muy mal programador.

Aquí te estás preocupando por otro no-problema. Todas las variables estáticas, a efectos prácticos, te van a entrar en la MISMA página. Todas las de tu programa. Lo normal es que esa página la tengas hasta en caché si usas las variables con cierta frecuencia.

¿Qué ocurre en la programación estructurada? Evidentemente el problema de acceder a un dato que no tenemos en memoria puede ocurrir (queremos acceder al círculo). Pero todos esos fallos por acceder a los datos de una clase en particular no se producen. Nuevamente vuelvo al caso de mi interfaz gráfica pese a que algunos insistan en que puedo confundir cosas. Si tengo una ventana cualquiera, es bastante probable que tenga ciertas constantes definidas sobre como los objetos se distribuyen en pantalla. Si en un determinado momento debo repintar la memoria tengo que acceder a las clases involucradas en dicha acción (posibles botones, tablas, o widget en general), obtener los datos de sus respectivas clases, además de conseguir tales objetos.

En serio, a efectos de despliegue de los elementos en memoria, no hay apenas diferencias entre un programa OO y uno en estructurada. Te recomiendo que mires cómo se implementa un lenguaje OO y cómo distribuye los distintos elementos.

Una vez más, creo que el gran problema es que te preocupas de microoptimizaciones desde un punto de vista de muy alto nivel.

Como curiosidad, para hacerte una idea, utiliza el programa 'gtime' para decirte los fallos de página de tus programas favoritos.

No es que no me guste tu idea, es que creo que no hay relación entre lo uno (paradigma) y lo otro (rendimiento). Trabajo con sistemas que tienen que ir A TODA LECHE, en máquinas con pocos o menos recursos, y la OO jamás ha sido un problema.

- ferdy

"No se por qué te preocupan tantísimo los fallos de página. Si tu software 'cabe' en memoria, lo normal es que tu código y tus datos SIEMPRE estén en memoria. En serio, mi máquina tiene ahora mismo 0 bytes usados en SWAP. Y le doy muchísima caña. Si estás preocupado por los fallos de página, lo que tienes que hacer es comprar más RAM."

En el primer post indiqué que cualquiera de estos fallos eran tonterías comparados con un mal diseño o un código poco optimizado. Simplemente preguntaron por las diferencias entre ambos paradigmas, a lo que respondí que la OO no respeta el principio de cercanía en la misma forma que lo hace la PE. Fuiste tú el primero que llegó y dijo que eso no era cierto, diciéndome que estaba muy equivocado. En estos mensajes, simplemente intentaba dar cierta información, ciertos argumentos que intentaran "justificar" los hechos.

Si me expresé mal, o no se han entendido mis intenciones, nunca quise decir que prefiriera la POO frente a la PE, o que la primera sea horriblemente lenta comparada con la segunda. El trabajo que me puede ahorrar el hacer uso de la STL de C++ se convertírian en grandes sudores en otros lenguajes. Cada paradigma se utilizará para unos objetivos más específicos, para unas tareas concretas. Tal vez sea exagerar decir que ese pequeño detalle afecta al rendimiento, y más hoy en día cuando en dispositivos como teléfonos móviles se pierde la distinción entre memoria principal/secundaria (entre lo que incluimos memoria virtual).

PD: Os recomiendo por si hay algun interesado en que ojeis algún lenguaje funcional (haskell o lisp entre otros).

En el primer post indiqué que cualquiera de estos fallos eran tonterías comparados con un mal diseño o un código poco optimizado. Simplemente preguntaron por las diferencias entre ambos paradigmas, a lo que respondí que la OO no respeta el principio de cercanía en la misma forma que lo hace la PE. Fuiste tú el primero que llegó y dijo que eso no era cierto, diciéndome que estaba muy equivocado. En estos mensajes, simplemente intentaba dar cierta información, ciertos argumentos que intentaran "justificar" los hechos.

Es que no es cierto que la OO no respete el principio de cercanía. Lo hace IGUAL de bien o mal que la PE. Te recomiendo que mires cómo se implementa un lenguaje como C++; verás que no hay ninguna diferencia.

- ferdy

Ferdy escribió:Cuando dije que oMega_2093 estaba MUY equivocado es por esto: 'Si quieres rendimiento no usas un lenguaje interpretado'. Realmente no tiene mucho sentido la frase. Hay lenguajes interpretados como prolog o Erlang que pueden proporcionarte mucho rendimiento en ciertas tareas. Incluso los lenguajes que a veces se llaman semi-interpretados como Java utilizan técnicas de compilación Just-In-Time que pueden llegar a ofrecer rendimientos superiores a otras aplicaciones según qué casos.

Así sí Disculpa no haber contestado antes, pero gracias por aclararlo.

Conozco Prolog muy por encima y Erlang cero patatero, así que no estoy en condiciones de replicarte a eso. Me refería más bien a lenguajes como PHP, Python, Ruby... etc, que en procesos en los que el rendimiento es crítico no veo que se usen nunca, aunque tampoco es que den mucho pie a ello. Creo que la computación distribuída es un buen ejemplo: la mayoría de los proyectos están desarrollados en C, creo que hay también bastantes en Fortran, y hay uno, que yo conozca, hecho en Java.

Ferdy escribió:Es que no es cierto que la OO no respete el principio de cercanía. Lo hace IGUAL de bien o mal que la PE. Te recomiendo que mires cómo se implementa un lenguaje como C++; verás que no hay ninguna diferencia.

- ferdy

No quise contestar antes por no meter la pata. Me examino por fin de esta asignatura el Jueves y aquí te dejo algo de información que he encontrado:

"Al mismo tiempo que la memoria principal se hace mayor, el espacio de direcciones que emplean las aplicaciones también crece. Esta tendencia es más evidente en los computadores personales y estaciones de trabajo, donde las aplicaciones se hacen cada vez más complejas. Es más, las técnicas de programación empleadas actualmente en los programas tienden a disminuir la cercanía de las referencias dentro de un proceso [1]. Por ejemplo:

- Las técnicas de orientación a objetos fomentan el uso de varios módulos pequeños de programas y datos con referencias dispersas por un número de objetos relativamente grande en un periodo corto de tiempo.

- Las aplicaciones con varios hilos dan como resultado cambios bruscos en el flujo de instrucciones y referencias a memorias dispersas.

Para un tamaño dado de TLB, a medida que crece el tamaño de los procesos en memoria y decrece su cercanía, disminuye el porcentaje de acierto en accesos a la TLB. En estas circunstancias, la TLB puede llegar a constituir un cuello de botella del rendimiento (por ejemplo, veáse [2])."

[1] "Architectural support for translation table management in large addres space machines", de Huck J. y Hays J.
[2] "A simulation based study of TLB performance" de Chen J., Borg A. y Jouppi N.

PD: En efecto se habla sobre la TLB y no sobre los fallos de página, es decir, podría darse el caso de que no encontrasemos la página en la TLB pero si que estuviera cargada en memoria principal. Para comparar si esto realmente supone una cuantía notable en el rendimiento me remito a [2]

Por cierto esta información la saqué de "Sistemas operativos" de Williams Stallings. Ahora por favor ferdy agradecería alguna referencia seria, algún análisis que algún entendido haya podido hacer sobre el tema "desmintiendo" (o mejor dicho refutando) lo que he encontrado en la literatura sobre el asunto.

Stallings es un autor de buenos libros, el de Sistemas Operativos es bueno; es mejor el Tanenbaum, pero eso es lo de menos. Stallings ahí peca de "bocachancla".

Lo único que te puedo recomendar es que estudies y apruebes la asignatura. Y cuando avances en la carrera y tengas conocimientos suficientes, mires cómo se implementa un lenguaje de orientación a objetos modernos. En ese momento, podrás decidir si Stallings se equivoca o no.

Por mi trabajo, se que es muy fácil coger una referencia y creersela a pies juntillas, pero hasta los más grandes cometen errores. Tu formación debe ser crítica; así que no te creas nada a priori (ojo, yo no te digo que me creas, te digo que mires por tu cuenta y decidas).

Por ejemplo, veamos lo que dice y cita Stallings. La referencia a [1] es de 1993, y [2] es de 1992. Las cosas han cambiado muchísimo desde entonces. Es posible que los artículos sigan siendo vigentes, pero lo dudo mucho.

Por ejemplo, dice: "- Las aplicaciones con varios hilos dan como resultado cambios bruscos en el flujo de instrucciones y referencias a memorias dispersas.". Esto a día de hoy es una chorrada como un piano.

Hay que ponerlo TODO en perspectiva.

Suerte en el examen. Ojalá la mitad de mis proyectandos tuvieran la mitad de ganas de aprender y entender que tu :/

- ferdy

Claro que las cosas han cambiado mucho, no creo que haya mayores dudas en eso. De hecho en el libro se mencionan muchas de las características "actuales" de los ordenadores y pecan de desfasadas. No creo que ponerme como ejemplo MS-DOS a día de hoy sea un acierto, pero ayuda a ver cómo funcionan las cosas.

A su vez cabría mencionar que las posibles memorias en la época (las TLB's concretamente) serían bastante inferiores. Aún así desconozco si se usan realmente TLB's en este campo. En otra asignatura nos enseñaron que existían memorias asociativas de n vías, que querían "imitar" a las memorias anteriores pero con un presupuesto menor (y una eficiencia inferior por tanto). Sin embargo, esto corresponde a la arquitectura del computador, pero como creo que ya aclaramos perder unos pocos nanosegundos no es equiparable a un mal diseño, o la elección de un algoritmo equivocado.

Finalmente, puntualizar el tema de los hilos. También me pareció una memez que se critiquen los hilos en cuestión del acceso a memoria, ya que una de las principales ventajas de los mismos era la posibilidad de compartir segmentos comunes entre los mismos, al igual con el bloque de control del proceso que pueda tener el SO, o la reutilización de la caché al ejecutarse sobre un mismo procesador (una de las políticas de planificación multiprocesador era asignar ráfagas a hilos por la tendencia de los mismos a iteracionar entre ellos).

Por tanto, entre ejecutar dos procesos "afines" o dos independientes, siempre que sea posible elegiremos la primera opción. Pero como puedes imaginar, no es sencillo poner en duda aquello que lees de un libro, que un profesor te explica y que además tú no tienes manera de demostrar o verificar empíricamente.

PD: El Tanenbaum también lo tengo por aquí cerca. La verdad que trata los aspectos de una manera más concisa y con una mayor profundidad. (Me examino exclusivamente de memoria virtual, I/O y gestión de ficheros y por ejemplo el análisis que se realiza sobre los algoritmos de reemplazo en memoria virtual dejan ver algo más allá del reloj o el fifo que Stallings nos enseña).