LINUX.ORG.RU

Go 1.3

 


1

3

Версия 1.3 выпущена спустя шесть месяцев после версии 1.2 и не содержит изменений в языке. Основная работа была произведена над реализацией, что обеспечило точную сборку мусора, рефакторинг тулчейна, результатом которого стала более быстрая сборка, особенно больших проектов, и значительное улучшение производительности. Как всегда, Go 1.3 держит обещание совместимости, и с новой версией почти все приложения будут продолжать собираться и запускаться без изменений.

Главные улучшения:

  • Прекращена поддержка Windows 2000.
  • Появилась экспериментальная поддержка Dragonfly BSD.
  • Вернулась поддержка Native Client (NaCl).
  • Добавлена экспериментальная поддержка Plan 9.
  • Добавлена экспериментальная поддержка Solaris.
  • Изменилась реализация стеков горутин: прежняя, «сегментированная» модель заменена на непрерывную, что устраняет старую проблему «горячей точки», когда вычисление многократно выходит за границу сегмента. Подробности, включающие статистику производительности, можно посмотреть здесь.
  • Долгое время сборщик мусора был точным при изучении значений в куче. В версии 1.3 аналогичная точность добавлена для значений в стеке. Это значит, что значения Go, не являющиеся указателями (например, целые), больше не будут ошибочно приниматься за указатели и препятствовать повторному использованию незанятой памяти.

А также многое другое.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 1)

Ответ на: комментарий от anonymous

И я напоминают, что мы говорим оне о дальвике. Как оно там - вообще непонятно.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

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

Когда мусор собирается чаще логично что его накапливается меньше?

Облегчат использование всех ядер процессора.

См. самое начало.

anonymous
()
Ответ на: комментарий от RedPossum

написание приложения как набора взаимодействующих через каналы «узлов» как метод заместо как выше уже отметили и явных потоков/процессов нижележащей ОС так и использования коллбэков логика использования достаточно не очевидна , и тем не очевидней , чем «свободней(снижение ограничений на логику)» приложение

qulinxao ★★☆
()
Ответ на: комментарий от anonymous

Ты неумный или прикидываешься?

неумный тут похоже ты, раз ничего объяснить толком не можешь. Так почему в go будет волшебный gc, а в далвике его нет, и в рантайме ART не будет?

См. самое начало.

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

RedPossum ★★★★★
()
Ответ на: комментарий от qulinxao

поставлю вопрос подругому, насколько(скольким разработчикам) это все удовольствие надо(мы же по прежнему про мобильную разработку), чтобы вместо использования fork-join pool'а надо было выкидывать жабу и запихивать новый язык?

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

отвечу повтором.

массовому разработчику лично фиолетово

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

зы. жабья «многонитиевость» как многое в энтерпрайзе «многословна»

не будет выкидывания,

либо голэнг быстрее займёт новые ( ещё не освоеные ни чем) области либо так и не взглетит.

т.е на растущем пространстве голэнгу нет необходимости выкидывать конкурентов с мест на которых они(конкуренты) есть , есть необходимость реализовать своё преимущество на устройствах с 8-16-... испольняющими(«одинаковыми») устройствами

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

массовому разработчику лично фиолетово

вот.

зы. жабья «многонитиевость» как многое в энтерпрайзе «многословна»

ну есть akka, там получше, но это явный оверхед на мобильных устройствах

либо голэнг быстрее займёт новые ( ещё не освоеные ни чем) области либо так и не взглетит.

солидарен. Но остается политика, и дурость оракла. MS же родили c#, тут по тем же причинам может чего-то получится.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Ты прям заставил меня мысленно вернутся в 2008 год когда я брал четырехъядерный процессор, а мой друг недоумевал что же я делаю. Тогда и правда единичный софт использовал даже 2 ядра, не говоря уже о таком количестве как 4. Но вот прошло время, софт и игры (а тогда я еще в них играл) стали использовать сначала 2 ядра, потом и около трех. А надо говорить про эмоции друга когда он захотел поиграть в последнюю гта на двух ядрах? Первая игра пожалуй так использующая вещь потенциал четырехъядерного процессора.

