Вместо того чтобы сравнивать три ответа для определения верного большинством голосов, система использует алгоритм выбора источника, упорядоченный по приоритету, среди исправных каналов, которые не перешли в режим «бесшумного отказа».
О, работают аналогично компьютерам в СПРН (и полагаю аналогично другим похожим системам)
Я вас удивлю, но в ядре и без "ржавого" постоянно обрубается старое и ненужное, либо что-то переписывается, есть даже релизы ядра в которых кода удаленно больше чем добавлено (чем разработчики очень довольны) --- из ядра постоянно выкидываются древние драйверы и переписываются подсистемы для повышения их перформанса/секьюрности.
Если посмотреть на то какие VPS люди арендуют, то можно заметить что они куда менее мощные чем их собственные компы, облако это далеко не только про мощность.
Будь у меня локально хоть 100 ядре и 500 гигов памяти, смысл ставить на свою машину тот же openVPn.
Ну, сначала по современному положил руки на wasd и мышь, чувствую неудобно, а поом вспомнил что раньше это делалось по другому и положи на правую на нумпад, а левую на ctrl,alt,space и без проблем зачистил уровень.
Извините за пассивно агрессивный тон, но дебажить это надо деббагером.
Мне лень прикреплять картинку, но IDE спокойно ставит брики внутри лямбд и спокойно проваливается внутрь функций
ускорять
1) По ситуации. Заменять библиотечные функции, своими если вас не устраивает их скорость, использовать sequence там где просто mapReduce обработка, добавить подсказки компилятору
Да, можно коллеги уже тестили. В целом пока этом можно использовать если вы готовы писать проект с нуля, с либами которые заведомо не опираются на существование GIL.
Запускать на уже существующем проекте это конечно гарантированный способ поймать гонку состояний.
Основная ваша проблема что вы совершенно не понимаете смысл терминов, но при этом вы активно пытаетесь их использовать.
Python не однопоточный, он вполне себе многопоточный язык, но в котором есть GIL, а это уже само по себе разные вещи. Не говоря уже что там хватает асинхроных библиотек.
Во-вторых вы постоянно используете термина микросервисы, хотя их у вас нет. Микросервисы это определенная архитектура, а не запуск нескольких параллельных обработчиков запросов. У вас что если поднять монолит на двух серверах и поставить балансировщик нагрузки, то монолит превратиться в микросервис?
В-третьих, там есть параллельность через мультипроцессинг, да это не так удобно и хорошо как параллелизм в общем пространстве памяти, но что есть. Кстати сама по себе многопоточность без gil не гарантирует параллельности, это разные понятия.
Вот представьте, я бы написал статью от том, как я начал писать на php оффлайн мобильные приложения и столкнувшись с асинхронного получения снимка с камеры сделал вывод о том что монолиты зло. Ваша статья выглядит примерно также.
>>> Просто я использую реальные знания, а не концепции из митапов и прочего Нет, вы используете какую чушь (видимо которую вам выдал искусственный идиот), Я знаю много претензий к пайтон, со многими вполне солидарен, но ваша статья выглядит как какая-то очень не смешная шутка.
Это тоже абсолютно решаемо, рас кажу как это сделано в Kotlin. Там при запуске корутины можно указать диспетчер корутин (один из встроенных или даже свою реализацию), который определит какой пул потоков использовать, и там есть диспетчер который запускает корутину всегда в главном потоке, который запускает в параллельном пуле, в специально io пуле.
Так что просто оставляем что по дефолту asyncio.run запускает всё в одном потоке, но опцией даем возможность передать диспетчер
И да, и нет. Если говорить о переменных которые в контексте текущего диспатчера корутин, то так и останется в этом дистпатчере, а переменные которые имеют какой-то глобальный доступ, так я и сейчас могу запустить отдельный тред из которого могу поменять значение между двумя вызовами async.
Никаких новых требований не предполагается, да переменные который не потокобезопасны, они остаются не потокобезопасными, но они и так всегда по умолчанию не потокобезопасны.
Не надо делать не потокобезопасные вызовы, неважно из корутины они делаются или из мультитрединга.
Вообще говоря нет, кроме того можно сделать эрзац вариант уже в текущем интерпретаторе: берем интерпретатор в no-gil сборке, а потом в отдельных потока запускаем свои EventLoop, у меня получился параллельные asyncio, внутри одно eventloopа естественно всё последовательно, но корутины из разных eventloopов могут работать параллельно в разных потоках
Вся статья строиться на измерениях текущей реализации asyncio, учитывающей GIL и работающей в одном потоке, но no GIL так же позволит переписать планировщик корутин, что бы он использовал пулы потоков и тогда async станет эффективным и в CPU bound задачах (за счёт параллельного выполнения корутин в разных потоках из пула).
Вообще глобально многопоточность и асинхронность корутин это не много ортогональные вещи, но если говорить с точки зрения практики, но корутины всегда в пределе будут эффективнее потоков, так потоки управляются внешним планировщиком ОС, а корутины внутренним и имеют больше информации для оптимизации потока выполнения.
О, работают аналогично компьютерам в СПРН (и полагаю аналогично другим похожим системам)
https://habr.com/ru/articles/1023600/
Быстрый гуглинг говорит, что для того что бы проблема была в инструкциях процессора он должен быть старше 20 лет 0_0
В литий-ионных аккумуляторах точно также используется ванадий, в той же роли и тех количествах, так что поэтому пункту паритет.
https://pikabu.ru/story/v_mire_vsego_4_natsionalnyikh_messendzhera_i_vse_oni_vyirosli_bez_blokirovok_13701603
Хабр уже не торт, буквально сегодня читал на пикабу (!) пост, который гораздо подробнее разбирает эту тему, и приходит к противоположенным выводам.
Плюс здесь автор явно передергивает факты
У вас устаревшие данные, в России уже появляется "собственный" процессор, как раз на архитектуре Loongson
Я вас удивлю, но в ядре и без "ржавого" постоянно обрубается старое и ненужное, либо что-то переписывается, есть даже релизы ядра в которых кода удаленно больше чем добавлено (чем разработчики очень довольны) --- из ядра постоянно выкидываются древние драйверы и переписываются подсистемы для повышения их перформанса/секьюрности.
Если посмотреть на то какие VPS люди арендуют, то можно заметить что они куда менее мощные чем их собственные компы, облако это далеко не только про мощность.
Будь у меня локально хоть 100 ядре и 500 гигов памяти, смысл ставить на свою машину тот же openVPn.
Ну, сначала по современному положил руки на wasd и мышь, чувствую неудобно, а поом вспомнил что раньше это делалось по другому и положи на правую на нумпад, а левую на ctrl,alt,space и без проблем зачистил уровень.
Извините за пассивно агрессивный тон, но дебажить это надо деббагером.
Мне лень прикреплять картинку, но IDE спокойно ставит брики внутри лямбд и спокойно проваливается внутрь функций
1) По ситуации. Заменять библиотечные функции, своими если вас не устраивает их скорость, использовать sequence там где просто mapReduce обработка, добавить подсказки компилятору
Да, можно коллеги уже тестили.
В целом пока этом можно использовать если вы готовы писать проект с нуля, с либами которые заведомо не опираются на существование GIL.
Запускать на уже существующем проекте это конечно гарантированный способ поймать гонку состояний.
Больше всего питонистов, потому что у гошников, джаваскрипетров и джавистов уже есть работа и им не надо её искать?
А если серьезно питон кончено входит в топ-10 языков для бэкенда, но он там один из, а не абсолютный лидер.
Основная ваша проблема что вы совершенно не понимаете смысл терминов, но при этом вы активно пытаетесь их использовать.
Python не однопоточный, он вполне себе многопоточный язык, но в котором есть GIL, а это уже само по себе разные вещи. Не говоря уже что там хватает асинхроных библиотек.
Во-вторых вы постоянно используете термина микросервисы, хотя их у вас нет. Микросервисы это определенная архитектура, а не запуск нескольких параллельных обработчиков запросов. У вас что если поднять монолит на двух серверах и поставить балансировщик нагрузки, то монолит превратиться в микросервис?
В-третьих, там есть параллельность через мультипроцессинг, да это не так удобно и хорошо как параллелизм в общем пространстве памяти, но что есть. Кстати сама по себе многопоточность без gil не гарантирует параллельности, это разные понятия.
Вот представьте, я бы написал статью от том, как я начал писать на php оффлайн мобильные приложения и столкнувшись с асинхронного получения снимка с камеры сделал вывод о том что монолиты зло. Ваша статья выглядит примерно также.
>>> Просто я использую реальные знания, а не концепции из митапов и прочего
Нет, вы используете какую чушь (видимо которую вам выдал искусственный идиот),
Я знаю много претензий к пайтон, со многими вполне солидарен, но ваша статья выглядит как какая-то очень не смешная шутка.
Это тоже абсолютно решаемо, рас кажу как это сделано в Kotlin.
Там при запуске корутины можно указать диспетчер корутин (один из встроенных или даже свою реализацию), который определит какой пул потоков использовать, и там есть диспетчер который запускает корутину всегда в главном потоке, который запускает в параллельном пуле, в специально io пуле.
Так что просто оставляем что по дефолту asyncio.run запускает всё в одном потоке, но опцией даем возможность передать диспетчер
И да, и нет.
Если говорить о переменных которые в контексте текущего диспатчера корутин, то так и останется в этом дистпатчере, а переменные которые имеют какой-то глобальный доступ, так я и сейчас могу запустить отдельный тред из которого могу поменять значение между двумя вызовами async.
Никаких новых требований не предполагается, да переменные который не потокобезопасны, они остаются не потокобезопасными, но они и так всегда по умолчанию не потокобезопасны.
Не надо делать не потокобезопасные вызовы, неважно из корутины они делаются или из мультитрединга.
Вообще говоря нет, кроме того можно сделать эрзац вариант уже в текущем интерпретаторе: берем интерпретатор в no-gil сборке, а потом в отдельных потока запускаем свои EventLoop, у меня получился параллельные asyncio, внутри одно eventloopа естественно всё последовательно, но корутины из разных eventloopов могут работать параллельно в разных потоках
Вся статья строиться на измерениях текущей реализации asyncio, учитывающей GIL и работающей в одном потоке, но no GIL так же позволит переписать планировщик корутин, что бы он использовал пулы потоков и тогда async станет эффективным и в CPU bound задачах (за счёт параллельного выполнения корутин в разных потоках из пула).
Вообще глобально многопоточность и асинхронность корутин это не много ортогональные вещи, но если говорить с точки зрения практики, но корутины всегда в пределе будут эффективнее потоков, так потоки управляются внешним планировщиком ОС, а корутины внутренним и имеют больше информации для оптимизации потока выполнения.
Ну разово 25 баксов, это не apple в котором каждый год 100, да ещё и закрытая ос.
Не на рекламу с донатами и же содержать инфраструктуру для андроида.