Дизассемблируем Python-циклы. Ассимиляция Гиперпространственного Фокала Социалистических Измерений! 

"для тех кто возбудился услышав пайтон и компилятор" .... поздравляю вы вылечены от импотенции при помощи пайтона

1:16 > Поэтому у тебя такой результат получается т.к. тут речь про мой коммент под прошлым видосом, то отвечу) Я отметил в комментах что эксперемент проведен не совсем ЧИСТО и что кеши МОГЛИ повлиять на результат P.S. Я не из тех адептов которые пишут что ты неправильно итерации посчитал P.S.S. Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

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

Спасибо вам за видео. Мне очень нравится ваша подача материала, всегда приятно смотреть и слушать

Вот от while на счетчиках я вообще такой подставы не ожидал. Т.е, у for под капотом будет создаваться итератор, который на каждой итерации будет илдить новый элемент. И все это это будет завернуто в try/except, чтобы ловить StopIteration. И все вот это дело быстрее чем счетчики в while?... Я аж у себя проверил - реально быстрее. Я так понимаю, тут прикол в том, что в случае со счетчиками в while мы там руками прописываем инкременты, а вот в случае for - там это уже прописано где-то глубоко под сишным капотом. Но это все равно какая-то прям мистика. Респект за такой видос!

Это как после того что в питоне нет переменных - понял) Надо смотреть, будет больно, но полезно)

Спасибо за видео! Справедливости ради хочется отметить, что если в цикле производится какая-то операция, по которой определяется условие его выхода, то while все же может быть быстрее :) К примеру, если часть вычислений уровнять (по примеру с видео): from functools import partial import timeit def for_loop(count: int): counter = 0 for _ in range(count): counter += 1 def while_loop(count: int): counter = 0 while counter < count: counter += 1 x = timeit.timeit(partial(for_loop, 1_000_000), number=100) y = timeit.timeit(partial(while_loop, 1_000_000), number=100) print(x, y, x / y) #x=2.7985 y=2.026 d=1.381 то while окажется быстрее до 40%

Если уж говорить про декартово произведение, то тут вложенный цикл и не нужен, можно обойтись одним for row, col in product(range(5), range(2)):

13:03 вообще, оч хороший пример, потому что в нем играют роль не только сами накладные расходы на циклы, но и, например, всякие кэши и конвейеризации на процессоре. Поэтому компиляторы многих языков циклы разворачивают по возможности или "подразворачивают", то есть в теле цикла пишут N раз одно и тоже, и количество итераций делят на N

Долго не мог понять, почему количество итераций разное, а потом написал эти 2 цикла и сразу понял)

лайк чисто за разбор байткода, многим будет интересно(наверное), тк, полагаю, мало народу вообще смотрит, как оно работает под капотом

Спасибо за пояснение к видео! А то алгопрогерский опыт не дал понять что имелось в виду под итерацией

Минуточку! Эдак и до спецификации не далеко.

Так эти накладные расходы никак не скалируются, т.е. если мы добавим в цикл какое-то полезное действие(sleep(0.1)), то эти десятитысячные секунды так и останутся десятитысячными, а время выполнения будет примерно одинаковым. Правильно же?

Алексей, спасибо за детальны разбор. Такой момент, мной, замечался ранее, около года назад. Но, вы, разобрали на достаточно детальных примерах. Интересно :))) Спасибо

Если вы побудите в комьюнити других языков, то там не редко говорят, что в питоне очень хреново работает for и while. На том же C C++ в разы лучше, ну ладно это такое себе сравнение. В целом лучше избегать циклы в питоне. : )

У меня есть подозрение, что самая тяжёлая операция в байткоде в начале - это GET_ITER, или что-то типа того. И получается, что итератор (а не итерация) создаётся либо 6 раз, либо 101 раз. Классическая тема, по-моему, просто питон это скрывает от пользователя. Скорее всего, если повторить этот тест с вложенными while со счётчиками, разницы не будет. Проверять я это, конечно, не буду, потому что мне лень :D

надо перевести столь удачный термин на английский и попробовать на SO спросить, интересно что подумают.

Крутой материал! Это же все началось с «чистого кода», если не ошибаюсь? И вона куда занесло ) Я периодически начинаю переходить на плюсы или ржавчину, когда думаю о скоростях исполнения, но когда вспоминаю, сколько там всего надо написать, чтобы решить простую задачку, все проходит )

Автор ответил на все возникшие у меня при просмотре каверзные вопросы. Подписался. При этом укрепился в мнении, что python - язык, что позволяет быстро писать медленно работающий код.

То что цикл несет дополнительные издержки, ясно уже интуитивно просто потому, что цп приходится исполнять инструкции оператора for

добвлю так чисто хрень, во время прыжка по инструкциям часто происходит промах в кэш и тд, но питон очень дубовый в этом плане, если эту задачу на си написать, то будет работать ровно наоборот. контекст внутреннего цикла будет храниться внутри кэша. чем больше прыжков по инструкциям сделать, тем больше вероятность, что другой код (браузер какой-нибудь) вытеснит контекст задачи и придется снова лезть в оператику.

13:02 ну я так понимаю это из-за использования итераторов в for циклах в питоне на каком си c циклом for (int i = 0; i < 10; i ++) разрыв был бы может и меньше, но все равно бы был короч, любое телодвижение - это процессорное время любое телодвижение x10^(10) - это фатальное процессорное время

