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

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

Пофигу на что?

на задержки сборщика

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

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

а как?

любая фабрика - указатель

более того

хочешь корректные нулы в json - в структуре пили указатели

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

это старый доклад

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

а как?

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

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

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

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

Май 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), т.к. область памяти специальная и сборщик про это знает.

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

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

В алибабе на Яве сделали, что а вообще мусор не собирается, условно до наступления ночи...

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

/report

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

Там две ответ на вопрос о том как он работает :)

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

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." Непонятно чему верить. Есть более свежие данные?

Докладу. В го принципы работы гц не поменялись. В общем такое поведение это цена за быструю stop the world фазу

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

Не хранить указатели, а максимально использовать структуры по значению?

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

Ну а как иначе в языке где нет альтернативы сборщику мусора? Можно переписывать узкие места на каком нибудь расте как в дропбоксе делают, можно написать свой аллокатор как в убере

Первое дороже

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

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

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

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

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

На чем тогда люди решают такие задачи? На плюсах?

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

См. выше ссылку на доклад из Убера.

Я не знаю ГО, но по-любому в языке механизмы для управления памятью... Не зря же они тащат совместимость с С.

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

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

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

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

Компилируют на клиентах

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

зато они зарабатывают больше тебя)

Убер то? Ок

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

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

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

на смартфоне :)

А вообще такая критика доставляет. Не нравится - не пользуйся. Есть решение - напиши им письмо. Я в Азии живу и тут grab отжал рынок. Убер вообще норм был по сравнению

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

Grab хоть и топят за go но сам продукт и клиент не удобный

А вообще такая критика доставляет. Не нравится - не пользуйся. Есть решение - напиши им письмо. Я в Азии живу и тут grab отжал рынок. Убер вообще норм был по сравнению

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

В этом чате точно всем плевать на убер.

жаль (

хороший сервис

только ПО не очень :)

только ПО не очень :)

функция хорошая, а код - г..но)))

ага

go-bindata депрекейтнули. Чо юзать для встраивания файликов в прогу на Го? Пока остановился на packr, но он глуп, не умеет в абсолютные пути

продолжайте использовать go-bindata, если он вас устраивает

Я тут mtproto обкатываю, поднял прокси для телеги, если кому нужно tg://proxy?server=185.205.210.186&port=443&secret=28903022c71ae67961d00ecacea6e0de

Я тут mtproto обкатываю, поднял прокси для телеги, если кому нужно tg://proxy?server=185.205.210.186&port=443&secret=28903022c71ae67961d00ecacea6e0de

Не кликабельно, добавь http

Это не хттп протокол, а телеграма.

Кликабельно ток с телефона

продолжайте использовать go-bindata, если он вас устраивает

пожалуй так сделаю

Кликабельно ток с телефона

У тебя скорее всего старая телега на компе

Обнови

У тебя скорее всего старая телега на компе

Возможно

Тг щас без прокси начала работать, странно. Первый раз такое после блокировки.

Это очень не стабильно, пол Новосибирска связь потеряли уже

Тг щас без прокси начала работать, странно. Первый раз такое после блокировки.

С фото иногда проблемы бывают

ERROR: S client not available

+

go-bindata депрекейтнули. Чо юзать для встраивания файликов в прогу на Го? Пока остановился на packr, но он глуп, не умеет в абсолютные пути

fileb0x

fileb0x

спасибо

спасибо

github.com/vektah/gqlgen

юзаешь?

юзаешь?

не, не видел до сих пор. спасбо

есть еще пяток генераторов, но этот поадекватнее

github.com/vektah/gqlgen

выглядит интересно

есть еще пяток генераторов, но этот поадекватнее

судя по докам он очень ок

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

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

конечно. но старайся сначала в гугл заглянуть

У меня такая проблема: пользователь вводит последовательность чисел. Если в течении 10 секунд ничего не было введено - программа выполняет определенные действия. Как правильно построить цикл (или это вообще должен быть свитч), чтобы программа сама по истечению 10 секунд выполняла определенное действие? Сейчас у меня выходит так, что после 10 секунд программа никак не реагирует, но если ввести число (когда время уже закончилось), то действие выполняется.

каналы, таймер, select

У меня такая проблема: пользователь вводит последовательность чисел. Если в течении 10 секунд ничего не было введено - программа выполняет определенные действия. Как правильно построить цикл (или это вообще должен быть свитч), чтобы программа сама по истечению 10 секунд выполняла определенное действие? Сейчас у меня выходит так, что после 10 секунд программа никак не реагирует, но если ввести число (когда время уже закончилось), то действие выполняется.

time.After

Кажется что пару дней назад на соседнем канале это уже было

сейчас у меня примерно так: timeout := time.After(10 * time.Second) for { select { case <-timeout: //some action default: //default action } }

Кажется что пару дней назад на соседнем канале это уже было

на этом же

если у тебя внутри select делается break в надежде выйти из цикла, то из цикла ты не выйдешь

https://stackoverflow.com/q/11104085

если у тебя внутри select делается break в надежде выйти из цикла, то из цикла ты не выйдешь

break нет, но есть continue label

Может ли быть связано такое торможение таймера ожидаем ввода?

Может ли быть связано такое торможение таймера ожидаем ввода?

Как на счёт сделать как в примере выше дали?

Как на счёт сделать как в примере выше дали?

Я так и делаю. Выводится "+", а дальше идет ожидание ввода от пользователя и ничего не происходит.

Я так и делаю. Выводится "+", а дальше идет ожидание ввода от пользователя и ничего не происходит.

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

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

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

так не бывает

Может, кинуть код? Наверняка я где-то напортачил

ну - да, без кода тут говорить не о чем

https://repl.it/repls/RelevantMediumorchidBash

у тебя все в одном потоке выполняется