воу

а это круто) спасибо

Привет чат всем

Привет чат всем

правила. ты их читал?

Есть питон, есть вим, не работают вместе, шо делать, какие подводные?

в смысле не работают и в смысле вместе?

Интеграция питона в вим через джедай

Интеграция питона в вим через джедай

я вообше хз, но в любом случае лучше подробнее описать проблему. Что именно не работает, что пробовал, что смотрел

я вообше хз, но в любом случае лучше подробнее описать проблему. Что именно не работает, что пробовал, что смотрел

Есть питон 3.7.3 64х, есть вим 8.1.чтотодальше 64х, хотел внедрить нормальную проверку и дополнение кода, почитал что хорош jedi-vim, выполнил его установку и вим начал обильно ругаться на невозможность инициализации питона, +python штуки в виме есть, Команда echo has(python) даёт 0,

@Kdanylov прошу прощения за, возможно, тупой вопрос, но в тесте asyncio количество загруженных ядер для асинка и тредов было равным? Я перед сном в чат заглянул, меня что-то клинит на том, что асинк в один поток работает.

@Kdanylov прошу прощения за, возможно, тупой вопрос, но в тесте asyncio количество загруженных ядер для асинка и тредов было равным? Я перед сном в чат заглянул, меня что-то клинит на том, что асинк в один поток работает.

да, все тесты запускались с привязкой к одному ядру. Генератор нагрузки пинился на другие ядра процессора. В питоне потоки тоже в один поток работают фактически. Пока один исполняет питон-байтокод - остальные стоят. Но потенциально могут исполнять узкие прослойки С-кода. Но тут нет, тест пинится на одно ядро процессора. Если не пинить на одно ядро - потоки начинают сильно проседать изза паразитных переключений. Это, в частности, проблема многих "тестов" потоки vs async в инете - народ тупо не знает что нужно пинить на одно ядро многопоточные программы на питоне

О как. А простого синхронного теста не было?

Без потоков и асинка

@nepherpitou собвственно это совершенно ожидаемый результат. asyncio выполняет просто безумное количество питон кода на каждый await сначала ты уходишь вних по славно задизайненному со всеми требуемыми паттернами стеку вызовов в недра asyncio что бы она сконтруировала тебе Future потом это future ты везешь обратно по всему своему стеку вызовов до самого loop. loop регистрирует на него калбек и проделывает вагон метаработы и всякой фигни. Однажды future исполнится, ему поставят done, вызовется callback и корутину подвинут в очередь готовых. Потом обратно через весь стек вниз прокинут результат. Выходит 400+ питоновских инструкций на каждый await. Каждая примерно по ~50 тактов CPU. или 20к+ тактов. А переключение потоков в ядре со всем скедуленгом и туда-сюда < 500 тактов. Так и живем

О как. А простого синхронного теста не было?

нет, да и нет смысла, будет совсем смешно. Но можно запустить потоковый тест на одном воркере

Тест будет полностью лимитироваться латентностью tcp стеков и сетки

Тест будет полностью лимитироваться латентностью tcp стеков и сетки

А с медлительным сервером не оценивал результаты? Когда время исполнения питонячей богодельни будет сильно меньше времени ответа сервера.

Блин, надо будет завтра поковыряться.

как удалить все папки в которых нету файла ПАРОЛИ ?

Хм... Для такого теста надо логику менять, в текущем виде асинк будет ждать каждого нового ответа, а потоки будут делать это в N раз чаще.

@nepherpitou если сервер будет тупить, или если на клиенткой стороне будет еще какая-то активность между приемом и посылкой сообщения, то просто возрастет латентность. Сообщения же не паплайнятся. Но в таком случае ты будешь мерять не совсем то. но вообще по мере роста количества соединений потокам становится все хуже и хуже, так что если сервер будет тупить и открытые соединения будут копится - потоки начнут проигрывать постепенно изза повышенного потребления ресурсов при простое. Собвественно на том ноуте где я это тестит больше 20к потоков не удавалось запустить. На текущем работает с 30k, но дальше уже не.

да, все тесты запускались с привязкой к одному ядру. Генератор нагрузки пинился на другие ядра процессора. В питоне потоки тоже в один поток работают фактически. Пока один исполняет питон-байтокод - остальные стоят. Но потенциально могут исполнять узкие прослойки С-кода. Но тут нет, тест пинится на одно ядро процессора. Если не пинить на одно ядро - потоки начинают сильно проседать изза паразитных переключений. Это, в частности, проблема многих "тестов" потоки vs async в инете - народ тупо не знает что нужно пинить на одно ядро многопоточные программы на питоне

Вот это сейчас неожиданно реально. Каждый поток на свое ядро пинил или все на одно?

Хм... Для такого теста надо логику менять, в текущем виде асинк будет ждать каждого нового ответа, а потоки будут делать это в N раз чаще.

нет, у тебя же асинков тоже много как и потоков. все параллельно

Вот это сейчас неожиданно реально. Каждый поток на свое ядро пинил или все на одно?

все на одно. иначе они бОльшую часть времени тупо за GIL воюют

нет, у тебя же асинков тоже много как и потоков. все параллельно

В десятый раз пошел с телефона а код тупить...

Они и так воюют за гил

В общем непонятно

Код теста бы

Они и так воюют за гил

код теста в той же репе. main.py

так они не воюют

Я проглядел ссылку

https://github.com/koder-ua/network_ping_test/blob/master/perf_report.md#%D1%81%D0%BE%D0%B2%D0%B5%D1%80%D1%88%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5-%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2%D1%8B вот кусок смотри - там есть расклады по системным вызовам с affiniti и без

