Телеграмм чат группы prophp7 страница 10892

02:23пожаловаться #1

A

Sergey Protko

оба асинхронны, если мы про ноду (где у тебя на самом верху в main program flow будет просто запуск и ожидание конца).

Но теперь еще более упоротая мысль. в ноде сейчас зарелизили top level await. И мы технически можем второй пример назвать main program flow. Можем ли мы говорить что теперь это синхронный код?)

Да хз. Наверное можем.

02:25пожаловаться #2

A

Короче надо прекращать о терминах спорить.

02:26пожаловаться #3

SP

вообще скорее всего проблема в подмене понятий "много поточность" "асинхронность" и "многозадачность"

02:28пожаловаться #4

SP

preemptive (твои любимы грин треды) vs cooperative multitasking

02:29пожаловаться #5

SP

асинхронность и синхронность проще понимать по тому в каком порядке относительно записи в коде возникают ивенты. Что мол порядок выполнения программы отличается от основного потока выполнения программы.

Классический пример - подписались на события и сделали просто run который хз в каком порядке чего будет выполнять.

Паралельность - возможность совмещать "ивенты" во времени.

02:31пожаловаться #6

A

Sergey Protko

preemptive (твои любимы грин треды) vs cooperative multitasking

Ну, мне кажется оно cooperative multitasking только потому, что так это проще реализовать, а не потому что это несет какие-то особые преимущества.
В том же го перешли от cooperative к preemptive.
Точно так-же и динамическая типизация появилась только потому, что не знали как хорошо и просто делать статику. А сейчас появляется и в пхп и в питоне и в руби.

SP

Ну, мне кажется оно cooperative multitasking только потому, что так это проще реализовать, а не потому что это несет какие-то особые преимущества.
В том же го перешли от cooperative к preemptive.
Точно так-же и динамическая типизация появилась только потому, что не знали как хорошо и просто делать статику. А сейчас появляется и в пхп и в питоне и в руби.

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

02:33пожаловаться #8

SP

а ты подумай о например планировщике процессов твоей операционки

02:33пожаловаться #9

SP

там же тоже вытесняющая многозадачность с приоритизацией

02:33пожаловаться #10

SP

а в допотопных досах была кооперативная

02:33пожаловаться #11

A

Google начал открытие реализации модели потоков M:N

Sergey Protko

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

А может и легковесные потоки на уровне оси реализуют.
https://www.opennet.ru/opennews/art.shtml?num=53443

www.opennet.ru

Компания Google предложила для включения в состав ядра Linux первый набор патчей с реализацией компонентов, необходимых для обеспечения работы модели потоков M:N. Инициатива Google связана с открытием развивавшегося за закрытыми дверями API SwitchTo для ядра Linux, обеспечивающего работу реализованной в пространстве пользователя многопоточной подсистемы, применяющей модель потоков M:N. Подсистема используется в Google для обеспечения работы сервисов, требующих минимальных задержек. Планирование и управление распределением потоков производится целиком в пространстве пользователя, что позволяет существенно снизить число операций переключения контекста за счёт минимизации выполнения системных вызовов.

02:36пожаловаться #12

SP

Google начал открытие реализации модели потоков M:N

Aleksandr Khristenko

А может и легковесные потоки на уровне оси реализуют.
https://www.opennet.ru/opennews/art.shtml?num=53443

www.opennet.ru

Компания Google предложила для включения в состав ядра Linux первый набор патчей с реализацией компонентов, необходимых для обеспечения работы модели потоков M:N. Инициатива Google связана с открытием развивавшегося за закрытыми дверями API SwitchTo для ядра Linux, обеспечивающего работу реализованной в пространстве пользователя многопоточной подсистемы, применяющей модель потоков M:N. Подсистема используется в Google для обеспечения работы сервисов, требующих минимальных задержек. Планирование и управление распределением потоков производится целиком в пространстве пользователя, что позволяет существенно снизить число операций переключения контекста за счёт минимизации выполнения системных вызовов.

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

Так же и с планировщиком задач. Твой рантайм может лучше знать и иметь больше информации о принятии решений для того что бы наиболее эффективно утилизировать CPU.

А то что ты скинул скорее всего просто другой набор сисколов какой который снижает накладные расходы

02:38пожаловаться #13

АГ

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

13:57пожаловаться #14

NO

Nex Otaku in PHP

В чëм заключается легковесность потоков от гугла? Если они на уровне оси работают, там один фиг останется conext switch

13:58пожаловаться #15

AM

Artem Molotov in PHP

Алексей Гевондян

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

Уверен, что достаточно разобрался, что бы писать статью, которая ещё и будет опубликована неизвестному кругу обучающихся лиц?

13:58пожаловаться #16

АГ

тут не столько о программировании, сколько о подходам к решению нескольких задач разными способами, на примере из жизни)

13:59пожаловаться #17

АГ

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

14:01пожаловаться #18

АГ

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

14:02пожаловаться #19

NO

Nex Otaku in PHP

Самая производительная система, как по мне, это N воркеров (процессов) на N + 1 ядер процессора, по ядру на воркер и плюс ядро на систему.

В каждом воркере обработчик сообщений плюс event loop для обработки асинхронных действий, чтобы ядро не простаивало. Тогда будет минимум оверхеда и эффективность максимальная.

Ну ещë можно постараться убрать все системные вызовы, чтобы вообще не блочилось.

Что будет быстрее такой схемы, не представляю.