![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
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 |
#2
|
||||
|
||||
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 |
#3
|
||||
|
||||
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] |
#4
|
||||
|
||||
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, |
#5
|
||||
|
||||
Cita:
// Saludos |
#6
|
||||
|
||||
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, |
#7
|
||||
|
||||
A no ser que un JMP sea sustancialmente más lento que un MOV, creo que no aplica tu cálculo de complejidad.
// 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. |
![]() |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
![]() |
||||
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 |
![]() |
|