How to become an author
Search
Write a publication
Pull to refresh

Comments 26

Спасибо за, как всегда, отличный материал)
А можешь посоветовать, на какие источники стоит подписаться на тему Go, на вроде Teiva Harsanyi из начала статьи?
Total votes 5: ↑5 and ↓0+5
Англоязычные?
Я подписан на golangweekly.com, слежу за reddit.com/r/golang, ну и статьи про Go часто проскакивают на Hacker News.
Еще можно следить за каналом News на российском Golang коммюнити Slack-е.
Total votes 4: ↑4 and ↓0+4
Спасибо
И всем, кто добавил ссылки ниже, тоже)
Total votes 2: ↑2 and ↓0+2

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

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

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

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


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

Total votes 3: ↑2 and ↓1+1
ерунда какая. конкурентное решение будет быстрее если есть I/O.
Total votes 2: ↑2 and ↓0+2
Надо уточнить, что речь про блокирующее I/O. На неблокирующем разницы не будет.
This comment wasn’t rated yet0
Я вас не понял.

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

Если под «обычным» решением мы понимаем простое однотредовое решение без использования файберов/зеленых тредов/корутин, то неблокирующее IO никак его быстрее не сделает.
Total votes 1: ↑1 and ↓0+1
Блокирующее I/O это то, которое возвращает управление только тогда, когда весь запрашиваемый блок данных был получен или уже не может быть получен.
This comment wasn’t rated yet0
Я понимаю, что такое блокирующее ио :). Яснее ваша позиция не стала.
Total votes 1: ↑1 and ↓0+1

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

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

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

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

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

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

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

Эммм… Rust?
Total votes 2: ↑1 and ↓10
Ранее мы отказались от конкурентности на уровне обработки линий,

Так линий или строк?
Total votes 2: ↑1 and ↓10
думаю, это неважно, так как ресурсы на создание го-рутины для обработки линии\строки намного выше, чем последовательная обработка нескольких линий\строк…

в моей практике была необходимость обработать большой файл (несколько гб) — читал его го-рутинами используя seek, это правда помогло, но выиграш только на больших объемах… правда можно ускориться в несколько раз.
Total votes 1: ↑1 and ↓0+1

Подобные изменения — это уже не рефакторинг.

This comment wasn’t rated yet0
UFO just landed and posted this here
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr