Производительность Google Go? - PullRequest
32 голосов
/ 01 июля 2011

Так кто-нибудь использовал Google Go?Мне было интересно, как математическая производительность (например, флопс) сравнивается с другими языками с сборщиком мусора ... как Java или .NET?

Кто-нибудь исследовал это?

Ответы [ 4 ]

82 голосов
/ 06 июля 2011

Теоретическая производительность: теоретическая производительность чисто Go программ находится где-то между C / C ++ и Java. Это предполагает расширенный оптимизирующий компилятор, а также предполагает, что программист использует все возможности языка (будь то C, C ++, Java или Go) и реорганизует код в соответствии с языком программирования.

Практическая производительность (по состоянию на июль 2011 года): стандартный компилятор Go (5g / 6g / 8g) в настоящее время не может генерировать эффективные потоки команд для высокопроизводительных числовых кодов, поэтому производительность будет ниже, чем в C / C ++ или Java. , Для этого есть несколько причин: каждый вызов функции имеет накладные расходы в виде пары дополнительных инструкций (по сравнению с C / C ++ или Java), отсутствие вставки функций, распределение регистров среднего качества, сборщик мусора среднего качества, ограниченная возможность стирания границ проверки, нет доступа к векторным инструкциям из Go, компилятор не поддерживает SSE2 на 32-битных процессорах x86 и т. д.

Итог: как правило, ожидайте, что производительность числовых кодов, реализованных в чистом Go, скомпилированных с помощью 5g / 6g / 8g, будет в 2 раза ниже, чем в C / C ++ или Java. Ожидайте, что производительность улучшится в будущем.


Практическая производительность (сентябрь 2013 г.): по сравнению со старым Go с июля 2011 г. Go 1.1.2 может генерировать более эффективные числовые коды, но они по-прежнему работают немного медленнее, чем C / C ++ и Java. Компилятор использует инструкции SSE2 даже на 32-разрядных процессорах x86, что приводит к гораздо более быстрому выполнению 32-разрядных числовых кодов, скорее всего благодаря лучшему распределению регистров. Компилятор теперь реализует встроенную функцию и экранирующий анализ. Сборщик мусора также был улучшен, но он остается менее продвинутым, чем сборщик мусора в Java. Все еще не поддерживается доступ к векторным инструкциям из Go.

Итог: разрыв в производительности кажется достаточно небольшим для Go, чтобы быть альтернативой C / C ++ и Java в числовых вычислениях, если конкурирующая реализация не использует векторные инструкции.

34 голосов
/ 01 июля 2011

Математический пакет Go в основном написан на ассемблере для повышения производительности.

Тесты часто ненадежны и могут быть интерпретированы. Например, статья Роберта Хандта Loop Recognition в C ++ / Java / Go / Scala выглядит некорректно. В блоге Go на Profiling Go Programs анализируются заявления Хундта.

15 голосов
/ 01 июля 2011

Вы на самом деле задаете несколько разных вопросов.Во-первых, математическое представление Go будет таким же быстрым, как и все остальное.Любой язык, который компилируется до нативного кода (который, возможно, включает в себя даже языки JIT, такие как .NET), будет работать очень хорошо в сырой математике - настолько быстро, насколько машина может работать.Простые математические операции очень легко компилировать в форму с нулевыми издержками.Это область, в которой скомпилированные (включая JIT) языки имеют преимущество перед интерпретируемыми.

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

Что касается самих реализаций GC - Go и .NET используют сборку мусора по меткам и зачисткам.Microsoft уделяет много внимания и инженерных разработок своему движку GC, и я должен думать, что это неплохо, учитывая все обстоятельства.GC-движок Go находится в стадии разработки, и хотя он не чувствует медленнее, чем архитектура .NET, ребята из Golang настаивают на том, что ему нужно немного поработать.Тот факт, что спецификация Go запрещает деструкторам, значительно ускоряет процесс, поэтому, возможно, это и не кажется таким медленным.

Наконец, в своем собственном анекдотическом опыте я обнаружил, что Go - это очень быстро .Я написал очень простые и легкие программы, которые в моих собственных тестах выдерживали сравнение с высокооптимизированным кодом C из некоторых давних и уважаемых проектов с открытым исходным кодом, которые гордятся производительностью.

Суть в том, что не весь код Go будет эффективным, точно так же, как не весь C-код эффективен.Вы должны построить его правильно, что часто означает, что вы делаете вещи не так, как вы привыкли в других языках. Профилирующее сообщение в блоге , упомянутое здесь несколько раз, является хорошим примером этого.

2 голосов
/ 01 июля 2011

Google провел исследование, сравнивая Go с некоторыми другими популярными языками (C ++, Java, Scala). Они пришли к выводу, что это не так сильно с точки зрения производительности:

https://days2011.scala -lang.org / сайты / days2011 / файлы / ws3-1-Hundt.pdf

Цитата из Заключения о Go:

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

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