Go Newsletter

Вот реализация мапы https://tip.golang.org/src/sync/map.go работать должна со скоростью map[interface{}]interface{} с мьютексом

type T1 = T2 вот это вроде круть)

monotonic time наконец то впиливают

Там еще сверху нахуевечено с atomic.Value, так что вангую, что будет работать чуть медленее. С другой стороны, sync.Map это абстракция, которая делает код чище, в большинстве случаев замедление будет незаметно :) К сожалению сейчас не могу побенчить, может кто-нибудь еще проверит и покажет нам результаты

Я правильно понимаю, что при добавлении mutex скорость работы мапы ограничится одним процом?

Я правильно понимаю, что при добавлении mutex скорость работы мапы ограничится одним процом?

Если атомик используется, то могут паралельные быть обращения к разным элементам (кроме вставки и удаления)

Надо смотреть.

Попробовал, вроде кушает все процы

Я правильно понимаю, что при добавлении mutex скорость работы мапы ограничится одним процом?

там скорее всего мьютекс нужен для вставки, на чтение там ничего нет

Почему все гоферы помешаны на скорости? Я пишу код первым попавшимся способом, и всё равно всё летает как ракета.

тоже пишу как знаю с оглядкой на эффективный го

там скорее всего мьютекс нужен для вставки, на чтение там ничего нет

не может быть такого

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

мьютекс и атомик местами есть в методе Load

Там два раза мапа хранится, одна с атомником только на чтения, вторая с мьютексом для записи

у го точно потребление памяти меньше джавы?

у го точно потребление памяти меньше джавы?

это да

а может есть статья какая-нибудь? с графиками?

https://benchmarksgame.alioth.debian.org/u64q/go.html

смотри память

спасибо, а не на числодробилках сравнение?

а правда что gc не упаковывает память в го и она фрагментируется?

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

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

Типа потребления памяти в геометрической прогрессии? Сначала 1кб, потом 2кб, затем 4кб и т.д.? 😄

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

по умолчанию 100%, т.е. столько сколько уже есть выделить

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

Попробовал, вроде кушает все процы

Мой итог тестов на коленке - mutex замедляет параллельную вставку в мапу в ~2.3 раза по сравнению с последовательной вставкой

а правда что gc не упаковывает память в го и она фрагментируется?

Го гц просто берёт данные кредитки хозяина и докупает оперативы у гугли

Го гц просто берёт данные кредитки хозяина и докупает оперативы у гугли

А гугля крадёт чужую оперативку через Chrome

экономика потребления

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

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

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

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

То есть отдавал оперативу обратно?

Только что попробовал на 1.8.3 - залил в мапу кучу элементов. Потом поочереди все удалил из мапы delete'ом. Оперативку обратно go не отдаёт.

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

Только что попробовал на 1.8.3 - залил в мапу кучу элементов. Потом поочереди все удалил из мапы delete'ом. Оперативку обратно go не отдаёт.

а код и чем смотрел можно?

а код и чем смотрел можно?

Код не могу кинуть, на работе нет тырнетов (( смотрел диспетчером задач винды ))

https://deferpanic.com/blog/understanding-golang-memory-usage/

Код не могу кинуть, на работе нет тырнетов (( смотрел диспетчером задач винды ))

этого достаточно)

Только что попробовал на 1.8.3 - залил в мапу кучу элементов. Потом поочереди все удалил из мапы delete'ом. Оперативку обратно go не отдаёт.

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

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

Так вроде понятнее, спасибо.

ну это обычное поведение гц

также если система или что-то попросит памяти, то го гц уменшит размер резерва

также если система или что-то попросит памяти, то го гц уменшит размер резерва

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

Память есть? А если найду?

https://github.com/golang/go/issues/14521

статьи не нашёл

но там есть комментарии Чени и компании именно как это сделано в рантайме Гоу

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

https://github.com/golang/go/issues/14521#issuecomment-189244596

а там как ОС решит

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

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

Типа вторая не будет кушать озу?

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

Ну вас нах

Ну вас нах

За что ты нас так ((

джава фан?

проверили? так и происходит?

проверили? так и происходит?

Windows 7 - система уходит в swap, оперативу не отдаёт ни один из экземпляров прог. Доберусь до дома, попробую в Linux...

когда liteide x32 в релиз выложат?

проверили? так и происходит?

ссылка выше на гитхаб, там обсуждение Чени и компании

Windows 7 - система уходит в swap, оперативу не отдаёт ни один из экземпляров прог. Доберусь до дома, попробую в Linux...

покажешь код

покажешь код

примерно через полчасика покажу как тестирую

ссылка выше на гитхаб, там обсуждение Чени и компании

Обсуждение != реальность же

А еще "доверяй, но проверяй"

А еще "зачем пачкать руки самому"

А еще, а еще...! ой, да ну вас =(

покажешь код

https://play.golang.org/p/g-kV89MP6z

А еще "зачем пачкать руки самому"

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

Каждый экземпляр проги ест ~600 Mb private bytes

Протестировал под Linux (ARM 32 bit, 1Gb RAM). Каждый экземпляр программы ~300 Mb (из-за меньшей разрядности), третий экземпляр надает с сообщением "недостаточно памяти", никто из экземпляров также оперативу не отдал.

Пробовал варианты как и с delete, так и с map = nil. Эффект тот же :(

не знаю насколько это правильно, но можно руками освобождать память debug.FreeOSMemory()

не знаю насколько это правильно, но можно руками освобождать память debug.FreeOSMemory()

Интересно. После вызова отдаёт около 250 Mb из 600, остальное не отдаёт.

Добро пожаловать в банковскую систему

Протестировал под Linux (ARM 32 bit, 1Gb RAM). Каждый экземпляр программы ~300 Mb (из-за меньшей разрядности), третий экземпляр надает с сообщением "недостаточно памяти", никто из экземпляров также оперативу не отдал.

а вот это странно On Unix based platforms we use a system call to tell the operating system that it can reclaim unused parts of the heap, this facility is not available on Windows platforms.

странно что под Linux не сработало

As I understand, memory is returned to the OS about 5 minutes after is has been marked as free by the GC. And the GC runs every two minutes top, if not triggered by an increase in memory use. So worst-case would be 7 minutes to be freed. In this case, I think that the slice is not marked as freed, but in use, so it would never be returned to the OS.

а вот ещё пишут

что место освободится после 5 минут если оно помеченно как неиспользуемое