Comments 81
Теперь ещё и геймдев возьмёт на вооружение.
Это победа, мужики, это победа!
Что только не придумают, что-бы не использовать Rust.
У него на много выше порог вхождения, менее стабильная стандартная библиотека и более плюс-плюсоподобный «размороженный» синтаксис.
Из-за этого он не годится для разработки «долгоиграющих» решений с lts'ом. Вот Golang проще и он вполне годен для lts'a.
Rust корректнее сравнивать со swift'ом — уже есть кривые objc биндинги к foundation'у, и можно даже собрать iOS таргет с правильной травой.
p.s. я и сам сижу сча рефакторю hyper :3
Из-за этого он не годится для разработки «долгоиграющих» решений с lts'ом. Вот Golang проще и он вполне годен для lts'a.
Rust корректнее сравнивать со swift'ом — уже есть кривые objc биндинги к foundation'у, и можно даже собрать iOS таргет с правильной травой.
p.s. я и сам сижу сча рефакторю hyper :3
А Go 1.5 собирается под iOS таргет уже без травы ;)
И где там bind'инги под Foundation?
C gobind'ом и Java под андроёд ещё понятно.
Но вот с iOS ситуация сейчас вроде как сложнее.
Я вообще думал брать, парсить существующие swiftmodule swiftdoc и генерить соответствующие биндинги под rust и golang.
Правда до этого ещё не скоро дойдёт — не так много свободного времени.
C gobind'ом и Java под андроёд ещё понятно.
Но вот с iOS ситуация сейчас вроде как сложнее.
Я вообще думал брать, парсить существующие swiftmodule swiftdoc и генерить соответствующие биндинги под rust и golang.
Правда до этого ещё не скоро дойдёт — не так много свободного времени.
менее стабильная стандартная библиотекаДо 2.0 всё железобетонно же (sans баги компилятора).
Нестабильных плюшек сейчас хватает и очень много проектов их использует по не совсем понятным мне причинам.
Ну вот rustfmt хрен на 1.1 соберёшь — нужна nightly сборка.
Там используется авторская strings.rs, не знаю что он там тянет и почему автор решил пилить свой велосипед.
Ну вот rustfmt хрен на 1.1 соберёшь — нужна nightly сборка.
Там используется авторская strings.rs, не знаю что он там тянет и почему автор решил пилить свой велосипед.
Ну на самом деле ниши у Go и Rust, хоть и пересекаются, всё же различные. У всего есть своё применение, и во многих случаях сборщик мусора очень удобен, гораздо удобнее чего бы то ни было ещё.
Согласен, но все же, там где важно отсутствие тормозов от сборки мусора — лучше Rust, IMHO. А клиенты, которые и так в сеть ходят, а значит тупят, можно и на Go писать.
На моем опыте, тут главная сложность именно в том, чтобы отличить, где важно отсутствие пауз, а где нет. Большинство сторонников языков без GC, занимают очень однобокую позицию, демонизируя GC и не понимая реалий компромиссов в разработке на языках с GC и без.
Вот с этого момента — поподробнее. Я, наверное, чего-то не понимаю, но реалии разработки таковы: языки без GC — дружелюбны и просты в использовании, языки на GC — это, я извинюсь, п@#$ец на выезде.
Объясняю, что я имею в виду. Предположим, что я решил написать какую-нибудь мегахрень. Взял библиотеку на FORTRAN'е, добавил модуль на каком-нибудь FreePascal'е, разумеется сдобрил ещё парой либ на C (с его gobject'ом) и С++(с его аллокаторами и аренами)… Ну и до кучи ещё LUA для исполнения скриптов прикрутил. Да, потребуется некоторое количество жвачки, скотча и проволоки, чтобы всё скрутить, но больших проблем нет.
А теперь давайте рассмотрим такой же вариант, только матбиблиотека у нас будет на C#, модуль на Go, ну и там пара компонент ещё на каком-нибудь V8 и Lisp'е. Попытка всё это добро объединить потребует кучу времени, а после этого можно будет ещё пару лет писать статьи на Хабр с объяснением того, как взаимодействие между этим всего-навсего четырьмя GC периодически всю нашу систему ставит раком.
Язык без GC — это просто язык, язык с GC — это захватчик, узурпатор, «должен остаться только один» царь-император, который, так и быть, будет ещё как-то повелевать языками без GC, но ужиться с себе подобными? Ооо..., об этом можно слагать легенды.
Объясняю, что я имею в виду. Предположим, что я решил написать какую-нибудь мегахрень. Взял библиотеку на FORTRAN'е, добавил модуль на каком-нибудь FreePascal'е, разумеется сдобрил ещё парой либ на C (с его gobject'ом) и С++(с его аллокаторами и аренами)… Ну и до кучи ещё LUA для исполнения скриптов прикрутил. Да, потребуется некоторое количество жвачки, скотча и проволоки, чтобы всё скрутить, но больших проблем нет.
А теперь давайте рассмотрим такой же вариант, только матбиблиотека у нас будет на C#, модуль на Go, ну и там пара компонент ещё на каком-нибудь V8 и Lisp'е. Попытка всё это добро объединить потребует кучу времени, а после этого можно будет ещё пару лет писать статьи на Хабр с объяснением того, как взаимодействие между этим всего-навсего четырьмя GC периодически всю нашу систему ставит раком.
Язык без GC — это просто язык, язык с GC — это захватчик, узурпатор, «должен остаться только один» царь-император, который, так и быть, будет ещё как-то повелевать языками без GC, но ужиться с себе подобными? Ооо..., об этом можно слагать легенды.
языки без GC — дружелюбны и просты в использовании, языки на GC — это, я извинюсь, п@#$ец на выезде
По вашему, C++ — дружелюбен, а Go — «п@#$це на выезде»? Извините, я тут даже не знаю тогда, с чего начать, и стоит ли вообще.
Не очень понял, каким образом «зоопарк» языков соотносится с вопросом оценки необходимости GC для каждого конкретного случая.
Я говорил о том, что очень редко встречал программистов, которые могут грамотно и спокойно оценить — где паузы GC будут проблемой, а где нет. Обычно, они склоняются к какой-то одной позиции, упрощая всё до «GC — плохо» или «ручное управление памятью — зло».
По вашему, C++ — дружелюбен, а Go — «п@#$це на выезде»?Для пользователей? Да, конечно. Qt можно вкрутить хоть в Python, хоть в Java, хоть в PHP, а попробуйте вызвать Go'шную библиотеку из той же Java'ы.
Я говорил о том, что очень редко встречал программистов, которые могут грамотно и спокойно оценить — где паузы GC будут проблемой, а где нет.Проблемы GC далеко не только в паузах. Проблемы в GC — в написании кода «на выброс». Вот выбрали вы какой-нибудь C# или там Go, а потом раз — и «парадигма изменилась» и вместо Windows теперь Android. Что вы с вашим кодом делать-то будете? Ну какое-то время можно пожить с «коллекцией костылей», но рано или поздно придётся всё переделывать. В то же время библиотеки, написанные на FORTRAN'е и/или C лет так 20-30 до сих пор в строю — и через 20-30 лет всё ещё будут в строю.
Если ваш проект не имеет «срока годности» (например если вы пишите игру, то тот факт, что её через 10 лет не на чем будет запускать никого не волнует) и не является чем-то «большим и серверным» (когда вы пишите ПО для станка или, наоборот, для кластера, то вы можете позволить себе выбирать ОС под вашу программу, а не наоборот), то лучше с языками с GC не связываться. И паузы пресловутые — далеко не самая большая проблема.
Сейчас можно и dll'ку go'шную линкануть, и метод откуда-угодно вызвать, другое дело что go runtime себя будет довольно странно вести, так что это немного неудачный пример.
Конкретно, в С++ есть следующие недостатки, которых нет в Golan'e
Конкретно, в С++ есть следующие недостатки, которых нет в Golan'e
- Много разношерстных стандартов
- Хватает побочных эффектов
- Много решений поощряют возникновение ошибок
- Ужасный порог вхождения, глянуть хотя бы костыли с boost'a
- Надо хотя бы пару лет для того что бы было понятно что и как и куда ...
Я расшифровал предыдущий пассаж следующим образом.
Есть языки с GC, а есть языки без GC. Далее, есть случай, когда используется только один язык программирования. Но это — неинтересный случай, т.к. бери и используй. Удобно С++? Хорошо. Java — тоже хорошо. Go — замечательно, ну в смысле тоже одинаково хорошо. Как говорится, зависит от задач и опыта разработчика(ов).
Другое дело, когда у нас необходимо скрещивать несколько языков, и вызывать один язык из другого. Если у нас все языки без GC, то проблемы со скрещиванием минимальны: С/C++/Fortran — практически безболезненно. А вот если скрещивать языки с GC, то тут могут возникнуть проблемы: у каждого свой рантайм, свой GC, и они могут внезапно подраться за память, объекты и т.п. Типичные проблемы managed/unmanaged помножаются на то, что тут связь уже может быть managed/unmanaged/managed или ещё что похлеще. По крайней мере, я знаю, как связывать C++ с Java/C#/Python/Lua и др., а вот как связать C#, Go и Java — не очень. Разве что через С++. Но кажется, что это будет адская хрень.
Тут в общем-то не поднимается вопрос о том, а нужно ли это. Тут скорее рассуждения на тему. Ну а моё личное мнение — языки с GC, безусловно, сильно удобнее в разработке. Хотя C++ с новыми стандартами уже начинает дышать в спину, но по удобству всё равно не дотягивает.
Есть языки с GC, а есть языки без GC. Далее, есть случай, когда используется только один язык программирования. Но это — неинтересный случай, т.к. бери и используй. Удобно С++? Хорошо. Java — тоже хорошо. Go — замечательно, ну в смысле тоже одинаково хорошо. Как говорится, зависит от задач и опыта разработчика(ов).
Другое дело, когда у нас необходимо скрещивать несколько языков, и вызывать один язык из другого. Если у нас все языки без GC, то проблемы со скрещиванием минимальны: С/C++/Fortran — практически безболезненно. А вот если скрещивать языки с GC, то тут могут возникнуть проблемы: у каждого свой рантайм, свой GC, и они могут внезапно подраться за память, объекты и т.п. Типичные проблемы managed/unmanaged помножаются на то, что тут связь уже может быть managed/unmanaged/managed или ещё что похлеще. По крайней мере, я знаю, как связывать C++ с Java/C#/Python/Lua и др., а вот как связать C#, Go и Java — не очень. Разве что через С++. Но кажется, что это будет адская хрень.
Тут в общем-то не поднимается вопрос о том, а нужно ли это. Тут скорее рассуждения на тему. Ну а моё личное мнение — языки с GC, безусловно, сильно удобнее в разработке. Хотя C++ с новыми стандартами уже начинает дышать в спину, но по удобству всё равно не дотягивает.
С java go вызывается довольно просто — генерится байндинг gobind'ом.
Мороки с вытеснением памяти кучи сейчас нет, а раньше была.
Бывают проблемы когда два сборщика мусора одновременно срабатывают, но это при оч загруженном приложении — обещали пофиксить в ближайшем будущем. А вообще сейчас можно собрать shared либу и вызывать с неё всё как с сишки, afaik runtime обычно сам поднимается с libgo, хотя я сильно не разбирался как и что там. У меня больших проблем с вызовом go функций с под NDK ведроида и со swift'a на iOS пока не возникало. С С# / Python / Lua будет вызываться как и любая сишная функция, предварительно инициализирующая рантайм.
Мороки с вытеснением памяти кучи сейчас нет, а раньше была.
Бывают проблемы когда два сборщика мусора одновременно срабатывают, но это при оч загруженном приложении — обещали пофиксить в ближайшем будущем. А вообще сейчас можно собрать shared либу и вызывать с неё всё как с сишки, afaik runtime обычно сам поднимается с libgo, хотя я сильно не разбирался как и что там. У меня больших проблем с вызовом go функций с под NDK ведроида и со swift'a на iOS пока не возникало. С С# / Python / Lua будет вызываться как и любая сишная функция, предварительно инициализирующая рантайм.
Тут в общем-то не поднимается вопрос о том, а нужно ли это. Тут скорее рассуждения на тему.Тут не голословные рассуждения на тему. Рассуждениями на тему эти вещи были лет 10 назад, когда языки без GC были нормой, а языки с GC — редкой экзотикой. Один язык с GC в проекте пережить можно (хотя зачастую возникает ощущение что «хвост виляет собакой»), но вот когда их становится больше одного… Сейчас же как раз дело дошло до достаточно их широкого использования для того, чтобы это начало реально происходить. И я вам скажу… глюки, которые возникают, когда в одном процессе у вас сталкиваются ART (а куда деваться: на нём все интерфейсы Android'а), C# (а это — уже потому что кто-то в Unity Technologies когда-то решил, что C# — это «самое то» для написания простеньких скриптов) и V8 (а чё: крутые web-технологии — это наше всё), то возникает не вопрос «а почему это всё падает периодически», а скорее «вау: они умудрились-таки сделать так, что эта хрень может 15 минут проработать и не упасть».
Но кажется, что это будет адская хрень.В том-то и дело, что это не будет адская хрень. Это уже есть адская хрень — и будет только хуже.
Ну а моё личное мнение — языки с GC, безусловно, сильно удобнее в разработке.Но сложнее в поддержке. Как я уже сказал: если вас не волнует что будет с вашим творением лет через 10 или, наоборот, вы уверены, что и через 10 лет сможете поддерживать всю необходимую инфраструктуру — тогда вперёд. Только хорошо подумайте: понятно что Google сможет всю необходимую инфраструктуру поддерживать сам, но вот уже даже у Яндекса с этим, скорее всего, возникнут проблемы.
Я вас правильно понимаю — вы засовываете в «один процесс» C#, Java и V8, сознательно создавая, по вашему же утверждению, «адскую хрень» и потом заявляете, что проблема в GC?
Засовываю не я — я только разгребаю случаи, когда всё это хозяйcтво начинает «разваливаться» от весьма небольших изменений в коде Android'а. И да — проблема в GC, от обычных языков, не требующих таких хитростей проблем гораздо меньше.
А собственно говоря, в чем проблема? Или желание юзать библиотеки из разных платформ (C#/Java) — это плохо? Или желание выполнять javascript код на беке для рендеринга это хуже чем писать клиент и сервер на javascript?
Проблема в понимании причинности проблем. Мне звучит нелогичным утверждение «GC — зло, потому что, если собрать адскую хрень из 3-х языков, то начинаются проблемы». Это как взгромоздить велосипед на автомобиль, а автомобиль на самолёт и утверждать, что «колёса — зло, потому что из-за них начинаются проблемы».
Гм… Я привел реальные юзкейсы, а ты приводишь какие-то ебнутые аналогии. Я даже не знаю как спросить повежливее: дяденька, ты дурак?
Нда уж, желание услышать нормальную аргументацию нынче расстреливается минусами…
Минусами расстреливаются неадекватно выраженные желания.
В далёком 87 году дедушка Вирт на своём языке со сборкой мусора написал многозадачную операционку скрещённую со средой разработки и неким подобием ActiveX. Сборщик мусора, запрет сишной адресной арифметики и принудительные проверки границ массивов не тормозили, не падали и не создавали проблем с поддержкой ни ему, ни его коллегам, ни студентам. Несколькими годами позже подобная система от его учеников стала управлять работой АЭС и тоже никаких проблем.
У вас проблема не от GC, а от того, что вы пользуетесь чужим говнокодом который не умеет, но пытается использовать ещё три кучи говнокода. Франкенштейн, знаете ли, монстром был не потому, что его током стукнуло, а потому, что его создателю до абсурдности идеи дела не было.
В далёком 87 году дедушка Вирт на своём языке со сборкой мусора написал многозадачную операционку скрещённую со средой разработки и неким подобием ActiveX. Сборщик мусора, запрет сишной адресной арифметики и принудительные проверки границ массивов не тормозили, не падали и не создавали проблем с поддержкой ни ему, ни его коллегам, ни студентам. Несколькими годами позже подобная система от его учеников стала управлять работой АЭС и тоже никаких проблем.
У вас проблема не от GC, а от того, что вы пользуетесь чужим говнокодом который не умеет, но пытается использовать ещё три кучи говнокода. Франкенштейн, знаете ли, монстром был не потому, что его током стукнуло, а потому, что его создателю до абсурдности идеи дела не было.
В далёком 87 году дедушка Вирт на своём языке со сборкой мусора написал многозадачную операционку скрещённую со средой разработки и неким подобием ActiveX. Сборщик мусора, запрет сишной адресной арифметики и принудительные проверки границ массивов не тормозили, не падали и не создавали проблем с поддержкой ни ему, ни его коллегам, ни студентам. Несколькими годами позже подобная система от его учеников стала управлять работой АЭС и тоже никаких проблем.Вы не поверите, но управление АЭС — это очень простая задача. Да, там очень высокая цена ошибки, но это не делает саму задачу сложной.
А поводу «многозадачных операционок с неким подобием ActiveX»… не расскажите — где она? И кто ей (или её потомками) сейчас пользуется?
У вас проблема не от GC, а от того, что вы пользуетесь чужим говнокодом который не умеет, но пытается использовать ещё три кучи говнокода.Нет, проблема-таки именно от GC. Идиоты-теоретики (я тут использую слово идиот в его изначальном смысле) типа Вирта и Танненбаума так и не поняли, что в 70е мир изменился. Провозвестником этого изменения было семейство IBM 360, а лет через 15-20 направление, которое она задала — стало главным и определяющим.
И это направление — это обратная совместимсть. Если в 50е и 60е переписывание программ с нуля было нормой (так как никакое железо ни с каким другим не было совместимо), то начиная с 70х — это стало вещью весьма желательной, а с 80х — практически железным требованием. Даже «всесильный Apple» закрывает глаза на использование в программах для iOSа всяких C# и/или Java (которые туда приходится засовывать с большим скрипом из-за ограничений системы), так как знает: если она заставить всех всё переписывать чисто под себя, то iOS отправится на свалку истории вслед за BlackBerry и Windows Phone'ом.
Кстати этот процесс Вирт мог легко наблюдать смотря на судьбу своим собственных творений: Паскаль — таки активно использовался, где-то как-то кто-то видел, а Оберон — вне лабораторий никто толком и не наблюдал.
А нам тут решением «вы просто перепишите всё» всерьёз предлагается как решение «проблемы GC».
Да, там очень высокая цена ошибки
И GC там к ошибкам во время работы не приводит. Если у них есть GC и всё хорошо, а в вашем зверинце всё плохо, то проблема не в идее сборки мусора.
Нет, проблема-таки именно от GC.
Если библиотека фигово отделяет друг от друга данные и код на трёх языках или кто-то криво написал _отдельно взятый_ сборщик мусора, то виновата идея сборки мусора. Хотя чего мелочиться? Давайте запретим стандартные библиотеки, а лучше вообще компьютеры, ведь это они работают неправильно.
Ножами в пьяных драках постоянно тоже каждый день убивают, но никто не вопит «во всём виноваты ножи и алкоголь, давайте их запретим».
А нам тут решением «вы просто перепишите всё»
Решение: не используйте говнокод, а если используете — не жалуйтесь что он не работает. И не обобщайте единичные проблемы до вселенского масштаба.
Если библиотека фигово отделяет друг от друга данные и код на трёх языках или кто-то криво написал _отдельно взятый_ сборщик мусора, то виновата идея сборки мусора.Проблема не в «отдельно взятом» сборщике мусора. Порочна сама идея GC, так как она основана на порочном предположении о том, что GC может знать о том что где в памяти расположено и никто кроме GC на это не влияет.
Эта идея — не работает. Уж сколько раз за полвека было попыток сделано. Не работает. На малых системах — работает (но там и без GC управлять памятью не проблема), на больших — не работает.
Т.е. вы говорите, что инкапсуляция — не для вас и вообще глупость, думаете, что точно знаете, как в памяти размещаются объекты нескольких языков и наивно полагаете, что этот формат не изменится.
Да, в языках с ручным управлением памятью и атавизмами типа адресной арифметики формат хранения в памяти описан и не меняется, а ваша логика работает, но глупо требовать работоспособности такого хардкода от более динамичных языков, в которых внутреннее представление объектов может измениться даже при мелких обновлениях.
Вы сами начали мешать сборщику мусора, но почему-то обвиняете в этом не себя и свой говнокод, а сборщик мусора. Простите, но идиотом (в том самом, изначальном смысле) являетесь вы сами, а не Вирт и Танненбаум — мир и языки изменились, а вы не заметили, что влезать с ржавым ножом внутрь системы уже нельзя.
Да, в языках с ручным управлением памятью и атавизмами типа адресной арифметики формат хранения в памяти описан и не меняется, а ваша логика работает, но глупо требовать работоспособности такого хардкода от более динамичных языков, в которых внутреннее представление объектов может измениться даже при мелких обновлениях.
Вы сами начали мешать сборщику мусора, но почему-то обвиняете в этом не себя и свой говнокод, а сборщик мусора. Простите, но идиотом (в том самом, изначальном смысле) являетесь вы сами, а не Вирт и Танненбаум — мир и языки изменились, а вы не заметили, что влезать с ржавым ножом внутрь системы уже нельзя.
Я восхищён вашим умением валить всё с больной головы на здоровую, но должен же быть у этого и какой-то предел, а?
Как только вы мне покажите систему где одновременно работают творения Вирта, Танненбаума (да я, в общем, на них не настаиваю — можно и других) — у нас будет предмет для обсуждения. А пока я вижу, что они отлично работают в отдельности «не участвуя в общем собрании граждан полиса», а как только в одном процессе у нас образуется «демократия», так там начинается фигня, то есть их творения являются классическими идиотами.
Т.е. вы говорите, что инкапсуляция — не для вас и вообще глупость, думаете, что точно знаете, как в памяти размещаются объекты нескольких языков и наивно полагаете, что этот формат не изменится.Наоброт! Я верю в инкапсуляцию и именно поэтому не верю в GC! Компилятор FORTRAN'а (вернее его библиотека) знает о том как работать с теми данными, которыми он заведует, компилятор C++ знает как он работает с данными, которые он насоздавал, Lua заведует своими объектами, все эти объекты могут свободно жить в одной куче и между ними не возникает никаких конфликтов. И вот только GC считает, что он всюду может просунуть свои щупальцы и про все объекты имеет право знать всё.
глупо требовать работоспособности такого хардкода от более динамичных языков, в которых внутреннее представление объектов может измениться даже при мелких обновлениях.Я ничего такого от них и не требую! Наборот — это они от меня требуют рассказывать где что у меня лежит и как оно устроено. А в идеале — требуют отказаться от своего рантайма и перейти на их собственный «самый главный и льючший».
Вы сами начали мешать сборщику мусораМешают сборщикам мусора в основном другие сборщики мусора, каждый из которых считает, что он — самый главный.
Простите, но идиотом (в том самом, изначальном смысле) являетесь вы сами, а не Вирт и Танненбаум — мир и языки изменились, а вы не заметили, что влезать с ржавым ножом внутрь системы уже нельзя.Действительно — мир изменился и теперь делать вид, что вы можете контролировать его целиком нельзя. Однако же творения теоретиков очень этого хотят, а когда в результате получается чушь собачья объясняют, что нужно было ходить в ногу, тогда и беды бы не было. Может быть, но проблема в том, что заставить всех «ходить в ногу» не получается.
Как только вы мне покажите систему где одновременно работают творения Вирта, Танненбаума (да я, в общем, на них не настаиваю — можно и других) — у нас будет предмет для обсуждения. А пока я вижу, что они отлично работают в отдельности «не участвуя в общем собрании граждан полиса», а как только в одном процессе у нас образуется «демократия», так там начинается фигня, то есть их творения являются классическими идиотами.
Т.е. вы утверждаете, что управлять памятью огромной системы гораздо проще? Чем больше кода, тем больше вероятность memory leak. В случае с platform with gc эта вероятность явно ниже. И я не предлагал делать, тупой copy-paste, естественно нужно учитывать особенности языка и платформы и делать оптимальнее.
P.S. если бы не было gc, то скорее всего у нас не было бы тонн софта. Для разработки на том же с++ времени уходит намного больше.
P.S. если бы не было gc, то скорее всего у нас не было бы тонн софта. Для разработки на том же с++ времени уходит намного больше.
Т.е. вы утверждаете, что управлять памятью огромной системы гораздо проще?Конечно. То, что вы при использовании 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, в результате чего, как правило, потребление ресурсов возрастает на порядки, а новой функциональности добавляется чуть-чуть.
Только в последнее время происходит переход на языки с GC, в результате чего, как правило, потребление ресурсов возрастает на порядки
Если бы у сборки мусора всё было настолько плохо, то Вирт просто не смог бы работать в ОС Оберон из-за тормозов, да и микроконтроллер внезапно зависающий на секунду («мусор собираема, насяльнике») никто бы продавать не рискнул. В случае Джавы с Далвиком ваше утверждение, возможно и верно, как-никак в их основе виртовская же виртуальная машина полувекового возраста, но в общем случае оно уже много лет как неактуально. По крайней мере я до сих пор вспоминаю, как BlackBox Component Builder пересобирал пять метров своих исходников пока VS 06 пыталась переварить Hello World о пяти строчках.
Единственный пусть — постепенно добавлять в неё модули на других, более современных, языках. Языки с GC делают этот путь невероятно сложным и рискованным.
В такое мамонтовое изделие, полагаю, любой язык отличный от оригинального добавлять сложно и рискованно. Однако вместо того, чтобы позволять этому зоопарку работать в одной области памяти лучше бы заставили их сообщениями, вместо кусков памяти, обмениваться — тогда какие-то части системы будет реально заменить на свежачок и без головной боли.
Наоброт! Я верю в инкапсуляцию и именно поэтому не верю в GC!
Как бы сказать, ваша фраза о том, что сборщику мусора нужно, чтобы никто кроме ОС в его памяти не ковырялся. Всё верно — ему необходима инкапсуляция, а, точнее, изоляция от других работающих с памятью сущностей. Уж не знаю как, но у вас нарушено это требование и проблемы «какая сволочь на место объекта число записала?!» всплывают на порядки быстрее, чем они могли бы всплыть без сборщика мусора (охотно верю, что без него они могли бы не всплывать ещё годы). Как и любой предмет, сборщик мусора требует соблюдения правил эксплуатации.
Уж не знаю как, но у вас нарушено это требование и проблемы «какая сволочь на место объекта число записала?!» всплывают на порядки быстрее, чем они могли бы всплыть без сборщика мусора (охотно верю, что без него они могли бы не всплывать ещё годы).Без него они бы вообще никогда бы не всплыли, так как число на месте объекта оказалось из-за того, что кто-то держал на этот объект ссылку в месте, о котором не удосужился GC сообщить и он его переиспользовал.
GC категорически несовместим с инкапсуляцией: для того, чтобы он мог работать он должен видеть все ссылки. Ещё раз: все ссылки. Приватные, публичные, какие угодно. Какая же это, к бесу, инкапсуляция?
Как и любой предмет, сборщик мусора требует соблюдения правил эксплуатации.Нет, нет и нет: он требует нарушения правил эксплуатации. И отказа от инкапсуляции и прав доступа. Иначе он не сможет работать. Тут правда есть тонкость: многие люди относят инструменты типа ARC к GC. Я его к GC не отношу именно потому, что он не требует отказа от инкапсуляции, «обхода» прав доступа и прочего ужаса. Это не панацея, конечно, но это нормальный, хороший, годный, инструмент. А вот GC — это раковая опухоль: раз появившись в системе он пускает метастазы и пытается заразить весь рантайм сниху доверху.
В такое мамонтовое изделие, полагаю, любой язык отличный от оригинального добавлять сложно и рискованно.Все успешные проекты со временем превращаются в подобные поделия. Есть правда, фирмы, которых иногда обуздывает зуд и они решают всё переписать с нуля. Большинство на этом и кончаются, часть просто выкидывает на ветер кучу денег и возвращается к истоками (см. Microsoft, который так и не переписал Windows и MS Office на C# — а иначе мы бы уже в прошедшем времени о нём говорили).
Однако вместо того, чтобы позволять этому зоопарку работать в одной области памяти лучше бы заставили их сообщениями, вместо кусков памяти, обмениваться — тогда какие-то части системы будет реально заменить на свежачок и без головной боли.А смысл какой? Только чтобы позволить использовать GC? А как же обещания на тему, что GC нам что-то там улучшит? Пока как-то получается что он в основном к проблемам приводит, а улучшениями и не пахнет.
Если бы у сборки мусора всё было настолько плохо, то Вирт просто не смог бы работать в ОС Оберон из-за тормозов, да и микроконтроллер внезапно зависающий на секунду («мусор собираема, насяльнике») никто бы продавать не рискнул.Не знаю как там в ОС Оберон, но моё первое общение с редактором, написанным на LISP'е примерно так и выглядело: он примерно раз в пару минут останавливался и «уходил куда-то» секунд на пять. Это было ещё на «эталонных» IBM PC XT (вернее клонах), но с тех пор ровным счётом ничего не изменилось, кроме масштаба: всё так же GC приводит к проблемам, только теперь они выражаются в том, что «выпадают кадры» и «дёргаются персонажи» и всё так же можно с этим справиться если выделить системе раз в этак 10 больше ресурсов, чем ей, на самом деле, нужно.
В случае Джавы с Далвиком ваше утверждение, возможно и верно, как-никак в их основе виртовская же виртуальная машина полувекового возраста, но в общем случае оно уже много лет как неактуально.И эти слова я тоже не первый год слышу. «Ну да, конкретно вот тут у нас проблемка, но это мелочи, ерунда, ещё чуть-чуть и все эти беды останутся в прошлом». Есть подозрение, что и полвека назад людям то же самое пели и ещё через полвека мы это будем слышать. Время течёт, проблема остаётся: GC, который, в теории, должен помогать людям решать проблемы, на самом деле их скорее создаёт.
Я видел кучу людей, которые работают с ручным выделением памяти годами и почти никто из них даже не задумывается над тем, что там «унутре» (иногда это бывает важно, но ооочень редко — даже в высоконагруженных системах), но зато если в языке есть GC, то вопросы его «приручения» — одни из самых обсуждаемых. Да и, собственно, данная статья — прекрасный тому пример. Вам не кажется, что эта… когда инструмент решает проблемы — то его просто используют, большинство людей сталкивается с описанием инструмента разве что «в курсе молодого бойца», а вот если его всё время дотачивают и обсуждают — то он их скорее создаёт?
да и микроконтроллер внезапно зависающий на секунду («мусор собираема, насяльнике») никто бы продавать не рискнул.В типичном микроконтроллере памяти столько нет, чтобы зависать на секунду, а о качестве его работы говорит тот факт, что подобные микроконтроллеры — экзотика, а не норма жизни. Хотя как раз там самое ужасное свойство GC роли не играет: обычно программы для микроконтроллеров не настолько велики, чтобы их нужно было годами разрабатывать на разных языках.
Я не утверждаю, что GC избежит всех проблем утечек, но он хотя бы поможет избежать глупых. К тому же если вы хоть раз писали на с++ (скорее всего да), то помните проблему еще и фантомными ссылками. Я не утверждаю, что GC это silverbullet, есть скоп задач для которых может не подойти такая платформа, но и утверждать что во всем виноват GC не правильно.
P.S. Кстати мне сложно представить, что у вас за система, которая разрабатывается 30 лет. К примеру той же Java всего 20)
P.S. Кстати мне сложно представить, что у вас за система, которая разрабатывается 30 лет. К примеру той же Java всего 20)
P.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) очень дорого обходились компании: они неизбежно кончались слезьми, потерей времени и откатом на прежние позиции. Переписывание отдельных компонент — да, во многих случаях от первой версии ни одной строчки не остаётся, а «сесть и написать заново» — не работает.
В такой ниже gc и не нужен. Это операционные системы, где желательно сделать отклик как можно меньше. И да, я издеваюсь. Я вижу, что вы не понимаете сравниваете несовместимое. У каждого языка есть своя ниша. Где-то нужно писать очень быстро и не думать, о указателях, ссылка, о командах процессора и оптимизации, нужно чтобы это просто работало по описанной бизнес логике с как можно меньшим количеством ошибок. На С++ к сожалению так не получится.
Я понял вашу точку зрения, не нужно брызгать слюной и доказывать мне что-то)
Я понял вашу точку зрения, не нужно брызгать слюной и доказывать мне что-то)
Это у вас текстовый процессор стал «такой нижой»? А что языки с GC вполне могут использоваться для случая «никуда они не денутся, будут жрать что дадут» — ну дык. Они там зачастую и используются. Вот только зачем там-то такие сложности? Раньше как-то тривиального Visual Basic'а хватало без всякого GC (там практически во всех программах все объекты статически аллоцировались), а сейчас сами себе наустраивали проблем с GC. Зачем?
Дядя, я просто мимо проходил. Если серьезно, то я никогда таким не занимался, но возможность скрестить нескольков миров, а не плодить копипасту — это очень хорошо. Просто посмотрите на стандартную и самые часто юзаемые библиотеки в языках — они же друг друга повторяют по функционалу, причем зачастую у каждого своя собственная кривая и бажная имплементация. И это не считая дублирующихся библиотек (когда библиотеки предназначены по сути для одних и тех же целей). По мне так желание плодить копипасту в мире — это куда более неадекватное желание.
Если быть точнее, то я не в теме, что именно в скрещивании вызывает основные проблемы, но вполне таки верю, что GC является проблемой для подобного скрещивания. И мне как-то очень грустно видеть такие сообщение. Кстати, вы не думали, что GC и является чужим говнокодом, которым мы все пользуемся?
Другое дело, что подобное скрещивание возможно не очень хорошее решение и гораздо лучшим решение были бы транскомпиляторы, но увы, с ними тоже есть куча проблем
Если быть точнее, то я не в теме, что именно в скрещивании вызывает основные проблемы, но вполне таки верю, что GC является проблемой для подобного скрещивания. И мне как-то очень грустно видеть такие сообщение. Кстати, вы не думали, что GC и является чужим говнокодом, которым мы все пользуемся?
Другое дело, что подобное скрещивание возможно не очень хорошее решение и гораздо лучшим решение были бы транскомпиляторы, но увы, с ними тоже есть куча проблем
За обсценную лексику вообще дают read-only. А еще вы грубы слишком, возможно дело в этом?
Скорее всего такое желание абсурдно. Так как с огромной вероятностью для C# или Java есть
либо wrapper, либо copypaste нужной вам либы. А вот про Javascript я и вовсе не понял. К примеру в java есть nashorn. Запускайте практический любой js код, который хотите. Только опять же не понятна цель всего этого.
либо wrapper, либо copypaste нужной вам либы. А вот про Javascript я и вовсе не понял. К примеру в java есть nashorn. Запускайте практический любой js код, который хотите. Только опять же не понятна цель всего этого.
Так как с огромной вероятностью для C# или Java есть либо wrapper, либо copypaste нужной вам либы.Враппер вам не поможет, а copy-paste — да, может быть. Только вот после этого все разговоры про то, что GC облегчает программирование становятся абсурдом. Что проще: написать одну библиотеку на языке без GC и использовать её везде или написать кучу copy-paste'ных библиотек на куче языков, следить за ними, переносить багфиксы и т.д. и т.п.
Об этом я и говорил изначально: GC — даёт вам тактический выигрыш за счёт стратегического проигрыша. Хуже того: весь «бравый новый мир» паразитических языков с GC живёт за счёт фундамента, построенного на основе языков без GC. Но при этом «эти люди» почему-то своим убожеством кишатся и делают вид, что «они тут самые главные». Нет, ребята, детишки, копающиеся совочком в песочнице, может и «цветы жизни», но без больших дядей, которые возять песок и стройматериалы им бы было просто негде копаться.
Враппер для языка c GC на Manual естественно сделать нельзя или сложно, а обратное можно вполне. Правильный ответ нужно писать либу для каждого языка, поскольку вызов native с той же java дает неплохие накладные расходы)
весь «бравый новый мир» паразитических языков с GC живёт за счёт фундамента, построенного на основе языков без GC
А Oberon 07 живет со сборщиком мусора на микроконтроллерах. На каких «фундаментах» boost'ов и фортранов паразитирует он? Кто подвозит стройматериалы?
С/C++/Fortran — практически безболезненно. А вот если скрещивать языки с GC, то тут могут возникнуть проблемы: у каждого свой рантайм, свой GC, и они могут внезапно подраться за память, объекты и т.п.
Это ваше «почти безболезненно» стоило десятилетий пота и крови, а вы хотите всё и сразу. Кому нужна совместимоть не на костылях и мазохизме давно уже обмениваются сообщениями.
Это ваше «почти безболезненно» стоило десятилетий пота и крови, а вы хотите всё и сразу.Нет — я не хочу «всё и сразу». Я хочу «здесь и сейчас». Это разные вещи. Идея GC появилась больше полувека назад и с тех пор она всё время находится в статусе «ну у нас уже почти всё сделано, ещё чуть-чуть поднажмём и всё будет зашибись». Если у вас проблема находится в этом статусе после полувекового активного развития то это не значит, что она никогда не будет решена (вот, полетели же самолёты в начале XX века — а до этого сотни лет были провалы), но это значит, что закладываться на то, что она вот-вот будет решена нельзя. Вот когда будет — тогда и будет. А пока — не нужно.
А Oberon 07 живет со сборщиком мусора на микроконтроллерах.Не бойтесь — он там тоже не удержится. Просто там ещё славная доисторическая эпоха (про которую я уже писал) не кончилась. Если вы разрабатываете небольшую, ограниченную, систему, то вы можете хоть GC использовать, хоть Forth, хоть верёвку с мылом. Проблемы начинаются, когда вы создаёте что-то большое и у вас проекты начинают разработываться десятилетиями. И вот там GC — строго противопоказан, но именно туда его с упорством, достойным лучшего применения, суют уже скоро 20 лет.
Только опять же не понятна цель всего этого.
Я же сказал, писать SPA и рендерить страницы для новых посетителей и поисковиков. Вполне себе разумная цель.
В рамках одной платформы (runtime-а) языки с GC совмещаются практически без жвачки/скотча/проволоки (разве что в некоторых случаях придётся прибегнуть к небольшим синтаксическим ограничениям, чтобы сделать совместимыми интерфейсы). Что касается языков, которые сами себе платформа (куда в т.ч. входит go), так не получится (хотя как минимум, под php можно писать модули на C, C++).
Код всех JVM-языков можно смешивать. Почти наверняка тоже самое касается .NET (утверждать не могу, в последний раз писал отдельно на c#, отдельно на managedC во времена 3го фреймворка).
Если же в арсенале имеются жвачка/скотч/проволока, то внезапно оказывается, что код под JVM можно совмещать с нативным в обе стороны (при чём, на сколько я помню, даже не один способ есть), код на .NET еще легче чем в java совмещается с нативным (даже писать скотч и проволока не потребуется, надо будет только немного клея написать). На счёт Go не знаю, не приходилось разбираться.
Кстати, вопрос. Аллокация в языках с GC по сложности - O(1), т.е., почти не зависит от объёма памяти. Что там с аллокацией в языках без GC в случае непрерывной работы с постоянно фрагментирующейся памятью (т.е., выделяем сотню объектов - освобождаем 30-50 случайных в произвольном порядке, выделяем еще 200 - освобождаем 100, включая часть выделенных в начале и т.д.)? Не получится ли в итоге, что время, теряемое на поиск свободного участка в куче при каждой аллокации, сравнимо по порядку с временем работы GC (я не утверждаю, что оно будт одинаковым - всё-таки, GC еще и перемещать объекты может, да и на поиск тратится время)?
Аллокация в языках с GC по сложности - O(1), т.е., почти не зависит от объёма памяти.
Только при условии, что этой памяти у вас — дофига и больше. Если у вас есть информация, что кто-то где-то изобрёл GC, способный как-то работать в условиях, когда количество “живых” объектов сравнимо с объёмом доступной памяти — поделитесь ссылкой.
Я за этой темой не слежу (в силу бессмысленности), но во времена написания этой статьи ситуация была такая же, как и в прошлом веке: если вы можете выделить для системы с GC в 10 раз больше памяти, чем суммарный объём всех “живых” объектов — то время, затрачиваемое на GC, оказывается приемлемым, если “всего лишь в 4” — начинаются проблемы, при приближении к 2 — получаем катастрофу.
Не получится ли в итоге, что время, теряемое на поиск свободного участка в куче при каждой аллокации, сравнимо по порядку с временем работы GC (я не утверждаю, что оно будт одинаковым - всё-таки, GC еще и перемещать объекты может, да и на поиск тратится время)?
Нет, не получится. Описываемый вами эффект действительно может, в теории, наблюдаться (современные аллокаторы, скажем, создают пулы на каждый поток, чтобы память оттуда разрадавать, то есть им тоже нужен некоторый “запас” по памяти).
Однако это начинает происходить в момент, когда аналогичная система с GC уже упёрлась в свои пределы и либо начала тратить 99% времени на сам процесс распределения памяти, либо начала кидать OutOfMemoryError (притом, что память, теоретически, ещё не исчерпана, но найти её уже невозможно).
В рамках одной платформы (runtime-а) языки с GC совмещаются практически без жвачки/скотча/проволоки
Ну дык я об этом и говорю: хотите GC - выкиньте всё, что вы наробрали для других систем.
Если же в арсенале имеются жвачка/скотч/проволока, то внезапно оказывается, что код под JVM можно совмещать с нативным в обе стороны (при чём, на сколько я помню, даже не один способ есть), код на .NET еще легче чем в java совмещается с нативным (даже писать скотч и проволока не потребуется, надо будет только немного клея написать).
Это, собственно, то самое паразитирование, о котором я и пишу.
Так, стоп, что за паразитирование и в чём оно состоит?
Если есть крутая, уникальная либа под jvm и я её вызываю из языка без gc - это тоже паразитирование?
Если я из rust-а вызываю системную либу, написанную на сях - это тоже паразитирование?
Или я ничего не понял и это - другое?
Так, стоп, что за паразитирование и в чём оно состоит?
В бессмысленной трате ресурсов, очевидно.
Если я из rust-а вызываю системную либу, написанную на сях - это тоже паразитирование?
Нет, потому что системная либа, написанная на сях, отработала — и успокоилась.
Если вы фортрановскую либу, дёргаете раз в 5 минут, когда пользователь просит график обновить — то оставшиеся 4 минуты 59 секунд у вас она не тратит вообще никаких ресурсов, а в последнюю секунду — потратит ровно столько, сколько потребуется на один график (даже если перед этим вы их уже оторисовали десять тысяч, но они вам пока не нужны и спокойно хранятся где-то в кеше).
Если есть крутая, уникальная либа под jvm и я её вызываю из языка без gc - это тоже паразитирование?
Если вы её вызываете, то тут ещё ладно. А если нет? Загрузили какую-нибудь крутую библиотеку для 3D-спецэффекктов в Protoshop, а пользователь нарисовал кубик и стар обратаывать его в 2D? JVM-runtime у вас всё равно будет “гудеть” производить какую-то бурную деятельность, жрать память и батарейку.
И это пока мы ещё не добавим другой рантайм — тут уже речь пойдёт не о бессмысленной трате ресурсов, а о том, как сделать, чтобы эта конструкция не обрушилась, выжрав всю память.
Любой язык с GC считает, что он в процессе — вамый важный, самый главный, что ради него вообще эту программу писали.
Даже если это крошечная библиотечка на 100 строк. Процитирую себя же самого из поста, на который вы затеяли отвечать:
А теперь давайте рассмотрим такой же вариант, только матбиблиотека у нас будет на C#, модуль на Go, ну и там пара компонент ещё на каком-нибудь V8 и Lisp'е.
С чего вы рассматриваете редкий и малоинтересный вариант, когда используются один рантайм, то есть редкие языки?
В Top10 языков с GC сейчас у нас в десятке: Java, Python, C#, VisualBasic, JavaScript. Общий рантайм только у VisualBasic и C#.
А что происходит если программисту на Java предлагают C# или наоборот? Я лучше нативную для моего рантайма поищу — разве не типичный ответ?
Языки с GC предполагают что в мире останется только один рантайм, но этого не просходило в прошлом, не происходит сейчас и не будет происходить в будущем.
При этом все они могут использовать нативные библиотеки (на C, C++, FORTRAN, Rust), а вот их частные библиотеки без их рантайма, увы, использовать невозможно.
Вот об этом паризитировании и речь: всё брать у нормальных языков, но ничего не давать взамен.
P.S. Замечу, что везде, где я пишу про GC нужно читать трассирующий GC. То есть такой, как в C#/Java/Go: “лезущий во все дыры” и требующий знания о том, живы или нет все объекты, в том числе те, которые созданы вообще в других языках, и которые его ну никаким боком касаться не должны. Некоторые бодро объявляют то, что есть в Rust или в Swift (а иногда даже в C++) “разновидностью GC”, но нет, это радикально разные вещи: автоматический подсчёт ссылок в Rust и Swift, всякие std::unique_ptr и std::shared_ptr в C++ действительно позволяют вам не писать вызов деаллокатора руками, но они, в отличие от “настоящего”, “трассирующего” GC не лезут куда их не просят. Для их работы не нужно нарушать инкапсуляцию: Box в Rust будет прекрасно работать независимо от наличия в языке стандартной библиотеки libstdc++. Запросы в неё уйдут только тогда, когда удаляемый Rust-объект будет содержать ссылку на C++-объект. И наоборот. а вот ситуация с GC — совсем иная. Максимум, что вы можете себе позволить - не запускать всю эту бандуру, пока не создадите первый объект. Создали хоть что-нибудь? Всё, теперь вам на “право использования GC” платить вечно (до окончания процесса в смысле… большинство языков с GC даже не предоставляют возможности остановить всё это и выгрузить библиотеку, когда она не нужна).
Что только не придумают, что-бы не использовать Rust.
Да, в Google вообще недалекие люди работают, наверное просто не знают про Rust )
Извините за сарказм, но эту фразу надо патентовать уже.
Тут уже было
Теперь ещё и rust.
Тут уже было
Что только не придумают, что-бы не использовать Erlang.
Что только не придумают, что-бы не использовать Haskell.
Что только не придумают, что-бы не использовать Lisp.
Теперь ещё и rust.
А ничего что они это придумали за долго до того как появился rust? :)
Молодцы! Глядишь и вправду игры делать начнут ;)
Странный график скорости у вас, к слову. Go 1.5 обозначен желтым цветом и все маркеры на отмекте 0 секунд. Куда стремиться уже?
Странный график скорости у вас, к слову. Go 1.5 обозначен желтым цветом и все маркеры на отмекте 0 секунд. Куда стремиться уже?
Можно я не поверю в мигание длинной в 300мс? Неужели человек не может моргнуть 4 раза за секунду? А ещё видеть в промежутках между этим?
Вот и гугль подсказывает: globalscience.ru/article/read/23157 — от 50 до 75мс.
Вот и гугль подсказывает: globalscience.ru/article/read/23157 — от 50 до 75мс.
Можно.
Вики говорит другое:
Вики говорит другое:
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
Из графиков совершенно непонятно, что авторы имеют в виду под «GC Pauses в секундах». Какая метрика используется для измерения? Это среднее? Это 95 процентиль? Это 99 процентиль? Это гарантированная верхняя оценка?
Ну и другие стандартные вопросы. Что за профиль загрузки? О каких объемах памяти идет речь?
Похоже, что тут есть интересные вещи с точки зрения алгоримов, хотя я пока не разбирался. А вот трейдофф между latency и throughput/bandwidth известен десятки лет. Чуваки поигрались с рантаймами и решили, что можно заплатить большим куском throughput за хорошую latency. Ну ок.
Дальше рассуждения чисто гипотетические.
Сколько было раньше на таком же ворклоаде? Пусть будет 5%. Стало 25%. Мы взяли и на ровном месте только что потеряли 20% процессора. Было у нас 95%, осталось 75%. Для одного-двух серверов это наверное оок. А если в бэкэнде у вас ну хотя бы сотня серверов, это означает, что нужно докупить еще около 27 серверов. Скажем, с учетом обслуживания в дата-центре это 10 тысяч долларов в год. 270 тысяч долларов в год вот так вот за гаранитрованную latency — это много или мало? Это хорошо или плохо?
Не все так однозначно, господа.
Ну и другие стандартные вопросы. Что за профиль загрузки? О каких объемах памяти идет речь?
Похоже, что тут есть интересные вещи с точки зрения алгоримов, хотя я пока не разбирался. А вот трейдофф между latency и throughput/bandwidth известен десятки лет. Чуваки поигрались с рантаймами и решили, что можно заплатить большим куском throughput за хорошую latency. Ну ок.
Дальше рассуждения чисто гипотетические.
Сколько было раньше на таком же ворклоаде? Пусть будет 5%. Стало 25%. Мы взяли и на ровном месте только что потеряли 20% процессора. Было у нас 95%, осталось 75%. Для одного-двух серверов это наверное оок. А если в бэкэнде у вас ну хотя бы сотня серверов, это означает, что нужно докупить еще около 27 серверов. Скажем, с учетом обслуживания в дата-центре это 10 тысяч долларов в год. 270 тысяч долларов в год вот так вот за гаранитрованную latency — это много или мало? Это хорошо или плохо?
Не все так однозначно, господа.
Что-то мне подсказывает что есть мало компаний, у которых «в бэкэнде» больше серверов, чем у Гугла. Причём «мало» — это почти наверняка «нуль».
Ваши рассуждения хороши только для тех компаний у которых, с одной стороны, сотни серверов, а с другой — клиенты, которые не могут вас «послать» и уйти к конкурентам и вынуждены ждать пока за несколько секунд GC прожуётся и сервер на нажатие кнопочки отреагирует (ещё раз: там на графике время в секундах: не в микро или милли, а просто в секундах). Это довольно узкая ниша. Всем остальным же приходится снижать нагрузку, чтобы не получать вот эти многосекундные задержки. Теперь же загрузку можно буде повысить — даже притом, что процессор больше станет тратить на GC.
Ваши рассуждения хороши только для тех компаний у которых, с одной стороны, сотни серверов, а с другой — клиенты, которые не могут вас «послать» и уйти к конкурентам и вынуждены ждать пока за несколько секунд GC прожуётся и сервер на нажатие кнопочки отреагирует (ещё раз: там на графике время в секундах: не в микро или милли, а просто в секундах). Это довольно узкая ниша. Всем остальным же приходится снижать нагрузку, чтобы не получать вот эти многосекундные задержки. Теперь же загрузку можно буде повысить — даже притом, что процессор больше станет тратить на GC.
А причем тут Гугл? Алексей вполне конкретные вопросы задал.
К тому же откуда инфа вообще о нескольких секундах? И собственно про какие алгоритмы сборки мусора идет речь? И может быть речь про full gc? Если да, то вы его можете очень долго ждать. У меня были логи за пару недель с прода, где full gc не вызвался ни разу.
К тому же откуда инфа вообще о нескольких секундах? И собственно про какие алгоритмы сборки мусора идет речь? И может быть речь про full gc? Если да, то вы его можете очень долго ждать. У меня были логи за пару недель с прода, где full gc не вызвался ни разу.
Не забывайте, что это перевод блогпоста, который «на коленке» записывает блоггер по ходу выступления докладчика.
Полагаю, что стандартный runtime.Memstats, в котором хранятся данные про паузы 256 последних срабатываний GC. Percentile или mean — не знаю, но, полагаю, что раз там была прямая корелляция, то mean там репрезентативен.
Никто такого и не говорит. Но ваши рассуждения и вправду, гипотетические и неверные. 25% будут отбираться только для фазы GC, а не на время всей работы программы. Пересчитывайте :)
Какая метрика используется для измерения?
Полагаю, что стандартный runtime.Memstats, в котором хранятся данные про паузы 256 последних срабатываний GC. Percentile или mean — не знаю, но, полагаю, что раз там была прямая корелляция, то mean там репрезентативен.
Не все так однозначно, господа.
Никто такого и не говорит. Но ваши рассуждения и вправду, гипотетические и неверные. 25% будут отбираться только для фазы GC, а не на время всей работы программы. Пересчитывайте :)
да, надо сделать скидку по поводу онлайна :) И по поводу фазы GC — тоже верно. Но пример примером, бог с ним. В нем вопрос в том, насколько часто выполняется эта самая «синяя» фаза.
Проблема в том, что я, блин, не могу нормальных статей найти ни по поводу нового GC (1.5), ни по поводу старого (1.4). Референсная статья по первой ссылке не отвечает на вопрос о том, как работает новый GC. Там есть только Goals, сформулированные, кстати, довольно изжоповым языком. Данная статья по материалам презентации — тоже не отвечает на этот вопрос. Отсюда вопрос: что делать? Читать исходники?
Народ, посоветуйте материалов по поводу Go 1.4 GC.
Проблема в том, что я, блин, не могу нормальных статей найти ни по поводу нового GC (1.5), ни по поводу старого (1.4). Референсная статья по первой ссылке не отвечает на вопрос о том, как работает новый GC. Там есть только Goals, сформулированные, кстати, довольно изжоповым языком. Данная статья по материалам презентации — тоже не отвечает на этот вопрос. Отсюда вопрос: что делать? Читать исходники?
Народ, посоветуйте материалов по поводу Go 1.4 GC.
В нем вопрос в том, насколько часто выполняется эта самая «синяя» фаза.
Насколько я понимаю, её частота зависит от того, сколько памяти аллоцирует программа. До Go 1.5 эту частоту можно было тюнить с помощью переменной GOGC, которая, по сути, выставляла порог (в процентах), когда уже пора запускать GC. Соответственно, для разных программ эта частота может быть очень разной.
Собственно, проблема с паузами релевантна только для высоконагруженных систем, которые лопатят гигабайты постоянно обновляемых данных в памяти (как в недавнем примере Qihoo 360). Для остальных случаев частота и продолжительность пауз нынешнего GC настолько низки, что абсолютно незаметны.
А по поводу материалов по предыдущим реализациям GC, надо искать в golang-nuts, были какие-то документы хорошие.
ага, понял по поводу старого. По поводу golang-nuts — искал, не нашел ничего толкового. Надо видимо забуриться туда надолго.
В любом случае, если увидете какой-нить адекватный документ — киньте, плиз.
В любом случае, если увидете какой-нить адекватный документ — киньте, плиз.
А что есть та самая «синяя» фаза? Насколько я понял gс в go concurrent и работает в фоне, а значит отжирает те самые 25 процентов у всех. Просто если случился stop world это уже full gc и там он может отожрать хоть 100 процентов
У меня тоже сначала сложилось впечатление, что 25% он жрет всегда. Например, постоянно сканирует данные на предмет актуальности. Но на графике почему-то нарисовано, что он включается время от времени. И это реально странно.
Еще одна странная вещь: нарисована какая-то розовая активность «Assist». Что это вообще? Почему за GC считается только «синяя» активность, а розовая не считается?
У меня получилось следующее: новый алгоритм позволяет ценой периодической потери пропускной способности повышать (в каком-то смысле) отзывчивость системы. То есть, в моменты GC система будет-таки подтормаживать (и возможно сильно подтормаживать), но не допускать пауз в несколько секунд.
Учитывая все, сказанное выше, я могу предположить такие изменения с точки зрения перфоманса (все это «в среднем по больнице»):
А вообще это все гадание на кофейной гуще, конечно. Нужны нормальные материалы, нужны алгоритмы.
Ну и конечно нужны тесты.
Еще одна странная вещь: нарисована какая-то розовая активность «Assist». Что это вообще? Почему за GC считается только «синяя» активность, а розовая не считается?
У меня получилось следующее: новый алгоритм позволяет ценой периодической потери пропускной способности повышать (в каком-то смысле) отзывчивость системы. То есть, в моменты GC система будет-таки подтормаживать (и возможно сильно подтормаживать), но не допускать пауз в несколько секунд.
Учитывая все, сказанное выше, я могу предположить такие изменения с точки зрения перфоманса (все это «в среднем по больнице»):
- worst-case latency будет меньше (и это круто)
- average latency будет больше (и это не очень здорово, но не критично)
- average throughput будет в среднем на несколько процентов меньше (это не критично)
А вообще это все гадание на кофейной гуще, конечно. Нужны нормальные материалы, нужны алгоритмы.
Ну и конечно нужны тесты.
Мои «рассуждения универсальны» :) На самом деле, это не рассуждения, а факты. Пример про сотню серверов — это просто пример, не фокусируйтесь на нем.
Я пишу о том, что для тех, для кого latency критична — это полезное улучшение. А для тех, для кого критична пропускная способность — это некоторая проблема. Что им делать? Докупать теперь серваки?
Ладно, это все не очень интересно. Гораздо интереснее — оригинальная статья про новый GC. Лично мне больше всего понравился кусок про Goals. Там подробно написаны причины, так что не нужно ничего выдумывать.
Я пишу о том, что для тех, для кого latency критична — это полезное улучшение. А для тех, для кого критична пропускная способность — это некоторая проблема. Что им делать? Докупать теперь серваки?
Ладно, это все не очень интересно. Гораздо интереснее — оригинальная статья про новый GC. Лично мне больше всего понравился кусок про Goals. Там подробно написаны причины, так что не нужно ничего выдумывать.
А почему не сделать возможность ручной уборки мусора, хотя бы частичной, а остальное что бы убирал автоматический сборщик? Я понимаю что это грозит некоторыми возможностями прострелить себе колено, но имхо это было бы намног практичнее, особенно при работе веб приложений, когда наверняка знаешь что, что то уже не понадобится до следующего запроса.
А смысл? Ну допустим мы часть памяти удаляете вручную, часть автоматически. Та часть которая собирается автоматически все равно будет работать параллельно вашей программы и потом может сделать тот же самый stop world. К тому же есть шанс удалить объект, а ссылку где-нибудь да оставить. Если и хочется избавится от gc, то можно использовать offheap )
На самом деле там были обсуждения и до Go 1.0 даже были в stdlib функции runtime.Alloc() и runtime.Free(), но их убрали. Надо мейллисты искать для подробностей.
Sign up to leave a comment.
Сборщик мусора в Go: решение проблемы отзывчивости в Go 1.5