The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз языка программирования Go 1.8, opennews (??), 17-Фев-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


150. "Релиз языка программирования Go 1.8"  +3 +/
Сообщение от Ivan (??), 17-Фев-17, 18:30 
Не хочется кормить тролля, но один раз отвечу.

Данный пример ничего полезного не делает и clang 3.9.1 компилирует его в функцию из одной инструкции ret: https://godbolt.org/g/aKZsWT Я думаю можно с уверенностью сказать, что нет ничего быстрее, чем пустая функция.

Но это всё благодаря оптимизации, когда мы видим, что память выделилась и тут же освободилась мы можем заменить аллокацию в хипе на аллокацию в стеке. GCC такую оптимизацию не делает. Я не знаю, про какую реализацию .NET ты говоришь, но приведенный код тоже может быть соптимизирован в ничто.

Хочу обратить внимание, что данный код на C++ пессимизирован и правильнее было бы создавать объект в стеке, просто: Node v; Тогда оба компилятора и clang и GCC компилируют код в пусто.

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

Я хочу обратить внимание вот на какой факт. Все современные аллокаторы памяти работают для маленьких объектов (до ~1kb, а это 99.9% всех объектов) за O(1). Все современные GC так или иначе обходят весь хип, это может по разному называется, но это происходит. Они стараются делать это как можно реже (применяют гипотезу поколений, используют счетчики ссылок, чтобы не обходить, когда не возникают циклы -- разные делают разному), но это всё равно проиходит. То есть мы сравниваем O(1) и O(размера хипа).

Есть ещё один момент компирующие сборщики мусора копируют объекты. Как правило увеличение размера объектов приводит к тому, что GC случаются чаще и копировать памяти нужно больше. Т.е. GC чувствителен к размеру наших объектов. Обычные аллокаторы памяти на 64-битных системах к этому не чувствительны.

Таким образом по мере роста размера хипа и увеличения размера объектов GC будет работать всё хуже и хуже по сравнению с обычным аллокатором памяти. Конечно обычные бенчмарки обычно проводятся в условиях почти идеальных для GC (маленькие объекты, маленький хип).

Ещё один способ наврать в бенчмарках это заточиться на гипотезу поколений и сделать так, чтобы все объекты умирали не выходя из Gen0, собственно, что ты сделал в своем примере. Но ответ на это очень простой -- если объект коротко живущий его надо создавать в стеке. И если мы для коротко живущих объектов будем использовать стек, то на долго живщих обычный аллокатор, скажем jemalloc или tcmalloc, порвет на тряпки дотнетовский Gen2 GC.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

161. "Релиз языка программирования Go 1.8"  +2 +/
Сообщение от Василий Теркин (?), 17-Фев-17, 18:55 
> Не хочется кормить тролля, но один раз отвечу.

Спасибо за развернутый ответ. Но я НИКОГДА и не спорил, что в С++ с его гибкостью нельзя решить задачку идеально, по сравнению с другими ЯП. Но, за это придется заплатить. 1. Время разработки/отладки 2. Квалификация программиста. И 90% программистов будут писать код "что вижу то и пишу", и без дополнительных механизмов повышения качества конечного продукта, увы, не обойтись. Поэтому Java в свое время оккупировала рынок энтерпрайз систем, вытеснив с этой ниши С и С++. Как я уже говорил, в некоторых случаях скорость разработки РАБОТОСПОСОБНОГО решения превалирует над макисмальной возможной скоростью его быстродействия. А требования к надежности и предсказуемости работы кода еще более сужают нишу применения с++. Высококлассных программистов в наше время не так уж и много, чтобы решать весь спектр существующих задач. ЯП - всего лишь инструмент. И если этот инструмент решает поставленные задачи - это хороший инструмент. А беседы об идеальных инструментах на все случаи жизни - это уже из разряда религий и верований.

Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз языка программирования Go 1.8"  –1 +/
Сообщение от Аноним (-), 17-Фев-17, 19:45 
А что про Python и Ruby скажете? Скорость разработки на них выше, чем на Java. И, подозреваю, выше, чем на Go. Считаете, что дольше надо будет добиваться РАБОТОСПОСОБНОГО решения?
Ответить | Правка | Наверх | Cообщить модератору

228. "Релиз языка программирования Go 1.8"  +/
Сообщение от Василий Теркин (?), 20-Фев-17, 14:56 
Ну вроде оба этих языка относятся к интерпретируемым(за исключением отдельно привязываемых костылей). И у обоих есть сборщики мусора. И если решение на этих языках конкретных задач более эффективно, чем на GO или С++, то я отношусь к этим языкам весьма положительно. И буду дальше добиваться РАБОТОСПОСОБНОГО приложения, по причине того, что НЕРАБОТОСПОСОБНЫЕ никому не нужны, кроме их авторов.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру