Badoo corporate blog
High performance
Programming
Designing and refactoring
Go
Comments 26
+5
Спасибо за, как всегда, отличный материал)
А можешь посоветовать, на какие источники стоит подписаться на тему Go, на вроде Teiva Harsanyi из начала статьи?
+4
Англоязычные?
Я подписан на golangweekly.com, слежу за reddit.com/r/golang, ну и статьи про Go часто проскакивают на Hacker News.
Еще можно следить за каналом News на российском Golang коммюнити Slack-е.
+1

А если нарушить красоту и правила, и сделать часто аллокируемые переменные с буфферами глобальными (хотя бы с точностью до горутины), сколько ещё можно выиграть?

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

Не могу понять, почему так?
+2
Идея в том что часть ваших горутин будут ожидать ответа от ОС и пока они это делают, другие могут поработать.
+2
Я не адепт Go, поэтому поясните, пожалуйста, следующую вещь: почему современный язык предусматривает возможность писать код, который в зависимости от знания нюансов языка может давать разницу в перформансе в 20 раз?
+5
Мне кажется это справедливо вообще для любого general purpose ЯП. Все что здесь написано можно было бы «натянуть» на любой другой язык, я считаю.
+1

в любом языке в concurrent решение не быстрее обычного, при условии что они выполняются на одном ядре.
в любом языке регулярки — очень жирные, потому что они рассчитаны на гибкость.
пример с trim — тоже показывает что обобщенное решение, не быстрее конкретного.


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

+2
ерунда какая. конкурентное решение будет быстрее если есть I/O.
0
Надо уточнить, что речь про блокирующее I/O. На неблокирующем разницы не будет.
+1
Я вас не понял.

Если у вас все IO блокирующее, то никакого ивентлупа (poll/select) вы не сделаете. Следовательно никакой конкурентности вы не получите.

Если под «обычным» решением мы понимаем простое однотредовое решение без использования файберов/зеленых тредов/корутин, то неблокирующее IO никак его быстрее не сделает.
0
Блокирующее I/O это то, которое возвращает управление только тогда, когда весь запрашиваемый блок данных был получен или уже не может быть получен.
+1
Я понимаю, что такое блокирующее ио :). Яснее ваша позиция не стала.
+1

Потому что супероптимизаторы никто в 21 веке ещё не написал. Немного трудная задача

+1
по моему, «современный» нужно трактовать не как «современный», а как «недавно созданный», по моему №2, современного языка априори нет, по моему №3, современный язык должен давать фантастическую гибкость при разработки абстрактных структур… и вообще, минимизировать количество кода и количество возможностей выстрелить в ногу…

вот сегодня была задача на го… есть входный интерфейс, изначально известно — это json, при чем в 1 уровень, нет вложенных объектов или массивов, секс начался, когда при сведении, значение 1 (ИД, который везде проходил как integer), внезапно начал при сведении типов определяться как float64, при чем с плавоющей точкой в пределах программы вообще нед ни действий не объявлений… вот и пожалуйства… работа над одной задачой призвела до анализа всей программы, день пришлось провозиться чтобы все в порядок привести…

друг сегодня книгу у меня увидел (заходил в гости пива попить), говрит "*бать, анси Си — разве си сегодня кому то нужен?" (интересовался в комерческих целях) — отвечаю: — нужен, си — о*енный язык, но сложный… и правда…

смотрю на рожденные языки в диапазоне последных 10-ти лет, и ниодин не нашел, который бы не позволял создавать программы с неправильными адресациями, некорректными указателями и т.п… зачем тогда писать на «современных ЯП», если можно писать на си, или си++, но такие программы, покрытые тестами, обыычно еффективней, и поведение их максимально приближено к ожилаемому?
+2

Очень интересный опыт, не хотите описать подводные камни го в отдельной статье?

0
смотрю на рожденные языки в диапазоне последных 10-ти лет, и ниодин не нашел, который бы не позволял создавать программы с неправильными адресациями, некорректными указателями и т.п…

Эммм… Rust?
0
Ранее мы отказались от конкурентности на уровне обработки линий,

Так линий или строк?
+1
думаю, это неважно, так как ресурсы на создание го-рутины для обработки линии\строки намного выше, чем последовательная обработка нескольких линий\строк…

в моей практике была необходимость обработать большой файл (несколько гб) — читал его го-рутинами используя seek, это правда помогло, но выиграш только на больших объемах… правда можно ускориться в несколько раз.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. , please.