Ричард Л. Хадсон (Рик) знаменит по своим работам в управлении памятью, включая изобретение алгоритмов Train, Sapphire и Mississippi Delta, а так же GC stack maps, которые позволили реализовать сборку мусора в статически-типизированных языках вроде Java, C# и Go. Под его авторством были опубликованы документы о рантаймах языков, управлении памятью, многопоточности, синхронизации, моделей памяти и транзакционной памяти. Сейчас Рик является одним из членов команды Go в Google и работает над проблемами сборщика мусора и рантайма.
В экономике существует понятие “замкнутого цикла”, когда один процесс усиливает другой, что приводит к усилению первого. Исторически, в мире компьютеров такой “замкнутый цикл” был между развитием железа и софта. Процессоры становились быстрее, что способствовало написанию более мощного софта, что, в свою очередь, стимулировало дальнейшее повышение скорости процессоров и мощностей компьютера в целом. Этот цикл работал примерно до 2004-го, когда Закон Мура перестал работать.
В наши дни, двухкратное увеличение количества транзисторов не означает двухкратное ускорение программ. Больше транзисторов == больше ядер процессора, но программы не эволюционировали настолько, чтобы использовать больше ядер. И именно из-за того, что современные программы не используют на полную катушку многоядерность, ребята, разрабатывающие процессоры, просто не добавляют больше ядер. Цикл заглох.
Долгосрочная миссия Go заключается в том, чтобы перезагрузить этот цикл, дав миру больше параллельных, конкурентных программ. Более же краткосрочная миссия — увеличить принятие Go мировым сообществом разработчиков. И одна из наибольших претензий к Go в данный момент — это слишком длинные паузы сборщика мусора.
Когда их команда изначально взялась за проблему, он, шутя, рассказывает, что их начальная реакция, как инженеров, была не решать саму проблему, а найти обходной путь, что-то вроде такого:
- добавить на компьютеры отслеживание глаз, и запускать сборщик мусора, когда никто не смотрит
- показывать иконку ожидания сети во время фазы сборки мусора, и винить в паузах не сборщик мусора, а задержки сети или что-нибудь ещё
Но Расс Кокс, почему-то, эти идеи завалил на корню, и они решили закатать рукава и на самом деле улучшить сборщик мусора в Go. Они пришли к алгоритму, который уменьшает паузы GC, но делает программу чуточку медленнее. Программы на Go станут чуть медленнее в обмен на гарантированно низкие паузы фаз сборки мусора.
Какие задержки мы можем различать?
- Наносекунда: Грейс Хоппер сравнила время с дистанцией. Наносекунда — это 11.8 дюймов.
- Микросекунда: 5.4 микросекунд это время, за которое свет проходит 1 милю в вакууме.
- Миллисекунды:
- 1: Последовательное чтение 1МБ с SSD.
- 20: Чтение 1МБ с вращающегося диска.
- 50: Порог восприятия (порог реакции)
- 50+: Различные задержки сети
- 300: Моргание глаза
Так сколько работы по сборке мусора мы можем успеть в одну миллисекунду?
Java GC против Go GC
Go:
- тысячи горутин
- синхронизация через каналы
- рантайм написан на Go, используя его особенности, как и обычный код
- контроль пространственной локальности (можно встраивать структуры, внутренние указатели(&foo.field))
Java:
- десятки потоков Java
- синхронизация через объекты/локи
- рантайм написан на C
- объекты связаны через указатели
Наибольшим различием тут является вопрос пространственной локальности. В Java всё является указателями, в Go же вы можете встраивать структуры одна в другую. Когда приходится заходить по ссылкам на много уровней вглубь, это может создавать массу проблем сборщику мусора.
Основы сборщика мусора
Вот краткий пример работы сборщика мусора. Обычно, она состоит из двух фаз:
- Фаза сканирования: определить, какие вещи в куче достижимы. Сюда входят указатели в стеках, регистры, глобальные переменные, и далее, указатели в куче.
- Фаза маркировки: проход по графу указателей. Пометить объекты, как достижимые по ходу исполнения программы. С точки зрения сборщика мусора, проще всего “остановить мир”, чтобы указатели не изменялись во время этой фазы вообще. По-настоящему параллельный сборщик мусора сделать очень сложно, потому что указатели постоянно изменяются. Программа использует так называемые “барьеры на запись” (write barriers), чтобы сообщать сборщику мусора, что этот объект не нужно захватывать. На практике, правда, барьеры на запись могут давать результат даже хуже, чем “остановка мира”.
Сборщик мусора в Go
Новый алгоритм сборщика мусора Go использует комбинацию барьеров на запись и коротких пауз для “остановки мира”. Вот его фазы:
Вот как выглядела работа сборщика мусора в Go 1.4:
А вот как она выглядит в Go 1.5:
Заметьте, что паузы для “остановки мира” намного короче. Во время работы параллельного сборщика мусора, он использует 25% процессора.
Вот результаты тестов:
В предыдущих версиях Go, паузы сборщика мусора были в общем случае намного длиннее и возрастали по мере роста размера кучи. В Go 1.5 паузы сборщика мусора стали более, чем на порядок меньше.
Если приблизить цифры, то видно, что всё ещё есть слабая позитивная корреляция между размером кучи и длительностью пауз GC. Но они знают, в чём причина и она будет устранена в Go 1.6.
Есть небольшой штраф в производительности с новым алгоритмом, но этот штраф уменьшается по мере того, как растёт объем кучи.
Глядя в будущее
Сообщите людям, что паузы сборщика мусора больше не являются проблемой в Go. Глядя в будущее, они планируют затюнить сборщик мусора для достижения ещё более коротких пауз, большей производительности и большей предсказуемости. Они хотят найти оптимальное соотношение в этом компромисе. Разработка Go 1.6 будет зависеть от обратной связи, поэтому они очень ждут отзывов сообщества.
Новый сборщик мусора сделает Go ещё более подходящей заменой для языков с ручным управлением памятью.
Ссылки
Слайды: talks.golang.org/2015/go-gc.pdf
Дополнительно о сборщике мусора в Go
Go 1.5 concurrent garbage collector pacing
Go 1.4+ Garbage Collection (GC) Plan and Roadmap
Комментарии (75)
vlad9486
11.07.2015 20:37Что только не придумают, что-бы не использовать Rust.
voidnugget
11.07.2015 20:47+7У него на много выше порог вхождения, менее стабильная стандартная библиотека и более плюс-плюсоподобный «размороженный» синтаксис.
Из-за этого он не годится для разработки «долгоиграющих» решений с lts'ом. Вот Golang проще и он вполне годен для lts'a.
Rust корректнее сравнивать со swift'ом — уже есть кривые objc биндинги к foundation'у, и можно даже собрать iOS таргет с правильной травой.
p.s. я и сам сижу сча рефакторю hyper :3
Xlab
11.07.2015 20:52+2А Go 1.5 собирается под iOS таргет уже без травы ;)
voidnugget
11.07.2015 21:13+1И где там bind'инги под Foundation?
C gobind'ом и Java под андроёд ещё понятно.
Но вот с iOS ситуация сейчас вроде как сложнее.
Я вообще думал брать, парсить существующие swiftmodule swiftdoc и генерить соответствующие биндинги под rust и golang.
Правда до этого ещё не скоро дойдёт — не так много свободного времени.
withkittens
12.07.2015 16:51+1менее стабильная стандартная библиотека
До 2.0 всё железобетонно же (sans баги компилятора).voidnugget
12.07.2015 18:30-1Нестабильных плюшек сейчас хватает и очень много проектов их использует по не совсем понятным мне причинам.
Ну вот rustfmt хрен на 1.1 соберёшь — нужна nightly сборка.
Там используется авторская strings.rs, не знаю что он там тянет и почему автор решил пилить свой велосипед.
Googolplex
11.07.2015 20:56+7Ну на самом деле ниши у Go и Rust, хоть и пересекаются, всё же различные. У всего есть своё применение, и во многих случаях сборщик мусора очень удобен, гораздо удобнее чего бы то ни было ещё.
vlad9486
11.07.2015 21:04Согласен, но все же, там где важно отсутствие тормозов от сборки мусора — лучше Rust, IMHO. А клиенты, которые и так в сеть ходят, а значит тупят, можно и на Go писать.
divan0 Автор
11.07.2015 21:07+1На моем опыте, тут главная сложность именно в том, чтобы отличить, где важно отсутствие пауз, а где нет. Большинство сторонников языков без GC, занимают очень однобокую позицию, демонизируя GC и не понимая реалий компромиссов в разработке на языках с GC и без.
khim
11.07.2015 22:20-14Вот с этого момента — поподробнее. Я, наверное, чего-то не понимаю, но реалии разработки таковы: языки без GC — дружелюбны и просты в использовании, языки на GC — это, я извинюсь, п@#$ец на выезде.
Объясняю, что я имею в виду. Предположим, что я решил написать какую-нибудь мегахрень. Взял библиотеку на FORTRAN'е, добавил модуль на каком-нибудь FreePascal'е, разумеется сдобрил ещё парой либ на C (с его gobject'ом) и С++(с его аллокаторами и аренами)… Ну и до кучи ещё LUA для исполнения скриптов прикрутил. Да, потребуется некоторое количество жвачки, скотча и проволоки, чтобы всё скрутить, но больших проблем нет.
А теперь давайте рассмотрим такой же вариант, только матбиблиотека у нас будет на C#, модуль на Go, ну и там пара компонент ещё на каком-нибудь V8 и Lisp'е. Попытка всё это добро объединить потребует кучу времени, а после этого можно будет ещё пару лет писать статьи на Хабр с объяснением того, как взаимодействие между этим всего-навсего четырьмя GC периодически всю нашу систему ставит раком.
Язык без GC — это просто язык, язык с GC — это захватчик, узурпатор, «должен остаться только один» царь-император, который, так и быть, будет ещё как-то повелевать языками без GC, но ужиться с себе подобными? Ооо..., об этом можно слагать легенды.divan0 Автор
11.07.2015 22:31+11языки без GC — дружелюбны и просты в использовании, языки на GC — это, я извинюсь, п@#$ец на выезде
По вашему, C++ — дружелюбен, а Go — «п@#$це на выезде»? Извините, я тут даже не знаю тогда, с чего начать, и стоит ли вообще.
Не очень понял, каким образом «зоопарк» языков соотносится с вопросом оценки необходимости GC для каждого конкретного случая.
Я говорил о том, что очень редко встречал программистов, которые могут грамотно и спокойно оценить — где паузы GC будут проблемой, а где нет. Обычно, они склоняются к какой-то одной позиции, упрощая всё до «GC — плохо» или «ручное управление памятью — зло».khim
11.07.2015 23:49-8По вашему, C++ — дружелюбен, а Go — «п@#$це на выезде»?
Для пользователей? Да, конечно. Qt можно вкрутить хоть в Python, хоть в Java, хоть в PHP, а попробуйте вызвать Go'шную библиотеку из той же Java'ы.
Я говорил о том, что очень редко встречал программистов, которые могут грамотно и спокойно оценить — где паузы GC будут проблемой, а где нет.
Проблемы GC далеко не только в паузах. Проблемы в GC — в написании кода «на выброс». Вот выбрали вы какой-нибудь C# или там Go, а потом раз — и «парадигма изменилась» и вместо Windows теперь Android. Что вы с вашим кодом делать-то будете? Ну какое-то время можно пожить с «коллекцией костылей», но рано или поздно придётся всё переделывать. В то же время библиотеки, написанные на FORTRAN'е и/или C лет так 20-30 до сих пор в строю — и через 20-30 лет всё ещё будут в строю.
Если ваш проект не имеет «срока годности» (например если вы пишите игру, то тот факт, что её через 10 лет не на чем будет запускать никого не волнует) и не является чем-то «большим и серверным» (когда вы пишите ПО для станка или, наоборот, для кластера, то вы можете позволить себе выбирать ОС под вашу программу, а не наоборот), то лучше с языками с GC не связываться. И паузы пресловутые — далеко не самая большая проблема.voidnugget
12.07.2015 00:17+3Сейчас можно и dll'ку go'шную линкануть, и метод откуда-угодно вызвать, другое дело что go runtime себя будет довольно странно вести, так что это немного неудачный пример.
Конкретно, в С++ есть следующие недостатки, которых нет в Golan'e
- Много разношерстных стандартов
- Хватает побочных эффектов
- Много решений поощряют возникновение ошибок
- Ужасный порог вхождения, глянуть хотя бы костыли с boost'a
- Надо хотя бы пару лет для того что бы было понятно что и как и куда ...
gridem
12.07.2015 00:05+1Я расшифровал предыдущий пассаж следующим образом.
Есть языки с GC, а есть языки без GC. Далее, есть случай, когда используется только один язык программирования. Но это — неинтересный случай, т.к. бери и используй. Удобно С++? Хорошо. Java — тоже хорошо. Go — замечательно, ну в смысле тоже одинаково хорошо. Как говорится, зависит от задач и опыта разработчика(ов).
Другое дело, когда у нас необходимо скрещивать несколько языков, и вызывать один язык из другого. Если у нас все языки без GC, то проблемы со скрещиванием минимальны: С/C++/Fortran — практически безболезненно. А вот если скрещивать языки с GC, то тут могут возникнуть проблемы: у каждого свой рантайм, свой GC, и они могут внезапно подраться за память, объекты и т.п. Типичные проблемы managed/unmanaged помножаются на то, что тут связь уже может быть managed/unmanaged/managed или ещё что похлеще. По крайней мере, я знаю, как связывать C++ с Java/C#/Python/Lua и др., а вот как связать C#, Go и Java — не очень. Разве что через С++. Но кажется, что это будет адская хрень.
Тут в общем-то не поднимается вопрос о том, а нужно ли это. Тут скорее рассуждения на тему. Ну а моё личное мнение — языки с GC, безусловно, сильно удобнее в разработке. Хотя C++ с новыми стандартами уже начинает дышать в спину, но по удобству всё равно не дотягивает.voidnugget
12.07.2015 00:29С java go вызывается довольно просто — генерится байндинг gobind'ом.
Мороки с вытеснением памяти кучи сейчас нет, а раньше была.
Бывают проблемы когда два сборщика мусора одновременно срабатывают, но это при оч загруженном приложении — обещали пофиксить в ближайшем будущем. А вообще сейчас можно собрать shared либу и вызывать с неё всё как с сишки, afaik runtime обычно сам поднимается с libgo, хотя я сильно не разбирался как и что там. У меня больших проблем с вызовом go функций с под NDK ведроида и со swift'a на iOS пока не возникало. С С# / Python / Lua будет вызываться как и любая сишная функция, предварительно инициализирующая рантайм.
khim
12.07.2015 00:40+2Тут в общем-то не поднимается вопрос о том, а нужно ли это. Тут скорее рассуждения на тему.
Тут не голословные рассуждения на тему. Рассуждениями на тему эти вещи были лет 10 назад, когда языки без GC были нормой, а языки с GC — редкой экзотикой. Один язык с GC в проекте пережить можно (хотя зачастую возникает ощущение что «хвост виляет собакой»), но вот когда их становится больше одного… Сейчас же как раз дело дошло до достаточно их широкого использования для того, чтобы это начало реально происходить. И я вам скажу… глюки, которые возникают, когда в одном процессе у вас сталкиваются ART (а куда деваться: на нём все интерфейсы Android'а), C# (а это — уже потому что кто-то в Unity Technologies когда-то решил, что C# — это «самое то» для написания простеньких скриптов) и V8 (а чё: крутые web-технологии — это наше всё), то возникает не вопрос «а почему это всё падает периодически», а скорее «вау: они умудрились-таки сделать так, что эта хрень может 15 минут проработать и не упасть».
Но кажется, что это будет адская хрень.
В том-то и дело, что это не будет адская хрень. Это уже есть адская хрень — и будет только хуже.
Ну а моё личное мнение — языки с GC, безусловно, сильно удобнее в разработке.
Но сложнее в поддержке. Как я уже сказал: если вас не волнует что будет с вашим творением лет через 10 или, наоборот, вы уверены, что и через 10 лет сможете поддерживать всю необходимую инфраструктуру — тогда вперёд. Только хорошо подумайте: понятно что Google сможет всю необходимую инфраструктуру поддерживать сам, но вот уже даже у Яндекса с этим, скорее всего, возникнут проблемы.divan0 Автор
12.07.2015 01:03+6Я вас правильно понимаю — вы засовываете в «один процесс» C#, Java и V8, сознательно создавая, по вашему же утверждению, «адскую хрень» и потом заявляете, что проблема в GC?
khim
12.07.2015 03:58Засовываю не я — я только разгребаю случаи, когда всё это хозяйcтво начинает «разваливаться» от весьма небольших изменений в коде Android'а. И да — проблема в GC, от обычных языков, не требующих таких хитростей проблем гораздо меньше.
nsinreal
13.07.2015 10:47А собственно говоря, в чем проблема? Или желание юзать библиотеки из разных платформ (C#/Java) — это плохо? Или желание выполнять javascript код на беке для рендеринга это хуже чем писать клиент и сервер на javascript?
divan0 Автор
13.07.2015 10:56+2Проблема в понимании причинности проблем. Мне звучит нелогичным утверждение «GC — зло, потому что, если собрать адскую хрень из 3-х языков, то начинаются проблемы». Это как взгромоздить велосипед на автомобиль, а автомобиль на самолёт и утверждать, что «колёса — зло, потому что из-за них начинаются проблемы».
nsinreal
13.07.2015 12:26-5Гм… Я привел реальные юзкейсы, а ты приводишь какие-то ебнутые аналогии. Я даже не знаю как спросить повежливее: дяденька, ты дурак?
nsinreal
14.07.2015 02:00-1Нда уж, желание услышать нормальную аргументацию нынче расстреливается минусами…
batyrmastyr
14.07.2015 10:48+3Минусами расстреливаются неадекватно выраженные желания.
В далёком 87 году дедушка Вирт на своём языке со сборкой мусора написал многозадачную операционку скрещённую со средой разработки и неким подобием ActiveX. Сборщик мусора, запрет сишной адресной арифметики и принудительные проверки границ массивов не тормозили, не падали и не создавали проблем с поддержкой ни ему, ни его коллегам, ни студентам. Несколькими годами позже подобная система от его учеников стала управлять работой АЭС и тоже никаких проблем.
У вас проблема не от GC, а от того, что вы пользуетесь чужим говнокодом который не умеет, но пытается использовать ещё три кучи говнокода. Франкенштейн, знаете ли, монстром был не потому, что его током стукнуло, а потому, что его создателю до абсурдности идеи дела не было.khim
14.07.2015 14:46В далёком 87 году дедушка Вирт на своём языке со сборкой мусора написал многозадачную операционку скрещённую со средой разработки и неким подобием ActiveX. Сборщик мусора, запрет сишной адресной арифметики и принудительные проверки границ массивов не тормозили, не падали и не создавали проблем с поддержкой ни ему, ни его коллегам, ни студентам. Несколькими годами позже подобная система от его учеников стала управлять работой АЭС и тоже никаких проблем.
Вы не поверите, но управление АЭС — это очень простая задача. Да, там очень высокая цена ошибки, но это не делает саму задачу сложной.
А поводу «многозадачных операционок с неким подобием ActiveX»… не расскажите — где она? И кто ей (или её потомками) сейчас пользуется?
У вас проблема не от GC, а от того, что вы пользуетесь чужим говнокодом который не умеет, но пытается использовать ещё три кучи говнокода.
Нет, проблема-таки именно от GC. Идиоты-теоретики (я тут использую слово идиот в его изначальном смысле) типа Вирта и Танненбаума так и не поняли, что в 70е мир изменился. Провозвестником этого изменения было семейство IBM 360, а лет через 15-20 направление, которое она задала — стало главным и определяющим.
И это направление — это обратная совместимсть. Если в 50е и 60е переписывание программ с нуля было нормой (так как никакое железо ни с каким другим не было совместимо), то начиная с 70х — это стало вещью весьма желательной, а с 80х — практически железным требованием. Даже «всесильный Apple» закрывает глаза на использование в программах для iOSа всяких C# и/или Java (которые туда приходится засовывать с большим скрипом из-за ограничений системы), так как знает: если она заставить всех всё переписывать чисто под себя, то iOS отправится на свалку истории вслед за BlackBerry и Windows Phone'ом.
Кстати этот процесс Вирт мог легко наблюдать смотря на судьбу своим собственных творений: Паскаль — таки активно использовался, где-то как-то кто-то видел, а Оберон — вне лабораторий никто толком и не наблюдал.
А нам тут решением «вы просто перепишите всё» всерьёз предлагается как решение «проблемы GC».batyrmastyr
14.07.2015 15:21Да, там очень высокая цена ошибки
И GC там к ошибкам во время работы не приводит. Если у них есть GC и всё хорошо, а в вашем зверинце всё плохо, то проблема не в идее сборки мусора.
Нет, проблема-таки именно от GC.
Если библиотека фигово отделяет друг от друга данные и код на трёх языках или кто-то криво написал _отдельно взятый_ сборщик мусора, то виновата идея сборки мусора. Хотя чего мелочиться? Давайте запретим стандартные библиотеки, а лучше вообще компьютеры, ведь это они работают неправильно.
Ножами в пьяных драках постоянно тоже каждый день убивают, но никто не вопит «во всём виноваты ножи и алкоголь, давайте их запретим».
А нам тут решением «вы просто перепишите всё»
Решение: не используйте говнокод, а если используете — не жалуйтесь что он не работает. И не обобщайте единичные проблемы до вселенского масштаба.khim
14.07.2015 17:56-2Если библиотека фигово отделяет друг от друга данные и код на трёх языках или кто-то криво написал _отдельно взятый_ сборщик мусора, то виновата идея сборки мусора.
Проблема не в «отдельно взятом» сборщике мусора. Порочна сама идея GC, так как она основана на порочном предположении о том, что GC может знать о том что где в памяти расположено и никто кроме GC на это не влияет.
Эта идея — не работает. Уж сколько раз за полвека было попыток сделано. Не работает. На малых системах — работает (но там и без GC управлять памятью не проблема), на больших — не работает.batyrmastyr
14.07.2015 18:28Т.е. вы говорите, что инкапсуляция — не для вас и вообще глупость, думаете, что точно знаете, как в памяти размещаются объекты нескольких языков и наивно полагаете, что этот формат не изменится.
Да, в языках с ручным управлением памятью и атавизмами типа адресной арифметики формат хранения в памяти описан и не меняется, а ваша логика работает, но глупо требовать работоспособности такого хардкода от более динамичных языков, в которых внутреннее представление объектов может измениться даже при мелких обновлениях.
Вы сами начали мешать сборщику мусора, но почему-то обвиняете в этом не себя и свой говнокод, а сборщик мусора. Простите, но идиотом (в том самом, изначальном смысле) являетесь вы сами, а не Вирт и Танненбаум — мир и языки изменились, а вы не заметили, что влезать с ржавым ножом внутрь системы уже нельзя.khim
14.07.2015 18:59Я восхищён вашим умением валить всё с больной головы на здоровую, но должен же быть у этого и какой-то предел, а?
Т.е. вы говорите, что инкапсуляция — не для вас и вообще глупость, думаете, что точно знаете, как в памяти размещаются объекты нескольких языков и наивно полагаете, что этот формат не изменится.
Наоброт! Я верю в инкапсуляцию и именно поэтому не верю в GC! Компилятор FORTRAN'а (вернее его библиотека) знает о том как работать с теми данными, которыми он заведует, компилятор C++ знает как он работает с данными, которые он насоздавал, Lua заведует своими объектами, все эти объекты могут свободно жить в одной куче и между ними не возникает никаких конфликтов. И вот только GC считает, что он всюду может просунуть свои щупальцы и про все объекты имеет право знать всё.
глупо требовать работоспособности такого хардкода от более динамичных языков, в которых внутреннее представление объектов может измениться даже при мелких обновлениях.
Я ничего такого от них и не требую! Наборот — это они от меня требуют рассказывать где что у меня лежит и как оно устроено. А в идеале — требуют отказаться от своего рантайма и перейти на их собственный «самый главный и льючший».
Вы сами начали мешать сборщику мусора
Мешают сборщикам мусора в основном другие сборщики мусора, каждый из которых считает, что он — самый главный.
Простите, но идиотом (в том самом, изначальном смысле) являетесь вы сами, а не Вирт и Танненбаум — мир и языки изменились, а вы не заметили, что влезать с ржавым ножом внутрь системы уже нельзя.
Действительно — мир изменился и теперь делать вид, что вы можете контролировать его целиком нельзя. Однако же творения теоретиков очень этого хотят, а когда в результате получается чушь собачья объясняют, что нужно было ходить в ногу, тогда и беды бы не было. Может быть, но проблема в том, что заставить всех «ходить в ногу» не получается.
Как только вы мне покажите систему где одновременно работают творения Вирта, Танненбаума (да я, в общем, на них не настаиваю — можно и других) — у нас будет предмет для обсуждения. А пока я вижу, что они отлично работают в отдельности «не участвуя в общем собрании граждан полиса», а как только в одном процессе у нас образуется «демократия», так там начинается фигня, то есть их творения являются классическими идиотами.
gurinderu
14.07.2015 20:12+2Т.е. вы утверждаете, что управлять памятью огромной системы гораздо проще? Чем больше кода, тем больше вероятность memory leak. В случае с platform with gc эта вероятность явно ниже. И я не предлагал делать, тупой copy-paste, естественно нужно учитывать особенности языка и платформы и делать оптимальнее.
P.S. если бы не было gc, то скорее всего у нас не было бы тонн софта. Для разработки на том же с++ времени уходит намного больше.khim
14.07.2015 21:07-2Т.е. вы утверждаете, что управлять памятью огромной системы гораздо проще?
Конечно. То, что вы при использовании GC вы не управляете памятью системы — это миф. Объекты всё равно пакуются в разнообразные скопы, пулы, арены и прочее. А иначе вы в них всё равно запутаетесь. Только вот после этого вместо того, чтобы дать этим скопам, пулам, аренам и прочему права на уничтожение объектов, которые в них хранятся, вы прикручиваете «сбоку» CG, с которым немедленно начинаете бороться.
Чем больше кода, тем больше вероятность memory leak.
GC тут ровным счётом ничего не меняет. Если у вас в нужный момент scope не будет уничтожен, то у вас будет память теряться — с GC или без GC. На самом-то деле GC нужен не для того, чтобы бороться с memory leak'ами! Он этого делать не умеет и не должен: у нас внушительный процент программ написаны на Java и также много на на C++, так вот «текут» (с течением времени RSS неограниченно растёт пока не дорастёт до квоты и сервер не перезапустят) почти исключительно программы на Java, с программами на C++ другая беда: обращение к удалённым объектам, выход за границы массива, etc. В общем всё то, что обещает починить rust. Посмотрим что из всего этого выйдет.
В случае с platform with gc эта вероятность явно ниже. И я не предлагал делать, тупой copy-paste, естественно нужно учитывать особенности языка и платформы и делать оптимальнее.
Проблема в том, что ни у кого нет ни времени ни сил на то, чтобы переписывать систему, которая разрабатывалась 10, 20, 30 лет. Единственный пусть — постепенно добавлять в неё модули на других, более современных, языках. Языки с GC делают этот путь невероятно сложным и рискованным.
P.S. если бы не было gc, то скорее всего у нас не было бы тонн софта. Для разработки на том же с++ времени уходит намного больше.
Совершенно не убедили. Стандартные инструменты разработки для какого-нибудь iOS'а GC не поддерживают, а софта под него написано до… и больше. Всякие IDE, офисные пакеты, браузеры и прочее, прочее, прочее написано на языках без GC. Только в последнее время происходит переход на языки с GC, в результате чего, как правило, потребление ресурсов возрастает на порядки, а новой функциональности добавляется чуть-чуть.batyrmastyr
14.07.2015 23:47Только в последнее время происходит переход на языки с GC, в результате чего, как правило, потребление ресурсов возрастает на порядки
Если бы у сборки мусора всё было настолько плохо, то Вирт просто не смог бы работать в ОС Оберон из-за тормозов, да и микроконтроллер внезапно зависающий на секунду («мусор собираема, насяльнике») никто бы продавать не рискнул. В случае Джавы с Далвиком ваше утверждение, возможно и верно, как-никак в их основе виртовская же виртуальная машина полувекового возраста, но в общем случае оно уже много лет как неактуально. По крайней мере я до сих пор вспоминаю, как BlackBox Component Builder пересобирал пять метров своих исходников пока VS 06 пыталась переварить Hello World о пяти строчках.
Единственный пусть — постепенно добавлять в неё модули на других, более современных, языках. Языки с GC делают этот путь невероятно сложным и рискованным.
В такое мамонтовое изделие, полагаю, любой язык отличный от оригинального добавлять сложно и рискованно. Однако вместо того, чтобы позволять этому зоопарку работать в одной области памяти лучше бы заставили их сообщениями, вместо кусков памяти, обмениваться — тогда какие-то части системы будет реально заменить на свежачок и без головной боли.
Наоброт! Я верю в инкапсуляцию и именно поэтому не верю в GC!
Как бы сказать, ваша фраза о том, что сборщику мусора нужно, чтобы никто кроме ОС в его памяти не ковырялся. Всё верно — ему необходима инкапсуляция, а, точнее, изоляция от других работающих с памятью сущностей. Уж не знаю как, но у вас нарушено это требование и проблемы «какая сволочь на место объекта число записала?!» всплывают на порядки быстрее, чем они могли бы всплыть без сборщика мусора (охотно верю, что без него они могли бы не всплывать ещё годы). Как и любой предмет, сборщик мусора требует соблюдения правил эксплуатации.khim
15.07.2015 00:30-1Уж не знаю как, но у вас нарушено это требование и проблемы «какая сволочь на место объекта число записала?!» всплывают на порядки быстрее, чем они могли бы всплыть без сборщика мусора (охотно верю, что без него они могли бы не всплывать ещё годы).
Без него они бы вообще никогда бы не всплыли, так как число на месте объекта оказалось из-за того, что кто-то держал на этот объект ссылку в месте, о котором не удосужился GC сообщить и он его переиспользовал.
GC категорически несовместим с инкапсуляцией: для того, чтобы он мог работать он должен видеть все ссылки. Ещё раз: все ссылки. Приватные, публичные, какие угодно. Какая же это, к бесу, инкапсуляция?
Как и любой предмет, сборщик мусора требует соблюдения правил эксплуатации.
Нет, нет и нет: он требует нарушения правил эксплуатации. И отказа от инкапсуляции и прав доступа. Иначе он не сможет работать. Тут правда есть тонкость: многие люди относят инструменты типа ARC к GC. Я его к GC не отношу именно потому, что он не требует отказа от инкапсуляции, «обхода» прав доступа и прочего ужаса. Это не панацея, конечно, но это нормальный, хороший, годный, инструмент. А вот GC — это раковая опухоль: раз появившись в системе он пускает метастазы и пытается заразить весь рантайм сниху доверху.
В такое мамонтовое изделие, полагаю, любой язык отличный от оригинального добавлять сложно и рискованно.
Все успешные проекты со временем превращаются в подобные поделия. Есть правда, фирмы, которых иногда обуздывает зуд и они решают всё переписать с нуля. Большинство на этом и кончаются, часть просто выкидывает на ветер кучу денег и возвращается к истоками (см. Microsoft, который так и не переписал Windows и MS Office на C# — а иначе мы бы уже в прошедшем времени о нём говорили).
Однако вместо того, чтобы позволять этому зоопарку работать в одной области памяти лучше бы заставили их сообщениями, вместо кусков памяти, обмениваться — тогда какие-то части системы будет реально заменить на свежачок и без головной боли.
А смысл какой? Только чтобы позволить использовать GC? А как же обещания на тему, что GC нам что-то там улучшит? Пока как-то получается что он в основном к проблемам приводит, а улучшениями и не пахнет.
Если бы у сборки мусора всё было настолько плохо, то Вирт просто не смог бы работать в ОС Оберон из-за тормозов, да и микроконтроллер внезапно зависающий на секунду («мусор собираема, насяльнике») никто бы продавать не рискнул.
Не знаю как там в ОС Оберон, но моё первое общение с редактором, написанным на LISP'е примерно так и выглядело: он примерно раз в пару минут останавливался и «уходил куда-то» секунд на пять. Это было ещё на «эталонных» IBM PC XT (вернее клонах), но с тех пор ровным счётом ничего не изменилось, кроме масштаба: всё так же GC приводит к проблемам, только теперь они выражаются в том, что «выпадают кадры» и «дёргаются персонажи» и всё так же можно с этим справиться если выделить системе раз в этак 10 больше ресурсов, чем ей, на самом деле, нужно.
В случае Джавы с Далвиком ваше утверждение, возможно и верно, как-никак в их основе виртовская же виртуальная машина полувекового возраста, но в общем случае оно уже много лет как неактуально.
И эти слова я тоже не первый год слышу. «Ну да, конкретно вот тут у нас проблемка, но это мелочи, ерунда, ещё чуть-чуть и все эти беды останутся в прошлом». Есть подозрение, что и полвека назад людям то же самое пели и ещё через полвека мы это будем слышать. Время течёт, проблема остаётся: GC, который, в теории, должен помогать людям решать проблемы, на самом деле их скорее создаёт.
Я видел кучу людей, которые работают с ручным выделением памяти годами и почти никто из них даже не задумывается над тем, что там «унутре» (иногда это бывает важно, но ооочень редко — даже в высоконагруженных системах), но зато если в языке есть GC, то вопросы его «приручения» — одни из самых обсуждаемых. Да и, собственно, данная статья — прекрасный тому пример. Вам не кажется, что эта… когда инструмент решает проблемы — то его просто используют, большинство людей сталкивается с описанием инструмента разве что «в курсе молодого бойца», а вот если его всё время дотачивают и обсуждают — то он их скорее создаёт?
да и микроконтроллер внезапно зависающий на секунду («мусор собираема, насяльнике») никто бы продавать не рискнул.
В типичном микроконтроллере памяти столько нет, чтобы зависать на секунду, а о качестве его работы говорит тот факт, что подобные микроконтроллеры — экзотика, а не норма жизни. Хотя как раз там самое ужасное свойство GC роли не играет: обычно программы для микроконтроллеров не настолько велики, чтобы их нужно было годами разрабатывать на разных языках.
gurinderu
15.07.2015 10:25+1Я не утверждаю, что GC избежит всех проблем утечек, но он хотя бы поможет избежать глупых. К тому же если вы хоть раз писали на с++ (скорее всего да), то помните проблему еще и фантомными ссылками. Я не утверждаю, что GC это silverbullet, есть скоп задач для которых может не подойти такая платформа, но и утверждать что во всем виноват GC не правильно.
P.S. Кстати мне сложно представить, что у вас за система, которая разрабатывается 30 лет. К примеру той же Java всего 20)
khim
15.07.2015 14:05+1P.S. Кстати мне сложно представить, что у вас за система, которая разрабатывается 30 лет. К примеру той же Java всего 20)
Вы притворяетесь или издеваетесь? Посмотрите на свой стол. Windows разрабатывается с 1983го года, MacOS базируется на FreeBSD и ведёт свою родословную с 70х, GNU/Linux разрабатывается с 1984го. Если посмотреть чуть повыше — там та же история: Autocad появился в 1982м, StarWriter (который постепенно эволюционировал в LibreOffice) — в 1985м, MacWord — в 1985м году. Многие из этих проектов переписывались неоднократно (скажем Windows был изначально написан на как раз Паскале но в Microsoft'е вовремя поняли, что это тупик и переписали всё на Си, позже произошёл переход на C++), но попытки переписать всё с нуля (Project Pyramid и Wi ndows Longhorn) очень дорого обходились компании: они неизбежно кончались слезьми, потерей времени и откатом на прежние позиции. Переписывание отдельных компонент — да, во многих случаях от первой версии ни одной строчки не остаётся, а «сесть и написать заново» — не работает.gurinderu
15.07.2015 14:24+1В такой ниже gc и не нужен. Это операционные системы, где желательно сделать отклик как можно меньше. И да, я издеваюсь. Я вижу, что вы не понимаете сравниваете несовместимое. У каждого языка есть своя ниша. Где-то нужно писать очень быстро и не думать, о указателях, ссылка, о командах процессора и оптимизации, нужно чтобы это просто работало по описанной бизнес логике с как можно меньшим количеством ошибок. На С++ к сожалению так не получится.
Я понял вашу точку зрения, не нужно брызгать слюной и доказывать мне что-то)khim
15.07.2015 14:58-1Это у вас текстовый процессор стал «такой нижой»? А что языки с GC вполне могут использоваться для случая «никуда они не денутся, будут жрать что дадут» — ну дык. Они там зачастую и используются. Вот только зачем там-то такие сложности? Раньше как-то тривиального Visual Basic'а хватало без всякого GC (там практически во всех программах все объекты статически аллоцировались), а сейчас сами себе наустраивали проблем с GC. Зачем?
nsinreal
14.07.2015 15:11Дядя, я просто мимо проходил. Если серьезно, то я никогда таким не занимался, но возможность скрестить нескольков миров, а не плодить копипасту — это очень хорошо. Просто посмотрите на стандартную и самые часто юзаемые библиотеки в языках — они же друг друга повторяют по функционалу, причем зачастую у каждого своя собственная кривая и бажная имплементация. И это не считая дублирующихся библиотек (когда библиотеки предназначены по сути для одних и тех же целей). По мне так желание плодить копипасту в мире — это куда более неадекватное желание.
Если быть точнее, то я не в теме, что именно в скрещивании вызывает основные проблемы, но вполне таки верю, что GC является проблемой для подобного скрещивания. И мне как-то очень грустно видеть такие сообщение. Кстати, вы не думали, что GC и является чужим говнокодом, которым мы все пользуемся?
Другое дело, что подобное скрещивание возможно не очень хорошее решение и гораздо лучшим решение были бы транскомпиляторы, но увы, с ними тоже есть куча проблем
cy-ernado
14.07.2015 13:41+2За обсценную лексику вообще дают read-only. А еще вы грубы слишком, возможно дело в этом?
nsinreal
14.07.2015 14:59-3Изначально я был вежлив, если что. По мне, так приводить какие-то странные аналогии в ответ на реальные кейсы — это грубость еще большая, чем трехэтажные маты.
gurinderu
13.07.2015 13:47+2Скорее всего такое желание абсурдно. Так как с огромной вероятностью для C# или Java есть
либо wrapper, либо copypaste нужной вам либы. А вот про Javascript я и вовсе не понял. К примеру в java есть nashorn. Запускайте практический любой js код, который хотите. Только опять же не понятна цель всего этого.khim
13.07.2015 16:27+1Так как с огромной вероятностью для C# или Java есть либо wrapper, либо copypaste нужной вам либы.
Враппер вам не поможет, а copy-paste — да, может быть. Только вот после этого все разговоры про то, что GC облегчает программирование становятся абсурдом. Что проще: написать одну библиотеку на языке без GC и использовать её везде или написать кучу copy-paste'ных библиотек на куче языков, следить за ними, переносить багфиксы и т.д. и т.п.
Об этом я и говорил изначально: GC — даёт вам тактический выигрыш за счёт стратегического проигрыша. Хуже того: весь «бравый новый мир» паразитических языков с GC живёт за счёт фундамента, построенного на основе языков без GC. Но при этом «эти люди» почему-то своим убожеством кишатся и делают вид, что «они тут самые главные». Нет, ребята, детишки, копающиеся совочком в песочнице, может и «цветы жизни», но без больших дядей, которые возять песок и стройматериалы им бы было просто негде копаться.gurinderu
13.07.2015 16:32Враппер для языка c GC на Manual естественно сделать нельзя или сложно, а обратное можно вполне. Правильный ответ нужно писать либу для каждого языка, поскольку вызов native с той же java дает неплохие накладные расходы)
batyrmastyr
14.07.2015 16:00+1весь «бравый новый мир» паразитических языков с GC живёт за счёт фундамента, построенного на основе языков без GC
А Oberon 07 живет со сборщиком мусора на микроконтроллерах. На каких «фундаментах» boost'ов и фортранов паразитирует он? Кто подвозит стройматериалы?
С/C++/Fortran — практически безболезненно. А вот если скрещивать языки с GC, то тут могут возникнуть проблемы: у каждого свой рантайм, свой GC, и они могут внезапно подраться за память, объекты и т.п.
Это ваше «почти безболезненно» стоило десятилетий пота и крови, а вы хотите всё и сразу. Кому нужна совместимоть не на костылях и мазохизме давно уже обмениваются сообщениями.khim
14.07.2015 17:51-1Это ваше «почти безболезненно» стоило десятилетий пота и крови, а вы хотите всё и сразу.
Нет — я не хочу «всё и сразу». Я хочу «здесь и сейчас». Это разные вещи. Идея GC появилась больше полувека назад и с тех пор она всё время находится в статусе «ну у нас уже почти всё сделано, ещё чуть-чуть поднажмём и всё будет зашибись». Если у вас проблема находится в этом статусе после полувекового активного развития то это не значит, что она никогда не будет решена (вот, полетели же самолёты в начале XX века — а до этого сотни лет были провалы), но это значит, что закладываться на то, что она вот-вот будет решена нельзя. Вот когда будет — тогда и будет. А пока — не нужно.
А Oberon 07 живет со сборщиком мусора на микроконтроллерах.
Не бойтесь — он там тоже не удержится. Просто там ещё славная доисторическая эпоха (про которую я уже писал) не кончилась. Если вы разрабатываете небольшую, ограниченную, систему, то вы можете хоть GC использовать, хоть Forth, хоть верёвку с мылом. Проблемы начинаются, когда вы создаёте что-то большое и у вас проекты начинают разработываться десятилетиями. И вот там GC — строго противопоказан, но именно туда его с упорством, достойным лучшего применения, суют уже скоро 20 лет.
nsinreal
14.07.2015 15:00Только опять же не понятна цель всего этого.
Я же сказал, писать SPA и рендерить страницы для новых посетителей и поисковиков. Вполне себе разумная цель.
divan0 Автор
11.07.2015 21:02+4Что только не придумают, что-бы не использовать Rust.
Да, в Google вообще недалекие люди работают, наверное просто не знают про Rust )divan0 Автор
12.07.2015 01:10+2Извините за сарказм, но эту фразу надо патентовать уже.
Тут уже было
Что только не придумают, что-бы не использовать Erlang.
Что только не придумают, что-бы не использовать Haskell.
Что только не придумают, что-бы не использовать Lisp.
Теперь ещё и rust.
kvark
11.07.2015 20:52Молодцы! Глядишь и вправду игры делать начнут ;)
Странный график скорости у вас, к слову. Go 1.5 обозначен желтым цветом и все маркеры на отмекте 0 секунд. Куда стремиться уже?divan0 Автор
11.07.2015 20:55Go 1.5 обозначен желтым цветом и все маркеры на отмекте 0 секунд. Куда стремиться уже?
Ну там резолюция в секундах. На следующем графике видно, что на 0.5Гб куче около 2мс. Но если есть возможность уменьшить — почему бы и нет. Есть области, где и 2мс — много.
amarao
11.07.2015 23:03Можно я не поверю в мигание длинной в 300мс? Неужели человек не может моргнуть 4 раза за секунду? А ещё видеть в промежутках между этим?
Вот и гугль подсказывает: globalscience.ru/article/read/23157 — от 50 до 75мс.divan0 Автор
11.07.2015 23:06Можно.
Вики говорит другое:
The duration of a blink is on average 100-150 milliseconds according to UCL researcher[3] and between 100-400ms according to the Harvard Database of Useful Biological Numbers
23derevo
12.07.2015 14:46+1Из графиков совершенно непонятно, что авторы имеют в виду под «GC Pauses в секундах». Какая метрика используется для измерения? Это среднее? Это 95 процентиль? Это 99 процентиль? Это гарантированная верхняя оценка?
Ну и другие стандартные вопросы. Что за профиль загрузки? О каких объемах памяти идет речь?
Похоже, что тут есть интересные вещи с точки зрения алгоримов, хотя я пока не разбирался. А вот трейдофф между latency и throughput/bandwidth известен десятки лет. Чуваки поигрались с рантаймами и решили, что можно заплатить большим куском throughput за хорошую latency. Ну ок.
Дальше рассуждения чисто гипотетические.
Сколько было раньше на таком же ворклоаде? Пусть будет 5%. Стало 25%. Мы взяли и на ровном месте только что потеряли 20% процессора. Было у нас 95%, осталось 75%. Для одного-двух серверов это наверное оок. А если в бэкэнде у вас ну хотя бы сотня серверов, это означает, что нужно докупить еще около 27 серверов. Скажем, с учетом обслуживания в дата-центре это 10 тысяч долларов в год. 270 тысяч долларов в год вот так вот за гаранитрованную latency — это много или мало? Это хорошо или плохо?
Не все так однозначно, господа.khim
12.07.2015 15:01Что-то мне подсказывает что есть мало компаний, у которых «в бэкэнде» больше серверов, чем у Гугла. Причём «мало» — это почти наверняка «нуль».
Ваши рассуждения хороши только для тех компаний у которых, с одной стороны, сотни серверов, а с другой — клиенты, которые не могут вас «послать» и уйти к конкурентам и вынуждены ждать пока за несколько секунд GC прожуётся и сервер на нажатие кнопочки отреагирует (ещё раз: там на графике время в секундах: не в микро или милли, а просто в секундах). Это довольно узкая ниша. Всем остальным же приходится снижать нагрузку, чтобы не получать вот эти многосекундные задержки. Теперь же загрузку можно буде повысить — даже притом, что процессор больше станет тратить на GC.gurinderu
12.07.2015 15:25+3А причем тут Гугл? Алексей вполне конкретные вопросы задал.
К тому же откуда инфа вообще о нескольких секундах? И собственно про какие алгоритмы сборки мусора идет речь? И может быть речь про full gc? Если да, то вы его можете очень долго ждать. У меня были логи за пару недель с прода, где full gc не вызвался ни разу.
divan0 Автор
12.07.2015 15:32Не забывайте, что это перевод блогпоста, который «на коленке» записывает блоггер по ходу выступления докладчика.
Какая метрика используется для измерения?
Полагаю, что стандартный runtime.Memstats, в котором хранятся данные про паузы 256 последних срабатываний GC. Percentile или mean — не знаю, но, полагаю, что раз там была прямая корелляция, то mean там репрезентативен.
Не все так однозначно, господа.
Никто такого и не говорит. Но ваши рассуждения и вправду, гипотетические и неверные. 25% будут отбираться только для фазы GC, а не на время всей работы программы. Пересчитывайте :)23derevo
12.07.2015 15:49да, надо сделать скидку по поводу онлайна :) И по поводу фазы GC — тоже верно. Но пример примером, бог с ним. В нем вопрос в том, насколько часто выполняется эта самая «синяя» фаза.
Проблема в том, что я, блин, не могу нормальных статей найти ни по поводу нового GC (1.5), ни по поводу старого (1.4). Референсная статья по первой ссылке не отвечает на вопрос о том, как работает новый GC. Там есть только Goals, сформулированные, кстати, довольно изжоповым языком. Данная статья по материалам презентации — тоже не отвечает на этот вопрос. Отсюда вопрос: что делать? Читать исходники?
Народ, посоветуйте материалов по поводу Go 1.4 GC.divan0 Автор
12.07.2015 16:03В нем вопрос в том, насколько часто выполняется эта самая «синяя» фаза.
Насколько я понимаю, её частота зависит от того, сколько памяти аллоцирует программа. До Go 1.5 эту частоту можно было тюнить с помощью переменной GOGC, которая, по сути, выставляла порог (в процентах), когда уже пора запускать GC. Соответственно, для разных программ эта частота может быть очень разной.
Собственно, проблема с паузами релевантна только для высоконагруженных систем, которые лопатят гигабайты постоянно обновляемых данных в памяти (как в недавнем примере Qihoo 360). Для остальных случаев частота и продолжительность пауз нынешнего GC настолько низки, что абсолютно незаметны.
А по поводу материалов по предыдущим реализациям GC, надо искать в golang-nuts, были какие-то документы хорошие.23derevo
12.07.2015 16:16ага, понял по поводу старого. По поводу golang-nuts — искал, не нашел ничего толкового. Надо видимо забуриться туда надолго.
В любом случае, если увидете какой-нить адекватный документ — киньте, плиз.
gurinderu
12.07.2015 18:28А что есть та самая «синяя» фаза? Насколько я понял gс в go concurrent и работает в фоне, а значит отжирает те самые 25 процентов у всех. Просто если случился stop world это уже full gc и там он может отожрать хоть 100 процентов
23derevo
12.07.2015 22:17+1У меня тоже сначала сложилось впечатление, что 25% он жрет всегда. Например, постоянно сканирует данные на предмет актуальности. Но на графике почему-то нарисовано, что он включается время от времени. И это реально странно.
Еще одна странная вещь: нарисована какая-то розовая активность «Assist». Что это вообще? Почему за GC считается только «синяя» активность, а розовая не считается?
У меня получилось следующее: новый алгоритм позволяет ценой периодической потери пропускной способности повышать (в каком-то смысле) отзывчивость системы. То есть, в моменты GC система будет-таки подтормаживать (и возможно сильно подтормаживать), но не допускать пауз в несколько секунд.
Учитывая все, сказанное выше, я могу предположить такие изменения с точки зрения перфоманса (все это «в среднем по больнице»):
- worst-case latency будет меньше (и это круто)
- average latency будет больше (и это не очень здорово, но не критично)
- average throughput будет в среднем на несколько процентов меньше (это не критично)
А вообще это все гадание на кофейной гуще, конечно. Нужны нормальные материалы, нужны алгоритмы.
Ну и конечно нужны тесты.
23derevo
12.07.2015 15:22+1Мои «рассуждения универсальны» :) На самом деле, это не рассуждения, а факты. Пример про сотню серверов — это просто пример, не фокусируйтесь на нем.
Я пишу о том, что для тех, для кого latency критична — это полезное улучшение. А для тех, для кого критична пропускная способность — это некоторая проблема. Что им делать? Докупать теперь серваки?
Ладно, это все не очень интересно. Гораздо интереснее — оригинальная статья про новый GC. Лично мне больше всего понравился кусок про Goals. Там подробно написаны причины, так что не нужно ничего выдумывать.
avdept
13.07.2015 17:54А почему не сделать возможность ручной уборки мусора, хотя бы частичной, а остальное что бы убирал автоматический сборщик? Я понимаю что это грозит некоторыми возможностями прострелить себе колено, но имхо это было бы намног практичнее, особенно при работе веб приложений, когда наверняка знаешь что, что то уже не понадобится до следующего запроса.
gurinderu
14.07.2015 10:16А смысл? Ну допустим мы часть памяти удаляете вручную, часть автоматически. Та часть которая собирается автоматически все равно будет работать параллельно вашей программы и потом может сделать тот же самый stop world. К тому же есть шанс удалить объект, а ссылку где-нибудь да оставить. Если и хочется избавится от gc, то можно использовать offheap )
avdept
14.07.2015 10:33А разве размер кучи не влияет на время работы сборщика?
divan0 Автор
14.07.2015 10:47Статья же об этом ) До 1.5 — влияет, после 1.5 — практически нет (есть небольшая корелляция, которую устранят к 1.6)
gurinderu
14.07.2015 11:28На самом деле авторы хитрят.
Я подозреваю там простая реализация сoncurrent mark and sweep или может быть аналог g1 из java.
В любом случае эту кучу нужно будет когда-нибудь полностью чистить и если она большая, то для этого может понадобится очень много времени)
divan0 Автор
14.07.2015 10:46На самом деле там были обсуждения и до Go 1.0 даже были в stdlib функции runtime.Alloc() и runtime.Free(), но их убрали. Надо мейллисты искать для подробностей.
Xlab
Теперь ещё и геймдев возьмёт на вооружение.
namespace
Go неплох, как замена Lua.
voidnugget
Как показала практика, с rust'a больше толку в геймдеве.
lightman
А можно ли подробнее?
voidnugget
Можно использовать с UE4, в принципе вполне съедобно. Постили про ржавый в OpenGL'е.
В принципе можно использовать так же как и С++ и совместно с ним, ток безопаснее и без побочки.