Да я сам по себе-без тимлида)

Осталось теперь что бы это завелось)

1. Сканирует проект и создает vendor.yml : govend -v -l 2. Если надо развернуть : копируете код и сохраненный vendor.yml, далее govend -v и все.... помоему проще....https://github.com/govend/govend

dep, is an official experiment for the dependency tool. It is currently being implemented, in pre-alpha state and should be used with caution as "Lots of functionality is knowingly missing or broken"

Всем, привет! Вот такое задание: есть слайс с обьектами из бд далее в цикле мы переверяем на несколько условий каждый елемент, если все ок, то добавляем этот елемент в новый слайс. вопрос: как мы можем эту проверку распаралелить?

Всем, привет! Вот такое задание: есть слайс с обьектами из бд далее в цикле мы переверяем на несколько условий каждый елемент, если все ок, то добавляем этот елемент в новый слайс. вопрос: как мы можем эту проверку распаралелить?

кстати, @zelenin это не твои либы я видел в yii2?)

Нормальная тема писать игровой сервер на го?

Никто тут не спрашивал и вот опять

ну по идее должно быть пофигу

Я на это обычно ссылку на этот доклад даю: https://www.usenix.org/conference/srecon17asia/program/presentation/sibiryov

Очень интересный доклад. На вопрос "а как работает сборщик в Go?" дан ответ "в продакшене Убера сборщик сжирает 75% времени процессора на фоновое сканирование указателей" (при размере кучи 96ГБ). Как с этим бороться: радикально уменьшать количество указателей в структурах данных.

а как?

ну по идее должно быть пофигу

двухлетней давности =)

1) заменять указатели дескрипторами; пример из доклада: использовать uintptr и кастовать его в *T при необходимости; утверждается, что в стандартной библиотеке Go такое часто делают; 2) минимизировать количество копий указателей; чтобы сборщик не удалил объект, достаточно сохранять всего 1 указатель на него; остальные указатели по возможности заменить на слабые uintptr; в идеале хранить 1 указатель на слайс однотипных объектов, не хранить указатели на индивидуальные ячейки слайса, вместо них хранить индексы или uintptr; 3) хранить максимум данных в специальных областях памяти, несканируемых сборщиком; например, в sync.Pool или в кастомном аллокаторе написанном кривыми добрыми руками (в докладе есть пример); при этом можно хранить указатели на объекты в этой области памяти, gc не будет по ним следовать вообще (кастомный вариант) или будет следовать по ним с большей эффективностью (вариант sync.Pool), т.к. область памяти специальная и сборщик про это знает.

Очень интересный доклад. На вопрос "а как работает сборщик в Go?" дан ответ "в продакшене Убера сборщик сжирает 75% времени процессора на фоновое сканирование указателей" (при размере кучи 96ГБ). Как с этим бороться: радикально уменьшать количество указателей в структурах данных.

1) заменять указатели дескрипторами; пример из доклада: использовать uintptr и кастовать его в *T при необходимости; утверждается, что в стандартной библиотеке Go такое часто делают; 2) минимизировать количество копий указателей; чтобы сборщик не удалил объект, достаточно сохранять всего 1 указатель на него; остальные указатели по возможности заменить на слабые uintptr; в идеале хранить 1 указатель на слайс однотипных объектов, не хранить указатели на индивидуальные ячейки слайса, вместо них хранить индексы или uintptr; 3) хранить максимум данных в специальных областях памяти, несканируемых сборщиком; например, в sync.Pool или в кастомном аллокаторе написанном кривыми добрыми руками (в докладе есть пример); при этом можно хранить указатели на объекты в этой области памяти, gc не будет по ним следовать вообще (кастомный вариант) или будет следовать по ним с большей эффективностью (вариант sync.Pool), т.к. область памяти специальная и сборщик про это знает.

Май 2017. Доклад подготовлен по более старому опыту работы с Go, разумеется. Кстати, в докладе Андрей показывает статистику, в которой паузы gc занимают ~5 мс, а в release notes 1.8 (август 2016) хвастают: "Garbage collection pauses should be significantly shorter than they were in Go 1.7, usually under 100 microseconds and often as low as 10 microseconds." Непонятно чему верить. Есть более свежие данные?

1) заменять указатели дескрипторами; пример из доклада: использовать uintptr и кастовать его в *T при необходимости; утверждается, что в стандартной библиотеке Go такое часто делают; 2) минимизировать количество копий указателей; чтобы сборщик не удалил объект, достаточно сохранять всего 1 указатель на него; остальные указатели по возможности заменить на слабые uintptr; в идеале хранить 1 указатель на слайс однотипных объектов, не хранить указатели на индивидуальные ячейки слайса, вместо них хранить индексы или uintptr; 3) хранить максимум данных в специальных областях памяти, несканируемых сборщиком; например, в sync.Pool или в кастомном аллокаторе написанном кривыми добрыми руками (в докладе есть пример); при этом можно хранить указатели на объекты в этой области памяти, gc не будет по ним следовать вообще (кастомный вариант) или будет следовать по ним с большей эффективностью (вариант sync.Pool), т.к. область памяти специальная и сборщик про это знает.

треш, угар и _содомия_

Согласен. Сжирать 75% ядер в продакшен-кластере на "бег на месте" это как-то слишком. Надеюсь, это поведение улучшат.

Смотря что гоняется через сервер. Иногда во время игры задержки gc недопустимы

а где это 75% на бег по кругу?

Очень интересный доклад. На вопрос "а как работает сборщик в Go?" дан ответ "в продакшене Убера сборщик сжирает 75% времени процессора на фоновое сканирование указателей" (при размере кучи 96ГБ). Как с этим бороться: радикально уменьшать количество указателей в структурах данных.

Думал, почему убер так тормозит и садит батарейку в телефоне? Оказывается, они не умеют писать программы и не знали, что оверзед в любом full scan gc пропорционален количеству указателей на объекты. Написали на го инмемори сторейдж на указателях и хотят, чтобы он быстро работал на стогиговом зипе с миллиардом указателей :) Бракоделы!!!

Думал, почему убер так тормозит и садит батарейку в телефоне? Оказывается, они не умеют писать программы и не знали, что оверзед в любом full scan gc пропорционален количеству указателей на объекты. Написали на го инмемори сторейдж на указателях и хотят, чтобы он быстро работал на стогиговом зипе с миллиардом указателей :) Бракоделы!!!

еще и запускают серверную часть на абонентских устройствах! раз батарейка садится