shared mutable state без мьютексов говорите? что-то я вам не верю, коллега

С разморозкой https://ru.m.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C

Я ещё раз повторяю. Можно спокойно написать многопоточный код, который будет практически совпадать с кодом на Го, просто он будет куда менее эффективным, потому что вместо горутин там будут обычные потоки.

обычные потоки менее эффективны горутин? с чего такое мнение?

green thread'ы в C, это таки не green thread'ы в констексте runtime'а языка

Ну да, только голый си и никаких библиотек

С разморозкой https://ru.m.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C

транзакции это банальный mutex под капотом, али нет?

обычные потоки менее эффективны горутин? с чего такое мнение?

Горутины чего-то стоят

обычные потоки менее эффективны горутин? с чего такое мнение?

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

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

вот я чёт сомневаюсь что горутины производительнее потоков в этом плане. Но это надо мерить, тут гадать не стоит.

транзакции это банальный mutex под капотом, али нет?

А это уже детали реализации

Да и там не все так просто

вот я чёт сомневаюсь что горутины производительнее потоков в этом плане. Но это надо мерить, тут гадать не стоит.

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

А это уже детали реализации

проблема в том что так или иначе mutable shared state требует синхронизации. Самая низкоуровневая примитива синхронизации это mutex, он в основе всех механизмов синхронизации. lock-free алгоритмы и структуры существуют, но не все проблемы решают, зависит от задачи. Порой mutex просто неизбежим

проблема в том что так или иначе mutable shared state требует синхронизации. Самая низкоуровневая примитива синхронизации это mutex, он в основе всех механизмов синхронизации. lock-free алгоритмы и структуры существуют, но не все проблемы решают, зависит от задачи. Порой mutex просто неизбежим

ну нет же

мьютекс - не самый низкоуровневый

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

вот и я о чём. горутины это про простое написание конкурентного приложения. в то время как для решение конкретных низкоуровневых задач thread pool'ы лучше

а чем горутина так принципиально отличается от потока?

мьютекс - не самый низкоуровневый

а что тогда?

а что тогда?

атомарные операции

это по моему самое низкоуровневое из всех

а чем горутина так принципиально отличается от потока?

тем что она не поток а лишь абстракция над ним которая обходится тебе ценой user-space runtime scheduler'а и 4кб памяти?

атомарные операции

ну может быть ты и прав, да

тем что она не поток а лишь абстракция над ним которая обходится тебе ценой user-space runtime scheduler'а и 4кб памяти?

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

то есть можно в теории запилить реализацию го, в которой вместо горутин будут тупо потоки

и никто особо не заметит разницы, пока этих потоков не станет слишком много

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

не стоит сравнивать системные потоки и горутины, это таки совершенно разные вещи горутина например не знает приоритета. А системный scheduler может приоризировать потоки

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

например представь себе игровой движок где у тебя рендеринг в горутине 0, физика в 1-10, а акторы AI в 10-10.000 проблема в том, что с scheduler'ом Go мы не сможем приоризировать горутину 0, хотя это было бы полезно чтобы не терять кадры в том случае, когда runtime больше занять вычислением AI..

с потоками можно приоризировать rendering thread дабы не терять кадры

ну тут уже да, абстракция немножко протекает

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

нет, никак, вообще никак, потому-что goroutine scheduler понятия не имеет какая из горутин важнее, ему плевать

нет, никак, вообще никак, потому-что goroutine scheduler понятия не имеет какая из горутин важнее, ему плевать

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

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

(но так делать конечно же не надо)

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

Гипотетически - да, практически - нет. У гугла нет планов встраивать приоритеты в Go scheduler ибо для таких вещей как коллективная обработка запросов API - она не нужна, а 3D движок на Go никто писать не будет. Однако я считаю можно бы конечно было и добавить, чтоб некоторые горутины намеренно планировались на приоризированных системных потоках или вообще запускались в своих отдельных.. было бы круто, но я не знаю какие этому могут быть последствия

нет, IPC это вам не shared memory, он дорого обойдётся как в плане написания кода так и в плане производительности

современные ОС меняют приоритеты потоков динамически, если поток computation bound - приоритет снижается, если он I/O bound - то повышается, чтобы сделать систему более отзывчивой

потоки на которых запускаются горутины - не исключение

Гипотетически - да, практически - нет. У гугла нет планов встраивать приоритеты в Go scheduler ибо для таких вещей как коллективная обработка запросов API - она не нужна, а 3D движок на Go никто писать не будет. Однако я считаю можно бы конечно было и добавить, чтоб некоторые горутины намеренно планировались на приоризированных системных потоках или вообще запускались в своих отдельных.. было бы круто, но я не знаю какие этому могут быть последствия

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

