А кто запилит производительность golang ?

Чувак, есть для этого ведь гугл. https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gpp

Попереключай внизу языки, найдешь всё что нужно.

да-да, читаем топик внимательно

Да, дурак я ._.

Но всё же, чем не устраивает данный ресурс?

На https://benchmarksgame.alioth.debian.org/ выложены исходники

Собирай, тестируй, сравнивай

этим

Чур без глупых синтетических тестов. Только реальные задачи, только хардкор!

Я так понял что ты математику называешь синтетикой (как на том же Benchmark Game), а «реальные задачи» в твоем понимании - это какие-то среднестатистические системы, которые пишет среднестатистическая компания. Тоесть какой-то сервер с узком месте в IO, где язык побоку для производительности.

Вот это можно использовать: https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

Это скорость парсинга + скорость работы хеш-мапы. Пока получилось так:

C++ 0.3 секунды, но там ещё можно выиграть сколько-то при замене memchr на поиск вручную.

Go 1.9 0.54 секунды.

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

Другие варианты лагают в пределах секунды секунды.

Ну так это либо будет та же самая «синтетика», либо задача будет «не та», либо железо «не то», либо настройки, либо ещё что. Поэтому бери и пили.

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

https://github.com/Balancer/benchmarks-fib-obj/wiki/Результат-теста:-i3-2.2ГГц

комбо, синтетика и реальная задача в одном - перемножение матриц. Исходники, конечно, прилагаются

Java все таки хороша, кто бы что ни говорил. А в обертке Котлина вообще идеальна

И на небольшом Heap. Иначе уже начинается магия с Off-Heap, для упрощения которой в языке ничего нет. :(

На Хабре есть истории успеха по переходу с питона на го в Яндексе, чего тебе ещё не хватает, милок

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

Мы перевели обработку 500-мегабайтных xml файлов с Ruby на Go. Хорошо хотя бы то, что можно использовать больше одного ядра процессора.

Думаю, Ruby сравним с Python по скорости.

https://github.com/Balancer/benchmarks-fib-obj/blob/47177c29d532ebb2fbe259d49...

Так и должно быть?

$ g++ -std=c++11 t.cpp -o t
$ ./t
10
n=55
n=55
n=55
n=55
n=55
n=55
n=55
n=55
n=55
n=55

А что тут тестить: C++ < (java | golang) < pypy < python

И на небольшом Heap. Иначе уже начинается магия с Off-Heap

Разве это не касается всех языков с gc? В golang вроде как тоже при его запусе stop the world происходит?

Касается. В идеале, мне кажется, нужно более тонкое управление памятью. Например, возможность иметь несколько куч, возможность иметь кучи без GC.

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

Это уже упростит, например, поднятие нескольких независимых сервисов в одной JVM.

А потом можно давать различные послабления, например, передавать константные объекты ссылкой, предполагая, что ответственность за то, что объект не соберётся в куче-владельце как мусор - на программисте.

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

Что по деньгам предлагаешь?

8

Channels на C++ обогнали go https://www.youtube.com/watch?v=N3CkQu39j5I

См. 34-ю минуту.

А чем это не устраивает? Там довольно популярные алгоритмы которые можно реализовать и самому. Вся методика описана: https://benchmarksgame.alioth.debian.org/how-programs-are-measured.html
Самопальные тесты будут иметь очень большую систематическую ошибку.