Не подскажете, что за тема у вас в vim? На гитхабе лежит ваш старенький vim.rc с Oceanic-Next, а тут явно что-то покрасивше)

Я нубас, но коммент и лайк для продвижения. Ничего не пойму, но посмотрю

модель клавиатуры подскажи плс.

31:09 я один заметил, что второй раз функция выдала -44% это как? Отрицательные значения мы понимаем, но каким образом при равном подходе (когда малый всегда значительно меньше большого) получилось отрицательное значение? (неужели где-то в кэше/еще чем-то происходит магия?) Вопрос без попытки в чем-то обвинить, просто рил не понял как такое произошло.

В том, что цикл несет накладные расходы, никто не спорит. В чем основной посыл - вложенный цикл с большим плечом ВНТУРИ медленнее вложенного с большим плечом снаружи. Верно? (Ну или наоборот - неважно.) Тогда предлагаю вам сделать такой эксперимент: меньшее плечо - 100, большее 1_000 (1 тысяча). Внутри самого внутреннего цикла какая-то емкая задача, скажем на 1 милисекунду - вызов CPU-bound функции, с подобранным временем примерно в 1мс, но всегда с одинаковыми данными, чтобы время работы не менялось. Теоретически прогон должен занять 100 * 1000 = 10_000 мс, то есть 10 секунд на саму работу ПЛЮС накладные расходы на циклы. Вот и сделать прогон для внешнего цикла с большим плечом, и с малым, и посмотреть, насколько разница в организации циклов будет влиять на результат, и будет ли она заметна вообще. А то еще окажется, что разница при изменении порядка циклов окажется 0,001% от всего времени работы программы, что делает усилия по такой оптимизации бессмысленными.

Твоя ошибка действительно в использовании слова итерации. Но в целом та ты прав. Если посмотреть на байт код, то циклы не бесплатные. 9-я и 10-я строки стоят сразу нескольких операций. Тело двух циклов выполняется 500 раз, но для того, чтобы выполнить 500 раз тело двух циклов в первом случае запуск двух циклов занял 600 раз - 10-я строка выполнялась 100 раз и 11-я выполнялась 500. Во втором случае запуск внешнего цикла происходил 5 раз, а внутреннего 500 раз. А глядя, во что превращается каждая из строк for, должно быть видно, на сколько получилась разница. Меньше запусков for приводит к экономии.

Картинка офигенная)

если нужно использовать циклы в питоне - нужен не питон (c)

Что что в названии написано? 😂

Хорошо жить одному в просторном доме и заниматься программированием

С итерациями все правильно, у каждого цикла свои итерации, почему они дожны объединяться? А если у тебя в одном цикле два вложенных разной длинны? Это сколько тогда у них в сумме итераций? :D

Вот это разбор - просто до атомного уровня!

Тоже несколько лет назад спорил. Мне доказывали, что копирование файла с индикатором прогресса выполняется быстрей, чем без него 😂😂😂😂

Не хочу ставить лайк. Всего лайков 128. Что-то это да значит) Пусть значит. P.S.: Обновил страницу, чтобы всё таки поставить лайк. На этот раз лайков было уже 193)

ну ассемблер это тоже не то что исполняется процессором. и никаких циклов вообще не существует, у проца все эти циклы это всегда какое то сравнение (CMP, TEST) и условный переход (JE JZ JNE JNZ...) байты этих команд можно поискать в IA32 Arch от intel, это и будут те самые байты которые проц выполняет. Ежу понятно что чем больше команд надо выполнить тем дольше работает программа, если внешний цикл меньше то как минимум команд сравнения будет выполнено меньше, а значит и работать будет быстрее, но процы умеет в предсказание переходов (привет SPECTRE и MELTWOWN и уже с нмни) и научились заренне исполнять код, так что это даже микро-оптимизацией наверное не стоит считать, скорее всего это вообще не особо актуально.

Вот его торкнуло 🤣🤣🤣 Мужик выдыхай!!! 😁😁😁

А всё почему, а всё потому, что пайтон не очень оптимизирует, я сейчас вбил аналогичный код в C++, так вот он мне внутренние циклы просто свернул до умножения простого P.S. Писать то я всё равно продолжу на любимом питончике, но, конечно, его оптимизирующему компилятору до компилятора а-ля clang или gcc ой, как далеко

Фрикциями?

имхо выгода от такой оптимизации будет стремиться к нулю, если внутри цикла будет стоять что-нить cpu-bound

Жду новых комментариев о том, что опять кто-то не прав и вообще всё не так и сам Гвидо говорил, что... 😂

Все правильно раскидал, и пример нормальный. Дурачки предлагающие размыть тяжелой операцией внутри - сводят одну задачу к совершенно другой. А итерация в твоем контексте - это один джамп в машинном коде, все отсальное это уже из совершенно других контекстов. И унижение этих "философов от cs'" при помощи байткода считаю абсолютно правильным. ЛайГ. И кстати индусский пример таки - пример трейдофа скорости на памятью И то же дичайше поддерживаю его добавление в методических целях

Ахахахахаха

34 минуты унижения адептов аптимызации в сфере веб технологий!

все функции с операциями сложения больших чисел лучше компилировать на Cython например для цикла инкрементирующего count 222222222 раза результаты: Cython: 5.83939254283905e-07 Python: 7.961033541010693 Cython выполнился быстрее на 1_363_332_384.09%