потоки на которых запускаются горутины - не исключение

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

нет, IPC это вам не shared memory, он дорого обойдётся как в плане написания кода так и в плане производительности

Вообще-то нет. Те же двери на солярке дешевые

что значит помехи?

Вообще-то нет. Те же двери на солярке дешевые

IPC всегда дороже и сложнее shared process memory

это будет работать так, поток ОС выполяет горутину, считающую какую-нибудь математику - ОС понизит динамический приоритет

что значит помехи?

потерянные кадры из-за того что выполняются AI акторы нежели rendering в нужное время

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

IPC всегда дороже и сложнее shared process memory

Правильно сделанный ipc - нет. См solaris doors

Правильно сделанный ipc - нет. См solaris doors

без понятия о Solaris'е, я к нему даже никогда не прикасался

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

Правильно сделанный ipc - нет. См solaris doors

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

Гипотетически - да, практически - нет. У гугла нет планов встраивать приоритеты в Go scheduler ибо для таких вещей как коллективная обработка запросов API - она не нужна, а 3D движок на Go никто писать не будет. Однако я считаю можно бы конечно было и добавить, чтоб некоторые горутины намеренно планировались на приоризированных системных потоках или вообще запускались в своих отдельных.. было бы круто, но я не знаю какие этому могут быть последствия

Ты можешь запустить в отдельном.

Ты можешь запустить в отдельном.

процессе?) удачи в IPC)

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

Там просто и изящно: процесс экспортирует набор своих функций. Вызывающий код оказывается в контексте вызываемого процесса

процессе?) удачи в IPC)

Да в чем проблема с ipc? Что ж вы так его демонизируете?

Там просто и изящно: процесс экспортирует набор своих функций. Вызывающий код оказывается в контексте вызываемого процесса

короче не буду спорить по солярису, я его не знаю)

если разные процессы то да, конечно

Да в чем проблема с ipc? Что ж вы так его демонизируете?

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

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

Кольцо в shm

И никаких копий

Кольцо в shm

shared memory это весчь прикольная, но не кросс-платформенная

shared memory это весчь прикольная, но не кросс-платформенная

А где ее нет?

ERROR: S client not available

А где ее нет?

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

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

На андроиде есть

надо разбираться. Факт в любом случае что кросс-платформенный бескопромиссный shared memory это вам не переменную прочитать/записать... это гораздо сложнее

Ну и копирование само по себе дешёвое

И оно становится заметным только на больших объемах

Перечитал и все ок

И оно становится заметным только на больших объемах

ну в этом то и проблема

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

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

Только в циклах. Создать мапу, загнать туда значения из одного слайса и потом проветить вначения второго слайса. Хотя если мелкий слайс, то без мапы может быстрей выйти.

Только в циклах. Создать мапу, загнать туда значения из одного слайса и потом проветить вначения второго слайса. Хотя если мелкий слайс, то без мапы может быстрей выйти.

спасибо!

Привет, а куда пропал https://gopkg.in/telegram-bot-api.v4 ?

Привет, а куда пропал https://gopkg.in/telegram-bot-api.v4 ?

а зачем он?

@toby3d вроде как получше запилил

@toby3d вроде как получше запилил

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

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

https://github.com/zelenin/grabot

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

Если корень сложности в примерах, то скоро запилю

Работаю. Не всегда есть время. Плюс я доделываю сейчас биндинги паспорта

А так, вроде, @madgopher пощупал и даже остался доволен

А так, вроде, @madgopher пощупал и даже остался доволен

+

а я тут к вам с оффтопным аккордеоном: https://github.com/kitlang/kit

Если корень сложности в примерах, то скоро запилю

Неплохо было бы побольше примеров, спасибо

Неплохо было бы побольше примеров, спасибо

API уже более-менее замораживается, так что как добью паспорт - займусь примерами

Сам механизм паспорта готов, нужно только оформить подобающе

API уже более-менее замораживается, так что как добью паспорт - займусь примерами

что значит замораживается?

что значит замораживается?

Приходит в стабильное состояние и практически не меняется с внесением новых фич

что значит замораживается?

frozen api/stable api

Приходит в стабильное состояние и практически не меняется с внесением новых фич

Жду примеров)

Жду примеров)

Без фидбека трудно понять что надо улучшить, так что - welcome: https://gitlab.com/toby3d/telegram

Без фидбека трудно понять что надо улучшить, так что - welcome: https://gitlab.com/toby3d/telegram

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