без афинити на каждый recv - 15 futex_wait

там хитрая фигня выходит - в добавок ОС начинает елозить потоки по все доступным ядрам CPU равномерно

мусорит кеши и прочее

нет, у тебя же асинков тоже много как и потоков. все параллельно

А где создаётся много асинков? Из шелла?

Да можно ссылку на строчку кода кинуть, я открою :) а то ты там, кажется, диссертацию так скоро напишешь.

https://github.com/koder-ua/network_ping_test/blob/master/perf_report.md#%D1%81%D0%BE%D0%B2%D0%B5%D1%80%D1%88%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5-%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2%D1%8B вот кусок смотри - там есть расклады по системным вызовам с affiniti и без

А какой объем пинга?

Размер данных

Необходимо собрать по дизайн-эскизам экранов весь функционал для магазина, на Django. Все стандартно: api для стыковки с фронтом, мультиязычность, мультивалюстность, фингерпринты, авторизация через соцсети, подбор товара, конструктор товара, оплата через платежный шлюз, чат. Для админки можно использовать шаблон аля jet. Фронт на angular уже готов. От вас нужен только бек на django. #работа #удаленка

А где создаётся много асинков? Из шелла?

тааак. все корутины (они же асинки) живут в одном потоке OC. Но корутин у тебя столько же, сколько и потоков. А, я тебя понял. Если в тестируемой части начать делать дополнительные операции, а не только пинг-понг, то расклады будут чутка другими. Долго писать. Но в общем этот тест не про симуляцию реальной нагрузки - он про накладные расходы. Накладные разходы зависят только от количества соединений. Потоки проседяют быстрее остальных про этим. Если у тебя будет МНОГО медленных клиентов - то потоки будут смотреться хуже, чем если их мало. Но все равно лучше async по пропусной способности. Но так то у async есть другие проймузества

А какой объем пинга?

64B

64B

Ээ

Черт дохуя мало

я гонял и на 2к

Давай-ка 100к хотя бы

А смысл?

Асинкио обещали быстрее за счёт экономии на чтении их буфера

ты просто начнешь тратить время на tcp стек, а не на свой код

я не понимаю как так может быть

Мол треды переключаются когда ты читаешь, а тут сразу

На маленьких размерах никто не обещал

И да, у тебя код с тредами не умеет дочитывать данных, остальные не с смотрел

тааак. все корутины (они же асинки) живут в одном потоке OC. Но корутин у тебя столько же, сколько и потоков. А, я тебя понял. Если в тестируемой части начать делать дополнительные операции, а не только пинг-понг, то расклады будут чутка другими. Долго писать. Но в общем этот тест не про симуляцию реальной нагрузки - он про накладные расходы. Накладные разходы зависят только от количества соединений. Потоки проседяют быстрее остальных про этим. Если у тебя будет МНОГО медленных клиентов - то потоки будут смотреться хуже, чем если их мало. Но все равно лучше async по пропусной способности. Но так то у async есть другие проймузества

Да я не о том. У тебя треды тоже живут на одном ядре, но их много. А корутина одна, или я не могу понять где они плодятся.

ты просто начнешь тратить время на tcp стек, а не на свой код

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

ээээ, я не понял. Когда ты используешь асинк - ты делаешь сначала poll и получаешь список сокетов на которых есть данные. Дальше ты из этих сокетов точно так же, как и в потоковой системе, читаешь данные. Тем же самым recv

Разницы ни в буферах ни в ос тут нет

Ну вот у тебя есть 100к данных. В асинке пока не прочитаешь не переключишься

А треде - можешь

нет

Там именно эту часть тюнили

Проверь, иначе это все теория

а кто мешает сделать в потоке recv(100000)

так а что проверять то - я и так те скажу

делаешь в потоке recv с большим размером буфера и читаешь все что есть

а кто мешает сделать в потоке recv(100000)

Никто не гарантирует что во время этого вызова не будет сотни переключений

причем ровно одним запросом в ядро

это один вызов ядра

Можно подумать питон именно так и сделает

какие переключения?

да

это один вызов ядра

Пруф?

Короче, имхо твой тест не полностью корректный

в смысле пруф? когда ты на сокете делаешь socket.recv(10000000) - вызов узодит в ядро с таким за размером требуемого буфера

если там нет данных - ты блокируешься

если дам есть хоть байт данных - ты получишь обратно все что есть

Не хочешь проверить поведение на большем объеме - твое дело. Но в реальности ради 50байт никто не будет такое писать, так что нагрузка у тебя нереальная

запусти под strace и посмотри

Не хочешь проверить поведение на большем объеме - твое дело. Но в реальности ради 50байт никто не будет такое писать, так что нагрузка у тебя нереальная

ты фигню полную несешь

Ну ок

Так никто не спорит с тем, что нагрузка не реальная

сори, но хоть посмотри как работает ядро и питон с сокетами

Так никто не спорит с тем, что нагрузка не реальная

Ну так а что измеряли?

Вот это я и пытаюсь понять

накладные расходы разных систем на передачу блока данных

Ну а размер блока не важен, ага. Мы должны проверить

Зачем тогда тесты, если все принимаем на веру

Но тут вопрос - почему потоки множатся, а корутина одна

Зато на одно ядро пинили

Ну а размер блока не важен, ага. Мы должны проверить

а от кокретных данных зависит скоротьс?

Но тут вопрос - почему потоки множатся, а корутина одна

Ээ. Там так?

может пробелы быстрее букв 'a' идут?

может в субботу быстрее asyncio?