Я вот реально начал въезжать в корутины только когда сел и написал свой планировщик (да, на PHP). До этого вроде пользуешся - прикольно, а понимания как оно внутри нет

Для тех кто хочет побаловаться с корутинами в PHP стоит начать отсюда: https://nikic.github.io/2012/12/22/Cooperative-multitasking-using-coroutines-in-PHP.html

B плавно перетекать сюда: https://amphp.org/

пхп - не торт

всем добрый день)

Я вот реально начал въезжать в корутины только когда сел и написал свой планировщик (да, на PHP). До этого вроде пользуешся - прикольно, а понимания как оно внутри нет

а чем корутины отличаются от горутин?

Тем что могут распределяться по go машинам и выполняться паралельно почти без накладных расходов

Тем что могут распределяться по go машинам и выполняться паралельно почти без накладных расходов

распределяться по go машинам, это что значит вообще?

Goтермины (с)

по сути умеют в многоядерность / многопоточность

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

агрегатор и парсер каких-нибудь апишек, с ограничением по одновременным вызовам, с задержками. вон на megogo тестовое мне нравится. ща найду

фетч данных с публичного апи dribbble, вытащить фоловеров, лайкеров, посты т.е. там граф связанных данных, потом агрегация чтобы посчитать топ юзеров. Основная фишка в том что у дрибла реквест лимиты, но он в ответе присылает timestamp когда можно сделать следующий запрос и нужно это все красиво сделать не прибегая к Thread.sleep.

по сути умеют в многоядерность / многопоточность

конкурентность или параллелизм ?

Goтермины (с)

ткни пальцем где "го машина"

Я для себя выбрал в качестве примера агрегатор авиабилетов. Вполне себе юзкейс

Типа миллиона аналогичных сервисов по поиску самых дешёвых вариантов

ну или так

>не прибегая к Thread.sleep вот тут и нужны неблокирующие операции

ткни пальцем где "го машина"

Не могу сходу оригинал найти про то как устроен планировщик в го. Кратко на русском тут: https://habrahabr.ru/post/141853/

короче кому влом читать статью го машина == поток

конкурентность или параллелизм ?

Хороший вопрос. Насколько я разобрался в Go оно может и так и так :) Могу быть не прав, если есть адепты го - поправьте.

и фиксируется в рантайме

Классические корутины конечно только конкурентность

Хороший вопрос. Насколько я разобрался в Go оно может и так и так :) Могу быть не прав, если есть адепты го - поправьте.

конкуретности там нет почти.

Хороший вопрос. Насколько я разобрался в Go оно может и так и так :) Могу быть не прав, если есть адепты го - поправьте.

вообще го про конкурентность!

конкуретности там нет почти.

ммм?!? )))

Классические корутины конечно только конкурентность

мультитаскинг вообще-то

мультитаскинг вообще-то

https://habrahabr.ru/company/piter/blog/274569/

мультитаскинг вообще-то

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

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

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

ой

https://habrastorage.org/files/ac1/f18/7d1/ac1f187d1d4b470a9dbad532754ee7f7.png

по моему эта картинка все объясняет

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

Имхо ты не прав. Конкурентность === мультитаскинг. Даже по изображение снизу видно. А вот параллельность это как раз два потока, ядра, процесса, etc.

Точнее даже не так

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

оле!

так вот вопрос был про go

и go это про конкурентность

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

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

конкурентный в моем понимании это когда идет гонка за ресурсами. i/O например.

и процессорное время. В этом плане обычный однопоточный event loop это просто мультиплексирование операций работы с I/O. Для этого не обязательно иметь потоки/процессы дополнительные. Просто в случае с go ты не ограничиваешь себя одним процессом что еще больше дает простора для ресурсов.

в erlang та же тема

в erlang та же тема

а в Haskell как?

а в Haskell как?

а в хаскеле есть какие-то подобные примитивы как горутины или микротреды эрланговские?

а в хаскеле есть какие-то подобные примитивы как горутины или микротреды эрланговские?

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

https://wiki.haskell.org/Concurrency#GHC_concurrency_specifics

STM Haskell и parallel Haskell

о хаскель в ооп чате я все ждал когда же начнется

о хаскель в ооп чате я все ждал когда же начнется

началось где-то на 3-ией день существования этого чата на самом деле

я пропустил, но святые срачи ооп vs фп

знатоки, поясните плз, почему переключение горутин такое быстрое?

знатоки, поясните плз, почему переключение горутин такое быстрое?

потому что его нет?)

контекст свитчинг происходит не на уровне операционки а на уровне рантайма языка

вот именно

и от того намного проще и эффективнее

более высокоуровневая операция, по идее

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

?

вопрос специализации скорее

http://blog.nindalf.com/how-goroutines-work/ > Goroutines are scheduled cooperatively and when a switch occurs, only 3 registers need to be saved/restored - Program Counter, Stack Pointer and DX. The cost is much lower. почему так?

http://blog.nindalf.com/how-goroutines-work/ > Goroutines are scheduled cooperatively and when a switch occurs, only 3 registers need to be saved/restored - Program Counter, Stack Pointer and DX. The cost is much lower. почему так?

в смысле почему так? ты ж привел ответ почему

можешь погуглить что происходит когда диспетчеризацией операционка занимается

мм, за счёт чего достигается такая лёгкость контекста?

и сколько она там всего еще делает

за счет того что реализовано в рантайме языка.

для упрощения, представь что ты делаешь многопоточность в юзерспейсе

а точнее это просто event loop

хм

и ты пишешь свой диспетчер который разруливает кто в каком порядке выполняется

и поскольку ты все делаешь сам - у тебя руки развязаны делать это так как тебе того надо

и ты можешь оптимизировать все что только можно, выкидывая то что тебе не надо

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

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

то есть профит по производительности за счет узкой специализации алгоритмов

я прост не понимаю, почему тогда джава машина не умеет так же? есть какое-то кардинальное различие между горутинами и тредами, которое я не улавливаю? или дело в заведомо невыгодном решение маппить джава тред на ос тред 1:1, которое уже не просто изменить?

спасибо за разжёвывание, стало понятней)

я прост не понимаю, почему тогда джава машина не умеет так же? есть какое-то кардинальное различие между горутинами и тредами, которое я не улавливаю? или дело в заведомо невыгодном решение маппить джава тред на ос тред 1:1, которое уже не просто изменить?

потому что джава машина оперирует тредами а не горутинами

для джавы есть например файберы

не знал про них, пойду почитаю, спасибо

http://blog.paralleluniverse.co/2016/05/03/skynet-go-quasar/