FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Hola JerS,
Para la máquina yo diría que le es indiferente. De todas formas, con cualquiera de ellos todo se reduce a lo mismo o muy parecido: intrucciones de salto o brinco. Es decir, el compilador traducirá el fin de ciclo como una instrucción de tipo: si se cumple la condición te sales... y esto está ya altamente optimizado y se podría asumir (y asume) que consumirá lo mismo aunque se tratase de un while, un for o un repeat. Como te han indicado los compañeros, el uso de estos ciclos dependerá de la naturaleza del problema. Lo que deba hacerse dentro es realmente lo que dará el peso real al problema. Lo que puedes hacer, para tener una idea de la complejidad de tu algoritmo y de lo rápido y eficiente que podría ser es calcular la complejidad computacional (en notación O) como la complejidad ciclomática V(G). La primera te dará una idea de lo rápido que podría hacer, y del "tiempo" que podría demorarse. Mientras que la segunda te dará una idea de lo complejo que es el algoritmo y de la cantidad de caminos y casos de prueba a aplicar para evaluarlo totalmente. El ejemplo de pcicom es un clásico. Si tuviéramos que calcular la complejidad computacional fácilmente comprobaremos que es T(n/5) mientras que su contraparte es T(n). De todas formas, ambos tienen por asíntota una complejidad O(n). ¿Eso quiere decir que ambos se harán en el mismo tiempo? No... solamente es que el primero puede asumir una constante c 5 veces menor que el "original"... Esto se traduce a que el primer algoritmo puede recibir un vector de tamaño 5 veces mayor que el original para estar en las mismas condiciones del original. Es decir que el algoritmo modificado "crece" 5 veces más lento, con lo que puede aprovecharse para más hacer operaciones. Por ejemplo: si en vez de esos 1000 fueran 2000, con el primero sólo necesitaríamos 400 pasadas. Para igualar a las 2000 instrucciones del original... se necesita un vector de 10000. Te aconsejo una lectura a libros sobre estructuras de datos y algoritmos. Allí encontrarás explicado el tema de la complejidad computacional. Saludos, |
#2
|
||||
|
||||
Pues yo creo que sí que se ejecutarán en el mismo tiempo. Cada vuelta del ciclo de cinco instrucciones se ejecutará cinco veces más lento que una vuelta del ciclo de una instrucción, con lo cual, realmente no se gana nada.
// Saludos |
#3
|
||||
|
||||
caso for i := 0 to 1000
Código:
1 inicializar i=0 2 inicializar limite=1000 3 hacer algo 4 incrementar i 5 ver si i > limite 6 verdadero saltar a 3 Pasos 4 se ejecuta 1000 veces pasos 5 se ejecuta 1000 veces pasos 6 se ejecuta 1000 veces caso for i := 0 to 200 Código:
1 inicializar i=0 2 inicializar limite=200 3 hacer algo 4 hacer algo 5 hacer algo 6 hacer algo 7 hacer algo 8 incrementar i 9 ver si i > limite 10 verdadero saltar a 3 pasos 8 se ejecuta 200 veces pasos 9 se ejecuta 200 veces pasos 10 se ejecuta 200 veces Conclusión: En el caso de hacer un for, la parte final (incrementar, comporbar, saltar) se ejecuta tantas veces como el for. La parte de dentro (hacer algo) siempre se ejecuta 1000 veces caso 1 = 1000+100+1000+1000+1000 = 5000 caso 2 = 200+1000+200+200+200 = 1800 |
#4
|
||||
|
||||
Según creo el ciclo for es el mas rápido de todos.
Esto se debe a que la condición de salida ya esta prefijada antes de iniciarse, lo que permite al compilador realizar optimizaciones utilizando registros internos del procesador para el contador y la condición de salida (en realidad deberiamos analizar el assembler generado en los diferentes casos). En el ciclo for la condición de salida no puede ser modificada. Por ejemplo:
Este ciclo se ejecuto 10 veces y no 5. Igualmente la diferencia no creo que sea apreciable y lo mas probable es que termines perdiendo mucho mas tiempo en otras partes de tu codigo o simplemente por tener un servicio innecesario corriendo en la misma maquina.
__________________
[Crandel] |
#5
|
||||
|
||||
Cita:
El tiempo está dado por diversos factores, mayormente externos, y es lo que al final se simboliza con una constante, por lo general simbolizada por c. Cuando comento la diferencia entre T(n) y T(n/5) estoy diciendo simplemente que el segundo crece 5 veces más lento. Por lo cual le permite recibir una entrada mayor al mismo costo. Para igualar las condiciones de T(n) la entrada que necesita debe ser 5 veces mayor. Si ambos algoritmos se prueban en un mismo equipo, con las mismas condiciones iniciales, etc. se tiene c * T(n) y c * T(n/5). Allí claramente se ve que el segundo caso es preferible al primero. Pero en vista a a que tanto T(n) y T(n/5) tienen el mismo órden, directamente se habla en términos de asíntota: O(n), y luego las constantes c se "ajustan". Para el caso de T(n/5) la constante c es en realidad c/5. ¿Me explico? Saludos, |
#6
|
||||
|
||||
Cita:
// Saludos |
#7
|
||||
|
||||
Roman me parece que no nos entendemos.
Si suponemos que cada una de las instrucciones dentro del ciclo son triviales, todas tienen un O(1). Y el costo total de éstas, no es O(5). En el cálculo de complejidad computacional se toma siempre aquel de mayor orden, que es el que más incide y afecta. Como todas son O(1), un Max( O(1), O(1), O(1), O(1), O(1) ) simplemente dará O(1). Luego, éste se multiplica por el del for, que es justamente en el caso del algoritmo "quebrado", n/5. Para este algoritmo sigue siendo determinante en realidad las pasadas. Saludos, |
#8
|
||||
|
||||
Algunos compiladores (como GCC y FPC, por ejemplo, y creo que algunas versiones de Delphi también) son capaces de hacer optimizaciones al estilo de lo explicado por duilioisola, lo que se denomina unroll loops.
Por otro lado, también depende de la longitud del código que ejecuta el bucle, así como la cantidad de los datos que manipula. Esto es importante sobre todo con los microprocesadores modernos ya que disponen de cachés internas que pueden acelerar considerablemente el acceso a los datos si se mantienen dentro de un cierto intervalo, así como circuitos de "predicción" que pueden acelerar la ejecución de algunas partes. También depende del tipo de datos que van a comprobarse a la hora de establecer el final del bucle. Con FOR esto es fácil, ya que siempre debe ser un tipo ordinal (INTEGER, BYTE, LONGINT, etc.), siempre se incrementa o decrementa la variable "contadora" en una unidad, y siempre es una variable local, por lo que el compilador puede hacer multitud de optimizaciones que no podría en el caso de un bucle WHILE con parámetros en punto flotante, por ejemplo. Sin embargo, si el WHILE utiliza también ordinales pues es posible que sí pueda hacer algunas de las optimizaciones, aunque no todas, y por otro lado un bucle WHILE o REPEAT no tiene porqué modificar siempre el contenido de las variables implicadas en la condición final. Otro detalle es que, por lo que sé, los bucles FOR sólo calculan las expresiones de la condición una vez, mientras que los bucles WHILE y REPEAT calculan estas expresiones cada vez que se repite el bucle (salvo si el resultado de la expresión se considera constante). Es decir: En el caso del FOR la longitud de "UnaVariableConTexto" se calculará una sola vez justo antes de iniciar el bucle, mientras que en el WHILE esta longitud se calcula cada vez que se hace la comprobación. Esto también afectaría dramáticamente al rendimiento del bucle. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Ayudenme Rapido, Rapido | omarys | Varios | 6 | 04-06-2011 09:45:34 |
Interrumpir un ciclo Repeat - Until | FGarcia | Varios | 10 | 07-01-2009 00:06:10 |
¿Qué es más rapido? | jcarteagaf | Humor | 3 | 05-07-2008 02:48:58 |
Duda sobre variable en un Bucle Repeat | gerupc | Varios | 9 | 21-07-2007 02:44:34 |
...rapido de mente... | Jure | Humor | 5 | 08-10-2004 16:09:13 |
|