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

В джаве она есть, это не сильно помогает. Все равно никаких гарантий, что новый джун не забудет написать кейворд synchronized в critical section

пробрасывая immutable data structures?

копию пробрасывая...

копию пробрасывая...

Ух

копию пробрасывая...

ну это то же самое в данном контексте (только не иммутабл)

Мач перформанс

ой, перестаньте

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

это как? даже в случаи банального int надо юзать мьютекст уже

если сотворили глобальный счетчик какой либо

это как? даже в случаи банального int надо юзать мьютекст уже

Открой для себя атомики

да знаю про них

ну вот

они же мьютекс оборачивают?

нет, наоборот

они же мьютекс оборачивают?

не знаешь

они же мьютекс оборачивают?

Видимо не знаешь

это мутексы сделаны на атомиках

не знаю

в кишки не лезу по возможности

работаю по возможности как с "черным ящиком"

а надо бы знать, если на перформанс топить

обычно перфоманс явно просаживается не на уровне приложения

в кишки не лезу по возможности

Это базовые вещи в параллельном программировании, хм.

"барьеры памяти" в нем базовые. с тех пор, как в проце есть кеш, и ядер больше одного

копию пробрасывая...

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

на самом деле - это все вопрос дизайна

совершенно не обязательно шарить что попало

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

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

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

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

оставаясь в рамках го?

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

Они в го mpmc? (multiple producers, multiple consumers)

да

Понятно

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

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

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

либо код делающий что-то полезное феноменально быстр

увы, я на такое натыкался =(

Открой для себя атомики

они больно бьют

они больно бьют

каким образом больно бьют?

они больно бьют

Это как?

В го есть атомики?

#вакансия #go #python #ruby #MachineLearning #ML #офис #fulltime Всем привет! 🦋 Кто давно хотел перейти в разработку на Go? 😊 Сейчас именно тот момент! Готовы знакомиться с опытными разработчиками, имеющими разный бекграунд (Python/Ruby/Java) и готовых переходить на Go. О компании: стартап, этап активного формирования команды. О проекте: разработка платформы, позволяющей автоматически создавать решения на базе машинного обучения для бизнеса. Основные задачи: - Создание инфраструктурных решений - Выстраивание архитектуры приложений - Разработка и поддержка микросервисов г. Москва, м. Охотный ряд ЗП: 150 - 250к на руки Фултайм в офисе (Возможность иногда работать удаленно). C подробностями можно ознакомиться здесь: https://vacancy.newhr.ru/golang/4 С радостью отвечу на все вопросы по почте: marina@new.hr 😊 Вакансия представлена агентством https://newhr.ru/ Спасибо!

каким образом больно бьют?

https://fgiesen.wordpress.com/2014/08/18/atomics-and-contention/

многабукв. что там в двух словах? сброс кеша невовремя?

Это как?

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

сброс кеша невовремя...

многабукв. что там в двух словах? сброс кеша невовремя?

инвалидация линейки кеша везде. это дорого. очень.

альтернатив то нет. или есть?

ну и при contention атомики становятся еще более дорогими

для понимания ужаса можно посмотреть на http://htor.inf.ethz.ch/publications/img/atomic-bench.pdf

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

альтернатив то нет. или есть?

нет, да. точнее, атомики плохи при contention. когда несколько потоков используя атомики модифицируют одну и ту же переменную

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

В контексте разговора Mutex<int> (не баньте меня за генерики) против AtomicInt, голый атомик один хрен выгоднее

В контексте разговора Mutex<int> (не баньте меня за генерики) против AtomicInt, голый атомик один хрен выгоднее

зависит от сценария использования.

@pragus спасибо за статью.

зависит от сценария использования.

Инкремент из несколькох потоков. Внутри мутекса все равно атомик

ну и при contention атомики становятся еще более дорогими

дада, дороже чем мьютексы (которые на пару с каналами сделаны поверх атомиков) или каналы + WaitGroup, тоже норм тема

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

Инкремент из несколькох потоков. Внутри мутекса все равно атомик

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

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

и не шарить вообще никаких данных

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

Когда данные надо мутировать, это не прокатит Когда их мутировать не надо, блокировка и не нужна

Когда данные надо мутировать, это не прокатит Когда их мутировать не надо, блокировка и не нужна

ну... есть вот тот же rcu, например.

данные обычно мутировать не надо.

если чтения больше чем модификации, оно почти lockless )

и не шарить вообще никаких данных

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

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

ЕМНИП, в го нет удобных инструментов для организации параллельных вычислений без блокировок совсем. Вроде параллельных итераторов

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

еще когда я это написал, я подумал, что будет так. канал медленный по сравнению с мутексом и атомиком. потому, что в нем 3 мутекса, кажется. но! вы об этом никогда не узнаете!!!

если чтения больше чем модификации, оно почти lockless )

Я его для эльбруса реализовывал. Там таки спинлок и атомик. Возможно на платформах где есть барьеры памяти оно поэффективнее)

еще когда я это написал, я подумал, что будет так. канал медленный по сравнению с мутексом и атомиком. потому, что в нем 3 мутекса, кажется. но! вы об этом никогда не узнаете!!!

ну так и я почти о том же

еще когда я это написал, я подумал, что будет так. канал медленный по сравнению с мутексом и атомиком. потому, что в нем 3 мутекса, кажется. но! вы об этом никогда не узнаете!!!

То есть о том что мутекс и атомик могут тормозить мы узнали, а об этом не узнаем?)

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

Я его для эльбруса реализовывал. Там таки спинлок и атомик. Возможно на платформах где есть барьеры памяти оно поэффективнее)

а у вас есть живой эльбрус? )

а у вас есть живой эльбрус? )

Даже не один х)

Даже не один х)

Вы из мцст?

Ага

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

ну как угодно 😊 Просто ты предоставляешь лишний интерфейс к компоненту 😊 То есть такого рода компонент должен быть инкапсулирован, за атомарность операций должен отвечать непосредственно публичный метод. По поводу тестов, тестировать нужно все 😊 Даже простые функции, пусть она просто складывает 2 + 2.

По поводу тестов, тестировать нужно все 😊 Даже простые функции, пусть она просто складывает 2 + 2. С этим не соглашусь

Человек, возможно, из мира динамической типизиции пришел, где тестировать нужно всё, чтобы не огребать от проблем с типами

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

ну обычно тестят внешний API и ещё какие-то сложные функции.