2016-06-01 3 views
1

Что-то я не понимаю с моим кодом. Я работаю с avr-gcc и оптимизирую свой код для скорости. Я читал о циклах, подсчетах и ​​позициях/pre (de), сравнении с 0 и обнаружил что-то странное.avr-gcc: loop with> = быстрее, чем> check

Этот код работает в 47s:

UInt8 ret, i; 
i = UJ_THREAD_QUANTUM; 
do { 
    ret = ujThreadPrvInstr(h, t); 
    if (ret == UJ_ERR_RETRY_LATER) { 
     // do not bother with the rest of time quantum if we're already stuck 
     ret = UJ_ERR_NONE;  
     break; 
    } 
    died = (t->pc == UJ_PC_DONE); 
    if (died) { 
     break; 
    } 
    if (ret != UJ_ERR_NONE) { 
     break; 
    } 
} while(--i); 

Этот код в 43s:

for (i = UJ_THREAD_QUANTUM; i >= 0; --i) { 
    ret = ujThreadPrvInstr(h, t); 
    if (ret == UJ_ERR_RETRY_LATER) { 
     // do not bother with the rest of time quantum if we're already stuck 
     ret = UJ_ERR_NONE; 
     break; 
    } 
    died = (t->pc == UJ_PC_DONE); 
    if (died) { 
     break; 
    } 
    if (ret != UJ_ERR_NONE) { 
     break; 
    } 
} 

Этот код в 47s снова:

for (i = UJ_THREAD_QUANTUM+1; i > 0; --i) { 
    ret = ujThreadPrvInstr(h, t); 
    if (ret == UJ_ERR_RETRY_LATER) { 
     // do not bother with the rest of time quantum if we're already stuck 
     ret = UJ_ERR_NONE;  
     break; 
    } 
    died = (t->pc == UJ_PC_DONE); 
    if (died) { 
     break; 
    } 
    if (ret != UJ_ERR_NONE) { 
     break; 
    } 
} 

Думая, что я, возможно, не понял некоторые внутренние механизмы , Я изменил значение UJ_THREAD_QUANTUM (по умолчанию это 10) и счетчики пост/предопределений, но даже что оказалось, что я принимаю решение >= 0 или > 0.

Может ли кто-нибудь объяснить, почему это так?

+2

Вы уже разобрали двоичные файлы? –

ответ

2
UInt8 ret, i; 

означает, что i >= 0 всегда правдиво. Но нужно оценить i > 0.

+0

И компилятор должен дать вам предупреждение, именно потому, что i> = 0 всегда верно, поэтому это скорее всего не то, что вы хотели. – gnasher729

+0

О, Боже! Это ослепительно очевидно в ретроспективе. Разумеется, целое число без знака. Я глуп! Спасибо! –

0

Забудьте все, что вы читаете о циклах, пошаговом приращении, отсчете до нуля и т. Д. Это даже не микро-оптимизация, это нано-оптимизация. Единственный способ, которым он имеет любой эффект на скорость вашего кода, если вы делаете код, который на самом деле изменяет что делает цикл. То есть, если поиграть с вашим циклом, вы представили ошибки.

Особенно в таком случае, когда вы играете с нитками - все довольно дорогостоящие операции. Что заставляет вас думать, что имеет значение даже один бит, как вы меняете переменные? Изменение i - вопрос наносекунды или меньше. Как это повлияет на код, который работает в течение 43 секунд, если вы не делаете это несколько десятков миллиардов раз?

Для ваших циклов используйте код правильно, и это можно прочитать.

+0

Это код с виртуальной машины на встроенных узлах. Соответственно, этот цикл будет выполняться постоянно, и я считаю, что оптимизация может помочь. При этом читаемость, естественно, наиболее важна. Но - i и i - являются такими же читаемыми, как обычно. –

 Смежные вопросы

  • Нет связанных вопросов^_^