Так вот если бы такие как ты разрабатывали софт, ситуация была бы как в 2008ом. Железо есть, а использовать нечему.

А зачем конкретно мобильным приложениям использовать все ядра? Да потому что если смартфон запускает приложение на 1 ядре за 3 секунды, а на 3-4 за полторы то это существенно. Именно так. Мне очень (очень!) важно что бы приложения на мобильных девайсах работали максимально быстро. Я не собираюсь загружать мобильник на 100% все время. Я столько его не использую. Но мне крайне важно что бы при моем использовании он реагировал молниеносно.

В Go не будет волшебного GC. Он там уже есть, правда очень обычный. Собирает часто и по-малу. В отличии от stoptheworld gc. Никакой магии, просто более подходящая реализация gc.

anonymous
()
Ответ на: комментарий от anonymous

все тяжелое(игры то есть), используют ndk. Как мы уже убедились, разницы между java и go в производительности нет. GC можно и подзаменить, если правда надо(а может в ART уже). Так что технических предпосылок для закатывания go в android - нет.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Ты видимо не читал про оптимизацию игр, как пытаются рассовать все данные так что бы GC не срабатывал во время игры и включают сборку мусора лишь между загрузкой уровней.

anonymous
()
Ответ на: комментарий от anonymous

Ты видимо не читал про оптимизацию игр

ну так то есть все притензии к GC. Язык менять не надо.

RedPossum ★★★★★
()
Ответ на: комментарий от anonymous

Кидать то кидал, но это была ссылка не на офф сайт.

anonymous
()

Хорошо, что пилят его, но вот пользоваться этим для бизнеса я бы не стал.

Вот когда они допилят свой GC, чтобы он умел подчищять за собой закрытые каналы, вот тогда и можно будет смотреть, а пока это смахивает на поделку для студентов. Сделаешь 10000 каналов и они будут висеть в памяти, пока приложение не убьешь. На этом фоне эрланг выглядит куда как более привлекательным (а уж тем более в нём есть обновление кода без остановки системы).

Синтаксис в Го вполне человеческий, но там тоже полно подводных камней, так что не стоит надеятся, что это будет как питон, только с concurrency.

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

kodx
()
Ответ на: комментарий от anonymous

Background. Android is an operating system designed for running apps.

no shit!!!

anonymous
()
Ответ на: комментарий от anonymous

Нет, GC подчищает каналы на которые нет ссылки, открытые или закрытые - не важно.

anonymous
()
Ответ на: комментарий от kodx

10000 небуферизованных каналов занимают около 1 мегабайта памяти (x64), стоит ли волноваться?

anonymous
()
Ответ на: комментарий от anonymous

Для программы, которая работает долго (серверное приложение) и периодически создает новые каналы — стоит. Но нужно посмотреть, скорее всего есть способ бороться с этим.

Weres ★★★
()
Ответ на: комментарий от Weres

скорее всего есть способ бороться с этим.

Конечно есть. Например, не сваливать вину на GC (который отлично собирает каналы, недостижимые из GC roots), а искать ошибки в своём коде.

anonymous
()
Ответ на: комментарий от Weres

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

anonymous
()
Ответ на: комментарий от anonymous

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

kodx
()
Ответ на: комментарий от anonymous

Неужели они это сделали? Последний раз смотрел на него год назад - такого не было. Да там и без этого проблем хватает, сейчас уже всего не вспомню.

kodx
()
Ответ на: комментарий от kodx

Полагаю, что в вашем случае верным будет сдвиг к фактору количества. Но, позвольте же таким организациям, как Google, Яндекс, Canonical, SoundCloud, CloudFlare и многим др. не согласиться с вами. Быть может это другой уровень опыта и кардинально новые проблемы; а до того, чем там геройствуют всякие рядовые компании, им-то какое дело?

anonymous
()
Ответ на: комментарий от kodx

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

Weres ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.