Go язык прёт?
От: Тёмчик Австралия жж
Дата: 03.08.18 03:02
Оценка:
Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?
Re: Go язык прёт?
От: mtnl  
Дата: 03.08.18 03:16
Оценка: 4 (2)
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?


Он как питон по синтаксису, но собирается в один бинарь который работает ближе к скорости, если бы такое было написано на С

Node с typescript дает много трудных граблей в плане эксплуатации (то есть востребованность специалистов обусловлена тем, что проекты приходится закидывать горами разработников) и знаю достаточно компаний которые походив по ноде пошли в го
Вконтактик, например, сейчас очень много го использует
Re: Go язык прёт?
От: StanislavK Великобритания  
Дата: 03.08.18 06:55
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?


Насколько я понимаю, так всегда происходит. Так было с Python, scala и так далее. Сначала хайп, потом язык или занимат нишу или медленно дохнет.
Учить надо то, чего уже много, что-нить сильно мэйнстримовое, с таким не не прогадаешь. Ну или ориентироваться на нишу, но это сложнее, конкуренция больше.
Re[2]: Go язык прёт?
От: smeeld  
Дата: 03.08.18 08:46
Оценка:
Здравствуйте, StanislavK, Вы писали:

SK>Насколько я понимаю, так всегда происходит. Так было с Python, scala и так далее. Сначала хайп, потом язык или занимат нишу или медленно дохнет.


Нишу он уже занял, сейчас начинает захватывать ниши других ЯП, пока выпихивает python, C++. Повсеместно на Go пишут то, что ещё лет пять назад писали бы или на C++, или на python, плюс многие берутся за переписывание существующего на Go.
PS go-хайп немного особенный по интенсивности входа в Ынтерпрайз, прежде всего, а там если что и обосновывается, то на десятилетия. Это вам не какой-то хипстерский ruby.
Re[2]: Go язык прёт?
От: kov_serg Россия  
Дата: 03.08.18 09:15
Оценка:
Здравствуйте, mtnl, Вы писали:

Тё>>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?

M>Он как питон по синтаксису, но собирается в один бинарь который работает ближе к скорости, если бы такое было написано на С
Черт, ждал когда rust завалит rust. А теперь его завалит go — какая жаль.
https://www.tiobe.com/tiobe-index Смотрите как C растёт, скоро яву обгонит
Programming LanguageRatings
1Java16.881%
2C14.966%
3C++7.471%
4Python6.992%
5Visual Basic .NET4.762%
6C#3.541%
7PHP2.925%
8JavaScript2.411%
9SQL2.316%
10Assembly language1.409%
11Swift1.384%
12Delphi/Object Pascal1.372%
13MATLAB1.366%
14Objective-C1.358%
15Ruby1.182%
16Perl1.175%
17Go0.996%
18R0.965%
19Visual Basic0.922%
20PL/SQL0.702%
Re[3]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 03.08.18 09:19
Оценка:
Здравствуйте, kov_serg, Вы писали:

Давай посмотрим рейтинг IEEE Spectrum:
Re[4]: Go язык прёт?
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 03.08.18 09:20
Оценка: :)
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:


N>Давай посмотрим рейтинг IEEE Spectrum:

Печально что Rust нет.
Sic luceat lux!
Re[2]: Go язык прёт?
От: Слава  
Дата: 03.08.18 09:29
Оценка: +1
Здравствуйте, mtnl, Вы писали:

M>работает ближе к скорости, если бы такое было написано на С


Вот это как-то сомнительно. Работает оно примерно со скоростью явы, где-то быстрее, где-то медленнее.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html
Re[2]: Go язык прёт?
От: benvenuto  
Дата: 03.08.18 09:42
Оценка:
Здравствуйте, mtnl, Вы писали:

M>Он как питон по синтаксису


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

Go по синтаксису похож на Си:

* только убрали арифметику указателей,
* добавили duck-type интерфейсы,
* а void * заменили на {}.
* Управление памятью с помощью сборщика мусора, который заточен на минимизацию latency (в отличие от большинства остальных сборщиков мусора, которые заточены на минимизацию общего времени сборки).

* Generics так и не добавили.

* Вместо exceptions предлагают использовать возвращаемое значение. Функции Go могут возвращать больше обного значения. Поэому проверку ошибки можно организовать примерно так:

if (value, err := foo("hi"); err == 0) {
}


* Встроенные средства поддержки моногопоточные и асинхронных приложений с помощтю channels.
Отредактировано 03.08.2018 9:46 benvenuto . Предыдущая версия .
go
Re[3]: Go язык прёт?
От: StanislavK Великобритания  
Дата: 03.08.18 09:42
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Нишу он уже занял, сейчас начинает захватывать ниши других ЯП, пока выпихивает python, C++. Повсеместно на Go пишут то, что ещё лет пять назад писали бы или на C++, или на python, плюс многие берутся за переписывание существующего на Go.

S>PS go-хайп немного особенный по интенсивности входа в Ынтерпрайз, прежде всего, а там если что и обосновывается, то на десятилетия. Это вам не какой-то хипстерский ruby.

Мне кажется еще рано для выводов. Стоит подождать пяток лет.

Кстати, вот интересный график, который собственно не очень коррелирует с моим словава, как, впрочем, и с вашими:

https://trends.google.com/trends/explore?date=all&q=%2Fm%2F06ff5,%2Fm%2F05z1_,%2Fm%2F09gbxjr,%2Fm%2F091hdj

Python все больше взлетает. Подозреваю, что интерес был подогрет machine learning. Остальные, включая go, скорее сдуваются.
Стоит еще отметить что график показывает "Interest over time" и я не совсем понимаю, что это такое. Подозревают, что что-то близкое к понятию "hype"
Re[4]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.08.18 10:15
Оценка: +1
Здравствуйте, Nuzhny, Вы писали:

Что это за рейтинги, где JavaScript на 8!!!! месте.
Вот опросы на Stack Overflow
https://tproger.ru/articles/stack-overflow-survey-18/
и солнце б утром не вставало, когда бы не было меня
Re[3]: Go язык прёт?
От: AlexRK  
Дата: 03.08.18 10:38
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Черт, ждал когда rust завалит rust.


Э... rust способен даже на такое?
Re[4]: Go язык прёт?
От: kov_serg Россия  
Дата: 03.08.18 10:56
Оценка:
Здравствуйте, AlexRK, Вы писали:

_>>Черт, ждал когда rust завалит rust.


ARK>Э... rust способен даже на такое?

когда сложности создают искуственно, такое вполне возможно.
Re[3]: Go язык прёт?
От: Sharov Россия  
Дата: 03.08.18 11:02
Оценка:
Здравствуйте, benvenuto, Вы писали:

B> который заточен на минимизацию latency (в отличие от большинства остальных сборщиков мусора, которые заточены на минимизацию общего времени сборки).


А это не одно и то же?
Кодом людям нужно помогать!
Re[5]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 03.08.18 11:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Что это за рейтинги, где JavaScript на 8!!!! месте.

S>Вот опросы на Stack Overflow
S>https://tproger.ru/articles/stack-overflow-survey-18/

Это вообще наркоманские опросы:
1. в одном графике бэкенд + фронтенд + full-stack-разработка ~= 150%
2. на следующем графике уже бэкенд + фронтенд + full-stack-разработка ~= 18%

Самая популярная платформа — Линукс! Почти половина разработчиков пишет под него. А, нет, больше! Там ещё есть такие платформы, как AWS, WordPress, Raspberry Pi, что надо тоже понимать, как Линукс. Что в сумме ещё процентов 50 собирает. Вендекапец наступил!
Re[6]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.08.18 11:23
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, Serginio1, Вы писали:


S>>Что это за рейтинги, где JavaScript на 8!!!! месте.

S>>Вот опросы на Stack Overflow
S>>https://tproger.ru/articles/stack-overflow-survey-18/

N>Это вообще наркоманские опросы:

N>1. в одном графике бэкенд + фронтенд + full-stack-разработка ~= 150%
N>2. на следующем графике уже бэкенд + фронтенд + full-stack-разработка ~= 18%

N>Самая популярная платформа — Линукс! Почти половина разработчиков пишет под него. А, нет, больше! Там ещё есть такие платформы, как AWS, WordPress, Raspberry Pi, что надо тоже понимать, как Линукс. Что в сумме ещё процентов 50 собирает. Вендекапец наступил!


То есть JavaScript на 8!!!! месте это не наркоманские сайты?
Вообще большая часть программистов в вэбе. А сейчас в тренде ажуры, авс. И все это на линуксе. Тот же .Net Core нужен исключительно для ажуров.

А то, что больше 100%, то это говорит о том, что владеют несколькими технологиями, используют несколько языков итд
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.08.2018 11:28 Serginio1 . Предыдущая версия .
Re[7]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 03.08.18 11:27
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>То есть JavaScript на 8!!!! месте это не наркоманские сайты?


Ну, у меня нет ни одного знакомого, разрабатывающего на JS. Вэб — да, но это PHP, Python, на Руби одного знаю. Кажется, что JS — это что-то типа bash или SQL, которыми многие пользуются, но они не являются основным языком разработки, приложения пишутся на другом.

S>Вообще большая часть программистов в вэбе. А сейчас в тренде ажуры, авс. И все это на линуксе. Тот же .Net Core нужен исключительно для ажуров.


Вооот. Столько перечислил, даже .Net Core упомянул. Но .Net Core — это же не JS?
Re[8]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.08.18 12:50
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, Serginio1, Вы писали:


S>>То есть JavaScript на 8!!!! месте это не наркоманские сайты?


N>Ну, у меня нет ни одного знакомого, разрабатывающего на JS. Вэб — да, но это PHP, Python, на Руби одного знаю. Кажется, что JS — это что-то типа bash или SQL, которыми многие пользуются, но они не являются основным языком разработки, приложения пишутся на другом.

Угу. Тое есть фронтом никто не занимается? Да и то при генерации страницы куча JS библиотек используется.

Ты не видишь суслика, а он есть. Даже занимаясь бэкэндом ты обязан!!! знать JS, даже если ты возвращаешь только json.


S>>Вообще большая часть программистов в вэбе. А сейчас в тренде ажуры, авс. И все это на линуксе. Тот же .Net Core нужен исключительно для ажуров.


N>Вооот. Столько перечислил, даже .Net Core упомянул. Но .Net Core — это же не JS?

Ты говорил про линукс. Причем тут JS? Да на ажурах используется в основном докеры по линукс.
Что касается .Net Core то там много интеграции с Ангуларом https://habr.com/post/318480/
и солнце б утром не вставало, когда бы не было меня
Re[4]: Go язык прёт?
От: anton_t Россия  
Дата: 03.08.18 13:06
Оценка:
Здравствуйте, StanislavK, Вы писали:

SK>Кстати, вот интересный график, который собственно не очень коррелирует с моим словава, как, впрочем, и с вашими:


SK>https://trends.google.com/trends/explore?date=all&q=%2Fm%2F06ff5,%2Fm%2F05z1_,%2Fm%2F09gbxjr,%2Fm%2F091hdj


SK>Python все больше взлетает. Подозреваю, что интерес был подогрет machine learning. Остальные, включая go, скорее сдуваются.

SK>Стоит еще отметить что график показывает "Interest over time" и я не совсем понимаю, что это такое. Подозревают, что что-то близкое к понятию "hype"

Scala-ы просто мало. Если остальные языки убрать, то видно что Scala растет.
Re[4]: Go язык прёт?
От: Mr.Delphist  
Дата: 03.08.18 13:24
Оценка: 4 (1) +2
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, benvenuto, Вы писали:


B>> который заточен на минимизацию latency (в отличие от большинства остальных сборщиков мусора, которые заточены на минимизацию общего времени сборки).


S>А это не одно и то же?


Не-а. Скажем, можно потратить 1000 раз по 10 мс на уборку одиночного мусора как только инстанс освобождается (итого 10 секунд), а можно собрать всю тыщщу инстансов за один проход, потратив 5 секунд. В первом случае система чутка подлагивает, но памяти много, во втором — работает код быстрее, но если началась уборка... Stop the World!

Вообще, политик сборки мусора довольно много, вплоть до "не собирать вообще, а дальше полный ребут — соседи подхватят". Сильно зависит от языка и рабочего окружения.
Re[9]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 03.08.18 13:25
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Угу. Тое есть фронтом никто не занимается? Да и то при генерации страницы куча JS библиотек используется.


Ну и пусть он используется при генерации. Вон, при компиляции ассемблерный код генерируется. Но это не выводит ассемблер на первое место. JS — это некий сервисный язык программирования, зачем ему первое место?

S>Ты не видишь суслика, а он есть. Даже занимаясь бэкэндом ты обязан!!! знать JS, даже если ты возвращаешь только json.


Ты, видимо, пропустил свою же ссылку опросов со stackoverflow. Там Фрон + Бэк + Фулл = 18% всего. Вот и JS где-то на 8-м месте и болтается.


S> Ты говорил про линукс. Причем тут JS? Да на ажурах используется в основном докеры по линукс.

S>Что касается .Net Core то там много интеграции с Ангуларом https://habr.com/post/318480/

А, это ты про Линукс. Всё равно его получается как-то слишком много на фоне того, что Windows + Андроид + iOS меньше. Ну, мне так кажется.
Re[6]: Go язык прёт?
От: sergey2b ЮАР  
Дата: 03.08.18 13:32
Оценка: 4 (1)
Здравствуйте, Nuzhny, Вы писали:


N>Самая популярная платформа — Линукс! Почти половина разработчиков пишет под него. А, нет, больше! Там ещё есть такие платформы, как AWS, WordPress, Raspberry Pi, что надо тоже понимать, как Линукс. Что в сумме ещё процентов 50 собирает. Вендекапец наступил!


в США половина вакансий под linux
на Си С++ примерно 95% linux
Re[10]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.08.18 13:34
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, Serginio1, Вы писали:


S>> Угу. Тое есть фронтом никто не занимается? Да и то при генерации страницы куча JS библиотек используется.


N>Ну и пусть он используется при генерации. Вон, при компиляции ассемблерный код генерируется. Но это не выводит ассемблер на первое место. JS — это некий сервисный язык программирования, зачем ему первое место?


Да не все генерится автоматом. Сейчас как раз модно использовать STA. А там бэкенд только Jason данные выдает.

S>>Ты не видишь суслика, а он есть. Даже занимаясь бэкэндом ты обязан!!! знать JS, даже если ты возвращаешь только json.


N>Ты, видимо, пропустил свою же ссылку опросов со stackoverflow. Там Фрон + Бэк + Фулл = 18% всего. Вот и JS где-то на 8-м месте и болтается.

Угу. Ты чего то выдернул и сам не понял. JS почти с 70% на первом месте.

S>> Ты говорил про линукс. Причем тут JS? Да на ажурах используется в основном докеры по линукс.

S>>Что касается .Net Core то там много интеграции с Ангуларом https://habr.com/post/318480/

N>А, это ты про Линукс. Всё равно его получается как-то слишком много на фоне того, что Windows + Андроид + iOS меньше. Ну, мне так кажется.



Опять у тебя что то со зрением
В отношении платформ разработчики отдают предпочтение Linux, Windows (Desktop или Server) и Android.
Linux 48.3
Windows (Desktop или Server) 35.2
Android 29.3


Просто Windows + Android > Linux

Опять же многие работают кроссплатформенно и с линукс и с Windows. Просто опять же большинство это вэб и бэкэнд
и солнце б утром не вставало, когда бы не было меня
Re[11]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 03.08.18 13:48
Оценка:
Здравствуйте, Serginio1, Вы писали:

N>>Ты, видимо, пропустил свою же ссылку опросов со stackoverflow. Там Фрон + Бэк + Фулл = 18% всего. Вот и JS где-то на 8-м месте и болтается.

S> Угу. Ты чего то выдернул и сам не понял. JS почти с 70% на первом месте.

Я видел это значение. Но ты пропустил и другие значения, которые как-то не совсем вяжутся с остальными. В итоге кажется, что доля JS — это больше автогенерация и копипаст.

S>Опять у тебя что то со зрением

S>В отношении платформ разработчики отдают предпочтение Linux, Windows (Desktop или Server) и Android.
S> Linux 48.3
S> Windows (Desktop или Server) 35.2
S> Android 29.3

S>Просто Windows + Android > Linux


Не совсем, я к Линуксу прибавил тот же Raspberry, потому что он ни на чём другом не используется. Ну и так далее. Я же говорю, что опрос наркоманский: они путают как программные, так и железные платформы.


S>Опять же многие работают кроссплатформенно и с линукс и с Windows. Просто опять же большинство это вэб и бэкэнд


Я тоже работаю кроссплатформенно. Если ты не понял, то я критикую именно опрос и его результаты. Он очень странный и не вяжется сам с собой. Ты заметил, что на программерсокм сайте больше всего технических директоров, аж 10% от всех посетителей! Тебе не кажется это странным. Судя по всему, они прекрасно знают JS, ведь это главное орудие директора. кто там дальше? Девопс, разработчики настоьных приложений, встраиваемые системы, аналитики, сисадмины, бдшники. Уже больше 50% набралось! И да, очень многие из них знают JS! Его доля же 70%! Номер 1!!!
Re[7]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 03.08.18 13:53
Оценка: +2
Здравствуйте, sergey2b, Вы писали:

N>>Самая популярная платформа — Линукс! Почти половина разработчиков пишет под него. А, нет, больше! Там ещё есть такие платформы, как AWS, WordPress, Raspberry Pi, что надо тоже понимать, как Линукс. Что в сумме ещё процентов 50 собирает. Вендекапец наступил!


S>в США половина вакансий под linux

S>на Си С++ примерно 95% linux

Я совсем не против Линукса, у самого он и на работе, и дома. Но результаты этого опроса как-то не вяжутся с другими статистиками. Думаю, что это лишь отражает аудиторию сайта, а не ситуацию в отрасли.
Re[8]: Go язык прёт?
От: Слава  
Дата: 03.08.18 14:38
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Я совсем не против Линукса, у самого он и на работе, и дома. Но результаты этого опроса как-то не вяжутся с другими статистиками. Думаю, что это лишь отражает аудиторию сайта, а не ситуацию в отрасли.


Совершенно верно. ВебОта (произносить как блевОта, ударение на "о") больше всех представлена в вебе, что неудивительно, и больше всех орёт о своей вездесущности.
Re: Go язык прёт?
От: vsb Казахстан  
Дата: 03.08.18 14:56
Оценка:
Никакого отношения к С Го не имеет, гонит товарищ.
Re[2]: Go язык прёт?
От: bexab  
Дата: 03.08.18 15:12
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Никакого отношения к С Го не имеет, гонит товарищ.


А по моему GoLang — это Cи 2.0
Re[2]: Go язык прёт?
От: m2l  
Дата: 03.08.18 15:27
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Никакого отношения к С Го не имеет, гонит товарищ.


Вообще там авторы как минимум те же
Re[3]: Go язык прёт?
От: vsb Казахстан  
Дата: 03.08.18 15:48
Оценка: +4
Здравствуйте, bexab, Вы писали:

vsb>>Никакого отношения к С Го не имеет, гонит товарищ.


B>А по моему GoLang — это Cи 2.0


С это язык с нулевыми абстракциями, в котором всё сделано для максимальной скорости работы. Его последователь это С++, который следует тем же принципам, но при этом обладает неимоверным числом фич. Если уж говорить про Си 2.0, это скорее Rust. У Го нет ни нулевых абстракций, ни максимальной скорости работы. Я не очень понимаю, что у них общего.
Отредактировано 03.08.2018 15:50 vsb . Предыдущая версия .
Re[3]: Go язык прёт?
От: vsb Казахстан  
Дата: 03.08.18 15:49
Оценка:
Здравствуйте, m2l, Вы писали:

vsb>>Никакого отношения к С Го не имеет, гонит товарищ.


m2l>Вообще там авторы как минимум те же


Один автор. Ну так можно считать, что Delphi, C# и TypeScript имеют много общего, ведь их Хейсберг сделал. Конечно общее найти можно, но надо постараться.
Re: Go язык прёт?
От: a_g_99 США http://www.hooli.xyz/
Дата: 03.08.18 16:07
Оценка: +2 :)))
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?


по синтаксису это pascal (я это презираю)
по производительности cpu это скорее на уровне джава (плюс минус — в некотрых тестах джава быстрее, в некоторых го)
по памяти я даже затрудняюсь — это гораздо лучще джава но хуже С++ (но не сильно хуже)
у платформы своя уникальная концепция (горутины, обработка ошибок и тд) — она сильная и достойна рассмотрения.
есть ощущение целостности синтаксиса языка (хотя сам язык мне очень неприятен), которого нет в современном С++
слабый фреймворк (я знаю сейчас тут будет буря но это правда) но основные фичи там есть чтобы начать работать

на область Node с typescript этот язык на претендует. нишу С и С++ занять не может по определению (там сборка мусора). скорее конкурент джава со своим хипстерским привкусом
Re: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 03.08.18 18:45
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go.


Успехов им, чо. Напомни через год, поржем.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 03.08.18 18:45
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Один автор. Ну так можно считать, что Delphi, C# и TypeScript имеют много общего, ведь их Хейсберг сделал


Таки да, у них довольно много общего.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 03.08.18 18:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Вообще большая часть программистов в вэбе.


То что они в вебе не означает, что они все фронт на JS пишут. У нас, к примеру, фронты в подавляющем меньшинстве даже на веб-проектах.

S> И все это на линуксе.


Нет, не все.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 04.08.18 02:40
Оценка:
Здравствуйте, benvenuto, Вы писали:

M>>Он как питон по синтаксису


B>В каком месте язык со статической типизацией и фигурными скобками для выделения блоков похож на питон по синтаксису?


B>Go по синтаксису похож на Си:


B>* только убрали арифметику указателей,

B>* добавили duck-type интерфейсы,
B>* а void * заменили на {}.
B>* Управление памятью с помощью сборщика мусора, который заточен на минимизацию latency (в отличие от большинства остальных сборщиков мусора, которые заточены на минимизацию общего времени сборки).

B>* Generics так и не добавили.


B>* Вместо exceptions предлагают использовать возвращаемое значение. Функции Go могут возвращать больше обного значения. Поэому проверку ошибки можно организовать примерно так:


B>
B>if (value, err := foo("hi"); err == 0) {
B>}
B>


B>* Встроенные средства поддержки моногопоточные и асинхронных приложений с помощтю channels.


Ну вот duck-type интерфейсы, Управление памятью с помощью сборщика мусора, который заточен на минимизацию latency (в отличие от большинства остальных сборщиков мусора, которые заточены на минимизацию общего времени сборки), Generics так и не добавили. — это от питона. Та же википедия явно указывает на питон. Типа go- соревнуется с питоном по скорости разработки и выразительности, при этом лишён его фатального недостатка- глобального лока, поэтому рвёт питон по скорости исполнения в сценариях с многопоточностью.
Re[3]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 04.08.18 04:09
Оценка: +1 :)
Здравствуйте, benvenuto, Вы писали:

B>* Вместо exceptions предлагают использовать возвращаемое значение. Функции Go могут возвращать больше обного значения. Поэому проверку ошибки можно организовать примерно так:

B>
B>if (value, err := foo("hi"); err == 0) {
B>}
B>


Это и в C++ есть:
auto foo(const char *)
{
    struct
    {
        int value, err;
    } result = {1, 0};
    return result;
}

int main()
{
    if(auto [value, err] = foo("hi"); err == 0)
    {
        cout << "true";
    }
}

Но обычные исключения или expected<T> или optional<T> — лучше

B>* Встроенные средства поддержки моногопоточные и асинхронных приложений с помощтю channels.


Корутины доступны в C++.
Re[4]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 04.08.18 08:31
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Корутины доступны в C++.


В последний раз я слышал про 2 реализации- одну представлял чел на митапе года 2 назад, вторая была с фатальным недостатком. Уж не помню с каким, но впечатление что пока любые реализации — хак.
Re: Go язык прёт?
От: Anton Batenev Россия https://github.com/abbat
Дата: 04.08.18 16:25
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Т> Что вообще происходит? Node с typescript уже стух и надо учить Go?


Go не конкурирует с Node — у них разные ниши. Но попробовав golang после C/C++ и Python в него невозможно не влюбиться. Тут я имею ввиду экосистему в целом, а не синтаксис или скорострельность языка — golang пока проигрывает по синтаксису обоим, а нишу C/C++ (т.е. там, где выжимают такты) он не может занять по определению. Но если в проекте не требуется адского хайлоада и среди разработчиков в команде отсутствуют "синтаксические снобы", то golang может стать сегодня (и уже часто становится) наилучшим выбором.
Бэкапимся на Яндекс.Диск
Re[2]: Go язык прёт?
От: benvenuto  
Дата: 07.08.18 21:45
Оценка: +1 -3 :))
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, Тёмчик, Вы писали:


Т>> Что вообще происходит? Node с typescript уже стух и надо учить Go?


AB> а нишу C/C++ (т.е. там, где выжимают такты) он не может занять по определению.


В подавляющем большинстве случаем C++ используют не там, где выжимают такты. А если реально надо выжимать такты — лучше не использовать С++, так как многие конструкции языка высокоуровневые и трудно предугадать во что они скомпилируются. Притом это зависит не только от компилятора (gcc/clang/whatever), но и от версии компилятора.
Re[4]: Go язык прёт?
От: benvenuto  
Дата: 07.08.18 21:54
Оценка:
Здравствуйте, Тёмчик, Вы писали:


Тё>Ну вот duck-type интерфейсы, Управление памятью с помощью сборщика мусора, который заточен на минимизацию latency (в отличие от большинства остальных сборщиков мусора, которые заточены на минимизацию общего времени сборки), Generics так и не добавили. — это от питона.


Сборка памяти питона организована абсолютно другим способом — через счетчик указателей и глобальный мьютекс GIL (у CPython). GIL, кстати, превращает Python в однопоточный язык, что опять же противоречит идеологии Go. Никаких duck-type интерфейсов у питона нет, он просто динамический язык и проверка существования той или иной операции производится в рантайме.

Тё> Та же википедия явно указывает на питон. Типа go- соревнуется с питоном по скорости разработки и выразительности, при этом лишён его фатального недостатка- глобального лока, поэтому рвёт питон по скорости исполнения в сценариях с многопоточностью.


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


Лучше процитировать сайт Go https://golang.org/doc/faq#ancestors

Go is mostly in the C family (basic syntax), with significant input from the Pascal/Modula/Oberon family (declarations, packages), plus some ideas from languages inspired by Tony Hoare's CSP, such as Newsqueak and Limbo (concurrency)

Re[3]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 08.08.18 04:09
Оценка:
Здравствуйте, benvenuto, Вы писали:

B>В подавляющем большинстве случаем C++ используют не там, где выжимают такты. А если реально надо выжимать такты — лучше не использовать С++, так как многие конструкции языка высокоуровневые и трудно предугадать во что они скомпилируются. Притом это зависит не только от компилятора (gcc/clang/whatever), но и от версии компилятора.


Ты тут забыл сказать, на чём же надо писать это самое битовыжимательство. Я посмотрел у себя на компе: Eigen — на С++, Intel IPP — С++ и ассемблер, Caffe и Tensorflow — С++, OpenCV — С++. Шаг в сторону видеокарт и ПО, написанное под них на CUDA — это тоже расширение языка С++.
С другой стороны, пожилые библиотеки типа ffmpeg — это С, но ffmpeg трудно назвать хорошей библиотекой, это жуткая смесь goto и файлов в тысячи строк. Есть также пожилые библиотеки линейной алгебры на Фортране.
Получается, что всё таки С++.
Re[3]: Go язык прёт?
От: Anton Batenev Россия https://github.com/abbat
Дата: 08.08.18 07:30
Оценка:
Здравствуйте, benvenuto, Вы писали:

b> В подавляющем большинстве случаем C++ используют не там, где выжимают такты. А если реально надо выжимать такты — лучше не использовать С++, так как многие конструкции языка высокоуровневые и трудно предугадать во что они скомпилируются. Притом это зависит не только от компилятора (gcc/clang/whatever), но и от версии компилятора.


(тут должна быть картинка про "Мои вкусы очень специфичны") Если кому-то перестало хватать плюсов в области веба (а тут речь больше про него все же), то его можно или поздравить с успехом или посочувствовать.
Бэкапимся на Яндекс.Диск
Re: Go язык прёт?
От: Aquilaware  
Дата: 08.08.18 08:38
Оценка: 4 (2) +1
Здравствуйте, Тёмчик, Вы писали:

Тё>Что вообще происходит? Node с typescript уже стух и надо учить Go?


Go прёт в основном в около-юниксовых кругах. Люди в тех местах настолько испуганны бинарной несовместимостью, что бинарная всеядность и стабильность Go для них стала целым базисом. Поэтому и сентименты в духе "как С".

В основном это касается тех компаний, которые продают свои продукты "в коробке", а не только как сервисы. Для них Go это настоящее чудо.
Re: Go язык прёт?
От: TimurSPB Интернет  
Дата: 08.08.18 09:02
Оценка: +1
Меня как то не прёт язык Go. Паскально так.
Make flame.politics Great Again!
Re[2]: Go язык прёт?
От: El Camino Real США  
Дата: 08.08.18 16:42
Оценка:
Здравствуйте, TimurSPB, Вы писали:

TSP>Меня как то не прёт язык Go. Паскально так.

Наоборот же. Школьные годы чудесные, скупая ностальгическая слеза. А го — хороший, когда надо много потоков наплодить, делающих всего понемногу. Показал недавно "облачной" команде пару примеров, теперь они прутся и активно избавляются от питона.
Re[9]: Go язык прёт?
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 10.08.18 18:24
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Угу. Тое есть фронтом никто не занимается?


Я видел фронт-енд команды в нескольких компаниях. Они по количеству были не очень большими. Буквально, один синьор-тимлид и один-два джуниора.

S>Даже занимаясь бэкэндом ты обязан!!! знать JS, даже если ты возвращаешь только json.


Зачем?
С уважением, Artem Korneev.
Re[3]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 11.08.18 03:53
Оценка: +2
Здравствуйте, benvenuto, Вы писали:

B>А если реально надо выжимать такты — лучше не использовать С++,




B>так как многие конструкции языка высокоуровневые и трудно предугадать во что они скомпилируются. Притом это зависит не только от компилятора (gcc/clang/whatever), но и от версии компилятора.


Конструкции, не смотря на то что высокоуровневые, предельно предсказуемые, но для этого внезапно нужно знать язык и его отображение на машину
Глядя на код ясно во что он скомпилируется с выключенными оптимизациями и во что он может скомпилироваться с максимальными настройками оптимизации (и в mainstream компиляторах он в это действительно компилируется с некоторой разумной и даже предсказуемой дисперсией).
Вот конкретный пример
Автор: Evgeny.Panasyuk
Дата: 11.07.16
— навернули абстракций в виде EDSL запросов, а результирующий ассемблерный код получился идентичен рукопашному бойлерлейту, причём ещё до начала реализации было понимание что результат если и не будет вдруг идентичным в несущественных деталях, по смыслу будет порождать подобный код.
Re[3]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 11.08.18 03:58
Оценка:
Здравствуйте, El Camino Real, Вы писали:

ECR>Наоборот же. Школьные годы чудесные, скупая ностальгическая слеза. А го — хороший, когда надо много потоков наплодить, делающих всего понемногу. Показал недавно "облачной" команде пару примеров, теперь они прутся и активно избавляются от питона.


И на Python'е есть stackful coroutines — http://www.gevent.org/
Re[4]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 12.08.18 02:44
Оценка:
Здравствуйте, ·, Вы писали:

EP>>Это и в C++ есть:

·>
·>Немного поменяем: http://coliru.stacked-crooked.com/a/4dd7fd6efc303676
·>С какого перепугу оно выдаёт "true, value=1"?

auto foo(const char *)
{
    struct
    {
        int value, err;
    } result = {1, 0};
    return result;
}

int main()
{
    if(auto [value, err] = foo("hi"); err == 0)
    {
        cout << "true, value=" << value;
    }
    else
    {
        cout << "false, value=" << value;
    }
}

И что оно по-твоему должно выдавать?

.>И вот весь С++ такой. Проще закопать.


С логикой борешься?
Re[4]: Go язык прёт?
От: Hobbes Россия  
Дата: 12.08.18 12:53
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>И на Python'е есть stackful coroutines — http://www.gevent.org/


И tornado. И начиная с 3.6/3.7 async/await.
Re[6]: Go язык прёт?
От: Hobbes Россия  
Дата: 12.08.18 13:00
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Самая популярная платформа — Линукс! Почти половина разработчиков пишет под него. А, нет, больше! Там ещё есть такие платформы, как AWS, WordPress, Raspberry Pi, что надо тоже понимать, как Линукс. Что в сумме ещё процентов 50 собирает. Вендекапец наступил!


Вендекапец на сервере безусловно наступил.
Re[5]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 12.08.18 13:47
Оценка:
Здравствуйте, Hobbes, Вы писали:

EP>>И на Python'е есть stackful coroutines — http://www.gevent.org/

H>И tornado. И начиная с 3.6/3.7 async/await.

async/await — это stackless, со всеми вытекающими.
Re[6]: Go язык прёт?
От: Sharov Россия  
Дата: 13.08.18 11:04
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>async/await — это stackless, со всеми вытекающими.


Где, в питон и го? В дотнет это кажется не так...
Кодом людям нужно помогать!
Re[7]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 13.08.18 14:05
Оценка: 4 (1) +1
Здравствуйте, Sharov, Вы писали:

EP>>async/await — это stackless, со всеми вытекающими.

S>Где, в питон и го? В дотнет это кажется не так...

В Python 3 и C# async/await — это stackless.
Питоновский gevent, Boost.Coroutine- stackful.
Goroutines в go — stackful.

Одна из отличительных особенностей stackful от stackless — возможность прозрачно yield'ануть/await'нуть через несколько уровней стороннего кода.
Отредактировано 13.08.2018 14:06 Evgeny.Panasyuk . Предыдущая версия .
Re[8]: Go язык прёт?
От: Sharov Россия  
Дата: 14.08.18 12:15
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>В Python 3 и C# async/await — это stackless.

EP>Питоновский gevent, Boost.Coroutine- stackful.
EP>Goroutines в go — stackful.

EP>Одна из отличительных особенностей stackful от stackless — возможность прозрачно yield'ануть/await'нуть через несколько уровней стороннего кода.


У дотнета есть TaskCompletionSource для ентих целей. Вполне прозрачно, кмк. Если я правильно понял суть вопроса.
Кодом людям нужно помогать!
Re[10]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.08.18 09:03
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Здравствуйте, Serginio1, Вы писали:


S>> Угу. Тое есть фронтом никто не занимается?


AK>Я видел фронт-енд команды в нескольких компаниях. Они по количеству были не очень большими. Буквально, один синьор-тимлид и один-два джуниора.


S>>Даже занимаясь бэкэндом ты обязан!!! знать JS, даже если ты возвращаешь только json.


AK>Зачем?


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

А по поводу "фронт-енд команды" смотрим на развитие Ангулара, и у меня большие сомнения в твоих утверждениях.
и солнце б утром не вставало, когда бы не было меня
Re[11]: Go язык прёт?
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 30.08.18 00:04
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Даже занимаясь бэкэндом ты обязан!!! знать JS, даже если ты возвращаешь только json.

AK>>Зачем?
S> Тебе так или иначе приходится возвращать код для динамичеких элементов, которые могут варьироваться от условий.

За много лет — ни разу не приходилось.
Если вы возвращаете какой-то JS-код из REST API-сервисов, то у вас что-то фундаментально не так с архитектурой.

S>Другое дело SPA. Там тебе действительно не нужно знать JS.


REST бэк-енду вообще все равно, что там на фронт-енде. Там может быть SPA, там может быть мобильное приложение, или какой-то другой сервис, который запросил эти данные.
Если у вас бэкенд зависит от фронтенда, то вы на ровном месте нашли себе грабли.

AK>>Я видел фронт-енд команды в нескольких компаниях. Они по количеству были не очень большими. Буквально, один синьор-тимлид и один-два джуниора.

S> А по поводу "фронт-енд команды" смотрим на развитие Ангулара, и у меня большие сомнения в твоих утверждениях.

А что с Angular такого специфического? Он вроде упрощает разработку, а не усложняет ее. Код на TypeScript хотя бы можно читать без поллитры.

Я таки как раз говорил про команды, пилящие фронтенд на Angular. Моя выборка не очень велика, но что есть, то есть. Но я согласен, что рейтинг и правда какой-то наркоманский. 8-е место для JavaScript выглядит очень странно. По меньше мере, я бы оценил долю JS больше, чем VB, PHP и Python.

It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.


Ну т.е. они оценивают как-то непонятно. Это не по количеству написанного кода.
С уважением, Artem Korneev.
Re: Go язык прёт?
От: _Cyber_ Россия  
Дата: 04.09.18 18:59
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?


О востребованности языка нужно судить с позиции, насколько хорошо он решает насущные задачи, под которые заточен, а не с позиции синтаксиса и удобства написания на нем.
Например, сейчас нужен язык для параллельных вычислений, который бы полностью освободил программиста от семафоров, барьеров, ..., чтоб не нужно было даже о них задумываться. Даже понятия о потоках не должно быть. Создал цикл, а он по возможности сам в отделом потоке работает. Естественно синтаксис изменится, это будет текст в несколько столбцов или графическое что-то, типа labview, но более компактное и читабельное.
Аналогично и для нейроних сетей и машинного обучения.
Re[2]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 04.09.18 19:42
Оценка:
Здравствуйте, _Cyber_, Вы писали:

_C_>Аналогично и для нейроних сетей и машинного обучения.


Для этого добра и так уже программировать почти не приходится, если использовать тот же Керас. Распознавание лиц за 10 минут — есть уже.
Re[3]: Go язык прёт?
От: El Camino Real США  
Дата: 05.09.18 09:33
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Для этого добра и так уже программировать почти не приходится, если использовать тот же Керас. Распознавание лиц за 10 минут — есть уже.

Всё совсем не так. Нейросети сейчас лезут во все утюги и микроволновки, т.е. программировать их очень даже приходится. На тёплом ламповом С зачастую. Без использования сторонних библиотек и уж тем более облачных сервисов, предоставляющих натренированные модели.
Re[4]: Go язык прёт?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 05.09.18 10:01
Оценка:
Здравствуйте, El Camino Real, Вы писали:

ECR>Всё совсем не так. Нейросети сейчас лезут во все утюги и микроволновки, т.е. программировать их очень даже приходится. На тёплом ламповом С зачастую. Без использования сторонних библиотек и уж тем более облачных сервисов, предоставляющих натренированные модели.


Ну, сделать inference уже не так сложно, как обеспечить процесс обучения. Тоже много работы, но не сопоставимо со всем остальным. Разве сейчас мало подобных открытых библиотек? Казалось только ленивый вендор не выкатил свой framework.
Re[9]: Go язык прёт?
От: Jack128  
Дата: 05.09.18 10:03
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>>В Python 3 и C# async/await — это stackless.

EP>>Питоновский gevent, Boost.Coroutine- stackful.
EP>>Goroutines в go — stackful.

EP>>Одна из отличительных особенностей stackful от stackless — возможность прозрачно yield'ануть/await'нуть через несколько уровней стороннего кода.


S>У дотнета есть TaskCompletionSource для ентих целей. Вполне прозрачно, кмк. Если я правильно понял суть вопроса.


нет, ты не понял.

int GetValue() => GetValue(1) + GetValue(2);
int GetValue1() => 1;
int GetValue2() => 2;

теперь представим, что внезапно GetValue1 должно возвращать значение асинхронно. В stackless (например в шарпе) тебе придется менять весь код который вызывает GetValue/GetValue1 потому они теперь возвращают не число, а некий объект, который содержит в себе состояние.

В stackfull нужно только поменять реализацию GetValue1. "Система" сама подменяет стек в нужные моменты, никакого специального объекта с состоянием ненужно.
Re[10]: Go язык прёт?
От: Sharov Россия  
Дата: 05.09.18 11:05
Оценка:
Здравствуйте, Jack128, Вы писали:

J>int GetValue() => GetValue(1) + GetValue(2);

J>int GetValue1() => 1;
J>int GetValue2() => 2;

J>теперь представим, что внезапно GetValue1 должно возвращать значение асинхронно. В stackless (например в шарпе) тебе придется менять весь код который вызывает GetValue/GetValue1 потому они теперь возвращают не число, а некий объект, который содержит в себе состояние.


Касательно конкретно этого примера -- можно сделать wait\await на GetValue1. Зачем GetValue переделывать?


J>В stackfull нужно только поменять реализацию GetValue1. "Система" сама подменяет стек в нужные моменты, никакого специального объекта с состоянием ненужно.


А можно подробнее про подмену стека, т.е. где почитать про енто можно? А то я не улавливаю связь Вашего примера с определением ниже:

stackfulness

In contrast to a stackless coroutine a stackful coroutine can be suspended from within a nested stackframe.
Execution resumes at exactly the same point in the code where it was suspended before. With a stackless coroutine,
only the top-level routine may be suspended. Any routine called by that top-level routine may not itself suspend.
This prohibits providing suspend/resume operations in routines within a general-purpose library.

Здесь -- https://stackoverflow.com/a/28989543/241446
Кодом людям нужно помогать!
Re[11]: Go язык прёт?
От: Jack128  
Дата: 05.09.18 13:54
Оценка: 10 (1) +1
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Jack128, Вы писали:


J>>int GetValue() => GetValue(1) + GetValue(2);

J>>int GetValue1() => 1;
J>>int GetValue2() => 2;

J>>теперь представим, что внезапно GetValue1 должно возвращать значение асинхронно. В stackless (например в шарпе) тебе придется менять весь код который вызывает GetValue/GetValue1 потому они теперь возвращают не число, а некий объект, который содержит в себе состояние.


S>Касательно конкретно этого примера -- можно сделать wait\await на GetValue1. Зачем GetValue переделывать?


Я там опечатался, GetValue должна выглядеть так:

int GetValue() => GetValue1() + GetValue2();

После перевода GetValue1 на асинхронность в stackless стало: Task<int> GetValue() => await GetValue1() + GetValue2();


J>>В stackfull нужно только поменять реализацию GetValue1. "Система" сама подменяет стек в нужные моменты, никакого специального объекта с состоянием ненужно.


S>А можно подробнее про подмену стека, т.е. где почитать про енто можно? А то я не улавливаю связь Вашего примера с определением ниже:


S>

S>stackfulness

S>In contrast to a stackless coroutine a stackful coroutine can be suspended from within a nested stackframe.
S>Execution resumes at exactly the same point in the code where it was suspended before. With a stackless coroutine,
S>only the top-level routine may be suspended. Any routine called by that top-level routine may not itself suspend.
S>This prohibits providing suspend/resume operations in routines within a general-purpose library.

S>Здесь -- https://stackoverflow.com/a/28989543/241446


Ну это оно и есть.

a stackful coroutine can be suspended from within a nested stackframe.
Execution resumes at exactly the same point in the code where it was suspended before

В stackless ты не можешь вызвать await без правки кода выше по стеку вызовов. В stackfull код GetValue не меняется, хотя GetValue1 стала асинхронной. Подмена стека — это реализация. Как мы можем реализовать асинхронность в GetValue1, чтоб не трогать GetValue ??
Очень просто:
int GetValue1() {
int result;
http.ReadData(&result);
// <-- сохраняем стек со всем лок. переменными выше по стеку вызовов

// выполнение кода приостанавливается, поток работает на другими задачами

// <- данные с сетки пришли, восстанавливаем стек
return result;
}
Re[12]: Go язык прёт?
От: Sharov Россия  
Дата: 05.09.18 14:06
Оценка:
Здравствуйте, Jack128, Вы писали:

J>

J>a stackful coroutine can be suspended from within a nested stackframe.
J>Execution resumes at exactly the same point in the code where it was suspended before


А разве await не так работает? Т.е. async\await не есть stackfull?

J>В stackless ты не можешь вызвать await без правки кода выше по стеку вызовов. В stackfull код GetValue не меняется, хотя GetValue1 стала асинхронной. Подмена стека — это реализация. Как мы можем реализовать асинхронность в GetValue1, чтоб не трогать GetValue ??

J>Очень просто:
J>int GetValue1() {
J> int result;
J> http.ReadData(&result);
J> // <-- сохраняем стек со всем лок. переменными выше по стеку вызовов

J> // выполнение кода приостанавливается, поток работает на другими задачами


J> // <- данные с сетки пришли, восстанавливаем стек

J> return result;
J>}


Правильно ли я понимаю, что если сделать тут: await // выполнение кода приостанавливается, поток работает на другими задачами,
то придется добалять сигнатуру async как GetValue1 так и GetValue?
Кодом людям нужно помогать!
Re[13]: Go язык прёт?
От: Jack128  
Дата: 05.09.18 15:00
Оценка: 5 (1)
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Jack128, Вы писали:


J>>

J>>a stackful coroutine can be suspended from within a nested stackframe.
J>>Execution resumes at exactly the same point in the code where it was suspended before


S>А разве await не так работает?

Не так. там же на SO писали,

With a stackless coroutine, only the top-level routine may be suspended. Any routine called by that top-level routine may not itself suspend

Почему так?? потому что в stackless состояние проносится в явном виде (в случае шарпа — в виде типа Task<>), а значит если какая то функция изначально не возвращала Task (например getValue1(), то внутри нее ты никак не можешь await'ить, ты обязан поменять тип результата функции на Task<>. А раз мы поменяли тип результата, то весь вышележащий код нужно править/перекомпилировать.


S>Т.е. async\await не есть stackfull?

async/await в C#/JavaScript НЕ stackfull. Эти конструкции порождают stackless код. Не, конечно JS движок нативно поддерживающий async/await может положить этот код на fiber'ы виндовые например, но смысла нет, самому JS stackfull coroutines не нужены.

J>>В stackless ты не можешь вызвать await без правки кода выше по стеку вызовов. В stackfull код GetValue не меняется, хотя GetValue1 стала асинхронной. Подмена стека — это реализация. Как мы можем реализовать асинхронность в GetValue1, чтоб не трогать GetValue ??

J>>Очень просто:
J>>int GetValue1() {
J>> int result;
J>> http.ReadData(&result);
J>> // <-- сохраняем стек со всем лок. переменными выше по стеку вызовов

J>> // выполнение кода приостанавливается, поток работает на другими задачами


J>> // <- данные с сетки пришли, восстанавливаем стек

J>> return result;
J>>}


S>Правильно ли я понимаю, что если сделать тут: await // выполнение кода приостанавливается, поток работает на другими задачами,

S>то придется добалять сигнатуру async как GetValue1 так и GetValue?
Это ж гипотетический пример на непонятно каком языке, пытающийся обяснить как работают stackfull короутины. Если мы говорим про шарп, то комментарии будет не верны, поскольку там stackless короутины.

Если представить, что это шарп, то да. нужно будет добвлять. Но конкретно слово async — это заморочка шарпа,без него вполне можно было бы обойтись, но перекомпилировать весь код, который использует GetValue1 — в любом случае придется, потому что был int GetValue1(), а стал Task<int> GetValue1(), было int x = GetValue1(); стало int x = await GetValue1(),

Повторюсь, сама необходимость слова async — это не концептуальная трабла, если б разрабы шарпа захотели можно было разрешить писать так:

/* нет слова async */Task<int> GetValue1() { ... }

await GetValue1(); // всё равно можем вызывать await

концептуальна тут смена типа результата. int vs Task<int>. А в stackfull тип результата менять не надо.
Re[14]: Go язык прёт?
От: Sharov Россия  
Дата: 05.09.18 15:18
Оценка:
Здравствуйте, Jack128, Вы писали:

J>Если представить, что это шарп, то да. нужно будет добвлять. Но конкретно слово async — это заморочка шарпа,без него вполне можно было бы обойтись, но перекомпилировать весь код, который использует GetValue1 — в любом случае придется, потому что был int GetValue1(), а стал Task<int> GetValue1(), было int x = GetValue1(); стало int x = await GetValue1(),


J>Повторюсь, сама необходимость слова async — это не концептуальная трабла, если б разрабы шарпа захотели можно было разрешить писать так:


J>/* нет слова async */Task<int> GetValue1() { ... }


J>await GetValue1(); // всё равно можем вызывать await


J>концептуальна тут смена типа результата. int vs Task<int>. А в stackfull тип результата менять не надо.


Я понял аргументацию, но не понял почему тогда замена и перекомпиляция кода не делает его stackfull. Изменили все на async, перекомпилировали и готово. Stackfull, да нет?
Мне видится, что здесь не все так просто и на уровне синтаксиса ситуацию не исправить, тут все дело в рантайме (или системе типов, а скорее вместе).
Просто в stackfull всегда будет возращаться Task<int>, даже если мы написали полность синхронный код. Или я не прав?
Кодом людям нужно помогать!
Re[4]: Go язык прёт?
От: c-smile Канада http://terrainformatica.com
Дата: 05.09.18 18:43
Оценка:
Здравствуйте, vsb, Вы писали:

B>>А по моему GoLang — это Cи 2.0


vsb>Си 2.0, это скорее Rust.



С 2.0 это скорее D в конфигурации DasBetterC т.е. без GC но со всеми остальными плюшками D — templates, RAII и пр.
Re[15]: Go язык прёт?
От: Jack128  
Дата: 05.09.18 19:59
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

S>Я понял аргументацию, но не понял почему тогда замена и перекомпиляция кода не делает его stackfull. Изменили все на async, перекомпилировали и готово. Stackfull, да нет?


Stack(full|less) определяется тем, как сохраняется состояние сверху/снизу от await

/* Task для Stackless или void Stackfull */ Example() {
var x = GetValue();
await http.ReadAsync();
Console.WriteLine(x);
}

В Stackless варианте x — хранится в дин памяти. Компилятор генерит класс, x становится полем этого класса, Console.WriteLine переносится в метод этого класса(соответсвенно имеет доступ к x) и после того, как работа с сетью закончится — вызывается этот сгенеренный метод. (на самом деле это сильно упрощенная схема, но для примера — норм)

В Stackfull — всё хранится как обычном синхронном коде, на стеке. Просто пока мы ждем на ReadAsync стек подменяеся, чтоб мог работать другой код, а когда чтение закончится — стек возвращается назад.

S>Мне видится, что здесь не все так просто и на уровне синтаксиса ситуацию не исправить, тут все дело в рантайме (или системе типов, а скорее вместе).

S>Просто в stackfull всегда будет возращаться Task<int>, даже если мы написали полность синхронный код. Или я не прав?
Нет. В том то и фича, что в stackfull варианте код выглядит как абсолютно синхронный, никаких тасков нету. Один минус, рантайм должен поддерживать подобную подмену стека.
Re[16]: Go язык прёт?
От: · Великобритания  
Дата: 05.09.18 21:54
Оценка:
Здравствуйте, Jack128, Вы писали:

J>В Stackless варианте x — хранится в дин памяти. Компилятор генерит класс, x становится полем этого класса, Console.WriteLine переносится в метод этого класса(соответсвенно имеет доступ к x) и после того, как работа с сетью закончится — вызывается этот сгенеренный метод. (на самом деле это сильно упрощенная схема, но для примера — норм)


J>В Stackfull — всё хранится как обычном синхронном коде, на стеке. Просто пока мы ждем на ReadAsync стек подменяеся, чтоб мог работать другой код, а когда чтение закончится — стек возвращается назад.

А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: Go язык прёт?
От: Jack128  
Дата: 06.09.18 05:34
Оценка: 5 (1)
Здравствуйте, ·, Вы писали:

·>Здравствуйте, Jack128, Вы писали:


J>>В Stackless варианте x — хранится в дин памяти. Компилятор генерит класс, x становится полем этого класса, Console.WriteLine переносится в метод этого класса(соответсвенно имеет доступ к x) и после того, как работа с сетью закончится — вызывается этот сгенеренный метод. (на самом деле это сильно упрощенная схема, но для примера — норм)


J>>В Stackfull — всё хранится как обычном синхронном коде, на стеке. Просто пока мы ждем на ReadAsync стек подменяеся, чтоб мог работать другой код, а когда чтение закончится — стек возвращается назад.

·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.
Если совсем абстрактно говорить, в stackfull: стек — глоб переменная, в stackless: контекст явно протаскивается посредством Task/IEnumerable и прочее. Отсюда и все различия.
Re: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.09.18 05:58
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?


Прет как паровоз, еще и Go 2 скоро подвезут
Автор: kaa.python
Дата: 03.09.18
. Одно хорошо, на этот язык можно и мартышку переучить, так что недостатка в кадрах нет – умел бы на чем-нибудь писать, и после недельного чтения доков готов продвинутый Go программист
Re[17]: Go язык прёт?
От: Cyberax Марс  
Дата: 06.09.18 07:24
Оценка:
Здравствуйте, ·, Вы писали:

·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.

Правильная реализация stackful coroutines позволяет делать произвольную глубину вложения. В случае с генерацией конечного автомата в одном классе — это вызовет взрыв объёма кода.
Sapienti sat!
Re[18]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.09.18 08:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, ·, Вы писали:


C>·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.

C>Правильная реализация stackful coroutines позволяет делать произвольную глубину вложения. В случае с генерацией конечного автомата в одном классе — это вызовет взрыв объёма кода.

Вообщето для каждого итератора (yield) которыми по сути и являются async await создается свой класс и замыкания.
Да если локальных переменных много то они попадают в поля генерируемого класса. Но эти поля в основном то являются локальными переменными.
Для полей основного класса как правило передается сам объект, а не поля. Так, что не вижу в чем взрыв?
и солнце б утром не вставало, когда бы не было меня
Re[2]: Go язык прёт?
От: smeeld  
Дата: 06.09.18 09:15
Оценка: -2
Здравствуйте, kaa.python, Вы писали:

KP> Одно хорошо, на этот язык можно и мартышку переучить, так что недостатка в кадрах нет – умел бы на чем-нибудь писать, и после недельного чтения доков готов продвинутый Go программист


Это в равной степени можно отнести к любому другому ЯП. Например, к C++. Если на проекте не выкобениваются и пишут тупо на Cи с классами, то C++ в на таком уровне тоже осилить за неделю не вопрос любой мартышке. А golang, кстати, сложнее чем python, не по синтаксису, а по возможностям: на golang можно писать динамично самопараллелящиеся системы со всей логикой, реализованной асинхронными каллебками, это вам не python или perl какой-нибудь.
Re[18]: Go язык прёт?
От: · Великобритания  
Дата: 06.09.18 10:04
Оценка:
Здравствуйте, Jack128, Вы писали:

J>>>В Stackless варианте x — хранится в дин памяти. Компилятор генерит класс, x становится полем этого класса, Console.WriteLine переносится в метод этого класса(соответсвенно имеет доступ к x) и после того, как работа с сетью закончится — вызывается этот сгенеренный метод. (на самом деле это сильно упрощенная схема, но для примера — норм)


J>>>В Stackfull — всё хранится как обычном синхронном коде, на стеке. Просто пока мы ждем на ReadAsync стек подменяеся, чтоб мог работать другой код, а когда чтение закончится — стек возвращается назад.

J>·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.
J>Если совсем абстрактно говорить, в stackfull: стек — глоб переменная, в stackless: контекст явно протаскивается посредством Task/IEnumerable и прочее. Отсюда и все различия.
Глобальность переменных это абстракции про ЯП и удобство его использования с т.з. человеков. С т.з. железяки глобальные переменные ничем не отличаются от прочего. Так что я до сих пор не понял различия, ну кроме того разницы в названиях соответсвующих сущностей в реализации ЯП, опять же для человеков.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[18]: Go язык прёт?
От: · Великобритания  
Дата: 06.09.18 10:08
Оценка: 5 (1)
Здравствуйте, Cyberax, Вы писали:

C>·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.

C>Правильная реализация stackful coroutines позволяет делать произвольную глубину вложения. В случае с генерацией конечного автомата в одном классе — это вызовет взрыв объёма кода.
Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться. А с генерацией это будут не области, а члены класса для каждой захваченной переменной. Взрывы откуда? Из-за необходимости типизировать каждую область захваченных локальных переменных?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Go язык прёт?
От: _Cyber_ Россия  
Дата: 06.09.18 10:09
Оценка: :))
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?

У меня блевательный рефлекс возникает как только заходит разговор об ООП. Возможно, это естественная защита организма, примерно как на алкоголь и отравление. Я не вижу смысла для себя во всех этих новых языках, если они только все усложняют своим ООП. Почему нет движений в сторону упрощения? Тут даже не в самом языке дело, а в IDE. Сделайте графический IDE для удобства чтения, типа Labview + Cи. Сделайте в том же IDE представление распараллеливание в виде столбцов, где будут пробелы в критических секциях. Сделайте умный компилятор, который будет сам распараллеливать. Хватит нас мучить новыми языками, которые особо ничего не меняют, но заставляют привыкать к новому. Большая часть программ сейчас — мелкие утилиты и прошивки для встраиваемых систем, там ваш ООП нафиг не вср.лся. Никто не захочет учить новый язык неделю, чтоб написать утилитку за час. Люди, одумайтесь!!!
Re[19]: Go язык прёт?
От: Jack128  
Дата: 06.09.18 11:00
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, Jack128, Вы писали:


J>>>>В Stackless варианте x — хранится в дин памяти. Компилятор генерит класс, x становится полем этого класса, Console.WriteLine переносится в метод этого класса(соответсвенно имеет доступ к x) и после того, как работа с сетью закончится — вызывается этот сгенеренный метод. (на самом деле это сильно упрощенная схема, но для примера — норм)


J>>>>В Stackfull — всё хранится как обычном синхронном коде, на стеке. Просто пока мы ждем на ReadAsync стек подменяеся, чтоб мог работать другой код, а когда чтение закончится — стек возвращается назад.

J>>·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.
J>>Если совсем абстрактно говорить, в stackfull: стек — глоб переменная, в stackless: контекст явно протаскивается посредством Task/IEnumerable и прочее. Отсюда и все различия.
·>Глобальность переменных это абстракции про ЯП и удобство его использования с т.з. человеков. С т.з. железяки глобальные переменные ничем не отличаются от прочего. Так что я до сих пор не понял различия, ну кроме того разницы в названиях соответсвующих сущностей в реализации ЯП, опять же для человеков.

а с точки зрения желязки на контактах просто меняется напряжение и пофиг — пишешь ты на хаскеле или асме. Разговор ни о чем.
Отредактировано 06.09.2018 11:03 Jack128 . Предыдущая версия .
Re[2]: Go язык прёт?
От: smeeld  
Дата: 06.09.18 11:26
Оценка:
Здравствуйте, _Cyber_, Вы писали:

_C_>У меня блевательный рефлекс возникает как только заходит разговор об ООП. Большая часть программ сейчас — мелкие утилиты


Вы явно ошиблись выбором профессии. ЯП-ы тут не причём. Прикол, но другим (большинству) как раз в кайф и ООП, и новые ЯП-ы, и всё прочее.
Re[20]: Go язык прёт?
От: · Великобритания  
Дата: 06.09.18 11:33
Оценка:
Здравствуйте, Jack128, Вы писали:

J>>>·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.

J>>>Если совсем абстрактно говорить, в stackfull: стек — глоб переменная, в stackless: контекст явно протаскивается посредством Task/IEnumerable и прочее. Отсюда и все различия.
J>·>Глобальность переменных это абстракции про ЯП и удобство его использования с т.з. человеков. С т.з. железяки глобальные переменные ничем не отличаются от прочего. Так что я до сих пор не понял различия, ну кроме того разницы в названиях соответсвующих сущностей в реализации ЯП, опять же для человеков.

J>а с точки зрения желязки на контактах просто меняется напряжение и пофиг — пишешь ты на хаскеле или асме. Разговор ни о чем.

Разница как минимум в том сколько конретно контактов надо менять и как долго меняется напряжение.
Я хочу разобраться почему меня, как программиста на ЯП, должна волновать разница stackless/stackfull?
В обычной жизни когда я пишу программу, я знаю, что размещение данных на стеке более эффективно работает на железе, т.к. менеджемент памяти на порядки проще, не нужно никакой динамики, куч памяти, подсчётов ссылок, сборки мусора и прочего, тогда как классическая работа с классическим стеком это просто инкремент/декремент одного регистра. Это всё влияет на производительность и мои решения о выборе конкретного механизма.
А вот если идёт жонглирование фреймами стека и их перемещение туда-сюда, то стек становится не стеком, а чёрт знает чем, и я перестаю понимать разницу — какая разница чем ЯП там манипулирует вунутре и как оно там называется — фрейм стека или объект?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 06.09.18 11:53
Оценка: +2
Здравствуйте, smeeld, Вы писали:

S>Если на проекте не выкобениваются и пишут тупо на Cи с классами, то C++ в на таком уровне тоже осилить за неделю не вопрос любой мартышке.


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

А в том, что на C++ всем приходится управлять вручную, в первую очередь -- управлять памятью. Что весьма не тривиально само по себе. И уж тем более в C++, где грабли можно встретить даже в элементарной std::min.

Именно поэтому был ряд экспериментов по созданию альтернатив C/C++ в нише низкоуровневого/системного программирования, но с безопасной работой с памятью. Успешным из которых, наверное, оказался только Rust. О простоте которого, в итоге, говорить не приходится.

На этом фоне Go невероятно простой язык с одним из самых низких порогов входа. Но при этом с хорошей производительностью, переносимостью и отсутствием "прицепа" в виде JVM или .NET-а. Шустрых и удобных нативных языков с GC пока не так много. Например, есть Eiffel и D. Но их освоить сложнее, чем Go, да и их популярность на фоне Go вообще никакая.
Re[4]: Go язык прёт?
От: smeeld  
Дата: 06.09.18 12:07
Оценка: +1
Здравствуйте, so5team, Вы писали:

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


Это субъектвное мнение.

S>А в том, что на C++ всем приходится управлять вручную, в первую очередь -- управлять памятью. Что весьма не тривиально само по себе.


Это одна из саамых тривиальных вещей в программировании-выделил память, обеспечь её освобождение. Это в любом случае можно обеспечить, если тольо об этом не забыть. А вот в golang есть такая неприятная вещь как утечка подпрограмм, вот это, на мой взгляд, вещь более коварная и трудновылавливаемая и вообще неочевидная, чем утечка памяти в C/C++, но очень просто схватываемая, если только пишешь на golang что-то чуть более сложное, чем простая утилита. Есть и другие неприятности, причём в golang они все какие-то неочевидные и странные. Так что дефирамбы про отутствие трудностей в golang-это исключительно от того, что большинство ещё ничего сёрьёзного на нем не писало, по сложности сравнимого с тем, что писалось на С++. Так что не всё так очевидно просто.
Re[5]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 06.09.18 12:18
Оценка: +1
Здравствуйте, smeeld, Вы писали:

S>>А в том, что на C++ всем приходится управлять вручную, в первую очередь -- управлять памятью. Что весьма не тривиально само по себе.


S>Это одна из саамых тривиальных вещей в программировании-выделил память, обеспечь её освобождение.


Простите, а вы вообще программист?
Re[3]: Go язык прёт?
От: _Cyber_ Россия  
Дата: 06.09.18 12:18
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, _Cyber_, Вы писали:


_C_>>У меня блевательный рефлекс возникает как только заходит разговор об ООП. Большая часть программ сейчас — мелкие утилиты


S>Вы явно ошиблись выбором профессии. ЯП-ы тут не причём. Прикол, но другим (большинству) как раз в кайф и ООП, и новые ЯП-ы, и всё прочее.

Так в том то и дело, что я не проф. программер, а всего лишь инженер, широкого профиля, и электронику на МК разрабатываю, и параллельные вычисления немного, и машинное обучение собираюсь.
Мы же говорим о массовости ЯП, так вот, массовый ЯП должен быть понятен сходу таким как я или студентам первашам. Им ваше ООП нах не нужно, чтоб написать первую программку. А дальше, когда освоят им другие ЯП лень осваивать, т.к. этот вполне устраивает своим удобством.
Re[6]: Go язык прёт?
От: smeeld  
Дата: 06.09.18 12:26
Оценка:
Здравствуйте, so5team, Вы писали:

S>Простите, а вы вообще программист?


С 1999 по 2005 писал на Си и perl, в основном под SunOS. C 2005 пошли C++, python, c 2010 почти только С++ и python. В этом году в проект затащили golang. Всегда работал в разработке системного софта, демоны, утилиты, а также ядра linux и solaris. И повторю, управление памятью в C и C++ это одна из самых тривиальных вещей в программировании. Например, чуваки иногда славливали утечку памяти, в софте, написанном на ЯП-е с GC, вот это сложно, отлавливать утечку памяти в GC. Или сейчас появился golang с его гороутинами-вангую кучу проблем у чуваков с утечками ресурсов на проектах, сложнее примитивных утилит, и отлавливание этих утечек будет сложнее, чем управление памятью с C/C++.
Re[7]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 06.09.18 12:34
Оценка: +1
Здравствуйте, smeeld, Вы писали:

S>И повторю, управление памятью в C и C++ это одна из самых тривиальных вещей в программировании.


Чего только на заборах в Интернетах не пишут...
Re[8]: Go язык прёт?
От: smeeld  
Дата: 06.09.18 12:40
Оценка:
Здравствуйте, so5team, Вы писали:

S>Чего только на заборах в Интернетах не пишут...


Но для кого-то это сложно, да. Таких и golang, кстати, не спасёт.
Re[9]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 06.09.18 12:47
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Но для кого-то это сложно, да.


Есть мнение, что это сложно для всех, кроме вас.

S>Таких и golang, кстати, не спасёт.


Практика показывает, что стоит только пересадить человека с C++ на Java, C# или go, как написанный им код перестает жрать память и падает гораздо реже. И даже когда падает, то быстро становится понятно, где и из-за чего.

Но это субъективное мнение, основанное на субъективных же наблюдениях. Разве этому можно верить?
Re[10]: Go язык прёт?
От: smeeld  
Дата: 06.09.18 13:03
Оценка:
Здравствуйте, so5team, Вы писали:

S>Есть мнение, что это сложно для всех, кроме вас.


Ну ok, любое мнение имеет право на существование.
Re[19]: Go язык прёт?
От: Cyberax Марс  
Дата: 06.09.18 23:49
Оценка:
Здравствуйте, ·, Вы писали:

·>Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться.

В том же Go — обычный (легковесный) стек без особой магии.
Sapienti sat!
Re[19]: Go язык прёт?
От: Cyberax Марс  
Дата: 06.09.18 23:57
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Для полей основного класса как правило передается сам объект, а не поля. Так, что не вижу в чем взрыв?

Представим, что у нас парсер SIP. Тогда естественно каждый уровень обработки сделать в своём классе отдельно и асинхронно. Получится что-то типа:
async Action* ParseSIPPacket(FrameSource f) {
   udpPacket = parseUdpPacket(f)
   // Parse SIP packet
...
}

async UDPPacket* ParseUDPPacket(FrameSource f) {
   ipPacket = parseIPPacket(f)
   // Parse UDP packet
...
}

async IPPacket* ParseIPPacket(FrameSource f) {
   ipPacket = parseEthPacket(f)
   // Parse IP packet
...
}

async EthPacket* ParseEthPacket(FrameSource f) {
    int packetLen = readPacketLen(f) //Might block
    char buf[packetLen];
    for(int i=0; i<packetLen; ++i) buf[i] = f.readByte(); //Might block

    return new EthPacket(buf);
}


Вот тут и начинаются варианты:
1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
2) Проходить все уровни вложения каждый раз при вызове асинхронной функции.
Sapienti sat!
Re[16]: stackful\stackless и потоки
От: Sharov Россия  
Дата: 07.09.18 10:01
Оценка:
Здравствуйте, Jack128, Вы писали:

J>Нет. В том то и фича, что в stackfull варианте код выглядит как абсолютно синхронный, никаких тасков нету. Один минус, рантайм должен поддерживать подобную подмену стека.


Еще вопрос относительно потоков и stackful\stackless -- в обоих случаях работает один физический поток (корутины) или же в сл. stackless(stackful?) их будет больше одного?
Кодом людям нужно помогать!
Re[20]: Go язык прёт?
От: Sharov Россия  
Дата: 07.09.18 10:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Представим, что у нас парсер SIP. Тогда естественно каждый уровень обработки сделать в своём классе отдельно и асинхронно. Получится что-то типа:

C>
C>async Action* ParseSIPPacket(FrameSource f) {
C>   udpPacket = parseUdpPacket(f)
C>   // Parse SIP packet
C>...
C>}

C>async UDPPacket* ParseUDPPacket(FrameSource f) {
C>   ipPacket = parseIPPacket(f)
C>   // Parse UDP packet
C>...
C>}

C>async IPPacket* ParseIPPacket(FrameSource f) {
C>   ipPacket = parseEthPacket(f)
C>   // Parse IP packet
C>...
C>}

C>async EthPacket* ParseEthPacket(FrameSource f) {
C>    int packetLen = readPacketLen(f) //Might block
C>    char buf[packetLen];
C>    for(int i=0; i<packetLen; ++i) buf[i] = f.readByte(); //Might block

C>    return new EthPacket(buf);
C>}
C>


C>Вот тут и начинаются варианты:

C>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).

Почему должен быть взрыв?
Кодом людям нужно помогать!
Re[21]: Go язык прёт?
От: Cyberax Марс  
Дата: 07.09.18 12:17
Оценка:
Здравствуйте, Sharov, Вы писали:

C>>Вот тут и начинаются варианты:

C>>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
S>Почему должен быть взрыв?
Потому, что в одном методе должны быть скомбинированы все состояния из всех Parse-методов.

В данном примере это не так много, но легко представить случаи, когда оно может экспоненциально взорваться.
Sapienti sat!
Re[20]: Go язык прёт?
От: · Великобритания  
Дата: 07.09.18 12:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>·>Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться.

C>В том же Go — обычный (легковесный) стек без особой магии.
И это там утечки подпрограмм, да?
Можешь объяснить детали на пальцах, что там такое? Ну или хотя бы ссылочку...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.09.18 13:59
Оценка: -1
Здравствуйте, Artem Korneev, Вы писали:

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


AK>За много лет — ни разу не приходилось.

AK>Если вы возвращаете какой-то JS-код из REST API-сервисов, то у вас что-то фундаментально не так с архитектурой.
Я не занимаюсь вэбом. Но часто приходится грабить сайты. И там многого насмотришься.
Но суть в том, что JS используется везде, в том числе и для получения динамических контролов со свои JS кодом для обработки событий.

S>>Другое дело SPA. Там тебе действительно не нужно знать JS.


AK>REST бэк-енду вообще все равно, что там на фронт-енде. Там может быть SPA, там может быть мобильное приложение, или какой-то другой сервис, который запросил эти данные.

AK>Если у вас бэкенд зависит от фронтенда, то вы на ровном месте нашли себе грабли.
Поэтому народ и идет в направлении SPA. Но он только начал этот путь. Поэтому всякие SMS с ПХП впереди планеты всей

AK>>>Я видел фронт-енд команды в нескольких компаниях. Они по количеству были не очень большими. Буквально, один синьор-тимлид и один-два джуниора.

S>> А по поводу "фронт-енд команды" смотрим на развитие Ангулара, и у меня большие сомнения в твоих утверждениях.

AK>А что с Angular такого специфического? Он вроде упрощает разработку, а не усложняет ее. Код на TypeScript хотя бы можно читать без поллитры.


Ангулар как раз это SPA. И действительно TypeScript во многих вещах даже поинтереснее C#.
Кстати если в опросах TypeScript занимает высокие место (20%) то на Tiobe он вообще отсутствует https://www.tiobe.com/tiobe-index/
и солнце б утром не вставало, когда бы не было меня
Re[20]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.09.18 14:06
Оценка:
Здравствуйте, Cyberax, Вы писали:



C>Вот тут и начинаются варианты:

C>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
C>2) Проходить все уровни вложения каждый раз при вызове асинхронной функции.

Каждый метод это класс со своим автоматом.
Также сделано и для итераторов.
1. вариант это аналог инлайнинга, но не думаю, что для асинхронных вычислений это актуально.

yeld уже 13 лет. И они показали свою эффективнось
и солнце б утром не вставало, когда бы не было меня
Re[21]: Go язык прёт?
От: Cyberax Марс  
Дата: 08.09.18 03:27
Оценка:
Здравствуйте, ·, Вы писали:

C>>В том же Go — обычный (легковесный) стек без особой магии.

·>И это там утечки подпрограмм, да?
Они возможны, но достаточно редкие.

·>Можешь объяснить детали на пальцах, что там такое? Ну или хотя бы ссылочку...

Каналы и сопроцессы.

Т.е. факториал будет:
// Создаём канал для вывода
var output = make(chan int64)

// "Запускаем" генератор
go func() {
   for i := 0; i < 10; i++ {
       output <- i // Возвращаем значение
   }
   close(output)
} ()

// В основном потоке читаем
for {
  val, ok := <- output
  if !ok {
     break
  }
  print(val)
}


Планировщик Go автоматически переключает лёгкие потоки, когда они блокируются (в этом примере при записи в канал).

Так как потоки реальные и имеют реальный стек, то они, в целом, получаются более дорогими, чем stackless coroutines. С другой стороны, если нужен реальный параллелизм (например, в сетевом сервисе), то они выигрывают.
Sapienti sat!
Re[21]: Go язык прёт?
От: Cyberax Марс  
Дата: 08.09.18 03:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

C>>Вот тут и начинаются варианты:

C>>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
C>>2) Проходить все уровни вложения каждый раз при вызове асинхронной функции.
S> Каждый метод это класс со своим автоматом.
См. выделенное.

S> Также сделано и для итераторов.

S>1. вариант это аналог инлайнинга, но не думаю, что для асинхронных вычислений это актуально.
S>yeld уже 13 лет. И они показали свою эффективнось
Вот не особо. Обычные stackless yield хорошо помогают в ограниченном наборе случаев, когда не нужна глубокая рекурсия.

Если их использовать, скажем, для реализации сложного сетевого сервера — начинаются проблемы.
Sapienti sat!
Re[19]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 08.09.18 09:51
Оценка: 10 (1)
Здравствуйте, ·, Вы писали:

·>Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться.


Нет, в случае stackful как раз и будет (в большинстве реализаций) самый обычный классический стэк, причём железный, то есть будет использоваться регистр SP (stack pointer, ESP, RSP), и машинные инструкции для манипулирования им — call, ret, push, pop — то есть машинный код внутри stackful сопроцедуры не будет ничем отличаться от обычного.
Вся "магия" происходит в месте yield/await — при переключении на другую сопроцедуру сохраняются регистры текущей и восстанавливаются регистры целевой, включая Stack Pointer и Instruction Pointer — в результате чего и происходит переключение стека и передача управления.
Механизм практически такой же как и с обычными потоками — у каждого потока свой стэк, и у каждой stackful сопроцедуры свой стэк. Можно даже сэмулировать сопроцедуры на потоках — пусть и неэффективно, но крякать будет точно также.

·>А с генерацией это будут не области, а члены класса для каждой захваченной переменной.


Со stackless сопроцедурами будет сохранён только один фрейм (не суть каким образом), поэтому и нельзя прозрачно yield'ануть из нижележащих фреймов (они-то не сохраняются автоматом).

У stackless и stackful есть свои преимущества и недостатки.
Re[20]: Go язык прёт?
От: · Великобритания  
Дата: 08.09.18 12:35
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться.

EP>Нет, в случае stackful как раз и будет (в большинстве реализаций) самый обычный классический стэк, причём железный, то есть будет использоваться регистр SP (stack pointer, ESP, RSP), и машинные инструкции для манипулирования им — call, ret, push, pop — то есть машинный код внутри stackful сопроцедуры не будет ничем отличаться от обычного.
EP>Вся "магия" происходит в месте yield/await — при переключении на другую сопроцедуру сохраняются регистры текущей и восстанавливаются регистры целевой, включая Stack Pointer и Instruction Pointer — в результате чего и происходит переключение стека и передача управления.
EP>Механизм практически такой же как и с обычными потоками — у каждого потока свой стэк, и у каждой stackful сопроцедуры свой стэк. Можно даже сэмулировать сопроцедуры на потоках — пусть и неэффективно, но крякать будет точно также.
Ок. Понятно. Но ведь получается, что нам нужно менять SP на некое значение — некий указатель на захваченный фрейм стека. Т.е. у нас где-то должна быть некая структура, которая содержит кучу этих фреймов.. memory heap? Потом ещё непонятно как там будут обстоять дела с очисткой, garbage collector?
Т.е. по сути с т.з. CPU лишь в одном разница — какой регистр меняется SP или какой-нибудь другой, общего назначения. Верно?

EP>·>А с генерацией это будут не области, а члены класса для каждой захваченной переменной.

EP>Со stackless сопроцедурами будет сохранён только один фрейм (не суть каким образом), поэтому и нельзя прозрачно yield'ануть из нижележащих фреймов (они-то не сохраняются автоматом).
EP>У stackless и stackful есть свои преимущества и недостатки.
Как я понял, полноценная альтернатива stackless это лямбды, continuation passing с захватом стековых значений внутрь объектов. Верно?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 13:20
Оценка:
Здравствуйте, _Cyber_, Вы писали:

S>>Вы явно ошиблись выбором профессии. ЯП-ы тут не причём. Прикол, но другим (большинству) как раз в кайф и ООП, и новые ЯП-ы, и всё прочее.

_C_>Так в том то и дело, что я не проф. программер

Это уже все поняли

_C_>, а всего лишь инженер, широкого профиля, и электронику на МК разрабатываю, и параллельные вычисления немного, и машинное обучение собираюсь.

_C_>Мы же говорим о массовости ЯП, так вот, массовый ЯП должен быть понятен сходу таким как я или студентам первашам.

Зачем?

_C_> Им ваше ООП нах не нужно, чтоб написать первую программку.


Для них есть специальные языки, некоторые даже популярны.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 13:35
Оценка: 10 (1) +1
Здравствуйте, Serginio1, Вы писали:

S>Для полей основного класса как правило передается сам объект, а не поля. Так, что не вижу в чем взрыв?


Взрыва нет, потому что компилятор тупой, и вложенные yield не понимает, генеря на каждый метод свой независимый автомат.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 13:35
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В данном примере это не так много, но легко представить случаи, когда оно может экспоненциально взорваться.


Есть отдельная теорема на эту тему. У Кнута вроде было.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[21]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 13:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>yeld уже 13 лет. И они показали свою эффективнось


И неэффективность. К примеру, как то раз в Решарпере производилась глобальная вычистка линка из кода. Как раз из-за тормозов при длинных цепочках итераторов.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 13:35
Оценка:
Здравствуйте, ·, Вы писали:

·> Взрывы откуда? Из-за необходимости типизировать каждую область захваченных локальных переменных?


Построенный в лоб НКА неэффективно выполняется на железе, а алгоритм построения ДКА в некоторых случаях дает экспоненциальный рост состояний. К примеру, довольно несложный код вполне может породить ДКА с 2М состояний на ровном месте.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[20]: Go язык прёт?
От: Sharov Россия  
Дата: 08.09.18 14:23
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:


НС> К примеру, довольно несложный код вполне может породить ДКА с 2М состояний на ровном месте.


А можно пример кода?
Кодом людям нужно помогать!
Re[21]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 14:31
Оценка:
Здравствуйте, Sharov, Вы писали:

НС>> К примеру, довольно несложный код вполне может породить ДКА с 2М состояний на ровном месте.

S>А можно пример кода?

Нельзя. Нет у меня под рукой. Почитай Кнута про ДКА, у него есть про экспоненциальный взрыв состояний.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[21]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 08.09.18 16:32
Оценка: 8 (1)
Здравствуйте, ·, Вы писали:

EP>>Вся "магия" происходит в месте yield/await — при переключении на другую сопроцедуру сохраняются регистры текущей и восстанавливаются регистры целевой, включая Stack Pointer и Instruction Pointer — в результате чего и происходит переключение стека и передача управления.

EP>>Механизм практически такой же как и с обычными потоками — у каждого потока свой стэк, и у каждой stackful сопроцедуры свой стэк. Можно даже сэмулировать сопроцедуры на потоках — пусть и неэффективно, но крякать будет точно также.
·>Ок. Понятно. Но ведь получается, что нам нужно менять SP на некое значение

Да, когда мы yield'аем или await'ем — нам нужно вернуть управление, переключить контекст. Для этого нужно загрузить в регистры, включая SP, состояние того контекста в который мы переключаемся/возвращаемся.
Например если у нас есть основной код который ждёт от генератора значений, то внутри генератора yield statement должен возвращать управление основному коду.

·>- некий указатель на захваченный фрейм стека.


Указатель на весь стек.
(фрейм стека это только часть стека, соответствующая одному вызову функции. В стеке как правило хранится множество фреймов)

·>Т.е. у нас где-то должна быть некая структура, которая содержит кучу этих фреймов.. memory heap?


Для каждой stackful корутины где-то должен хранится её стэк, точно также как и для обычных потоков — у них у каждого тоже есть стек.
Стек потока или сопроцедуры это просто непрерывный кусок памяти (правда бывают ещё сегментированные стеки, но это другая история).

·>Потом ещё непонятно как там будут обстоять дела с очисткой, garbage collector?


Зависит от языка и используемого подхода. Если брать C++ то можно использовать те же самые механизмы что и для обычной памяти — RAII, GC, no-op free и т.д.
Пример RAII:
#include <boost/coroutine2/all.hpp>
#include <iostream>

int main()
{    
    using namespace boost::coroutines2;

    coroutine<int>::pull_type coro([](auto &yield)
    {
        for(int i=0; i!=10; ++i)
            yield(i);
        for(int j=5; j!=0; --j)
            yield(j);
    });

    for(auto x : coro)
        std::cout << x << " ";
}

LIVE DEMO

·>Т.е. по сути с т.з. CPU лишь в одном разница — какой регистр меняется SP или какой-нибудь другой, общего назначения. Верно?


Не понял вопроса. Разница между чем и чем?

EP>>·>А с генерацией это будут не области, а члены класса для каждой захваченной переменной.

EP>>Со stackless сопроцедурами будет сохранён только один фрейм (не суть каким образом), поэтому и нельзя прозрачно yield'ануть из нижележащих фреймов (они-то не сохраняются автоматом).
EP>>У stackless и stackful есть свои преимущества и недостатки.
·>Как я понял, полноценная альтернатива stackless это лямбды, continuation passing с захватом стековых значений внутрь объектов. Верно?

Эта альтернатива только с той позиции, что используя лямбды можно решить те же задачи что решаются посредством stackless. Само решение будет структурно другим, будет иметь другие характеристики, другие объекты, другой memory layout, другой машинный код и т.п.

Если на пальцах, не вдаваясь в детали, то stackless работают следующим образом. Есть код вида:
auto generator()
{
    for(int i=0; i!=10; ++i)
        yield i;
    for(int j=5; j!=0; --j)
        yield j;
}

Под капотом компилятор преобразовывает его во что-то типа:
class Generator
{
    int i, j;
    int state = 0;
public:
    optional<int> operator()()
    {
        switch(state)
        {
            case 0:
                for(i=0; i!=10; ++i)
                {
                    state = 1;
                    return i;
            case 1:;
                }
                state = 2;
            case 2:
                for(j=5; j!=0; --j)
                {
                    state = 3;
                    return j;
            case 3:;
                }
                state = 4;
            case 4:;
        }
        return {};
    }
};

LIVE DEMO
Из функции генератора создаётся класс, локальные переменные функции переходят в поля генератора, тело функции нарезается на автомат и становится методом класса. Номер текущего состояния автомата хранится в поле класса. При вызове метода сразу делается переход на текущее состояние. При yield/await — сохраняется номер состояния в которое должны вернуться при следующем заходе.
Re[5]: Go язык прёт?
От: _Cyber_ Россия  
Дата: 08.09.18 18:45
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, _Cyber_, Вы писали:


_C_>>, а всего лишь инженер, широкого профиля, и электронику на МК разрабатываю, и параллельные вычисления немного, и машинное обучение собираюсь.

_C_>>Мы же говорим о массовости ЯП, так вот, массовый ЯП должен быть понятен сходу таким как я или студентам первашам.

НС>Зачем?

Ааа, ну тогда понятно, проф. программисты изобретают более сложные ЯП, чтоб стать еще более проф-м программатором. И не о каком удобстве и повышении производительности труда в массовом выражении говорить нет смысла.

_C_>> Им ваше ООП нах не нужно, чтоб написать первую программку.


НС>Для них есть специальные языки, некоторые даже популярны.

Да, но тенденция к усложнению, а не к удобству.
Re[2]: Go язык прёт?
От: Слава  
Дата: 08.09.18 18:53
Оценка:
Здравствуйте, _Cyber_, Вы писали:

_C_>Например, сейчас нужен язык для параллельных вычислений, который бы полностью освободил программиста от семафоров, барьеров, ..., чтоб не нужно было даже о них задумываться. Даже понятия о потоках не должно быть. Создал цикл, а он по возможности сам в отделом потоке работает. Естественно синтаксис изменится, это будет текст в несколько столбцов или графическое что-то, типа labview, но более компактное и читабельное.


Такой язык есть, называется он Chapel. Пользуются им три с половиной человека.
Re[2]: Go язык прёт?
От: AntoxaM  
Дата: 08.09.18 19:55
Оценка:
Здравствуйте, _Cyber_, Вы писали:

_C_>Здравствуйте, Тёмчик, Вы писали:


Тё>>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?

_C_>...Сделайте графический IDE для удобства чтения, типа Labview + Cи. ....
Labview — это удобно и понятно???? хорошо не дракон
Re[3]: Go язык прёт?
От: _Cyber_ Россия  
Дата: 08.09.18 20:34
Оценка:
Здравствуйте, AntoxaM, Вы писали:

AM>Labview — это удобно и понятно???? хорошо не дракон

Labview очень далек от идеала, но это хоть какой-то прогресс, по сравнению с текстовыми редакторами, в плане развития IDE.
Re[6]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 20:36
Оценка:
Здравствуйте, _Cyber_, Вы писали:

НС>>Зачем?

_C_>Ааа, ну тогда понятно, проф. программисты изобретают более сложные ЯП, чтоб стать еще более проф-м программатором.

Нет, чтобы решать все более сложные задачи все эффнктивнее.

_C_> И не о каком удобстве и повышении производительности труда в массовом выражении говорить нет смысла.


Профессиональные инструменты не всегда подходят любителям, увы.
Re[7]: Go язык прёт?
От: AlexRK  
Дата: 08.09.18 20:52
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

_C_>>Ааа, ну тогда понятно, проф. программисты изобретают более сложные ЯП, чтоб стать еще более проф-м программатором.


НС>Нет, чтобы решать все более сложные задачи все эффнктивнее.


C# был изобретен, чтобы решать более сложные задачи, чем С++, причем более эффективным образом?
Re[8]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 08.09.18 21:01
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

НС>>Нет, чтобы решать все более сложные задачи все эффнктивнее.

ARK>C# был изобретен, чтобы решать более сложные задачи, чем С++, причем более эффективным образом?

Что, пуканчик зачесался?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 06:50
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Нет, чтобы решать все более сложные задачи все эффнктивнее.

ARK>>C# был изобретен, чтобы решать более сложные задачи, чем С++, причем более эффективным образом?

НС>Что, пуканчик зачесался?


Что, твоя «умная теория» дала трещину?
Re[10]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 07:51
Оценка:
Здравствуйте, AlexRK, Вы писали:

НС>>Что, пуканчик зачесался?

ARK>Что, твоя «умная теория» дала трещину?

Нет. А вот твой пукан — да.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 08:02
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Что, пуканчик зачесался?

ARK>>Что, твоя «умная теория» дала трещину?

НС>Нет.


Оно и видно.

НС>А вот твой пукан — да.


Ты уделяешь моему пукану подозрительно много внимания.
Re[12]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 12:22
Оценка:
Здравствуйте, AlexRK, Вы писали:

НС>>Нет.

ARK>Оно и видно.
НС>>А вот твой пукан — да.
ARK>Ты уделяешь моему пукану подозрительно много внимания.

Это ты с баттхертом сюда прибежал, не я.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[13]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 13:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ARK>>Ты уделяешь моему пукану подозрительно много внимания.


НС>Это ты с баттхертом сюда прибежал, не я.


Не, всё было не так. Ты сказал глупость, я указал тебе на это, а ты решил мне рассказать про какой-то баттхерт.
Re[14]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 13:36
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>>>Ты уделяешь моему пукану подозрительно много внимания.

НС>>Это ты с баттхертом сюда прибежал, не я.
ARK>Не, всё было не так.

Все было именно так.

ARK> Ты сказал глупость


Обоснуй сперва.

ARK>, я указал тебе на это


Не, у тебя, судя по тону и количеству смайликов, мощно полыхнуло.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[15]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 13:47
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ARK>> Ты сказал глупость

НС>Обоснуй сперва.

Ход обсуждения:

массовый ЯП должен быть понятен сходу таким как я или студентам первашам

Зачем?

проф. программисты изобретают более сложные ЯП, чтоб стать еще более проф-м программатором

Нет, чтобы решать все более сложные задачи все эффнктивнее


Много какие языки, в том числе C#, были изобретены вовсе не для того, чтобы решать все более сложные задачи.

ARK>>, я указал тебе на это

НС>Не, у тебя, судя по тону и количеству смайликов, мощно полыхнуло.

А, ты ясновидящий, я забыл.
Re[16]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 14:05
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Много какие языки, в том числе C#, были изобретены вовсе не для того, чтобы решать все более сложные задачи.


О как. А для чего?

ARK>>>, я указал тебе на это

НС>>Не, у тебя, судя по тону и количеству смайликов, мощно полыхнуло.
ARK>А, ты ясновидящий, я забыл.

Тут не надо быть ясновидящим. Все твое последующее поведение только подтверждает мою догадку.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[17]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 15:14
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ARK>>Много какие языки, в том числе C#, были изобретены вовсе не для того, чтобы решать все более сложные задачи.


НС>О как. А для чего?


Чтобы дать возможность решать некоторые (далеко не все) задачи программистам более низкой квалификации, чем потребной для того же Ц++. Повышение эффективности с точки зрения бизнеса. То же самое относится к Java/Swift/etc.

А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи.

Единственный язык из недавних, что я могу вспомнить, который действительно позволяет делать более сложные вещи, чем это было до него (да и этот факт многими не признается) — это руст.
Re[18]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 16:28
Оценка:
Здравствуйте, AlexRK, Вы писали:

НС>>О как. А для чего?

ARK>Чтобы дать возможность решать некоторые (далеко не все) задачи программистам более низкой квалификации, чем потребной для того же Ц++.

Обосновать сможешь?

ARK> Повышение эффективности с точки зрения бизнеса.


О, значит таки повышение эффективность.

ARK>А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи.


Нет, не для того. И?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 16:54
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>О как. А для чего?

ARK>>Чтобы дать возможность решать некоторые (далеко не все) задачи программистам более низкой квалификации, чем потребной для того же Ц++.

НС>Обосновать сможешь?


Вот слова Хейлсберга:

https://habr.com/post/314616/

Мы решили создать упрощенную версию С++, чтобы повысить производительность труда разработчиков.


Разумеется, он не скажет — "я сделал C# для дураков".

Однако, более простая вещь является:
1) Более доступной, то есть более простой вещью может пользоваться большее число людей, и требования к интеллекту этих людей — ниже.
2) В общем случае — более ограниченной, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).

ARK>> Повышение эффективности с точки зрения бизнеса.

НС>О, значит таки повышение эффективность.

Эффективность бизнеса, а не программиста. И не решение сложных задач, которые без С# эффективно не решить.

Не, если под "задачами" понимаются не задачи программирования, а задачи бизнеса, то всё, конечно, меняется.

ARK>>А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи.

НС>Нет, не для того. И?

Ну, собственно, твое заявление верно только для очень малого числа языков.
Re[20]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 17:28
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>https://habr.com/post/314616/

ARK>

Мы решили создать упрощенную версию С++, чтобы повысить производительность труда разработчиков.


Т.е. ровно то, о чем написал и я. ЧТД.

ARK>Разумеется, он не скажет — "я сделал C# для дураков".


Зато тебе, я смотрю, очень хочется это сказать. Ну как же, ты ведь С++ освоил, правда?

ARK>Однако, более простая вещь является:

ARK>1) Более доступной, то есть более простой вещью может пользоваться большее число людей, и требования к интеллекту этих людей — ниже.

Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику?

ARK>2) В общем случае — более ограниченной


Обоснуй.

ARK>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).


А он ниже?

ARK>>> Повышение эффективности с точки зрения бизнеса.

НС>>О, значит таки повышение эффективность.
ARK>Эффективность бизнеса, а не программиста.

А это одно и тоже, когда мы о коммерческом программировании говорим.

ARK> И не решение сложных задач, которые без С# эффективно не решить.


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

ARK>Не, если под "задачами" понимаются не задачи программирования, а задачи бизнеса, то всё, конечно, меняется.


Прекрасная демонстрация, чо. Мне даже нечего добавить к картинке.

ARK>>>А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи.

НС>>Нет, не для того. И?
ARK>Ну, собственно, твое заявление верно только для очень малого числа языков.

Мое заявление верно для мейнстрима. На иное я и не претендовал.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[21]: Go язык прёт?
От: AlexRK  
Дата: 09.09.18 18:00
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Зато тебе, я смотрю, очень хочется это сказать. Ну как же, ты ведь С++ освоил, правда?


Нет, ты хреновый телепат. И С++ я знаю довольно скверно. И моя персона вообще не имеет отношения к теме.

ARK>>Однако, более простая вещь является:

ARK>>1) Более доступной, то есть более простой вещью может пользоваться большее число людей, и требования к интеллекту этих людей — ниже.

НС>Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику?


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

ARK>>2) В общем случае — более ограниченной

НС>Обоснуй.

По-моему, это очевидно. Более простая в использовании вещь в общем случае имеет меньшее число возможностей взаимодействия с ней (по определению простоты). Если сложная вещь спроектирована более-менее разумно, то большее число возможностей взаимодействия будет использовано для достижения бОльшего числа вариантов использования.

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

ARK>>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).

НС>А он ниже?

У C# безусловно ниже, чем у С++. У сишарпа он, собственно, вообще весьма узкий. Если, конечно, рассматривать разные классы задач. В абсолютных величинах даже одна задача "быдлокодить внутренние системы предприятий" будет довольно большой по размеру.

ARK>>Эффективность бизнеса, а не программиста.

НС>А это одно и тоже, когда мы о коммерческом программировании говорим.

С точки зрения владельца бизнеса — одно и то же. С точки зрения программиста — это не очевидно.

ARK>> И не решение сложных задач, которые без С# эффективно не решить.

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

eao197 с тобой не согласится.

ARK>>Ну, собственно, твое заявление верно только для очень малого числа языков.

НС>Мое заявление верно для мейнстрима. На иное я и не претендовал.

Твое заявление для мейнстрима верно только в той части, где говорится про эффективность, при условии дополнительного ограничения, что под словом "эффективность" понимается эффективность с точки зрения бизнеса.
Re[22]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 09.09.18 21:46
Оценка:
Здравствуйте, AlexRK, Вы писали:

НС>>Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику?

ARK>Это у тебя кривая логика. На машине НЕ проще доехать, на ней быстрее доехать, что совершенно не одно и то же. Ты подменил понятия.

Это ты подменил. В русском языке можно сказать вместо быстрее — проще. То же самое и в случае шарпа.

ARK>>>2) В общем случае — более ограниченной

НС>>Обоснуй.
ARK>По-моему, это очевидно.

Нет.

ARK> Более простая в использовании вещь в общем случае имеет меньшее число возможностей взаимодействия с ней


Нет. Тем более что речь не об общем, а о конкретном, и твои высосанные из пальца сомнительные обобщения доказательной силы не имеют.

ARK> (по определению простоты).


Определение в студию. Полное.

ARK> Если сложная вещь спроектирована более-менее разумно


А если нет?

ARK>>>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).

НС>>А он ниже?
ARK>У C# безусловно ниже, чем у С++

Нет.

ARK>. У сишарпа он, собственно, вообще весьма узкий. Если, конечно, рассматривать разные классы задач. В абсолютных величинах даже одна задача "быдлокодить внутренние системы предприятий" будет довольно большой по размеру.


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

ARK>>>Эффективность бизнеса, а не программиста.

НС>>А это одно и тоже, когда мы о коммерческом программировании говорим.
ARK>С точки зрения владельца бизнеса — одно и то же. С точки зрения программиста — это не очевидно.

Кого волнует мнение программиста, интересы которого противоречат бизнесу? Что за бред?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[23]: Go язык прёт?
От: AlexRK  
Дата: 10.09.18 06:06
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику?

ARK>>Это у тебя кривая логика. На машине НЕ проще доехать, на ней быстрее доехать, что совершенно не одно и то же. Ты подменил понятия.

НС>Это ты подменил. В русском языке можно сказать вместо быстрее — проще. То же самое и в случае шарпа.


Нет, нельзя. Быстрее — не проще, а проще — не быстрее.

НС>Тем более что речь не об общем, а о конкретном, и твои высосанные из пальца сомнительные обобщения доказательной силы не имеют.


Точно так же твои высосанные из пальца рассуждения о новых языках для решения сложных задач доказательной силы не имеют.

ARK>> Если сложная вещь спроектирована более-менее разумно

НС>А если нет?

Ксли нет, то такие вещи я не рассматриваю.

ARK>>>>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).

НС>>>А он ниже?
ARK>>У C# безусловно ниже, чем у С++
НС>Нет.

Да. Один сборщик мусора сразу вычеркивает кучу применений. Операционные системы, коробочный софт, игры, софт для самолетов-машин-марсоходов-роботов, ядра высокопроизводительных серверных систем (трейдинговых, поисковых и т.д.) — нигде здесь C# нет и никогда не будет.

ARK>>. У сишарпа он, собственно, вообще весьма узкий. Если, конечно, рассматривать разные классы задач. В абсолютных величинах даже одна задача "быдлокодить внутренние системы предприятий" будет довольно большой по размеру.

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

Халва, халва.
Re[24]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 10.09.18 07:28
Оценка: :)
Здравствуйте, AlexRK, Вы писали:

ARK>>> Если сложная вещь спроектирована более-менее разумно

НС>>А если нет?
ARK>Ксли нет, то такие вещи я не рассматриваю.

Рассматриваешь. Ты ж ведь про С++ тут вещаешь, верно?

ARK>Да. Один сборщик мусора сразу вычеркивает кучу применений. Операционные системы, коробочный софт, игры, софт для самолетов-машин-марсоходов-роботов, ядра высокопроизводительных серверных систем (трейдинговых, поисковых и т.д.) — нигде здесь C# нет и никогда не будет.


Ровно как практически нет С++ в вебе, кроме небольшого количества узкоспециализированных сервисов. Да и с поиском у тебя смешно получилось. В сегменте локальных поисковых сервисов однозначный лидер — Эластик. Ну и ELK на его основе для логов. А он, о ужас, на джаве писан, а вовсе не на С++.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 07:54
Оценка:
Здравствуйте, AlexRK, Вы писали:

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


ARK>eao197 с тобой не согласится.


eao197 сказал, что по поводу асинхронного и веб-ориентированного более релевантна вот эта ссылка.
Re[23]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 10:03
Оценка:
Здравствуйте, so5team, Вы писали:

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

ARK>>eao197 с тобой не согласится.

от 2M msg/sec при обмене сообщениями между разными нитями

Что так медленно-то? На блокировках поди всё?
Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[20]: Go язык прёт?
От: Sharov Россия  
Дата: 10.09.18 10:10
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

Ключевой момент для моегом понимания:

EP>Со stackless сопроцедурами будет сохранён только один фрейм (не суть каким образом), поэтому и нельзя прозрачно yield'ануть из нижележащих фреймов (они-то не сохраняются автоматом).


Наверное надо так: прозрачно yield'ануть в нижележащие фреймы . Не сохраняются же нижележацие фреймы.
Кодом людям нужно помогать!
Re[24]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 10:11
Оценка:
Здравствуйте, ·, Вы писали:

·>

от 2M msg/sec при обмене сообщениями между разными нитями

·>Что так медленно-то? На блокировках поди всё?

Конечно. Да еще и в режиме пинг-понга одиночными сообщениями.

·>Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности...


Если бы там был еще обмен сообщениями...
Re[25]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 10:19
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>

от 2M msg/sec при обмене сообщениями между разными нитями

S>·>Что так медленно-то? На блокировках поди всё?
S>Конечно.
Не надо использовать блокировки в высокопроизводительных системах.

S>Да еще и в режиме пинг-понга одиночными сообщениями.

Если батчами, то там ещё быстрее.

Disruptor has an explicit batching API on the publisher side that can give over 100 million messages per second.


S>·>Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности...

S>Если бы там был еще обмен сообщениями...
Так это оно и есть:

A simple ping-pong algorithm will be used to signal from one to the other and back again

но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 10:24
Оценка:
Здравствуйте, ·, Вы писали:

·> Не надо использовать блокировки в высокопроизводительных системах.


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

S>>Да еще и в режиме пинг-понга одиночными сообщениями.

·>Если батчами, то там ещё быстрее.
·>

Disruptor has an explicit batching API on the publisher side that can give over 100 million messages per second.


Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?

S>>·>Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности...

S>>Если бы там был еще обмен сообщениями...
·>Так это оно и есть:
·>

A simple ping-pong algorithm will be used to signal from one to the other and back again

Там нет обмена сообщениями, там идет взаимный инкремент атомарных переменных двумя конкурирующими потоками на busy wait-инге. К доставке и обработке произвольных сообщений это имеет крайне отдаленное отношение.
Re[27]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 10:43
Оценка:
Здравствуйте, so5team, Вы писали:

S>·> Не надо использовать блокировки в высокопроизводительных системах.

S>Если производительность вашей системы упирается в систему передачи сообщений между рабочими потоками, значит вы что-то делаете сильно не так.
Не упирается, но составляет значительную часть.

S>>>Да еще и в режиме пинг-понга одиночными сообщениями.

S>·>Если батчами, то там ещё быстрее.
S>·>

Disruptor has an explicit batching API on the publisher side that can give over 100 million messages per second.

S>Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?
Оно не дружит с low latency. Вручную набирать bulk-сообщение из 100 мелких — довольно тяжко логически и грозит непредвиденными задержками. Disruptor позволяет потреблять сообщения батчами, публикуемые по мере поступления.

S>·>Так это оно и есть:

S>·>

A simple ping-pong algorithm will be used to signal from one to the other and back again

S>Там нет обмена сообщениями, там идет взаимный инкремент атомарных переменных двумя конкурирующими потоками на busy wait-инге. К доставке и обработке произвольных сообщений это имеет крайне отдаленное отношение.
Это демонстрируется собственно что можно иметь по максимуму. А так https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 11:02
Оценка:
Здравствуйте, ·, Вы писали:

S>>Если производительность вашей системы упирается в систему передачи сообщений между рабочими потоками, значит вы что-то делаете сильно не так.

·>Не упирается, но составляет значительную часть.

По хорошему, Tprocessing должно быть значительно больше, чем Texchange. Если это не так, значит у вас с декомпозицией по рабочим контекстам проблема и то, что вы хотите делать на другой нити, можно сделать на текущей, тем самым совсем избежав коммуникаций.

S>>>>Да еще и в режиме пинг-понга одиночными сообщениями.

S>>·>Если батчами, то там ещё быстрее.
S>>·>

Disruptor has an explicit batching API on the publisher side that can give over 100 million messages per second.

S>>Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?
·>Оно не дружит с low latency. Вручную набирать bulk-сообщение из 100 мелких — довольно тяжко логически и грозит непредвиденными задержками. Disruptor позволяет потреблять сообщения батчами, публикуемые по мере поступления.

Вы уж определитесь, ссылаетесь ли вы на результаты bulk-операций (что и есть тот самый batching), либо оно у вас не дружит с low latency.

S>>·>Так это оно и есть:

S>>·>

A simple ping-pong algorithm will be used to signal from one to the other and back again

S>>Там нет обмена сообщениями, там идет взаимный инкремент атомарных переменных двумя конкурирующими потоками на busy wait-инге. К доставке и обработке произвольных сообщений это имеет крайне отдаленное отношение.
·>Это демонстрируется собственно что можно иметь по максимуму.

По максимуму бесполезности? Обмен int-ами или void* через atomic-и показывает вам предел обмена минимальным объемом информации между двумя нитями. Но когда речь заходит о прикладных сообщениях, то у вас появляется конструирование сообщения, снабжение его мета-информацией, передача сообщения, сохранение его куда-то, извлечение его откуда-то (возможно, не сразу), анализ мета-информации, поиск обработчика, вызов обработчика, контроль успешности обработки (был сбой или нет), утилизация сообщения и мета-информации. 2M msg/sec, к которым вы прицепились -- это вот это все вместе. Раз вы сравниваете эту всю кухню с примитивным бенчмарком на atomic-ах, то это о чем-то да говорит.

·>А так https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results


И? Может вы еще скажете, что Disruptor -- это унивесальный паттерн или даже хотя бы широко использующийся? А может еще вспомните про освежающие перезагрузки, которые раз в сутки делали этому самому Disruptor-у, дабы память не чистить?
Re[29]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 11:34
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>Если производительность вашей системы упирается в систему передачи сообщений между рабочими потоками, значит вы что-то делаете сильно не так.

S>·>Не упирается, но составляет значительную часть.
S>По хорошему, Tprocessing должно быть значительно больше, чем Texchange.
Не "по хорошему", а в некоторых сценариях. А в некоторых это не так.

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

Можно и на текущей, но тогда будет медленнее, т.к. преимущество параллельного исполнения не используется.

S>>>Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?

S>·>Оно не дружит с low latency. Вручную набирать bulk-сообщение из 100 мелких — довольно тяжко логически и грозит непредвиденными задержками. Disruptor позволяет потреблять сообщения батчами, публикуемые по мере поступления.
S>Вы уж определитесь, ссылаетесь ли вы на результаты bulk-операций (что и есть тот самый batching), либо оно у вас не дружит с low latency.
Так batching это на стороне подписчика, для повышения пропускной способности. Latency это не ухудшает.

S>>>·>Так это оно и есть:

S>>>·>

A simple ping-pong algorithm will be used to signal from one to the other and back again

S>>>Там нет обмена сообщениями, там идет взаимный инкремент атомарных переменных двумя конкурирующими потоками на busy wait-инге. К доставке и обработке произвольных сообщений это имеет крайне отдаленное отношение.
S>·>Это демонстрируется собственно что можно иметь по максимуму.
S>По максимуму бесполезности? Обмен int-ами или void* через atomic-и показывает вам предел обмена минимальным объемом информации между двумя нитями. Но когда речь заходит о прикладных сообщениях, то у вас появляется конструирование сообщения, снабжение его мета-информацией, передача сообщения, сохранение его куда-то, извлечение его откуда-то (возможно, не сразу), анализ мета-информации, поиск обработчика, вызов обработчика, контроль успешности обработки (был сбой или нет), утилизация сообщения и мета-информации.
Это всё детали конкретной имплементации. В реальном коде это не необходимость.

S>2M msg/sec, к которым вы прицепились -- это вот это все вместе. Раз вы сравниваете эту всю кухню с примитивным бенчмарком на atomic-ах, то это о чем-то да говорит.

Ну я хотя бы пытаюсь сравнивать с другими системами. А там у вас просто заявляется "2M — это круто!". Но непонятно что значит и почему так мало.

S>·>А так https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results

S>И? Может вы еще скажете, что Disruptor -- это унивесальный паттерн или даже хотя бы широко использующийся?
В принципе довольно таки универсальный. И там где надо — используется успешно. А так и вот тебе акторы: 50M msg/sec. Или вот.

S>А может еще вспомните про освежающие перезагрузки, которые раз в сутки делали этому самому Disruptor-у, дабы память не чистить?

С памятью там azul c4 gc возится.
И не перезагрузки, а snapshotting и всякие другие maintenance tasks, которые могут поломать low latency SLA.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 11:56
Оценка:
Здравствуйте, ·, Вы писали:

·>Не "по хорошему", а в некоторых сценариях. А в некоторых это не так.


Это в каких?


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

·>Можно и на текущей, но тогда будет медленнее, т.к. преимущество параллельного исполнения не используется.

Есть ощущение, что русский для вас не родной. Поскольку было написано, что если у вас затраты на передачу сопоставимы с затратами на обработку, значит обработка у вас настолько дешевая, что делегировать ее кому-то нет смысла. И параллельная обработка начинает иметь смысл только когда у вас обработка дорогая. Но тогда затраты на коммуникацию должны быть маленькими.

S>>Вы уж определитесь, ссылаетесь ли вы на результаты bulk-операций (что и есть тот самый batching), либо оно у вас не дружит с low latency.

·>Так batching это на стороне подписчика, для повышения пропускной способности. Latency это не ухудшает.

Что значит batching на стороне подписчика? Что подписчик сперва накапливает N сообщений, потом скопом их обрабатывает?
Ну и как же это не сказывается на latency, первое сообщение будет ждать, пока придет N-е?

S>>2M msg/sec, к которым вы прицепились -- это вот это все вместе. Раз вы сравниваете эту всю кухню с примитивным бенчмарком на atomic-ах, то это о чем-то да говорит.

·>Ну я хотя бы пытаюсь сравнивать с другими системами.

С какими системами? Как сравнивать? Что-то пока ничего не видно.

·>А там у вас просто заявляется "2M — это круто!".


Где заявляется, что это круто? Цитату, пожалуйста.

·>Но непонятно что значит и почему так мало.


И вместо того, чтобы разобраться, что это означает, вы начинаете кричать "так мало".

S>>·>А так https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results

S>>И? Может вы еще скажете, что Disruptor -- это унивесальный паттерн или даже хотя бы широко использующийся?
·>В принципе довольно таки универсальный.

Пруфы?

·>И там где надо — используется успешно.


Редко он используется. Даже слово Disruptor мало кто знает.

·>А так и вот тебе акторы: 50M msg/sec.


Ну как раз тот самый eao197 разбирал этот бенчмарк: http://eao197.blogspot.com/2015/02/progsobjectizer-50m-msgsec-akka.html
Там речь идет не о скорости обмена между двумя конкурирующими нитями (а это и есть сценарий, при котором получилось 2M msg/sec), а суммарная пропускная способность обмена сообщениями между группами акторов на 48-ядерной машине.

S>>А может еще вспомните про освежающие перезагрузки, которые раз в сутки делали этому самому Disruptor-у, дабы память не чистить?

·>С памятью там azul c4 gc возится.
·>И не перезагрузки, а snapshotting и всякие другие maintenance tasks, которые могут поломать low latency SLA.

В оригинальной статье про LMAX и Disruptor речь шла о том, что JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали.

Если вы еще о чем-то захотите поспорить со взятыми с потолка цифрами, то давайте мы вам сперва простую вещь объясним. Есть универсальные фреймворки. Для C++ это SObjectizer, CAF, QP/C++. Для JVM -- Akka, Vert.x. Для .NET -- Orleans. Универсальность означает, что эти фреймворки могут использоваться для разных задач и разных сценариев.

Наряду с этим есть и специализированные решения, заточенные либо под какой-то сценарий (вроде Disruptor-а), либо под какую-то специфическую задачу и железо.

Так вот, существует очевидная вещь: производительность универсальных фреймворков будет ниже, чем специализированных решений. И это нормально. Т.к. цели у инструментов разные.
Re[31]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 13:44
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>Не "по хорошему", а в некоторых сценариях. А в некоторых это не так.

S>Это в каких?
hft, например, раз уж disruptor упомянут.
А в тех сценариях, где Tprocessing >> Texchange, то какая разница как обмениваться? Пусть хоть голубиной почтой. Непонятно тогда преимущества SO.

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

S>·>Можно и на текущей, но тогда будет медленнее, т.к. преимущество параллельного исполнения не используется.
S>Есть ощущение, что русский для вас не родной. Поскольку было написано, что если у вас затраты на передачу сопоставимы с затратами на обработку, значит обработка у вас настолько дешевая, что делегировать ее кому-то нет смысла. И параллельная обработка начинает иметь смысл только когда у вас обработка дорогая. Но тогда затраты на коммуникацию должны быть маленькими.
Если делегирование даёт преимущество, значит надо делегировать. Это не зависит от дешевизны.

S>>>Вы уж определитесь, ссылаетесь ли вы на результаты bulk-операций (что и есть тот самый batching), либо оно у вас не дружит с low latency.

S>·>Так batching это на стороне подписчика, для повышения пропускной способности. Latency это не ухудшает.
S>Что значит batching на стороне подписчика? Что подписчик сперва накапливает N сообщений, потом скопом их обрабатывает?
Что подписчик в момент получения забирает сколько может забрать.

S>Ну и как же это не сказывается на latency, первое сообщение будет ждать, пока придет N-е?

Никто ничто не ждёт. Допустим, приходят сетевые пакеты в одном треде и складируютсяи в журнал в другм. В журнал можно положить одно сообщение, а можно 100 сразу — время примерно одинаково (буферы, постраничная запись или вроде того). Поэтому, пока мы складировали первое сообщение, могло прийти ещё 50. На следующей итерации мы положим все 50 одним батчем.

S>>>2M msg/sec, к которым вы прицепились -- это вот это все вместе. Раз вы сравниваете эту всю кухню с примитивным бенчмарком на atomic-ах, то это о чем-то да говорит.

S>·>Ну я хотя бы пытаюсь сравнивать с другими системами.
S>С какими системами? Как сравнивать? Что-то пока ничего не видно.
С другими системами обмена сообщениями.

S>·>А там у вас просто заявляется "2M — это круто!".

S>Где заявляется, что это круто? Цитату, пожалуйста.
Ок.. Что "круто" не заявляется. Но цифры даются бессмысленные.

S>·>Но непонятно что значит и почему так мало.

S>И вместо того, чтобы разобраться, что это означает, вы начинаете кричать "так мало".
Ок, рассказывайте, почему так мало. Что вообще означает цифра 2M?

S>>>И? Может вы еще скажете, что Disruptor -- это унивесальный паттерн или даже хотя бы широко использующийся?

S>·>В принципе довольно таки универсальный.
S>Пруфы?
Ээээ. Что вы ожидаете в качестве пруфа? Читайте доки, какие виды взаимодействия там выражаются и сравнивайте, например, с тем что предоставляют другие способы, тот же SObj.

S>·>И там где надо — используется успешно.

S>Редко он используется. Даже слово Disruptor мало кто знает.
Он широко известен в узких кругах. Об SObj знают ещё меньше. Я вот о SObj никогда нигде не слышал, кроме как на этом форуме.

S>·>А так и вот тебе акторы: 50M msg/sec.

S>Ну как раз тот самый eao197 разбирал этот бенчмарк: http://eao197.blogspot.com/2015/02/progsobjectizer-50m-msgsec-akka.html
S>Там речь идет не о скорости обмена между двумя конкурирующими нитями (а это и есть сценарий, при котором получилось 2M msg/sec), а суммарная пропускная способность обмена сообщениями между группами акторов на 48-ядерной машине.
Ну да, непонятно. Честного сравнения похоже никто так и не сделал.

S>>>А может еще вспомните про освежающие перезагрузки, которые раз в сутки делали этому самому Disruptor-у, дабы память не чистить?

S>·>С памятью там azul c4 gc возится.
S>·>И не перезагрузки, а snapshotting и всякие другие maintenance tasks, которые могут поломать low latency SLA.
S>В оригинальной статье про LMAX и Disruptor речь шла о том, что JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали.
Не знаю о какой ты статье говоришь. Теоретически возможно оно так было много лет назад. Сейчас там перезапуск раз в две недели, для выкатывания очередного релиза. Раз в сутки так называемый end-of-day event когда всяческое медленное делается.

S>Если вы еще о чем-то захотите поспорить со взятыми с потолка цифрами, то давайте мы вам сперва простую вещь объясним. Есть универсальные фреймворки. Для C++ это SObjectizer, CAF, QP/C++. Для JVM -- Akka, Vert.x. Для .NET -- Orleans. Универсальность означает, что эти фреймворки могут использоваться для разных задач и разных сценариев.

Хотя бы так. Пусть если бенчмарки и будут, то для сравнения хотя бы среди этих решений.

S>Наряду с этим есть и специализированные решения, заточенные либо под какой-то сценарий (вроде Disruptor-а), либо под какую-то специфическую задачу и железо.

S>Так вот, существует очевидная вещь: производительность универсальных фреймворков будет ниже, чем специализированных решений. И это нормально. Т.к. цели у инструментов разные.
Ок, почти согласен. Но тот же disruptor достаточно универсален, хотя _необходим_ в менее популярных сценариях, а не то что специально заточен под что-то одно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 10.09.18 13:45
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Ключевой момент для моегом понимания:

S>

EP>>Со stackless сопроцедурами будет сохранён только один фрейм (не суть каким образом), поэтому и нельзя прозрачно yield'ануть из нижележащих фреймов (они-то не сохраняются автоматом).

S>Наверное надо так: прозрачно yield'ануть в нижележащие фреймы . Не сохраняются же нижележацие фреймы.

Нет, именно yield'ануть из нижележащих фреймов.
#include <boost/coroutine2/all.hpp>
#include <iostream>

using namespace boost::coroutines2;
using Coro = coroutine<int>;

Coro::push_type *coro = nullptr;

void yield(int x)
{
    (*coro)(x);
}

/************************************************************/

void c()
{
    for(int i=0; i!=10; ++i)
        yield(i);
}

void b()
{
    c();
}

void a()
{
    b();
}

int main()
{    
    coroutine<int>::pull_type xs([](auto &x)
    {
        coro = &x;
        a();
    });

    for(auto x : xs)
        std::cout << x << " ";
}

LIVE DEMO
Здесь фрейм b, находится ниже фрейма a, а фрейм c ниже фрейма b.
Из фрейма с происходит yield, прозрачно для функций a и b.
Со stackless а-я Python/C# так не получится, придётся протаскивать каждое значение и через каждый уровень (и каждую сигнатуру в C#).

Но стоит также заменить, что после yield и передачи управления в main, при ожидании следующего значения происходит передача управления обратно в c (но формально это не yield, а переключение контекста).
Отредактировано 10.09.2018 13:48 Evgeny.Panasyuk . Предыдущая версия .
Re[22]: Go язык прёт?
От: Sharov Россия  
Дата: 10.09.18 14:08
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Со stackless а-я Python/C# так не получится, придётся протаскивать каждое значение и через каждый уровень (и каждую сигнатуру в C#).


Вот не понимаю, чем вышеприведенный код отличается от ентого:
 public class Exec
    {

        public IEnumerable<int> A()
        {
            return B();
        }

        private IEnumerable<int> B()
        {
            return C();
        }

        private IEnumerable<int> C()
        {
            foreach (var i in Enumerable.Range(1,10))
            {
                yield return i;
            }
        }


        public static void Main()
            {

                foreach (var i in new Exec().A())
                {
                    Console.Write(i);
                }

                Console.ReadLine();
       }


Тем, что у нас одинаковая сигнатура у всех методов?
Кодом людям нужно помогать!
Re[32]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 14:15
Оценка:
Здравствуйте, ·, Вы писали:

·>hft, например, раз уж disruptor упомянут.


Вроде как disruptor был сделан для обработки потока ставок на букмекерском сайте. Что здесь общего с HFT не понятно.
Да и сам disruptor, как представляется, стал следствием того, что высокую производительность попытались извлечь из Java.

·>А в тех сценариях, где Tprocessing >> Texchange, то какая разница как обмениваться?


О том и речь. Если у вас прикладная обработка сообщения занимает хотя бы 10ms, то 2M msg/sec вам хватит с большим запасом. А если обработка должна укладываться в 1us, то за желание делегировать обработку на другой поток нужно проверять профпригодность. Или, хотя бы, адекватность выбора технологии и инструментов.

·>Непонятно тогда преимущества SO.


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

·>Если делегирование даёт преимущество, значит надо делегировать. Это не зависит от дешевизны.


Разговариваем о сферических конях в вакууме?

·>Что подписчик в момент получения забирает сколько может забрать.

·>Никто ничто не ждёт. Допустим, приходят сетевые пакеты в одном треде и складируютсяи в журнал в другм. В журнал можно положить одно сообщение, а можно 100 сразу — время примерно одинаково (буферы, постраничная запись или вроде того). Поэтому, пока мы складировали первое сообщение, могло прийти ещё 50. На следующей итерации мы положим все 50 одним батчем.

И какое отношение это имеет к результату честного ping-pong-а между двумя рабочими нитями? Там же весь фокус в том, что когда pinger ждет ответа от ponger-а, то ему делать нечего, его очередь пуста.

S>>С какими системами? Как сравнивать? Что-то пока ничего не видно.

·>С другими системами обмена сообщениями.

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

·>Ок.. Что "круто" не заявляется. Но цифры даются бессмысленные.


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

·>Ок, рассказывайте, почему так мало.


Ok, рассказываете, почему 2M msg/sec на честном ping-pong-е для вас мало. Хотя бы сколько вам нужно?

·>Что вообще означает цифра 2M?


Это означает, что за 1 секунду pinger отослал 1M сигналов ping актору ponger, а тот, в ответ, отослал 1M сигналов pong.
При этом сценарий работы такой: pinger отсылает сообщения и засыпает на пустой очереди, в это время ponger получает сообщение, обрабатывает его, отсылает ответный pong, после чего засыпает на своей пустой очереди. В это время просыпается pinger, обрабатывает pong и отсылает ping, после чего засыпает на своей пустой очереди. И т.д. "Засыпает" -- это условный термин. Фокус в том, что pinger/ponger может продолжить свою работу только когда придет ответ от противоположной стороны.

S>>>>И? Может вы еще скажете, что Disruptor -- это унивесальный паттерн или даже хотя бы широко использующийся?

S>>·>В принципе довольно таки универсальный.
S>>Пруфы?
·>Ээээ. Что вы ожидаете в качестве пруфа?

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

·>Он широко известен в узких кругах. Об SObj знают ещё меньше. Я вот о SObj никогда нигде не слышал, кроме как на этом форуме.


У нас PR сильно слабее. Да и мир JVM гораздо больше сейчас, чем мир C++. И какие-то вещи, которые распространены в мире Java, в C++ не вызывают большого интереса. Вот та же Модель Акторов, например.

·>Ну да, непонятно. Честного сравнения похоже никто так и не сделал.


Кому это интересно и кто обладает достаточными для этого ресурсами пусть делает.
Мы в свое время делали те бенчмарки, которые нам были нужны.

·>Не знаю о какой ты статье говоришь.


Вероятно об одной из самых первых, которая вышла лет 7 или 8 назад.
Re[33]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 14:57
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>hft, например, раз уж disruptor упомянут.

S>Вроде как disruptor был сделан для обработки потока ставок на букмекерском сайте. Что здесь общего с HFT не понятно.
Да, на самой заре, а потом это fx биржа.

S>Да и сам disruptor, как представляется, стал следствием того, что высокую производительность попытались извлечь из Java.

Эээ. И что? Успешно же, извлекли.

S>·>А в тех сценариях, где Tprocessing >> Texchange, то какая разница как обмениваться?

S>О том и речь. Если у вас прикладная обработка сообщения занимает хотя бы 10ms, то 2M msg/sec вам хватит с большим запасом. А если обработка должна укладываться в 1us, то за желание делегировать обработку на другой поток нужно проверять профпригодность. Или, хотя бы, адекватность выбора технологии и инструментов.
На биржах в среднем порядка 300us вопрос-ответ, а не обработка одного сообщения. 10ms это уже production incident, всех на уши поднимают.

S>·>Непонятно тогда преимущества SO.

S>Как и у любого другого универсального фреймворка: снижение стоимости разработки и поддержки ценой производительности. Хотя, для выжимания максимальной производительности нужны и руки и знания, что есть не у всех.
Может я слишком скептик, но пока даже сравнив с java — стоимость разработки и поддержки ниже практически любого C++-решения.

S>·>Если делегирование даёт преимущество, значит надо делегировать. Это не зависит от дешевизны.

S>Разговариваем о сферических конях в вакууме?
А "делегировать ее кому-то нет смысла" это о сфероконях или о чём? Я лично о руках и знании.

S>·>Что подписчик в момент получения забирает сколько может забрать.

S>·>Никто ничто не ждёт. Допустим, приходят сетевые пакеты в одном треде и складируютсяи в журнал в другм. В журнал можно положить одно сообщение, а можно 100 сразу — время примерно одинаково (буферы, постраничная запись или вроде того). Поэтому, пока мы складировали первое сообщение, могло прийти ещё 50. На следующей итерации мы положим все 50 одним батчем.
S>И какое отношение это имеет к результату честного ping-pong-а между двумя рабочими нитями? Там же весь фокус в том, что когда pinger ждет ответа от ponger-а, то ему делать нечего, его очередь пуста.
Контекст теряешь. Я отвечал на этот вопрос: "Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?".

S>>>С какими системами? Как сравнивать? Что-то пока ничего не видно.

S>·>С другими системами обмена сообщениями.
S>Не видно никаких сравнений. Пока только вбрасывания -- а вот там вот так. Без понимания что, где и почему.
Так это вы должны продвигая ваш фреймворк конкурировать с широкоизвестными альтернативами.

S>·>Ок.. Что "круто" не заявляется. Но цифры даются бессмысленные.

S>Большинство синтетических бенчмарков бессмыслены. Особенно, как в данном разговоре, когда сравниваются результаты, полученные на разных бенчмарках, разными людьми, на разной технике.
Так займитесь.

S>·>Ок, рассказывайте, почему так мало.

S>Ok, рассказываете, почему 2M msg/sec на честном ping-pong-е для вас мало. Хотя бы сколько вам нужно?
Мне нужно хотя бы честное сравнение.

S>·>Что вообще означает цифра 2M?

S>Это означает, что за 1 секунду pinger отослал 1M сигналов ping актору ponger, а тот, в ответ, отослал 1M сигналов pong.
S>При этом сценарий работы такой: pinger отсылает сообщения и засыпает на пустой очереди, в это время ponger получает сообщение, обрабатывает его, отсылает ответный pong, после чего засыпает на своей пустой очереди. В это время просыпается pinger, обрабатывает pong и отсылает ping, после чего засыпает на своей пустой очереди. И т.д. "Засыпает" -- это условный термин. Фокус в том, что pinger/ponger может продолжить свою работу только когда придет ответ от противоположной стороны.
И сколько выдают альтернативы?

S>·>Ээээ. Что вы ожидаете в качестве пруфа?

S>Например, десяток упоминаний использования Disrupt-ора в разных организациях для решения разных задач.
А что-нибудь подобное для sobj есть?
Что с ходу нагуглил в открытых источниках — apereo.org и opencensus.io.

S>·>Он широко известен в узких кругах. Об SObj знают ещё меньше. Я вот о SObj никогда нигде не слышал, кроме как на этом форуме.

S>У нас PR сильно слабее. Да и мир JVM гораздо больше сейчас, чем мир C++. И какие-то вещи, которые распространены в мире Java, в C++ не вызывают большого интереса. Вот та же Модель Акторов, например.
Так и запишем: SObj — неуниверсальный фреймворк, заточенный для определённого мало кому интересного сценария. Но при этом универсально тормозит.

S>·>Ну да, непонятно. Честного сравнения похоже никто так и не сделал.

S>Кому это интересно и кто обладает достаточными для этого ресурсами пусть делает.
Вот поэтому у вас PR и слабее. С чего вдруг это кому-то внезапно может стать интересно?

S>Мы в свое время делали те бенчмарки, которые нам были нужны.

Обойдёте лидеров — вас заметят (как в своё время заметили lmax), а с таким подходом...

S>·>Не знаю о какой ты статье говоришь.

S>Вероятно об одной из самых первых, которая вышла лет 7 или 8 назад.
Это ошибка, скорее всего или какая-то неточность. Знаю из первых рук, ежедневно там ничего не перезапускают и не перезапускали. Вот пруфлинк, я этого товарища лично знаю.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 15:27
Оценка:
Здравствуйте, ·, Вы писали:

S>>Да и сам disruptor, как представляется, стал следствием того, что высокую производительность попытались извлечь из Java.

·>Эээ. И что? Успешно же, извлекли.

Сначала придумали себе проблему, затем ее успешно решили. А за пределами мира Java, где производительность кода изначально высокая, и не нужно Disruptor-ы изобретать.

·>На биржах в среднем порядка 300us вопрос-ответ, а не обработка одного сообщения. 10ms это уже production incident, всех на уши поднимают.


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

·>Может я слишком скептик, но пока даже сравнив с java — стоимость разработки и поддержки ниже практически любого C++-решения.


Да не вопрос. Если вы можете выбирать между Java и C++, то вряд ли оглядываетесь на какие-то C++ные фреймворки. Мы же делаем фреймворк для C++. И если у вас нет выбора, а есть только C++, тогда SObjectizer может вами рассматриваться. И тогда он вам экономит время и ресурсы.

·>А "делегировать ее кому-то нет смысла" это о сфероконях или о чём? Я лично о руках и знании.


Ну т.е. о сфероконях.

·>Контекст теряешь. Я отвечал на этот вопрос: "Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?".


Это вы сперва к цифрам ping-pong-а приплели результаты batch-процессинга.

·>Так это вы должны продвигая ваш фреймворк конкурировать с широкоизвестными альтернативами.


Пока самая большая проблема в продвижении, это не показать, что наш фреймворк быстрее других. А просто рассказать, что местами можно брать готовые фреймворки, а не клепать на коленке свою thread-safe queue и thread-pool в придачу.

S>>Большинство синтетических бенчмарков бессмыслены. Особенно, как в данном разговоре, когда сравниваются результаты, полученные на разных бенчмарках, разными людьми, на разной технике.

·>Так займитесь.

Зачем? Чтобы потешить вас цифрами на форуме?

S>>Ok, рассказываете, почему 2M msg/sec на честном ping-pong-е для вас мало. Хотя бы сколько вам нужно?

·>Мне нужно хотя бы честное сравнение.

Сделайте, если вам нужно. Мы с Java вообще не работаем, да и смысла сравнивать Java и C++ фреймворки не видим.

·>И сколько выдают альтернативы?


Сходите по ссылке, которую вам дали. Посмотрите.

·>А что-нибудь подобное для sobj есть?


Нет. Публично открытой информации о том, где и как используется SObjectizer, практически нет еще.

·>Что с ходу нагуглил в открытых источниках — apereo.org и opencensus.io.


ЧТД. О Disruptor-е говорят больше, чем применяют.

·>Так и запишем: SObj — неуниверсальный фреймворк, заточенный для определённого мало кому интересного сценария.


Запишите, вам-то все равно он не нужен.

·>Но при этом универсально тормозит.


И в это вам никто верить не запрещает.

·>С чего вдруг это кому-то внезапно может стать интересно?


А с чего бы кому-нибудь стали нужны сравнения скорости Akka и SObjectizer-а? Как будто в результате этих замеров кто-то предпочтет Java С++у или наоборот.

S>>·>Не знаю о какой ты статье говоришь.

S>>Вероятно об одной из самых первых, которая вышла лет 7 или 8 назад.
·>Это ошибка, скорее всего или какая-то неточность. Знаю из первых рук, ежедневно там ничего не перезапускают и не перезапускали. Вот пруфлинк, я этого товарища лично знаю.

https://martinfowler.com/articles/lmax.html:

By event sourcing into replicas they can switch between processors in a matter of micro-seconds. As well as taking snapshots every night, they also restart the Business Logic Processors every night.

Re[35]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 16:22
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>Да и сам disruptor, как представляется, стал следствием того, что высокую производительность попытались извлечь из Java.

S>·>Эээ. И что? Успешно же, извлекли.
S>Сначала придумали себе проблему, затем ее успешно решили. А за пределами мира Java, где производительность кода изначально высокая, и не нужно Disruptor-ы изобретать.
Тебя обманули, нет нигде "изначально высокой производительности".

S>·>На биржах в среднем порядка 300us вопрос-ответ, а не обработка одного сообщения. 10ms это уже production incident, всех на уши поднимают.

S>На биржах не применяют универсальные фреймворки. Может быть это ваша больная тема и у вас это болит, но многопоточность применяется много где. В том числе и там, где время обработки сообщений измеряется десятками, сотнями миллисекунд. А то и секундами.
Ну так и в web как выяснилось C++ тоже не рулит. Есть, конечно, области где C++ рулит, но что-то сомневаюсь это там где обработка сообщений.

S>·>Может я слишком скептик, но пока даже сравнив с java — стоимость разработки и поддержки ниже практически любого C++-решения.

S>Да не вопрос. Если вы можете выбирать между Java и C++, то вряд ли оглядываетесь на какие-то C++ные фреймворки. Мы же делаем фреймворк для C++. И если у вас нет выбора, а есть только C++, тогда SObjectizer может вами рассматриваться. И тогда он вам экономит время и ресурсы.
Возможно, но "нет выбора" это и значит что "специализированные решения, заточенные либо под какой-то сценарий".

S>·>Контекст теряешь. Я отвечал на этот вопрос: "Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?".

S>Это вы сперва к цифрам ping-pong-а приплели результаты batch-процессинга.
Ну потому что с одиночными сообщениями было как-то грустно. А обещание 200M — как оказалось так вообще ни о чём.

S>·>Так это вы должны продвигая ваш фреймворк конкурировать с широкоизвестными альтернативами.

S>Пока самая большая проблема в продвижении, это не показать, что наш фреймворк быстрее других. А просто рассказать, что местами можно брать готовые фреймворки, а не клепать на коленке свою thread-safe queue и thread-pool в придачу.
В смысле SObj это единственное решение в мире C++? Остальные клепают наколенное?
И вы зачем-то изначально ограничиваетесь миром С++. Раз позиционируете свою систему как обмен сообщениями, модель акторов, так вам нужно конкурировать именно с другими такими системами, не важно какой ЯП. Какие-нибудь erlang и Akka не стесняются конкурировать, а у вас особый путь.

S>>>Большинство синтетических бенчмарков бессмыслены. Особенно, как в данном разговоре, когда сравниваются результаты, полученные на разных бенчмарках, разными людьми, на разной технике.

S>·>Так займитесь.
S>Зачем? Чтобы потешить вас цифрами на форуме?
Вы же о плохом PR плачетесь...

S>>>Ok, рассказываете, почему 2M msg/sec на честном ping-pong-е для вас мало. Хотя бы сколько вам нужно?

S>·>Мне нужно хотя бы честное сравнение.
S>Сделайте, если вам нужно. Мы с Java вообще не работаем, да и смысла сравнивать Java и C++ фреймворки не видим.
Почему? Если будет система по удобству сравнима с Javа, а производительность заметно выше — то некоторые, компании с большими деньгами обратят на это внимание.

S>·>А что-нибудь подобное для sobj есть?

S>Нет. Публично открытой информации о том, где и как используется SObjectizer, практически нет еще.
ЧТД. Ну нет так нет.

S>·>Что с ходу нагуглил в открытых источниках — apereo.org и opencensus.io.

S>ЧТД. О Disruptor-е говорят больше, чем применяют.
Публично открытая информация о том, где и как используется Disruptor хотя бы есть.

S>·>Так и запишем: SObj — неуниверсальный фреймворк, заточенный для определённого мало кому интересного сценария.

S>Запишите, вам-то все равно он не нужен.
Ну как видно SObj не только мне не нужен.

S>·>С чего вдруг это кому-то внезапно может стать интересно?

S>А с чего бы кому-нибудь стали нужны сравнения скорости Akka и SObjectizer-а? Как будто в результате этих замеров кто-то предпочтет Java С++у или наоборот.
Конечно, найдутся те, кто предпочтут. А что, думаешь все монетку кидают для предпочтений?
Я знаю, что один из Top 10 IB переводят одну свою высокопроизводительную систему с C++ на java. И причина именно "снижение стоимости разработки и поддержки".

S>>>Вероятно об одной из самых первых, которая вышла лет 7 или 8 назад.

S>·>Это ошибка, скорее всего или какая-то неточность. Знаю из первых рук, ежедневно там ничего не перезапускают и не перезапускали. Вот пруфлинк, я этого товарища лично знаю.
S>https://martinfowler.com/articles/lmax.html:
S>

By event sourcing into replicas they can switch between processors in a matter of micro-seconds. As well as taking snapshots every night, they also restart the Business Logic Processors every night.

Snapshots — да, верно. А restart — это ошибка. Читай мою ссылку, если мне не веришь. Martin в lmax не работал, Tom работал, можешь проверить по linkedin.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[23]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 16:46
Оценка:
Здравствуйте, Sharov, Вы писали:

EP>>Со stackless а-я Python/C# так не получится, придётся протаскивать каждое значение и через каждый уровень (и каждую сигнатуру в C#).

S>Вот не понимаю, чем вышеприведенный код отличается от ентого:
Как я понимаю, У Evgeny методы b,c ничего про елданутость не знают и эти методы можно использовать прозначно в другом контексте без всякой асинхронности. В твоём же коде елданутость протаскивается явно сквозь все слои.
Вот только я не понимаю как оно работает внутре. У него в том коде "Coro::push_type *coro" — глобальная переменная, что, как я понял, просто "объяснение на пальцах". Как оно работает в реальности "на железе" — я не понимаю. Должна быть какая-то хитрая динамическая структура таких корутин...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Go язык прёт?
От: Sharov Россия  
Дата: 10.09.18 16:58
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, Sharov, Вы писали:


EP>>>Со stackless а-я Python/C# так не получится, придётся протаскивать каждое значение и через каждый уровень (и каждую сигнатуру в C#).

S>>Вот не понимаю, чем вышеприведенный код отличается от ентого:
·>Как я понимаю, У Evgeny методы b,c ничего про елданутость не знают и эти методы можно использовать прозначно в другом контексте без всякой асинхронности. В твоём же коде елданутость протаскивается явно сквозь все слои.

Я к сожалениею в цпп не очень умею, поэтому не очень понимаю как там результаты возвращаются, если везде void? Думается, там либо компилятор что-то за кадром генерит, либо рантайм (какой-то у цпп должен быть, а-дя C runtime).

·>Вот только я не понимаю как оно работает внутре.


И я...

·>Как оно работает в реальности "на железе" — я не понимаю.


На железе я более-менее прдествляю, а вот в чем разница ful\less на примере того же C# пока не очень понял. Так обрывками. Не в сигнатурах же разница...

·>Должна быть какая-то хитрая динамическая структура таких корутин...


Поддрежка рантайма нужна для диспетчеризации вызова в соотв. фрейм. Это как с обработкой прерывания, только не в одну сторону стек разматывать, а в обе.
Кодом людям нужно помогать!
Re[36]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 10.09.18 17:11
Оценка:
Здравствуйте, ·, Вы писали:

·>Тебя обманули, нет нигде "изначально высокой производительности".


Java уже перестала тормозить? Робот Tommy не даст соврать.
Может тогда объясните, почему тогда в каждом новом релизе Java еще быстрее становится? Наверное, уже обогнала процессоры, на которых работает.

·>Ну так и в web как выяснилось C++ тоже не рулит.


Вы бы еще объяснили, как при таких бенчмарках Web-ом рулят PHP, Django и RoR.

·>Возможно, но "нет выбора" это и значит что "специализированные решения, заточенные либо под какой-то сценарий".


Ну вам-то конечно виднее, из мира JVM. А вот люди из России, например, рассказывают, что для определенных платформ ничего кроме C и C++ нет. И не будет в обозримом будущем.

·>Ну потому что с одиночными сообщениями было как-то грустно.


Так вы ж не сравнивали. Но мнение имеете.

·>А обещание 200M — как оказалось так вообще ни о чём.


Это было не обещание. А объяснение, как на большом потоке сообщений получить 200M. Это не фокус. Фокус на одиночных сообщениях высокую скорость передачи сообщений обеспечить.

·>В смысле SObj это единственное решение в мире C++? Остальные клепают наколенное?


Не единственное. Но одно из немногих живых и развивающихся.

·>И вы зачем-то изначально ограничиваетесь миром С++.


Мы вышли из мира C++.

·>Раз позиционируете свою систему как обмен сообщениями, модель акторов, так вам нужно конкурировать именно с другими такими системами, не важно какой ЯП. Какие-нибудь erlang и Akka не стесняются конкурировать, а у вас особый путь.


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

S>>Зачем? Чтобы потешить вас цифрами на форуме?

·>Вы же о плохом PR плачетесь...

Кто плачется? Вам опять что-то померещилось.
А если вы думаете, что из-за публикации результатов бенчмарков внезапно волна интереса возникнет, то разочарую вас. Не возникнет.

·>Почему? Если будет система по удобству сравнима с Javа, а производительность заметно выше — то некоторые, компании с большими деньгами обратят на это внимание.


Потому, что выбор между Java и C++ определяется далеко не наличием фреймворков, вроде SObjectizer-а.

·>Публично открытая информация о том, где и как используется Disruptor хотя бы есть.


Если вы не поняли, то речь шла о том, что сам по себе Disruptor -- это не универсальное решение. Универсальное -- это, например, Akka. Или Vert.x. И применяются они в мире Java гораздо активнее, чем Disruptor.

S>>·>Так и запишем: SObj — неуниверсальный фреймворк, заточенный для определённого мало кому интересного сценария.

S>>Запишите, вам-то все равно он не нужен.
·>Ну как видно SObj не только мне не нужен.

То, что он не нужен вам, нас очень радует. Это очень хорошо.

S>>А с чего бы кому-нибудь стали нужны сравнения скорости Akka и SObjectizer-а? Как будто в результате этих замеров кто-то предпочтет Java С++у или наоборот.

·>Конечно, найдутся те, кто предпочтут. А что, думаешь все монетку кидают для предпочтений?

Вменяемые люди оценивают по целому спектру критериев. И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов.

·>Я знаю, что один из Top 10 IB переводят одну свою высокопроизводительную систему с C++ на java. И причина именно "снижение стоимости разработки и поддержки".


А пользователь одного из наших продуктов рассказывал, что они переписывают кусок с Java на C++, потому что на нынешних объемах данных Java тормозит.

·>Snapshots — да, верно. А restart — это ошибка. Читай мою ссылку, если мне не веришь. Martin в lmax не работал, Tom работал, можешь проверить по linkedin.


Мартин написал свою статью в 2011-ом, сразу после конференции на которой про Disruptor рассказывали. А слова вашего знакомого сказаны в 2016-ом. Тут любой может врать как очевидец.
Re[37]: Go язык прёт?
От: StanislavK Великобритания  
Дата: 10.09.18 19:36
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>Тебя обманули, нет нигде "изначально высокой производительности".

S>Java уже перестала тормозить? Робот Tommy не даст соврать.
Надо просто уметь готовить.

S>·>Snapshots — да, верно. А restart — это ошибка. Читай мою ссылку, если мне не веришь. Martin в lmax не работал, Tom работал, можешь проверить по linkedin.

S>Мартин написал свою статью в 2011-ом, сразу после конференции на которой про Disruptor рассказывали. А слова вашего знакомого сказаны в 2016-ом. Тут любой может врать как очевидец.

Перезагрузка там была просто по причине того, что в таких системах так принято. Disruptor к этому отношения не имеет.
Кстати кому интересно, идея развилась в Aeron, там уже ipc и udp есть.
Re[37]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 21:47
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>Тебя обманули, нет нигде "изначально высокой производительности".

S>Java уже перестала тормозить? Робот Tommy не даст соврать.
S>Может тогда объясните, почему тогда в каждом новом релизе Java еще быстрее становится? Наверное, уже обогнала процессоры, на которых работает.
А, что C++ или SObj с каждым релизом становится медленнее?

S>·>Ну так и в web как выяснилось C++ тоже не рулит.

S>Вы бы еще объяснили, как при таких бенчмарках Web-ом рулят PHP, Django и RoR.
Они рулят вебом как языки склейки с бэкендами, написанными на C++ (веб-сервера, субд), Java (всякая всячина, типа ElasticSearch, кешей, распред-вычислений и т.п.). Да и далеко не всем в вебе нужна высокая производительность.

S>·>Возможно, но "нет выбора" это и значит что "специализированные решения, заточенные либо под какой-то сценарий".

S>Ну вам-то конечно виднее, из мира JVM. А вот люди из России, например, рассказывают, что для определенных платформ ничего кроме C и C++ нет. И не будет в обозримом будущем.
Не понял зачем ты мне мой тезис доказываешь. "определенных платформ" это и есть "специализированные решения".

S>·>Ну потому что с одиночными сообщениями было как-то грустно.

S>Так вы ж не сравнивали. Но мнение имеете.
Вы, похоже тоже. Но мне от этих сравнений ни тепло, ни холодно, а у вас PR страдает.

S>·>А обещание 200M — как оказалось так вообще ни о чём.

S>Это было не обещание. А объяснение, как на большом потоке сообщений получить 200M. Это не фокус. Фокус на одиночных сообщениях высокую скорость передачи сообщений обеспечить.
Это не "получить". Т.к. передавать 8-байтный указатель на мелкое сообщение или 8-байтный указатель на большое батч-сообщение — это мягко говоря не про то.

S>·>В смысле SObj это единственное решение в мире C++? Остальные клепают наколенное?

S>Не единственное. Но одно из немногих живых и развивающихся.
Почему?

S>·>И вы зачем-то изначально ограничиваетесь миром С++.

S>Мы вышли из мира C++.
Так не засиживайтесь в своём мирке.

S>·>Раз позиционируете свою систему как обмен сообщениями, модель акторов, так вам нужно конкурировать именно с другими такими системами, не важно какой ЯП. Какие-нибудь erlang и Akka не стесняются конкурировать, а у вас особый путь.

S>Erlang и Akka, вообще-то говоря, находятся в одной нише. Но вы этого не понимаете, как и многого другого в данном разговоре.
Ы?

S>>>Зачем? Чтобы потешить вас цифрами на форуме?

S>·>Вы же о плохом PR плачетесь...
S>Кто плачется? Вам опять что-то померещилось.
" У нас PR сильно слабее. " — это что было? Хвастовство что-ли?

S>А если вы думаете, что из-за публикации результатов бенчмарков внезапно волна интереса возникнет, то разочарую вас. Не возникнет.

Это условие как минимум необходимое.

S>·>Почему? Если будет система по удобству сравнима с Javа, а производительность заметно выше — то некоторые, компании с большими деньгами обратят на это внимание.

S>Потому, что выбор между Java и C++ определяется далеко не наличием фреймворков, вроде SObjectizer-а.
Всяко бывает.

S>·>Публично открытая информация о том, где и как используется Disruptor хотя бы есть.

S>Если вы не поняли, то речь шла о том, что сам по себе Disruptor -- это не универсальное решение. Универсальное -- это, например, Akka. Или Vert.x. И применяются они в мире Java гораздо активнее, чем Disruptor.
Не понимаю каким образом из более активного применения или популярности следует универсальность...

S>>>А с чего бы кому-нибудь стали нужны сравнения скорости Akka и SObjectizer-а? Как будто в результате этих замеров кто-то предпочтет Java С++у или наоборот.

S>·>Конечно, найдутся те, кто предпочтут. А что, думаешь все монетку кидают для предпочтений?
S>Вменяемые люди оценивают по целому спектру критериев. И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов.
Я говорю о другом, есть задачи, где важна производительность и за выбором языка реализации дело не стоит.

S>·>Я знаю, что один из Top 10 IB переводят одну свою высокопроизводительную систему с C++ на java. И причина именно "снижение стоимости разработки и поддержки".

S>А пользователь одного из наших продуктов рассказывал, что они переписывают кусок с Java на C++, потому что на нынешних объемах данных Java тормозит.
Хз что. Если что-то типа числодробилок — поверю.

S>·>Snapshots — да, верно. А restart — это ошибка. Читай мою ссылку, если мне не веришь. Martin в lmax не работал, Tom работал, можешь проверить по linkedin.

S>Мартин написал свою статью в 2011-ом, сразу после конференции на которой про Disruptor рассказывали. А слова вашего знакомого сказаны в 2016-ом.
Специально для тебя спросил, у чувака, который работал там с января 2012. Его ответ:

As part of eod, we’d gc, snapshot and reset the message sequence numbers, the latter of which could be interpreted as ‘restart the logic processors’. The next message they’d process after eod would be message zero

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

S>Тут любой может врать как очевидец.

Мда, религиозные убеждения не лечатся. В лучшем случае, в конце-концов услышишь: "вы всё врёте!"
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Go язык прёт?
От: · Великобритания  
Дата: 10.09.18 22:04
Оценка: +1
Здравствуйте, Sharov, Вы писали:

S>>>Вот не понимаю, чем вышеприведенный код отличается от ентого:

S>·>Как я понимаю, У Evgeny методы b,c ничего про елданутость не знают и эти методы можно использовать прозначно в другом контексте без всякой асинхронности. В твоём же коде елданутость протаскивается явно сквозь все слои.

S>Я к сожалениею в цпп не очень умею, поэтому не очень понимаю как там результаты возвращаются, если везде void? Думается, там либо компилятор что-то за кадром генерит, либо рантайм (какой-то у цпп должен быть, а-дя C runtime).

А вот так "магически" и возвращается. Что, мол, место объявления корутины и место где елдится — связываются как-то неявно, несмотря на то что между ними есть промежуточные "простые" функции. Что-то вроде тредов по сути.

S>·>Как оно работает в реальности "на железе" — я не понимаю.

S>На железе я более-менее прдествляю, а вот в чем разница ful\less на примере того же C# пока не очень понял. Так обрывками. Не в сигнатурах же разница...
Как я понял именно в них. Т.е. одна и та же функция может работать в разных условиях по-разному — асинхронно или нет.

S>·>Должна быть какая-то хитрая динамическая структура таких корутин...

S>Поддрежка рантайма нужна для диспетчеризации вызова в соотв. фрейм. Это как с обработкой прерывания, только не в одну сторону стек разматывать, а в обе.
Ну да, как-бы наверное что-то такое этакое... Ещё там как-то SP подменяется. Вот только я не очень понимаю все эти детали.

Надеюсь кто-нибудь объяснит...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 11.09.18 06:10
Оценка:
Здравствуйте, ·, Вы писали:

S>>Может тогда объясните, почему тогда в каждом новом релизе Java еще быстрее становится? Наверное, уже обогнала процессоры, на которых работает.

·> А, что C++ или SObj с каждым релизом становится медленнее?

Это вы попытались заболтать тезис, что

нет нигде "изначально высокой производительности".

Но у вас не получилось.

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

S>>Ну вам-то конечно виднее, из мира JVM. А вот люди из России, например, рассказывают, что для определенных платформ ничего кроме C и C++ нет. И не будет в обозримом будущем.

·>Не понял зачем ты мне мой тезис доказываешь. "определенных платформ" это и есть "специализированные решения".

У вас какое-то специфическое представление о "специализированных решениях".

S>>Так вы ж не сравнивали. Но мнение имеете.

·>Вы, похоже тоже.

В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают.

·>Но мне от этих сравнений ни тепло, ни холодно,


Но рот-то вы зачем-то открыли. Зачем?

S>>Это было не обещание. А объяснение, как на большом потоке сообщений получить 200M. Это не фокус. Фокус на одиночных сообщениях высокую скорость передачи сообщений обеспечить.

·>Это не "получить". Т.к. передавать 8-байтный указатель на мелкое сообщение или 8-байтный указатель на большое батч-сообщение — это мягко говоря не про то.

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

S>>·>В смысле SObj это единственное решение в мире C++? Остальные клепают наколенное?

S>>Не единственное. Но одно из немногих живых и развивающихся.
·>Почему?

Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О.

S>>·>И вы зачем-то изначально ограничиваетесь миром С++.

S>>Мы вышли из мира C++.
·>Так не засиживайтесь в своём мирке.

Ну вот если Rust мир будет и дальше развиваться так же активно, попробуем пойти еще и туда.
А в вашем Java мире и скучно, и тесно. И идиотов слишком много.

S>>Erlang и Akka, вообще-то говоря, находятся в одной нише. Но вы этого не понимаете, как и многого другого в данном разговоре.

·>Ы?

Вот-вот. Отличная демонстрация.

S>>Кто плачется? Вам опять что-то померещилось.

·>" У нас PR сильно слабее. " — это что было? Хвастовство что-ли?

Это констатация факта. Плачем было бы, если бы мы написали что-то вроде "У нас, к сожалению, PR сильно слабее не смотря на все прилагаемые усилия и мы уже даже не знаем, что можно еще сделать в этом направлении". Так что вы не только в предмете разговора не разбираетесь, вы еще и читать не умеете.

S>>А если вы думаете, что из-за публикации результатов бенчмарков внезапно волна интереса возникнет, то разочарую вас. Не возникнет.

·>Это условие как минимум необходимое.

А вот вы посмотрели на результаты бенчмарков, которые мы вам показали?

S>>·>Почему? Если будет система по удобству сравнима с Javа, а производительность заметно выше — то некоторые, компании с большими деньгами обратят на это внимание.

S>>Потому, что выбор между Java и C++ определяется далеко не наличием фреймворков, вроде SObjectizer-а.
·>Всяко бывает.

Сказки рассказываете.

S>>Если вы не поняли, то речь шла о том, что сам по себе Disruptor -- это не универсальное решение. Универсальное -- это, например, Akka. Или Vert.x. И применяются они в мире Java гораздо активнее, чем Disruptor.

·>Не понимаю каким образом из более активного применения или популярности следует универсальность...

Очевидно, что не понимаете. Но с этим мы вам не поможем.

S>>Вменяемые люди оценивают по целому спектру критериев. И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов.

·>Я говорю о другом, есть задачи, где важна производительность и за выбором языка реализации дело не стоит.

Не понятно вообще о чем вы говорите в данном случае. То, как можно понять ваши слова, только подтверждает сказанное: "И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов."

S>>А пользователь одного из наших продуктов рассказывал, что они переписывают кусок с Java на C++, потому что на нынешних объемах данных Java тормозит.

·>Хз что. Если что-то типа числодробилок — поверю.

Вообще-то нам без разницы, поверите вы или нет. Люди агрегируют большое количество данных в json-е из разных источников. И обработка этого хозяйства на Java менее эффективна, чем на С++.

S>>Тут любой может врать как очевидец.

·> Мда, религиозные убеждения не лечатся. В лучшем случае, в конце-концов услышишь: "вы всё врёте!"

Да вы еще и выражение "врать как очевидец" не понимаете. Ну вообще полный комплект: ни русского не понимает, ни в теме не разбирается.
Re[22]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.09.18 07:48
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Serginio1, Вы писали:


S>>yeld уже 13 лет. И они показали свою эффективнось


НС>И неэффективность. К примеру, как то раз в Решарпере производилась глобальная вычистка линка из кода. Как раз из-за тормозов при длинных цепочках итераторов.


Ну для этого есть roslyn-linq-rewrite

Что в принципе несложно сделать и для рекурсивных yeld ов
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.09.2018 7:49 Serginio1 . Предыдущая версия .
Re[23]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 11.09.18 08:15
Оценка:
Здравствуйте, Serginio1, Вы писали:

НС>>И неэффективность. К примеру, как то раз в Решарпере производилась глобальная вычистка линка из кода. Как раз из-за тормозов при длинных цепочках итераторов.

S>Ну для этого есть <span class='lineQuote level1'>S&gt;roslyn-linq-rewrite</span>

Это глючный костыль.

S> Что в принципе несложно сделать и для рекурсивных yeld ов


А что с экспоненциальными взрывами то делать?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[26]: Go язык прёт?
От: Sharov Россия  
Дата: 11.09.18 09:24
Оценка:
Здравствуйте, ·, Вы писали:

·>Ну да, как-бы наверное что-то такое этакое... Ещё там как-то SP подменяется. Вот только я не очень понимаю все эти детали.


SP стека которому мы передали управление, для текущего потока выставляет runtime. Наверное.
Кодом людям нужно помогать!
Re[24]: Go язык прёт?
От: Sharov Россия  
Дата: 11.09.18 09:28
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

S>> Что в принципе несложно сделать и для рекурсивных yeld ов


НС>А что с экспоненциальными взрывами то делать?


Откуда оне в энумераторе шарпа возьмутся? Там простейший автомат для обхода коллекции.
Кодом людям нужно помогать!
Re[26]: Go язык прёт?
От: Cyberax Марс  
Дата: 11.09.18 10:29
Оценка: 5 (1)
Здравствуйте, ·, Вы писали:

S>>Поддрежка рантайма нужна для диспетчеризации вызова в соотв. фрейм. Это как с обработкой прерывания, только не в одну сторону стек разматывать, а в обе.

·>Ну да, как-бы наверное что-то такое этакое... Ещё там как-то SP подменяется. Вот только я не очень понимаю все эти детали.
Stackful сопрограммы делаются очень просто и тупо. Вызов yield — это обычный вызов функции, сохраняющий состояние вызывающего на стеке. Далее yield делает (аналог) longjump в планировщик, который решает что там нужно запускать дальше.

Когда нужно возобновить сопрограмму — делается longjump обратно в тело yield, что восстанавливает стек. Ну а затем yield штатным образом делает ret и сопрограмма идёт себе дальше.
Sapienti sat!
Re[39]: Go язык прёт?
От: · Великобритания  
Дата: 11.09.18 11:08
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>Может тогда объясните, почему тогда в каждом новом релизе Java еще быстрее становится? Наверное, уже обогнала процессоры, на которых работает.

S>·> А, что C++ или SObj с каждым релизом становится медленнее?
S>Это вы попытались заболтать тезис, что

нет нигде "изначально высокой производительности".

S>Но у вас не получилось.
Заболтать? Какой вопрос (я его специально оставил в квоте), такой ответ. В чём было твоё возражение против тезиса-то?

S>А поскольку вы поражаете своим эээ, специфически ограниченным взглядом, то придется открыть вам очередную банальность: новые фичи не обходятся бесплатно. И где-то да, за новую функциональность приходится расплачиваться. Местами производительностью, местами расходом памяти.

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

S>>>Ну вам-то конечно виднее, из мира JVM. А вот люди из России, например, рассказывают, что для определенных платформ ничего кроме C и C++ нет. И не будет в обозримом будущем.

S>·>Не понял зачем ты мне мой тезис доказываешь. "определенных платформ" это и есть "специализированные решения".
S>У вас какое-то специфическое представление о "специализированных решениях".
Да ваще.

S>>>Так вы ж не сравнивали. Но мнение имеете.

S>·>Вы, похоже тоже.
S>В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают.
Клёво. А что вы ждёте от нас? И сколько вы готовы за это заплатить?

S>·>Но мне от этих сравнений ни тепло, ни холодно,

S>Но рот-то вы зачем-то открыли. Зачем?
Это публичный форум, я тут развлекаюсь. А вы зачем открыли?

S>>>Это было не обещание. А объяснение, как на большом потоке сообщений получить 200M. Это не фокус. Фокус на одиночных сообщениях высокую скорость передачи сообщений обеспечить.

S>·>Это не "получить". Т.к. передавать 8-байтный указатель на мелкое сообщение или 8-байтный указатель на большое батч-сообщение — это мягко говоря не про то.
S>Скажите, а вы точно уверены в том, что понимаете предмет разговора? Со стороны видно, что вы вообще не представляете себе, чем отличается обработка единичных сообщений в режиме request-reply от обработки стабильно плотного потока входящих сообщений.
Я наоборот очень хорошо представляю, поэтому меня удивило обещание 200М. Как оказалось, не зря удивило, т.к. это простое словоблудие.

S>>>·>В смысле SObj это единственное решение в мире C++? Остальные клепают наколенное?

S>>>Не единственное. Но одно из немногих живых и развивающихся.
S>·>Почему?
S>Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О.
Почему "одно", очевидно же, господин тролль.

S>>>Мы вышли из мира C++.

S>·>Так не засиживайтесь в своём мирке.
S>Ну вот если Rust мир будет и дальше развиваться так же активно, попробуем пойти еще и туда.
S>А в вашем Java мире и скучно, и тесно. И идиотов слишком много.
Причём тут ЯП?

S>>>Erlang и Akka, вообще-то говоря, находятся в одной нише. Но вы этого не понимаете, как и многого другого в данном разговоре.

S>·>Ы?
S>Вот-вот. Отличная демонстрация.
Ты повторяешь мои слова, без всякого смысла, да ещё на личности всё разговор сводишь, господин тролль.
Я знаю, что erlang и akka в одной нише, я спрашиваю почему SObj в другой и в какой другой?

S>>>Кто плачется? Вам опять что-то померещилось.

S>·>" У нас PR сильно слабее. " — это что было? Хвастовство что-ли?
S>Это констатация факта. Плачем было бы, если бы мы написали что-то вроде "У нас, к сожалению, PR сильно слабее не смотря на все прилагаемые усилия и мы уже даже не знаем, что можно еще сделать в этом направлении". Так что вы не только в предмете разговора не разбираетесь, вы еще и читать не умеете.
Т.е. фактически ты заявил "мы — неудачники, и это константация факта". Понятно, спасибо за откровенность.

S>>>А если вы думаете, что из-за публикации результатов бенчмарков внезапно волна интереса возникнет, то разочарую вас. Не возникнет.

S>·>Это условие как минимум необходимое.
S>А вот вы посмотрели на результаты бенчмарков, которые мы вам показали?
Да, мельком. Могу рассказать о своём впечатлении. Мне не очень понятно что там сравнивалось с т.з. прикладных задач и что этим предполагалось продемонстрировать.
Во-первых, я плохо знаю CAF, никогда не использовал. Как я понял CAF позиционируется как гибкое высокопараллельное распределённое решение. А вы его тестируете для пинг-понга между двумя тредами. Пинг-понг делается volatile переменными, давая охренительную производительность, непонятно зачем для этого нужен целый фреймворк.
Во-вторых, у CAF есть свои бенчмарки, притом они не стесняясь сравнили свой продукт с чем только можно, не ограничиваясь миром С++. Так и вам можно было бы просто реализовать эти же бенчмарки на вашем продукте и показать преимущества. А по факту выглядит так, что в вашем бенчмарке вы сравнивали те сценарии которые вы знаете, на которые ваш SObj _специализированно_ заточен, используя в качестве "груши для битья" _универсальный_ фреймворк, который, грубо говоря, позволяет одним флажком перенести прикладной код с микроконтроллера на массивный кластер или в GPU.
Но даже побить-то особо не получилось. Скажем "scheduling" на одном треде дал прирост аж 30% (но кому нужен actor model на одном треде?!), а на тред-пуле внезапно в 50 раз медленнее.
В-третьих, ведь собственно весь этот Actor Model собственно и затевается для массивной параллелизации вычислений... а вы тестируете на 8-ядерном компе, большинство тестов — 1-2 треда, при этом постоянно настаиваете на универсальности вашего решения.

S>>>Вменяемые люди оценивают по целому спектру критериев. И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов.

S>·>Я говорю о другом, есть задачи, где важна производительность и за выбором языка реализации дело не стоит.
S>Не понятно вообще о чем вы говорите в данном случае. То, как можно понять ваши слова, только подтверждает сказанное: "И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов."
Фреймворк != ЯП. В десятый раз повторяю. Не понимаю почему ты не различаешь.

S>>>А пользователь одного из наших продуктов рассказывал, что они переписывают кусок с Java на C++, потому что на нынешних объемах данных Java тормозит.

S>·>Хз что. Если что-то типа числодробилок — поверю.
S>Вообще-то нам без разницы, поверите вы или нет. Люди агрегируют большое количество данных в json-е из разных источников. И обработка этого хозяйства на Java менее эффективна, чем на С++.
Обычно нет. Эффективное решение задачи такого типа на Java как правило не отстаёт по производительности от C++ больше, чем на десяток процентов. А та ссылка на web-бенчмарки показывает (с json тоже, кстати), что java код может работать даже эффективнне чем С за счёт JIT. Но у них может быть какой-то специфичный сценарий, я не знаю.

S>>>Тут любой может врать как очевидец.

S>·> Мда, религиозные убеждения не лечатся. В лучшем случае, в конце-концов услышишь: "вы всё врёте!"
S>Да вы еще и выражение "врать как очевидец" не понимаете. Ну вообще полный комплект: ни русского не понимает, ни в теме не разбирается.
Понимаю, конечно, господин тролль. Факт остаётся фактом, что "JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали" — заблуждение, за которое ты с религиозным фанатизмом цепляешься и делаешь из него странные выводы о неэффективности gc.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 11.09.2018 11:36 · . Предыдущая версия .
Re[40]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 11.09.18 11:56
Оценка: -1
Здравствуйте, ·, Вы писали:

·>Заболтать?


Заболтать. Единственное, что у вас получается, это включать дурочку.

·>В чём было твоё возражение против тезиса-то?


Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.

·>А иногда что-нибудь оптимизируется или предлагаются другие подходы для решения тех же задач. Если ваш продукт с каждым релизом всё медленнее, то вы делаете что-то не то.


Да-да, мы вам во всем верим.

S>>В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают.

·>Клёво. А что вы ждёте от нас?

От "вас" -- это от кого?

·>И сколько вы готовы за это заплатить?


Мы заплатить? Это типа шутка.

S>>·>Но мне от этих сравнений ни тепло, ни холодно,

S>>Но рот-то вы зачем-то открыли. Зачем?
·>Это публичный форум, я тут развлекаюсь.

Было подозрение, что вы херней страдаете. Подтвердилось.

·>А вы зачем открыли?


Вам закрыть. Боремся с непрофессионализмом и мракобесием.

·>Я наоборот очень хорошо представляю


Что-то пока не видно. Вам даже принцип бенчмарка ping-pong пришлось объяснять на пальцах.

·>поэтому меня удивило обещание 200М. Как оказалось, не зря удивило, т.к. это простое словоблудие.


Еще раз: обещаний не было. Вам это русским языком уже было сказано. Но с русским у вас явные проблемы.

S>>Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О.

·>Почему "одно", очевидно же, господин тролль.

Продолжаем обучать вас русскому языку. Исходная фраза: "Но одно из немногих живых и развивающихся". Словом "одно" обозначается наше решение, т.е. SObjectizer. SObjectizer в единственном числе. Поэтому "одно [решение] из немногих". Если бы SObjectizer-ов было несколько, фраза была бы построена по другому.

·>Причём тут ЯП?


42.

·>Ты повторяешь мои слова, без всякого смысла, да ещё на личности всё разговор сводишь, господин тролль.


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

·>Я знаю, что erlang и akka в одной нише, я спрашиваю почему SObj в другой и в какой другой?


В нише C++: небезопасного нативного языка без сборщика мусора.

·>Т.е. фактически ты заявил "мы — неудачники, и это константация факта".


Нет. Мы заявили, что вы не в ладах с русским языком.

·>Да, мельком. Могу рассказать о своём впечатлении. Мне не очень понятно что там сравнивалось с т.з. прикладных задач и что этим предполагалось продемонстрировать.


На этом можно и закончить. Что, собственно, весь остальной текст и продемонстрировал.
Более того, вы даже не смогли разобрать, что в бенчмарке участвовали как тесты из SO-5, так и тесты из CAF-а.

·> _универсальный_ фреймворк, который, грубо говоря, позволяет одним флажком перенести прикладной код с микроконтроллера на массивный кластер или в GPU.


Это вообще уже за гранью добра и зла.

·>В-третьих, ведь собственно весь этот Actor Model собственно и затевается для массивной параллелизации вычислений...


Для массивной параллелизации вычислений применяются подходы из области parallel computing-а. OpenMP, например, MPI. И соответствующие библиотеки, вроде TBB или HPX.

А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются.

·>Фреймворк != ЯП. В десятый раз повторяю. Не понимаю почему ты не различаешь.


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

·>Понимаю, конечно, господин тролль. Факт остаётся фактом, что "JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали" — заблуждение, за которое ты с религиозным фанатизмом цепляешься и делаешь из него странные выводы о неэффективности gc.


Зафиксируем еще раз проблемы с восприятием. То, что вам сказали про перезапуски -- это не было придумано. Это было взято из статьи Мартина Фаулера, на которую вам дали ссылку. Насколько это соответствует действительности сейчас, спустя несколько лет после публикации статьи -- это уже другой вопрос.

Даже если уже и не рестартуют JVM, то вот этот вот запуск GC только в строго определенное время и переинициализация счетчиков -- это просто образец универсальности решения.
Re[24]: Go язык прёт?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.09.18 12:16
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Serginio1, Вы писали:


НС>>>И неэффективность. К примеру, как то раз в Решарпере производилась глобальная вычистка линка из кода. Как раз из-за тормозов при длинных цепочках итераторов.

S>>Ну для этого есть <span class='lineQuote level2'>S&gt;&gt;roslyn-linq-rewrite</span>

НС>Это глючный костыль.


S>> Что в принципе несложно сделать и для рекурсивных yeld ов


НС>А что с экспоненциальными взрывами то делать?


Кстати а можно ссылочку на эти взрывы
и солнце б утром не вставало, когда бы не было меня
Re[41]: Go язык прёт?
От: · Великобритания  
Дата: 11.09.18 13:52
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>В чём было твоё возражение против тезиса-то?

S>Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.
Если вы работаете перемножателем матриц, то конечно, java не очень подойдёт. Но даже в этом случае выбор C++ будет не очевиден. Сейчас есть GPU, FPGA, упомянутый parallel computing и прочие радости.
А если рассуждать о производительности реальной системы, решающей бизнес-задачи, то "изначально высокой производительности" тебе никто не гарантирует.
И вообще, это жуткий увод в сторону. Обсуждаются 2М сообщений, и внезапно "умножаем матрицы не прогревая". Кстати, если прогрев является проблемой, есть решения, например Azul ReadyNow, jaotc и т.п.

S>>>В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают.

S>·>Клёво. А что вы ждёте от нас?
S>От "вас" -- это от кого?
Вы наверное имели в виду меня.

S>·>И сколько вы готовы за это заплатить?

S>Мы заплатить? Это типа шутка.
Ну так хотя бы будет какое-то основание что-то от меня требовать.

S>>>Но рот-то вы зачем-то открыли. Зачем?

S>·>Это публичный форум, я тут развлекаюсь.
S>Было подозрение, что вы херней страдаете. Подтвердилось.
Я не страдаю, я наслаждаюсь.

S>·>А вы зачем открыли?

S>Вам закрыть. Боремся с непрофессионализмом и мракобесием.
Начните с себя. Будет больше результата.

S>·>Я наоборот очень хорошо представляю

S>Что-то пока не видно. Вам даже принцип бенчмарка ping-pong пришлось объяснять на пальцах.
Принцип я не спрашивал. Я спрашивал накой такой бенчмарк. Но объяснить вы затрудняетесь.

S>·>поэтому меня удивило обещание 200М. Как оказалось, не зря удивило, т.к. это простое словоблудие.

S>Еще раз: обещаний не было. Вам это русским языком уже было сказано. Но с русским у вас явные проблемы.
Не вали с больной головы. Ты заявил "вы получите 200M сообщений в секунду". Что, мягко говоря, словоблудие.

S>>>Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О.

S>·>Почему "одно", очевидно же, господин тролль.
S>Продолжаем обучать вас русскому языку. Исходная фраза: "Но одно из немногих живых и развивающихся". Словом "одно" обозначается наше решение, т.е. SObjectizer. SObjectizer в единственном числе. Поэтому "одно [решение] из немногих". Если бы SObjectizer-ов было несколько, фраза была бы построена по другому.
Где-то выше было сказано, что альтернатива будет — наколенные решения.

S>·>Я знаю, что erlang и akka в одной нише, я спрашиваю почему SObj в другой и в какой другой?

S>В нише C++: небезопасного нативного языка без сборщика мусора.
Это не ниша. Это детали имплементации. Нет такой бизнес-задачи "запускать приложения на нативном языке".

S>·>Т.е. фактически ты заявил "мы — неудачники, и это константация факта".

S>Нет. Мы заявили, что вы не в ладах с русским языком.
Халва-халва.

S>·>В-третьих, ведь собственно весь этот Actor Model собственно и затевается для массивной параллелизации вычислений...

S>Для массивной параллелизации вычислений применяются подходы из области parallel computing-а. OpenMP, например, MPI. И соответствующие библиотеки, вроде TBB или HPX.
S>А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются.
Ок. Какой же тогда смысл запускать Actor Model на одном треде?! Или даже на двух?

S>·>Понимаю, конечно, господин тролль. Факт остаётся фактом, что "JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали" — заблуждение, за которое ты с религиозным фанатизмом цепляешься и делаешь из него странные выводы о неэффективности gc.

S>Зафиксируем еще раз проблемы с восприятием. То, что вам сказали про перезапуски -- это не было придумано. Это было взято из статьи Мартина Фаулера, на которую вам дали ссылку. Насколько это соответствует действительности сейчас, спустя несколько лет после публикации статьи -- это уже другой вопрос.
Я тебе в четвёртый раз повторяю. В статье Мартина Фаулера неточность или неоднозначность, которую ты не так понимаешь. Как оно работает на самом деле я знаю прекрасно. Не делай выводов из ложного утверждения.

S>Даже если уже и не рестартуют JVM, то вот этот вот запуск GC только в строго определенное время и переинициализация счетчиков -- это просто образец универсальности решения.

Продолжаешь нести бред. Запуск GC тоже давно не делают. Счётчики и снапшоты это специфика бизнеса. Есть такое понятие End of Day на биржах.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 11.09.18 14:36
Оценка: 15 (2)
Здравствуйте, Serginio1, Вы писали:

НС>>А что с экспоненциальными взрывами то делать?

S> Кстати а можно ссылочку на эти взрывы

Ссылочку сложно. ВОт тут можно в описании проблемы почитать — https://www.cse.msu.edu/~alexliu/publications/D2FAconstruction/D2FAconstruction_NDSS2012.pdf
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 11.09.18 14:49
Оценка:
Здравствуйте, ·, Вы писали:

·>Если вы работаете перемножателем матриц, то конечно, java не очень подойдёт.


Ну т.е. высокая производительность сама по себе есть. ЧТД.
Далее вопрос только в том, как производительность, данная вам языком и рантаймом, вы будете убивать выбранными вами подходами.
И, внезапно, если у вас производительность изначально ниже, то и убить ее проще.

·>Но даже в этом случае выбор C++ будет не очевиден. Сейчас есть GPU, FPGA, упомянутый parallel computing и прочие радости.


Здесь границы применимости C++ не обсуждаются.

·>Вы наверное имели в виду меня.


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

·>Ну так хотя бы будет какое-то основание что-то от меня требовать.


От вас никто ничего не требует.

·>Принцип я не спрашивал. Я спрашивал накой такой бенчмарк.


Простите, такого вопроса не было видно. Можете показать цитату?

·>Но объяснить вы затрудняетесь.


Вообще-то это очевидно. Подобный ping-pong бенчмарк с двумя рабочими нитями и передачей единичных сообщений в каждую сторону, является самой жесткой проверкой на стоимость передачи одного сообщения между рабочими нитями. Именно здесь видно, сколько стоит передача сообщения. В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики.

·>Не вали с больной головы. Ты заявил "вы получите 200M сообщений в секунду". Что, мягко говоря, словоблудие.


Ничего подобного. Но т.к. вы в предмете не разбираетесь, то объяснять вам в очередной раз про разницу в нагрузке при большом потоке сообщений (когда batch/bulk обработка используется) и при единичных сообщениях, бесполезно.

·>Где-то выше было сказано, что альтернатива будет — наколенные решения.


Вы бы это, раз пришли общаться на русскоязычный форум, язык бы выучили. Поскольку вам русским языком было сказано:

Пока самая большая проблема в продвижении, это не показать, что наш фреймворк быстрее других. А просто рассказать, что местами можно брать готовые фреймворки, а не клепать на коленке свою thread-safe queue и thread-pool в придачу.

Тут даже "фреймворки" во множественном числе употреблены, мы не говорили, что наш продукт единственный.

·>Это не ниша. Это детали имплементации. Нет такой бизнес-задачи "запускать приложения на нативном языке".


Это из-за вашего эээ альтернативного понимания. Видите ли, когда вы можете использовать в своей задаче безопасный язык с GC и, более того, с VM, то вы можете сравнивать Erlang с Akka или Akka с Orleans. Но когда вам нужно писать на C, C++, Ada или Rust-е, то вам результаты замеров Erlang-а или Akka будут, мягко говоря, нерелевантны. Вам нужен будет инструмент для своего нативного языка. Со всей стоимостью, которую за это придется заплатить. И вам нужны будут результаты бенчмарков нативных фреймворков, в которых, например, нет GC и используется либо подсчет ссылок, либо вообще отданная на откуп пользователю преаллокация сообщений. Со всеми вытекающими.

S>>А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются.

·>Ок. Какой же тогда смысл запускать Actor Model на одном треде?! Или даже на двух?

От задачи зависит. Но т.к. мир C++ от вас бесконечно далек, то посмотрите в качестве примера на Go. Там ведь можно создать 100500 гороутин. И обслуживаться они будут всего несколькими рабочими нитями. Может, по вашему, в этом так же нет смысла?

·>Я тебе в четвёртый раз повторяю. В статье Мартина Фаулера неточность или неоднозначность, которую ты не так понимаешь.


Вы сколько угодно можете это повторять. Вас интересовало, откуда взялась инфа про рестарты. Вам сказали. Далее можете спорить с Фаулером. Все приведенные здесь цитаты -- это спор о показаниях разных свидетелей, да еще в разное время.

·>Продолжаешь нести бред. Запуск GC тоже давно не делают.


Но ведь делали: We used to trigger a manual GC each night in a 5-minute trading gap, and tuned so that would be the only major GC in a day.
Это слова того вашего знакомого, на которого вы ссылаетесь.

Опять же, работа без ручного вызова GC лишь за счет Azul Zing -- это еще один признак универсальности Disruptor-а.
Re[26]: Go язык прёт?
От: Sharov Россия  
Дата: 11.09.18 16:42
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Serginio1, Вы писали:


НС>>>А что с экспоненциальными взрывами то делать?

S>> Кстати а можно ссылочку на эти взрывы

НС>Ссылочку сложно. ВОт тут можно в описании проблемы почитать — https://www.cse.msu.edu/~alexliu/publications/D2FAconstruction/D2FAconstruction_NDSS2012.pdf


Про регулярки понятно, то же и с состояниями в асинхронных системах. А какое к этому имеет отношение генератор в linq?
Кодом людям нужно помогать!
Re[27]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 11.09.18 17:00
Оценка: -1
Здравствуйте, Sharov, Вы писали:

НС>>Ссылочку сложно. ВОт тут можно в описании проблемы почитать — https://www.cse.msu.edu/~alexliu/publications/D2FAconstruction/D2FAconstruction_NDSS2012.pdf

S>Про регулярки понятно, то же и с состояниями в асинхронных системах. А какое к этому имеет отношение генератор в linq?

Там все ровно то же. Сперва простым алгоритмом строим НКА, потом преобразуем его в ДКА. Вот на этапе построения ДКА и можем получить тот самый взрыв состояний при неудачных данных.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[28]: Go язык прёт?
От: Sharov Россия  
Дата: 11.09.18 17:02
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС> Вот на этапе построения ДКА и можем получить тот самый взрыв состояний при неудачных данных.


Что значит неудачные данные?
foreach(var t in items) yield return t;


Что может быть неудачного в items?
Кодом людям нужно помогать!
Re[29]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 11.09.18 17:03
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Что значит неудачные данные?


Давай ты дальше сам, ок?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[30]: Go язык прёт?
От: Sharov Россия  
Дата: 11.09.18 17:09
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Давай ты дальше сам, ок?


Не ок. Я пока не увидел ответа на свой вопрос. Про регулярки понятно, а и итератором какие пробелемы? На пальцах то можно пример привести?
Кодом людям нужно помогать!
Re[31]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 11.09.18 17:25
Оценка: :)
Здравствуйте, Sharov, Вы писали:

НС>>Давай ты дальше сам, ок?

S>Не ок. Я пока не увидел ответа на свой вопрос.

А я пока и не нанимался тебе его давать во всех подробностях. Интересна тема — вперед.

S> Про регулярки понятно, а и итератором какие пробелемы?


Ровно те же самые, как только появляются вложенные автоматы, которые нужно собрать в один большой ДКА.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[32]: Go язык прёт?
От: Sharov Россия  
Дата: 11.09.18 17:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А я пока и не нанимался тебе его давать во всех подробностях. Интересна тема — вперед.


Интересна в разрезе linq, а не re. Инф-ии на этот счет не густо, можно было бы и на пальцах объясинть.

S>> Про регулярки понятно, а и итератором какие пробелемы?


НС>Ровно те же самые, как только появляются вложенные автоматы, которые нужно собрать в один большой ДКА.


А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?
Кодом людям нужно помогать!
Re[33]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 11.09.18 21:39
Оценка:
Здравствуйте, Sharov, Вы писали:

НС>>А я пока и не нанимался тебе его давать во всех подробностях. Интересна тема — вперед.

S>Интересна в разрезе linq, а не re. Инф-ии на этот счет не густо, можно было бы и на пальцах объясинть.

На пальцах я уже объяснил — никакой разницы с регексами нет, отличия только в исходном алгоритме построения НКА. Дальше все одинаково.

S>>> Про регулярки понятно, а и итератором какие пробелемы?

НС>>Ровно те же самые, как только появляются вложенные автоматы, которые нужно собрать в один большой ДКА.
S>А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?

Потому что минимизация ДКА и перформанс. Все ровно то же что и с регексами.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[43]: Go язык прёт?
От: · Великобритания  
Дата: 11.09.18 22:21
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>Если вы работаете перемножателем матриц, то конечно, java не очень подойдёт.

S>Ну т.е. высокая производительность сама по себе есть. ЧТД.
S>Далее вопрос только в том, как производительность, данная вам языком и рантаймом, вы будете убивать выбранными вами подходами.
S>И, внезапно, если у вас производительность изначально ниже, то и убить ее проще.
Я имел в виду решение задач, а не микробенчмарки. Можно найти примеры, где C++ сливает Яве. Будем из этого делать вывод, что и у C++ нет никакой изначальной высокой производительности? Или ты предлагаешь заняться тщательным отбором удобных фактов?

S>·>Но даже в этом случае выбор C++ будет не очевиден. Сейчас есть GPU, FPGA, упомянутый parallel computing и прочие радости.

S>Здесь границы применимости C++ не обсуждаются.
Т.е. применимость java к матрицам — обсуждается, а C++ не обсуждается. Предвзятненько как-то...

S>·>Но объяснить вы затрудняетесь.

S>Вообще-то это очевидно. Подобный ping-pong бенчмарк с двумя рабочими нитями и передачей единичных сообщений в каждую сторону, является самой жесткой проверкой на стоимость передачи одного сообщения между рабочими нитями. Именно здесь видно, сколько стоит передача сообщения.
Обычно это проверяют передачей кучи сообщений от одного producer к одному consumer. И это является более менее реально возможным сценарием. В какой системе может понадобится пинг-понг — для меня загадка.

S>В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики.

Так пачек (batch) сообщений или больших (bulk) сообщений? Это вообще-то немного разные штуки.

S>·>Не вали с больной головы. Ты заявил "вы получите 200M сообщений в секунду". Что, мягко говоря, словоблудие.

S>Ничего подобного. Но т.к. вы в предмете не разбираетесь, то объяснять вам в очередной раз про разницу в нагрузке при большом потоке сообщений (когда batch/bulk обработка используется) и при единичных сообщениях, бесполезно.
И каким же образом получить 200М?

S>·>Где-то выше было сказано, что альтернатива будет — наколенные решения.

S>Вы бы это, раз пришли общаться на русскоязычный форум, язык бы выучили. Поскольку вам русским языком было сказано:
S>

Пока самая большая проблема в продвижении, это не показать, что наш фреймворк быстрее других. А просто рассказать, что местами можно брать готовые фреймворки, а не клепать на коленке свою thread-safe queue и thread-pool в придачу.

S>Тут даже "фреймворки" во множественном числе употреблены, мы не говорили, что наш продукт единственный.
Блин, настолько странное мировосприятие... повеяло IT моего студенчества, что даже не ожидал, MFC, ATL, EJB, CORBA, проекты на sourceforge... Бедный ваш PR. Вместо тривиальной queue и pool предлагаете внезапно тащить в проект какой-то _фреймворк_. Почему эти queue и pool должны быть наколенными — мне вообще непонятно. Тем более слово "фреймворк" в последнее время стало ругательным. Не удивительно, что это самая большая проблема, так слона вы не продадите.

S>·>Это не ниша. Это детали имплементации. Нет такой бизнес-задачи "запускать приложения на нативном языке".

S>Это из-за вашего эээ альтернативного понимания. Видите ли, когда вы можете использовать в своей задаче безопасный язык с GC и, более того, с VM, то вы можете сравнивать Erlang с Akka или Akka с Orleans. Но когда вам нужно писать на C, C++, Ada или Rust-е, то вам результаты замеров Erlang-а или Akka будут, мягко говоря, нерелевантны. Вам нужен будет инструмент для своего нативного языка. Со всей стоимостью, которую за это придется заплатить. И вам нужны будут результаты бенчмарков нативных фреймворков, в которых, например, нет GC и используется либо подсчет ссылок, либо вообще отданная на откуп пользователю преаллокация сообщений. Со всеми вытекающими.
Ну так я и пытаюсь понять, что за такая бизнес-задача? Какого типа системы делаются на базе вашего фреймворка?

S>>>А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются.

S>·>Ок. Какой же тогда смысл запускать Actor Model на одном треде?! Или даже на двух?
S>От задачи зависит. Но т.к. мир C++ от вас бесконечно далек, то посмотрите в качестве примера на Go. Там ведь можно создать 100500 гороутин. И обслуживаться они будут всего несколькими рабочими нитями. Может, по вашему, в этом так же нет смысла?
Горутины это не модель акторов, насколько я знаю.

S>·>Я тебе в четвёртый раз повторяю. В статье Мартина Фаулера неточность или неоднозначность, которую ты не так понимаешь.

S>Вы сколько угодно можете это повторять. Вас интересовало, откуда взялась инфа про рестарты. Вам сказали. Далее можете спорить с Фаулером. Все приведенные здесь цитаты -- это спор о показаниях разных свидетелей, да еще в разное время.
Я не хочу ни с кем спорить по этому поводу. Я знаю факты. Хотите верьте, хотите — нет, фактам ваша религиозная вера не интересна. Более того. Если почитать статью повнимательнее, то неоднозначность становится явной:

Restarting the Business Logic Processor is fast, a full restart — including restarting the JVM, loading a recent snapshot, and replaying a days worth of journals — takes less than a minute ....... they also restart the Business Logic Processors every night

Т.е. тот же самый "restart BLP" упомянут дважды, а restart JVM упомянут лишь в контексте "full restart".

В любом случае. Даже если бы пришлось рестартовать каждый хост в системе каждые 10 минут, это всё не имеет значения, благодаря архитектуре системы, когда копии сервисов запущены одновременно на нескольких хостах:

The replication allows them to do this with no downtime, so they continue to process trades 24/7.

Кстати, ещё одна неточность — у них система 24/5, по выходным торгов нет, биржа не работает.

S>·>Продолжаешь нести бред. Запуск GC тоже давно не делают.

S>Но ведь делали: We used to trigger a manual GC each night in a 5-minute trading gap, and tuned so that would be the only major GC in a day.
S>Это слова того вашего знакомого, на которого вы ссылаетесь.
Ну делали, давным давно перестали. И какой ты делаешь из этого вывод?

S>Опять же, работа без ручного вызова GC лишь за счет Azul Zing -- это еще один признак универсальности Disruptor-а.

Нет, проблема не в универсальности, а в жесткости требований. Задержка более 1ms — являются проблемой, более 10ms — нарушением SLA и звонок от "довольных" клиентов. С вашими блокировками эта задача вообще не решается. А с жутким и ужасным gc на тормознющей яве — задачу решили много лет назад.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[44]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 12.09.18 05:18
Оценка:
Здравствуйте, ·, Вы писали:

·>Я имел в виду решение задач, а не микробенчмарки. Можно найти примеры, где C++ сливает Яве. Будем из этого делать вывод, что и у C++ нет никакой изначальной высокой производительности? Или ты предлагаешь заняться тщательным отбором удобных фактов?


Вы высказали тезис, что изначально высокой производительности нет. В этом вы не правы. Она есть. Все. Дальше вы пытаетесь оправдываться.

·>Обычно это проверяют передачей кучи сообщений от одного producer к одному consumer. И это является более менее реально возможным сценарием. В какой системе может понадобится пинг-понг — для меня загадка.


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

S>>В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики.

·>Так пачек (batch) сообщений или больших (bulk) сообщений? Это вообще-то немного разные штуки.

Если вы пытаетесь провести такой водораздел между batch/bulk, то в случае в batch-ами, например, тормоза с выборкой сообщений из входящих очередей могут с лихвой компенсироваться тем, что из очереди сразу изымается N сообщений. Так, если у вас захват lock-объекта для очереди при изъятии сообщения стоит 1us, но вы забираете сразу 1000 сообщений, то общую производительность (т.е. количество сообщений, принятых для обработки за единицу времени) вы получите большую, чем если вы захватываете lock-объект за 250ns, но забираете из очереди всего одно сообщение.

Если до вас и такое объяснение не дойдет, то медицина здесь уже бессильна.

·>И каким же образом получить 200М?


Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е.

Ну и сразу предупрежу, что в SO-5 вы не получите 200M msg/sec на одном consumer-е, если на входе будет поток единичных сообщений. Даже при том, что некоторые диспетчеры в SO-5 механизм batching-а при извлечении сообщений используют.

·>Вместо тривиальной queue и pool предлагаете внезапно тащить в проект какой-то _фреймворк_. Почему эти queue и pool должны быть наколенными — мне вообще непонятно.


Ну покажите, например, queue и pool в стандартной библиотеке C++.

·>Ну так я и пытаюсь понять, что за такая бизнес-задача?


С вашим эээ альтернативным восприятием вы не сможете, не тратьте время.

·>Какого типа системы делаются на базе вашего фреймворка?


Разные. Из области телекома, платежных сервисов, имитационного моделирования, АСУТП.

·>Горутины это не модель акторов, насколько я знаю.


Ваш альтернативный способ мышления не позволяет проводить аналогии?

·>Хотите верьте, хотите — нет, фактам ваша религиозная вера не интересна.


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

·>Ну делали, давным давно перестали. И какой ты делаешь из этого вывод?

·>Нет, проблема не в универсальности, а в жесткости требований. Задержка более 1ms — являются проблемой, более 10ms — нарушением SLA и звонок от "довольных" клиентов.

Вывод очень простой -- паттерн Disruptor не является универсальным. Это частное решение специфической задачи, да еще заточенное под специфические условия, инструменты и особый режим эксплуатации. А вы, в силу своей альтернативности, пытаетесь сравнивать частные специализированные решения с универсальными фреймворками.

·>С вашими блокировками эта задача вообще не решается.


Не решается. А разве где-то утверждалось обратное?
Более того, тот, кто будет пытаться такую задачу решать на SObjectizer-е, а так же любую другую задачу из области hard real-time, тот просто откровенный идиот.

·>А с жутким и ужасным gc на тормознющей яве — задачу решили много лет назад.


Молодцы. Могли бы еще проще решить на C++, если бы не религиозный фанатизм. Но речь вообще-то не об этом.

А о вашем гавкании "2M msg/sec -- это мало" при абсолютном непонимании того, о чем речь.
Re: Go язык прёт?
От: C0x  
Дата: 12.09.18 08:43
Оценка:
Еще как прет. Я на Go решил делать свой новый сервис. Язык классный, с одной стороны все удобства Си: скорость, развертываемость (тупо скопировал на машину файл и запустил), а с другой стороны синтаксис и garbage collection и гороутины делают программирование приятным как скажем на c# или питоне ))
Re[34]: Go язык прёт?
От: Sharov Россия  
Дата: 12.09.18 09:30
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>На пальцах я уже объяснил — никакой разницы с регексами нет, отличия только в исходном алгоритме построения НКА. Дальше все одинаково.


Вот думается, что не все одинаково. Иначе бы об трубили в трубы, а гугл на счет взрыва для linq молчит.

S>>А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?


НС>Потому что минимизация ДКА и перформанс. Все ровно то же что и с регексами.


Да, но у нас линейная зависимость по числу nested expression. Откуда экспоненциальный взрыв? Работает для каждого expression свой автомат и всех делов.
Кодом людям нужно помогать!
Re[45]: Go язык прёт?
От: · Великобритания  
Дата: 12.09.18 10:31
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>Я имел в виду решение задач, а не микробенчмарки. Можно найти примеры, где C++ сливает Яве. Будем из этого делать вывод, что и у C++ нет никакой изначальной высокой производительности? Или ты предлагаешь заняться тщательным отбором удобных фактов?

S>Вы высказали тезис, что изначально высокой производительности нет. В этом вы не правы. Она есть. Все. Дальше вы пытаетесь оправдываться.
Так где же она? Покажи.

S>·>Так пачек (batch) сообщений или больших (bulk) сообщений? Это вообще-то немного разные штуки.

S>Если вы пытаетесь провести такой водораздел между batch/bulk, то в случае в batch-ами, например, тормоза с выборкой сообщений из входящих очередей могут с лихвой компенсироваться тем, что из очереди сразу изымается N сообщений. Так, если у вас захват lock-объекта для очереди при изъятии сообщения стоит 1us, но вы забираете сразу 1000 сообщений, то общую производительность (т.е. количество сообщений, принятых для обработки за единицу времени) вы получите большую, чем если вы захватываете lock-объект за 250ns, но забираете из очереди всего одно сообщение.
S>Если до вас и такое объяснение не дойдет, то медицина здесь уже бессильна.
Я задал конкретный вопрос — заявленные 200M это для batch или для bulk? Не надо К.О.-шничать.

S>·>И каким же образом получить 200М?

S>Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е.
Так каким образом создать такой поток? Пусть без пинг-понга.

S>Ну и сразу предупрежу, что в SO-5 вы не получите 200M msg/sec на одном consumer-е, если на входе будет поток единичных сообщений. Даже при том, что некоторые диспетчеры в SO-5 механизм batching-а при извлечении сообщений используют.

Ну и? Я знаю как не получить 200М. Я спрашиваю как можно получить 200М. Пока я вижу, только такой вариант: "давайте будем считать что в одном сообщении передаётся 1000 сообщений, то у нас получится 200М". Это мягко говоря словоблудие, т.к. таким образом, т.е. меняя способ подсчёта, можно получить произвольное число и о эффективности передачи ничего не говорит, а только призвано впечатлять невнимательных читателей.

S>·>Вместо тривиальной queue и pool предлагаете внезапно тащить в проект какой-то _фреймворк_. Почему эти queue и pool должны быть наколенными — мне вообще непонятно.

S>Ну покажите, например, queue и pool в стандартной библиотеке C++.
Все решения, которых нет в стандартной библиотеке считаются наколенными? Ну это может только с SObj так... не обобщай.

S>·>Какого типа системы делаются на базе вашего фреймворка?

S>Разные. Из области телекома, платежных сервисов, имитационного моделирования, АСУТП.
Ок. Хорошо, но уже лучше, хоть какя-то конретика. Теперь попробуем извлечь ответ на заданный выше вопрос: что из них ниша "небезопасного нативного языка без сборщика мусора."?

S>·>Горутины это не модель акторов, насколько я знаю.

S>Ваш альтернативный способ мышления не позволяет проводить аналогии?
Мой альтернативный способ мышления не воспринимает аналогии как доказательства. Вопрос был конкретный: "зачем акторы на одном треде?". Вы ответили: "горутины на одном треде". Но горутины это не акторы.

S>·>Хотите верьте, хотите — нет, фактам ваша религиозная вера не интересна.

S>Наш альтернативно одаренный собеседник, еще раз вынуждены вам сообщить о том, что здесь идет вопрос не о вере, а о свидетельских показаниях разных людей в разное время. Мы ничего не придумали, мы привели вам слова одного из свидетелей. Дальше вы с этим можете делать все, что захотите.
Ты привёл слова, но интерпретировал слова неверно, т.к. не знаком с контекстом. Ты ошибся, но из-за своей упёртости не хочешь признавать ошибку.

S>·>Ну делали, давным давно перестали. И какой ты делаешь из этого вывод?

S>·>Нет, проблема не в универсальности, а в жесткости требований. Задержка более 1ms — являются проблемой, более 10ms — нарушением SLA и звонок от "довольных" клиентов.
S>Вывод очень простой -- паттерн Disruptor не является универсальным. Это частное решение специфической задачи, да еще заточенное под специфические условия, инструменты и особый режим эксплуатации. А вы, в силу своей альтернативности, пытаетесь сравнивать частные специализированные решения с универсальными фреймворками.
ЧТД — неверный вывод из ошибочной посылки. Вот к чему приводит упёртое невежество.
Вообще-то disruptor это не совсем верно называеть паттерном, это название библиотеки. Паттерн, который там используется называется ring buffer. Просто библиотекой он доведён до такого состояния, что он стал более универсальным, т.к. позволяет обеспечить различные схемы взаимодействия продьюсеров и консьюмеров, тогда как классический ring buffer обычно подразумевает 1p-1c.

S>·>С вашими блокировками эта задача вообще не решается.

S>Не решается. А разве где-то утверждалось обратное?
Было что-то там про универсальность...

S>Более того, тот, кто будет пытаться такую задачу решать на SObjectizer-е, а так же любую другую задачу из области hard real-time, тот просто откровенный идиот.

Ты почему-то предполагаешь, что disruptor или ring buffer применяется только в RT. Это не так.

S>·>А с жутким и ужасным gc на тормознющей яве — задачу решили много лет назад.

S>Молодцы. Могли бы еще проще решить на C++, если бы не религиозный фанатизм. Но речь вообще-то не об этом.
Если бы кабы, может и могли, может и не могли. И уж точно не проще. У C++, особенно по состоянию ~7 лет назад, много своих заморочек. Но ты главное — верь!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[46]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 12.09.18 11:24
Оценка: -3
Здравствуйте, ·, Вы писали:

·>Так где же она?


Русский выучите. Потом перечитайте внимательно и вдумчиво:

Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.


·>Я задал конкретный вопрос — заявленные 200M это для batch или для bulk? Не надо К.О.-шничать.


Русский выучите. Потом перечитайте внимательно и вдумчиво:

Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.


S>>Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е.

·>Так каким образом создать такой поток? Пусть без пинг-понга.

От нескольких producer-ов, к примеру. Которые шлют сообщения с заданным темпом, не ожидая подтверждения от consumer-а. Ваш К.О.

·>Ну и?


42.

·>Я спрашиваю как можно получить 200М.


Русский выучите. Потом перечитайте внимательно и вдумчиво:

Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.


·>Пока я вижу, только такой вариант: "давайте будем считать что в одном сообщении передаётся 1000 сообщений, то у нас получится 200М". Это мягко говоря словоблудие


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

S>>Ну покажите, например, queue и pool в стандартной библиотеке C++.

·>Все решения, которых нет в стандартной библиотеке считаются наколенными?

Есть то, что в stdlib, есть публично доступные библиотеки, есть наколенные. Отличий доступных библиотек от наколенных разработок не так много.

·>Что из них ниша "небезопасного нативного языка без сборщика мусора."?


Ниша "небезопасного нативного языка без сборщика мусора" -- это разработка софта, где требуется нативный код и нельзя использовать сборщик мусора, ваш К.О. Требуется такая разработка во множестве прикладных применений. Начиная от бортового ПО для марсоходов и заканчивая разгоном PHP кода.

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

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


Во-первых, ваш альтернативный способ мышления пытается найти доказательства там, где их нет. Во-вторых, ваш альтернативный способ мышления не позволяет вам задуматься о том, почему гороутины мапятся на нити ОС как M:N. Если бы вы задумались, вы бы поняли, какой в этом смысл. А поняв смысл, вы бы поняли, почему тоже самое работает и с Акторами.

Но не судьба.

·>Вы ответили: "горутины на одном треде"


Ответ был не таким. Но тут мы опять возвращаемся к русскому языку.

·>тогда как классический ring buffer обычно подразумевает 1p-1c.


Мать-мать-мать. Да вы просто клинический случай.

S>>·>С вашими блокировками эта задача вообще не решается.

S>>Не решается. А разве где-то утверждалось обратное?
·>Было что-то там про универсальность...

Дословно было следующее:

Если вы еще о чем-то захотите поспорить со взятыми с потолка цифрами, то давайте мы вам сперва простую вещь объясним. Есть универсальные фреймворки. Для C++ это SObjectizer, CAF, QP/C++. Для JVM -- Akka, Vert.x. Для .NET -- Orleans. Универсальность означает, что эти фреймворки могут использоваться для разных задач и разных сценариев.

Наряду с этим есть и специализированные решения, заточенные либо под какой-то сценарий (вроде Disruptor-а), либо под какую-то специфическую задачу и железо.

Так вот, существует очевидная вещь: производительность универсальных фреймворков будет ниже, чем специализированных решений. И это нормально. Т.к. цели у инструментов разные.


Так вот еще раз, специально для клинических идиотов: SObjectizer, CAF, Akka, Vert.x и пр. -- это универсальные фреймворки. А вот Disruptor -- нет. И попытка сравнения универсальных фреймворков со специализированными, да еще на сценариях, под которые специализированные заточены -- это очевидный идиотизм.

Ну и контрольный вопрос: где утверждалось, что SObjectizer заточен под задачи реального времени?
Re[47]: Go язык прёт?
От: · Великобритания  
Дата: 12.09.18 13:01
Оценка:
Здравствуйте, so5team, Вы писали:

S>·>Так где же она?

S>Русский выучите. Потом перечитайте внимательно и вдумчиво:
S>

Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.

О чём я и говорю — выбираем только удобные факты и делаем выводы вселенского масштаба. А давай сравним не какие-нибудь вычисления, а какие-нибудь веб-сервисы?

S>·>Я задал конкретный вопрос — заявленные 200M это для batch или для bulk? Не надо К.О.-шничать.

S>Русский выучите. Потом перечитайте внимательно и вдумчиво:
S>

Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.

Цитировать умеешь. А за контекстом следить не умеешь. Этот вопрос я задал на это высказывание: "В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики".

S>>>Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е.

S>·>Так каким образом создать такой поток? Пусть без пинг-понга.
S>От нескольких producer-ов, к примеру. Которые шлют сообщения с заданным темпом, не ожидая подтверждения от consumer-а. Ваш К.О.
А ты попробуй. Все эти твои продьюсеры будут драться за один лок и всё станет только медленее.

S>·>Я спрашиваю как можно получить 200М.

S>Русский выучите. Потом перечитайте внимательно и вдумчиво:
S>

Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.

Ок, согласен, слажал. Просто я почему-то надеялся на чудо, что это какой-то реальный результат (С++ же, высокая производительность как таковая же), а не китайские ватты, манипуляции цифрами рассчитанные на неграмотных.

S>·>Пока я вижу, только такой вариант: "давайте будем считать что в одном сообщении передаётся 1000 сообщений, то у нас получится 200М". Это мягко говоря словоблудие

S>Словоблудием и тормозами пока здесь отличаетесь только вы.
S>А то, что было сказано про пакетирование сообщений -- это обычный инженерный подход.
Верно. Но когда измеряют характеристики системы передачи сообщений, измеряют количество переданных сообщений, а не интерпретацию содержимого этих сообщений.

S>>>Ну покажите, например, queue и pool в стандартной библиотеке C++.

S>·>Все решения, которых нет в стандартной библиотеке считаются наколенными?
S>Есть то, что в stdlib, есть публично доступные библиотеки, есть наколенные. Отличий доступных библиотек от наколенных разработок не так много.
А чем stdlib не публично доступная библиотека?

S>·>Что из них ниша "небезопасного нативного языка без сборщика мусора."?

S>Ниша "небезопасного нативного языка без сборщика мусора" -- это разработка софта, где требуется нативный код и нельзя использовать сборщик мусора, ваш К.О. Требуется такая разработка во множестве прикладных применений. Начиная от бортового ПО для марсоходов и заканчивая разгоном PHP кода.
В смысле у вас телеком на марсоходах или АСУТП на php? SObj-то тут причём?

S>·>Мой альтернативный способ мышления не воспринимает аналогии как доказательства.

S>Во-первых, ваш альтернативный способ мышления пытается найти доказательства там, где их нет. Во-вторых, ваш альтернативный способ мышления не позволяет вам задуматься о том, почему гороутины мапятся на нити ОС как M:N. Если бы вы задумались, вы бы поняли, какой в этом смысл. А поняв смысл, вы бы поняли, почему тоже самое работает и с Акторами.
Понятно. Доказательство аналогией. Фтопку.

S>Так вот еще раз, специально для клинических идиотов: SObjectizer, CAF, Akka, Vert.x и пр. -- это универсальные фреймворки. А вот Disruptor -- нет. И попытка сравнения универсальных фреймворков со специализированными, да еще на сценариях, под которые специализированные заточены -- это очевидный идиотизм.

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

S>Ну и контрольный вопрос: где утверждалось, что SObjectizer заточен под задачи реального времени?

А кто утверждал, что Disruptor только для задач реального времени? Сконфигурил waitStrategy=blocking — и вот никакого РТ. Такой универсальности SObj-у и не снилось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[35]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 12.09.18 13:32
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

S>Вот думается, что не все одинаково.


Да ради бога.

S> Иначе бы об трубили в трубы, а гугл на счет взрыва для linq молчит.


Потому что в linq этого нет. Там автомат генерируется только для одного метода. Вложенные вызовы только через foreach, т.е. остается неоптимизированный НКА и стадии сборки автомата и преобразования его в ДКА нет.

S>>>А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?

НС>>Потому что минимизация ДКА и перформанс. Все ровно то же что и с регексами.
S>Да, но у нас линейная зависимость по числу nested expression. Откуда экспоненциальный взрыв? Работает для каждого expression свой автомат и всех делов.

Для каждого экспрешена свой автомат это НКА.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[48]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 12.09.18 13:39
Оценка: -1 :)
Здравствуйте, ·, Вы писали:

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

Поэтом кратко и тезисно.

SObjectizer -- это универсальный фреймворк. Универсальные фреймворки, т.к. Akka, Orleans, CAF, SObjectizer и пр. всегда будут проигрывать специализированным решениям. Например, таким, как Disruptor, особенно когда этот Disruptor работает в специализированной конфигурации для биржи.

Вам кажется, что 2M msg/sec на честном ping-pong-е -- это мало. Нет проблем, возьмите любой другой универсальный фреймворк и сравните, если вам это интересно.

Вы не видите смысла в таком бенчмарке? Не вопрос. Не видите, значит не видите. Значит 2M msg/sec для вас вообще не имеет значения.

Вы хотите иметь 200M прикладных сообщений в секунду? Вариант, как это получить в SObjectizer вам сказали. Не нравится? Да не вопрос. Можете попробовать получить эти цифры с любым другим универсальным фреймворком, любым удобным для вас способом.

SObjectizer -- это решение для C++. Видите ли вы ниши для C++ или не видите -- это не важно. SObjectizer предназначен для C++ и здесь он конкурирует с другими такими же фреймворками (коих не много). Сравнение производительности с ближайшим конкурентом мы сделали. Сравнение с решениями для других языков мы не делаем, т.к. не видим в этом смысла. Нравится вам это или не нравится -- это не важно. Кто хочет получить такие сравнения может сделать их самостоятельно, благо все лежит в открытом доступе.

Не понимаете, зачем привязывать несколько акторов к одной рабочей нити? Это проблема вашего образования. Никто вас учить не будет, благо доступной информации в интернете в избытке. Изучите матчасть. Посмотрите на то, как работают диспетчеры в той же Akka. Почему гороутины в Go мапятся на реальные нити M:N. Может даже дойдете до того, что модели CSP и Actors обладают рядом сходств и могут выражаться одна через другую.


Как-то так. Будете тупить и демонстрировать непонимание, общаться дальше будете в одиночестве.
Re[49]: Go язык прёт?
От: · Великобритания  
Дата: 12.09.18 14:00
Оценка:
Здравствуйте, so5team, Вы писали:

S>Как-то так. Будете тупить и демонстрировать непонимание, общаться дальше будете в одиночестве.

И вам успехов в PR.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Go язык прёт?
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.18 04:44
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ровно как практически нет С++ в вебе, кроме небольшого количества узкоспециализированных сервисов. Да и с поиском у тебя смешно получилось. В сегменте локальных поисковых сервисов однозначный лидер — Эластик. Ну и ELK на его основе для логов. А он, о ужас, на джаве писан, а вовсе не на С++.
Ну и Bing, не забываем, писан аккурат на шарпе.
Хреновая релевантность там никак не связана с ЯП или платформой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 01.10.18 22:26
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Еще как прет. Я на Go решил делать свой новый сервис. Язык классный, с одной стороны все удобства Си: скорость, развертываемость (тупо скопировал на машину файл и запустил), а с другой стороны синтаксис и garbage collection и гороутины делают программирование приятным как скажем на c# или питоне ))


Я тут прочитал на выходных Go blueprints. Хочется больше почитать, а что именно? Интересует меня практический вопрос: какие в Go есть либы/фреймворки, чтобы «из коробки» actions от redux-а и потом push-notifications на клиента? Какие есть либы, чтобы генерить интерфейсы в Go на JSON- сообщения (из protobuf или из pojo java- есть генераторы в typescript), а не дублировать вручную описания?
Re[3]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 01.10.18 22:49
Оценка: 6 (1)
Здравствуйте, Тёмчик, Вы писали:

Тё>Я тут прочитал на выходных Go blueprints. Хочется больше почитать, а что именно? Интересует меня практический вопрос: какие в Go есть либы/фреймворки, чтобы «из коробки» actions от redux-а и потом push-notifications на клиента? Какие есть либы, чтобы генерить интерфейсы в Go на JSON- сообщения (из protobuf или из pojo java- есть генераторы в typescript), а не дублировать вручную описания?


https://github.com/avelino/awesome-go
Re[3]: Go язык прёт?
От: C0x  
Дата: 02.10.18 07:32
Оценка: 6 (1)
Здравствуйте, Тёмчик, Вы писали:

Тё>Я тут прочитал на выходных Go blueprints. Хочется больше почитать, а что именно? Интересует меня практический вопрос: какие в Go есть либы/фреймворки, чтобы «из коробки» actions от redux-а и потом push-notifications на клиента? Какие есть либы, чтобы генерить интерфейсы в Go на JSON- сообщения (из protobuf или из pojo java- есть генераторы в typescript), а не дублировать вручную описания?


Я советую сюда заглянуть: https://forum.golangbridge.org/

Я все ответы нахожу в Гугле по теме какие библиотеки использовать. Благо на Github их уже навалом. Из последней радости которую я раскопал и использую: bbolt — встроенная в приложение No SQL база данных. Тем самым не нужны мне больше Postgres, MySQL и прочие сервисы.
Re: Go язык прёт?
От: iHateLogins  
Дата: 09.10.18 01:00
Оценка: +5
Здравствуйте, Тёмчик, Вы писали:

Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?


После сишарпа гоу кажется как если бы пересел с последней топовой бэхи на ЗАЗ 968.
Re: Go язык прёт?
От: reversecode google
Дата: 15.10.18 09:09
Оценка:
слился гоу при нагрузке
https://oatpp.io/benchmark/aws
С++ его порвал как тузик грелку
Re[2]: Go язык прёт?
От: C0x  
Дата: 15.10.18 10:07
Оценка:
Здравствуйте, reversecode, Вы писали:

R>слился гоу при нагрузке

R>https://oatpp.io/benchmark/aws
R>С++ его порвал как тузик грелку

Нагрузку по кол-ву коннетов сравнивали? Исходный код самих тестов не нашел.
Re[24]: Go язык прёт?
От: Hardballer  
Дата: 15.10.18 10:11
Оценка: 4 (1) :)
Здравствуйте, AlexRK, Вы писали:

ARK>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.


Да ну? :D
Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#
Re[3]: Go язык прёт?
От: reversecode google
Дата: 15.10.18 10:15
Оценка:
смеeтесь ?
там по ссылкам же все есть на гитхабе
https://github.com/oatpp/benchmark
Re[25]: Go язык прёт?
От: C0x  
Дата: 15.10.18 10:18
Оценка:
Здравствуйте, Hardballer, Вы писали:

H>Здравствуйте, AlexRK, Вы писали:


ARK>>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.


H>Да ну? :D

H>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#

Тут слишком много вопросов: какое железо использовалось? А с аналогичным на С++ кодом сравнивали? А что там вообще на С# написано, может там голый Си на 80% а на C# только обертка красивая? и т.д. и т.п.
Re[4]: Go язык прёт?
От: C0x  
Дата: 15.10.18 10:18
Оценка:
Здравствуйте, reversecode, Вы писали:


R>смеeтесь ?

R>там по ссылкам же все есть на гитхабе
R>https://github.com/oatpp/benchmark

Сорри, ступил.
Re[26]: Go язык прёт?
От: Hardballer  
Дата: 15.10.18 10:39
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Здравствуйте, Hardballer, Вы писали:


H>>Здравствуйте, AlexRK, Вы писали:


ARK>>>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.


H>>Да ну? :D

H>>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#

C0x>Тут слишком много вопросов: какое железо использовалось? А с аналогичным на С++ кодом сравнивали? А что там вообще на С# написано, может там голый Си на 80% а на C# только обертка красивая? и т.д. и т.п.


Железо неплохое, сам HFT Server это DELL PowerEdge R640 DX292 в не самой плохой конфигурации, но и не топовой-64 физических ядра, 256Гб памяти. Дисковое хранилище датафида на другом сервере находится, который заточен именно под быструю запись(на таких скоростях исполнения ордеров запись самого датафида ордеров еще та задачка, как и распухание БД под хранение).
На плюсах подобное в удобоваримые сроки ИМХО не сделать.
C# там везде.
А так NDA. Ждите публичную бету
Re[2]: Go язык прёт?
От: DTB Россия  
Дата: 15.10.18 10:40
Оценка:
Здравствуйте, reversecode, Вы писали:

R>слился гоу при нагрузке

R>https://oatpp.io/benchmark/aws
R>С++ его порвал как тузик грелку

ну так там же видно, что на нормальном сервере результаты практически одинаковы после 1000 соединений на aws и на 5000 на digital ocean

не все так однозначно (ц), это при том, что стандарный net/http у golang никогда не считался быстрым, взять тот же fasthttp, который должен быть пошустрее
Have fun...
Re[3]: Go язык прёт?
От: reversecode google
Дата: 15.10.18 10:46
Оценка:
напишите это автору
сделайте вместе новые тесты
Re[4]: Go язык прёт?
От: torvic Голландия  
Дата: 15.10.18 11:05
Оценка:
Здравствуйте, reversecode, Вы писали:
R>напишите это автору
ему уже написали на редите
и про fasthttp
и про techEmpower, а не самопальные hello word-ы
Re[5]: Go язык прёт?
От: C0x  
Дата: 15.10.18 11:06
Оценка:
Здравствуйте, torvic, Вы писали:


T>ему уже написали на редите


А можно ссылку на дискуссию?
Спасибо.
Re[6]: Go язык прёт?
От: torvic Голландия  
Дата: 15.10.18 11:15
Оценка:
Здравствуйте, C0x, Вы писали:
C0x>А можно ссылку на дискуссию?
https://www.reddit.com/r/cpp/comments/9ntgap/benchmarks_coat_vs_gonethttp_on_aws_cloud_t2micro/
Re[2]: Go язык прёт?
От: smeeld  
Дата: 15.10.18 11:31
Оценка:
Здравствуйте, reversecode, Вы писали:

R>слился гоу при нагрузке


Нашли с чем сравнивать. C C++ они сравнили. Конечно Go сольёт C++-ам, это без бенмарков ясно. Там одного GC хватит чтоб слить в нагрузке. Go ЯП другого класса, его сравнивать нужно с java, C#, python etc.
Re[25]: Go язык прёт?
От: · Великобритания  
Дата: 15.10.18 11:37
Оценка:
Здравствуйте, Hardballer, Вы писали:

ARK>>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.

H>Да ну? :D
H>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#
Ты по-моему яблоки с апельсинам сравниваешь. Orderbook вроде должен быть однопоточный. Если оно у тебя параллелится, то это значит что у тебя 1024 orderbook-а. Если так можно, то такое лучше завести на на десятке серверов, для надёжности. Получается, что это 1000 ордеров в секунду на один поток... много что-ли? Да и самое хитрое — шедулер потоков — ложится на операционку.
А гистограмма latency какая?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 15.10.18 11:42
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Конечно Go сольёт C++-ам, это без бенмарков ясно.


Обогнать Go с fasthttp не так-то и просто. Пикантности ситуации добавляет еще и то, что oat++ -- это совсем новый фреймворк с, AFAIK, самописным HTTP-парсером. Насколько этот фреймворк устойчив и надежен, пока мало кто знает (включая и самого автора oat++).
Re[26]: Go язык прёт?
От: Hardballer  
Дата: 15.10.18 11:48
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, Hardballer, Вы писали:


ARK>>>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.

H>>Да ну? :D
H>>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#
·>Ты по-моему яблоки с апельсинам сравниваешь. Orderbook вроде должен быть однопоточный. Если оно у тебя параллелится, то это значит что у тебя 1024 orderbook-а. Если так можно, то такое лучше завести на на десятке серверов, для надёжности. Получается, что это 1000 ордеров в секунду на один поток... много что-ли? Да и самое хитрое — шедулер потоков — ложится на операционку.
·>А гистограмма latency какая?
OrderBook однопоточный и есть(в таком режиме он 6М выдает), а вот вся сетевая обвязка, валидация входящих ордеров, выхлоп исполнения ордеров в сеть, укладывание в хранилище и прочая бижутерия, вроде трансляции на сервер рынка и истории-многопоточная(и все эти издержки в разы режут пиковый перформанс, в том числе из-за необходимости раскидывать данные по множеству потоков).
95% в 3мс укладывается, включая затраты на ping(это если с горкой наваливать ордера).
А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.
Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
Отредактировано 15.10.2018 11:59 Hardballer . Предыдущая версия . Еще …
Отредактировано 15.10.2018 11:57 Hardballer . Предыдущая версия .
Отредактировано 15.10.2018 11:56 Hardballer . Предыдущая версия .
Re[27]: Go язык прёт?
От: StanislavK Великобритания  
Дата: 15.10.18 12:19
Оценка:
Здравствуйте, Hardballer, Вы писали:

H>Здравствуйте, ·, Вы писали:


H>·>Здравствуйте, Hardballer, Вы писали:


H>OrderBook однопоточный и есть(в таком режиме он 6М выдает),

Перефразируя, это это 1us на апдейт структуры в пямяти с сортировками и плюшками. Ну так, средненько. На яве делали за 250-300ns даже не особо не оптимизируя, давно еще лет 7 назад. Сколько уровней в книжке?

H>95% в 3мс укладывается, включая затраты на ping(это если с горкой наваливать ордера).

Я это время успеваю кофе налить и выпить! И обычно принято говорить как минимум о 99.99%.

H>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.

H>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
А зачем вам больше потоков чем ядер? Вроде же речь шла о 1024 потоках.
Re[4]: Go язык прёт?
От: smeeld  
Дата: 15.10.18 12:37
Оценка:
Здравствуйте, so5team, Вы писали:


S>Обогнать Go с fasthttp не так-то и просто.


Тестировали у себя это fasthttp и http движок из Аpache Traffiсserver (превратив его в http сервер, работающий на отдачу). На нагрузочных тестах гошка сливал в 1.5-2 раза по всем параметрам. И при этом, во столько же раз больше съедал ресурсов. Короче, качественная реализация системы на C++ в любом случае уделает аналогичную, но на Go. Go c С/C++ пусть даже не конкурирует.
Re[5]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 15.10.18 13:23
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Тестировали у себя это fasthttp и http движок из Аpache Traffiсserver (превратив его в http сервер, работающий на отдачу). На нагрузочных тестах гошка сливал в 1.5-2 раза по всем параметрам. И при этом, во столько же раз больше съедал ресурсов. Короче, качественная реализация системы на C++ в любом случае уделает аналогичную, но на Go. Go c С/C++ пусть даже не конкурирует.


Применительно к вышеупомянутому oat++ тут вот какой фокус: в Go любой мало-мальски знающий язык программист может затащить к себе fasthttp и получить в своем приложении HTTP-вход с весьма высокой производительностью. В C++ сделать это не так просто. Вот тот же Trafficserver интегрировать в свое приложение -- это может быть тот еще квест.
Re[27]: Go язык прёт?
От: · Великобритания  
Дата: 15.10.18 13:26
Оценка:
Здравствуйте, Hardballer, Вы писали:

H>>>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#

H>·>Ты по-моему яблоки с апельсинам сравниваешь. Orderbook вроде должен быть однопоточный. Если оно у тебя параллелится, то это значит что у тебя 1024 orderbook-а. Если так можно, то такое лучше завести на на десятке серверов, для надёжности. Получается, что это 1000 ордеров в секунду на один поток... много что-ли? Да и самое хитрое — шедулер потоков — ложится на операционку.
H>·>А гистограмма latency какая?
H>OrderBook однопоточный и есть(в таком режиме он 6М выдает), а вот вся сетевая обвязка, валидация входящих ордеров, выхлоп исполнения ордеров в сеть, укладывание в хранилище и прочая бижутерия, вроде трансляции на сервер рынка и истории-многопоточная(и все эти издержки в разы режут пиковый перформанс, в том числе из-за необходимости раскидывать данные по множеству потоков).
H>95% в 3мс укладывается, включая затраты на ping(это если с горкой наваливать ордера).
А failover/recoverу как обеспечивается?

H>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.

H>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
Ну да... Зачем тогда 1к потоков? Их должно быть не больше чем физических ядер, иначе переключений и прочего не избежать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Go язык прёт?
От: Hardballer  
Дата: 15.10.18 13:31
Оценка:
Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, Hardballer, Вы писали:


H>>Здравствуйте, ·, Вы писали:


H>>·>Здравствуйте, Hardballer, Вы писали:


H>>OrderBook однопоточный и есть(в таком режиме он 6М выдает),

SK>Перефразируя, это это 1us на апдейт структуры в пямяти с сортировками и плюшками. Ну так, средненько. На яве делали за 250-300ns даже не особо не оптимизируя, давно еще лет 7 назад. Сколько уровней в книжке?

1 миллиард(можно и больше, если памяти хватит). Сколько транслируется уровней наружу, зависит от настроек-сейчас 90.

H>>95% в 3мс укладывается, включая затраты на ping(это если с горкой наваливать ордера).

SK>Я это время успеваю кофе налить и выпить! И обычно принято говорить как минимум о 99.99%.

10 мс при нагрузке "ордера в навал". И не на топовом оборудовании, к слову.

H>>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.

H>>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
SK>А зачем вам больше потоков чем ядер? Вроде же речь шла о 1024 потоках.
Поток пристегивается к TCP/IP коннекту и обслуживает только его в первичном парсинге, валидации и прочем.
Отредактировано 15.10.2018 13:40 Hardballer . Предыдущая версия . Еще …
Отредактировано 15.10.2018 13:37 Hardballer . Предыдущая версия .
Re[28]: Go язык прёт?
От: Hardballer  
Дата: 15.10.18 13:39
Оценка:
Здравствуйте, ·, Вы писали:

·>А failover/recoverу как обеспечивается?

NDA
H>>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.
H>>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
·>Ну да... Зачем тогда 1к потоков? Их должно быть не больше чем физических ядер, иначе переключений и прочего не избежать.
Зависит от профиля нагрузки.
Если придет 1024 клиента, пишущих в стакан, то эффективнее держать для каждого свой поток.
Re[29]: Go язык прёт?
От: · Великобритания  
Дата: 15.10.18 13:49
Оценка:
Здравствуйте, Hardballer, Вы писали:

H>·>А failover/recoverу как обеспечивается?

H>NDA
Хм. Ясно, расскажи, как публично станет.

H>>>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.

H>>>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
H>·>Ну да... Зачем тогда 1к потоков? Их должно быть не больше чем физических ядер, иначе переключений и прочего не избежать.
H>Зависит от профиля нагрузки.
H>Если придет 1024 клиента, пишущих в стакан, то эффективнее держать для каждого свой поток.
Да ладно? Кабель-то всё равно один, и сетевуха одна и буфер у неё один — всё равно последовательно передача происходит, накой потоки?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Go язык прёт?
От: C0x  
Дата: 15.10.18 14:12
Оценка:
Здравствуйте, ·, Вы писали:

·>Да ладно? Кабель-то всё равно один, и сетевуха одна и буфер у неё один — всё равно последовательно передача происходит, накой потоки?


За тем наверно, что могут быть ожидания в процессе работы потоков. Пусть даже миллисекундные. Например обрабатывающий поток делает запрос в базу, в этот момент зачем ему кушать процессор? Пусть принимает новые коннекты и обрабатывает.
Re[31]: Go язык прёт?
От: · Великобритания  
Дата: 15.10.18 14:26
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>·>Да ладно? Кабель-то всё равно один, и сетевуха одна и буфер у неё один — всё равно последовательно передача происходит, накой потоки?

C0x>За тем наверно, что могут быть ожидания в процессе работы потоков.
Ожидание в hft — смерти подобно!

C0x>Пусть даже миллисекундные.

Время там в наносекундах измеряются. 1 миллисекунда это уже пипец как долго.

C0x>Например обрабатывающий поток делает запрос в базу,

База в hft?!

C0x>в этот момент зачем ему кушать процессор?

Там busyspin делают и жгут процессор, чтобы не дай боже поток не вытеснился.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: Go язык прёт?
От: reversecode google
Дата: 15.10.18 14:27
Оценка:
так запрос к базе тоже не блокирующий ИО
Re[6]: Go язык прёт?
От: reversecode google
Дата: 15.10.18 14:31
Оценка:
вывод — маломайские программисты используют только гоу

так а как же ваш фреймворк, разве он не для этого создавался ?
Re[7]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 15.10.18 14:42
Оценка:
Здравствуйте, reversecode, Вы писали:

R>вывод — маломайские программисты используют только гоу


А так оно и есть.

R>так а как же ваш фреймворк, разве он не для этого создавался ?


Для этого. И в начале мы сравнивали себя с Go-ными реализациями. ЕМНИП, go/http обходится довольно легко. С fasthttp ходили ноздря в ноздрю. Но мы не делали таких больших замеров, чтобы 30K параллельных клиентов висело. Да не просто висело, а активно грузило сервак запросами.
Re[32]: Go язык прёт?
От: C0x  
Дата: 15.10.18 14:47
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, C0x, Вы писали:


C0x>>·>Да ладно? Кабель-то всё равно один, и сетевуха одна и буфер у неё один — всё равно последовательно передача происходит, накой потоки?

C0x>>За тем наверно, что могут быть ожидания в процессе работы потоков.
·>Ожидание в hft — смерти подобно!

Я не в теме к сожалению. Если там так все страшно, то тогда наверно нужно специальное железо делать для таких задач, а не с софтом извращаться. А все что касается софта на асме писать для этих спец машин.
А уж если там люди выбирают Си# и Java то видимо все не так страшно
Re[33]: Go язык прёт?
От: · Великобритания  
Дата: 15.10.18 15:12
Оценка: :)
Здравствуйте, C0x, Вы писали:

C0x>>>За тем наверно, что могут быть ожидания в процессе работы потоков.

C0x>·>Ожидание в hft — смерти подобно!
C0x>Я не в теме к сожалению. Если там так все страшно, то тогда наверно нужно специальное железо делать для таких задач, а не с софтом извращаться. А все что касается софта на асме писать для этих спец машин.
Тут такая особенность, что такое не получается, как например, один раз реализовали какой-нибуь там h.264 в железе и забыли... А тут вся эта бизнес-логика постоянно меняется. Начиная с регуляторов, то там mifid ii, то brexit, то finfrag, не говоря уж о том, что собственно хотелки самих htf-компаний — и это всё ваять в железе в темпе вальса довольно проблематично. Железо — довольно сложен весь процесс разработки. На асме писать код, чтоб было быстро на современных процах — человекам практически не под силу, компиляторы с этим справляются лучше.

C0x>А уж если там люди выбирают Си# и Java то видимо все не так страшно

Нет, просто миф о том, что Java и (судя по тому что говорит Hardballer) C# тормозные — таки миф.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Go язык прёт?
От: Cyberax Марс  
Дата: 15.10.18 16:49
Оценка: 4 (1)
Здравствуйте, reversecode, Вы писали:

R>слился гоу при нагрузке

R>https://oatpp.io/benchmark/aws
R>С++ его порвал как тузик грелку
Тест на t2.micro — facepalm.

Для тех кто не знает, t2/t3 инстансы — это разделяемое железо с прозрачной миграцией контейнеров и жёстким CPU throttling. Но там есть burst bucket, который временно даёт контейнерам дополнительные квоты на CPU.

Т.е. делать какие-либо сравнения на t2/t3 — это идиотизм.
Sapienti sat!
Re[4]: Go язык прёт?
От: reversecode google
Дата: 16.10.18 09:19
Оценка:
что то я так мельком глянул имплементацию корутин в гоу
и она мне показалась более тяжелой чем в бусте

вообще полистал пару видосов кекса который fasthttp написал
он какой то топорный, про С++ ничего не знает, в одной конфе пытался типа показать как в гоу все круто с корутинами
задал вопрос в зал а как там в других языках, потом увел тему
про мютексы тоже мало что знает во внутренностях, начал заплетаться сам в своих расcказах

парсер http который в fasthttp я бы сказал так себе, в том же nginx намного оптимальнее и лучше
так что вся крутость fasthttp только в том что оно производительнее стандартной библиотечной
ну а поскольку язык "новый" а реализаций чего либо крайне мало
то любую маломайскую поделку гоуисты сразу поднимают на ура
Re[5]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 16.10.18 11:39
Оценка:
Здравствуйте, reversecode, Вы писали:

R>что то я так мельком глянул имплементацию корутин в гоу

R>и она мне показалась более тяжелой чем в бусте

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

Этого нет в короутинах из Boost-а.

R>то любую маломайскую поделку гоуисты сразу поднимают на ура


Ну вот подняли и довели fasthttp до вполне себе хорошего состояния. Просто так слепить аналог на коленке, который бы сильно обгонял fasthttp, пусть даже аналог и на C++ будет написан, не получится.
Re[6]: Go язык прёт?
От: C0x  
Дата: 16.10.18 11:42
Оценка:
Здравствуйте, so5team, Вы писали:

S>Здравствуйте, reversecode, Вы писали:


R>>что то я так мельком глянул имплементацию корутин в гоу

R>>и она мне показалась более тяжелой чем в бусте

А можно подробнее? Что именно там утежеляет горотины в сравнении с бустом?
Re[6]: Go язык прёт?
От: reversecode google
Дата: 16.10.18 12:12
Оценка:
корутина-горутина это переключение стека
они стекфул
есть асм функции(для разных архитектур) переключение стека на бусте
и есть те же асм функции переключения в гоу
так вот по объему подготовке и переключение
не вникал глубоко но бегло в гоу выглядит тяжелее

яндекс вон ушел дальше, и чуть чуть подправил бустовое переключение стека флагом,
что бы если FPU не используется, то не сохранять и не восстанавливать контекст FPU
и реализовал размазивание корутин по доступным ЦПУ в системе


так что размазать корутинами по цпу на С++ ну вообще сложности нет
ну ок, в гоу это возможно сделали "из коробки"

проблемы обогнать fasthttp нет, есть другая проблема
С++ шники более скрытны и свои имплементации — решениями не очень любят делиться или публиковать
Re[7]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 16.10.18 12:44
Оценка:
Здравствуйте, reversecode, Вы писали:

R>С++ шники более скрытны и свои имплементации — решениями не очень любят делиться или публиковать


Да ладно. Вообще не припоминается ни одного закрытого embeddable HTTP server-а для C++. Boost.Beast, Pistache, C++REST SDK, Silicon, CROW, RestBed, RESTinio, cpp-httplib, served. Все открытые и большинство под более чем либеральными лицензиями.
Re[8]: Go язык прёт?
От: reversecode google
Дата: 16.10.18 12:53
Оценка:
не использую ни один из них
они топорные
тема веб серверов вообще
ничего нормального С++ в опенсорсе нет
можете не перечислять,я в теме большинства решений

ps кстати на видео докладе автора fasthttp вначале спросили а что там под капотом у вас
он замялся, что то там начал придумывать, потом сказал аааааа ну с strace под линуксом видно епулл юзается

вот до чего доводит знание гоу ...
Re[9]: Go язык прёт?
От: smeeld  
Дата: 16.10.18 13:11
Оценка:
Здравствуйте, reversecode, Вы писали:

R>вот до чего доводит знание гоу ...


Тема квалификации гошников мусолится.
Re[9]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 16.10.18 13:13
Оценка: +1
Здравствуйте, reversecode, Вы писали:

R>не использую ни один из них

R>они топорные

А что не топорное?

R>тема веб серверов вообще

R>ничего нормального С++ в опенсорсе нет

А не в оперсорсе?

R>вот до чего доводит знание гоу ...


Есть мнение, что многие современные разработчики что-либо за рамками Go просто не смогут освоить.
Re[10]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 16.10.18 13:15
Оценка: -1 :)))
Здравствуйте, so5team, Вы писали:

S>Есть мнение, что многие современные разработчики что-либо за рамками Go просто не смогут освоить.


Есть мнение, что сиплюсплюс осваивают школьники в качестве факультатива.
Re[11]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 16.10.18 13:22
Оценка: +1
Здравствуйте, Тёмчик, Вы писали:

S>>Есть мнение, что многие современные разработчики что-либо за рамками Go просто не смогут освоить.


Тё>Есть мнение, что сиплюсплюс осваивают школьники в качестве факультатива.


Одно другому не противоречит, т.к. речь идет о двух не пересекающихся группах.
Re[10]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 16.10.18 13:59
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, reversecode, Вы писали:


R>>вот до чего доводит знание гоу ...


S>Тема квалификации гошников мусолится.



Смешная темя, спасибо!
Квалификация Гошников и правда ниже плинтуса, но там и уровня мартышки хватает.
Re[29]: Go язык прёт?
От: StanislavK Великобритания  
Дата: 16.10.18 15:19
Оценка:
Здравствуйте, Hardballer, Вы писали:

H>>>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.

H>>>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
SK>>А зачем вам больше потоков чем ядер? Вроде же речь шла о 1024 потоках.
H>Поток пристегивается к TCP/IP коннекту и обслуживает только его в первичном парсинге, валидации и прочем.
Все равно не понятно. Без проблем можно кучу коннектов в одном потоке рулить. Как не крути потоки только лейтенси добавляют.
Re[30]: Go язык прёт?
От: Hardballer  
Дата: 16.10.18 16:53
Оценка:
Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, Hardballer, Вы писали:


H>>>>А так, не упираясь в пиковый перфоманс-меньше 1мс в оба конца.

H>>>>Каждое переключение потока, это сбрасывание стека и прочие издержки, поэтому я бы не стал полагаться на операционку :D
SK>>>А зачем вам больше потоков чем ядер? Вроде же речь шла о 1024 потоках.
H>>Поток пристегивается к TCP/IP коннекту и обслуживает только его в первичном парсинге, валидации и прочем.
SK>Все равно не понятно. Без проблем можно кучу коннектов в одном потоке рулить. Как не крути потоки только лейтенси добавляют.
Добавляют только в том случае, если потоков больше физических ядер.
1 HFT коннект это либо HFT трейдер, либо сервер с фронтэндом, обслуживающий обычных пользователей(10-20К+ "ручников").
Современное топовое железо имеет 384 физических ядра. Если они все заняты под HFT подключения даже на одном торговом инструменте-это означает, что мы добились успеха
Но это пока 384 ядра, года через 3-4 будет и 1024 физических ядер в рамках одного сервера.
А мы к этому уже готовы сейчас, вот дайте такое железо-я это все эффективно, без переделки кода (чуть конфиги только крутану)-освою на все 100%.
Тема холиварная и все такое, поэтому дальше спорить не вижу смысла, но я уже сейчас готов к росту количества ядер в CPU в будущих серверах, все утилизирую начисто
Отредактировано 16.10.2018 16:59 Hardballer . Предыдущая версия .
Re[11]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 16.10.18 18:34
Оценка:
Здравствуйте, kaa.python, Вы писали:

S>>Тема квалификации гошников мусолится.



KP>Смешная темя, спасибо!

KP>Квалификация Гошников и правда ниже плинтуса, но там и уровня мартышки хватает.

Плохому танцору ... мешают
Re[5]: Go язык прёт?
От: Cyberax Марс  
Дата: 16.10.18 19:13
Оценка:
Здравствуйте, reversecode, Вы писали:

R>что то я так мельком глянул имплементацию корутин в гоу

R>и она мне показалась более тяжелой чем в бусте
Golang автоматически занимается планированием горутин, в том числе при блокирующихся вызовах в С-код. Туда же добавляются и перемещаемые стеки, которых в С++ нет в принципе.
Sapienti sat!
Re[6]: Go язык прёт?
От: reversecode google
Дата: 16.10.18 19:37
Оценка: :)
какая разница как он планируется если я говорю об имплементации переключения стека на асме
хотя гугл вместо этого мог просто написать библиотеку для С++ и получить тоже самое
впрочем я уже раскрыл коварный замысел гугла по созданию языка гоу что бы создать рабочие места бездомным бродягам как минимум в сша
Re[7]: Go язык прёт?
От: Cyberax Марс  
Дата: 16.10.18 21:43
Оценка: 2 (1) +1
Здравствуйте, reversecode, Вы писали:

R>какая разница как он планируется если я говорю об имплементации переключения стека на асме

А что, как-то можно по-другому переключать?

R>хотя гугл вместо этого мог просто написать библиотеку для С++ и получить тоже самое

Такие библиотеки были ещё так года с 89-го.

R>впрочем я уже раскрыл коварный замысел гугла по созданию языка гоу что бы создать рабочие места бездомным бродягам как минимум в сша

Хватит бредить, а?

Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.
Sapienti sat!
Re[8]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 16.10.18 23:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.


Писать надежные сетевые приложения позволяет дохрена чего. А вот использовать мартышек в разработке, при этом получая что-то полезное, раньше ничего кроме PHP не позволяло. А теперь есть Go
Re[12]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.10.18 00:16
Оценка:
Здравствуйте, Тёмчик, Вы писали:

KP>>Смешная темя, спасибо!

KP>>Квалификация Гошников и правда ниже плинтуса, но там и уровня мартышки хватает.

Тё>Плохому танцору ... мешают


Ты довольно верно причины создания Go описал
Re[33]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 17.10.18 02:07
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>А уж если там люди выбирают Си# и Java то видимо все не так страшно


Совершенно не страшно со стороны биржи/matching engine, собственно там Java в полный рост со всеми вытекающими. Те же кто торгуют, и кому важна latency, в большинстве своём используют C++, ибо время — деньги
Re[13]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 17.10.18 02:10
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>>>Квалификация Гошников и правда ниже плинтуса, но там и уровня мартышки хватает.


Тё>>Плохому танцору ... мешают


KP>Ты довольно верно причины создания Go описал


Веб на плюсах не взлетел. Значит, танцорам плюсникам мешали яйца? Бигдата пошла с жавы и потом в питон и js. Кто мешал плюсникам идти в бигдату? Теперь go стремится вытеснить питон из скриптов и жаву из микросервисов. С сферой применения C++ он не пересекается, хоть и декларируется "скорость компилируемого языка".
Так почему у тебя претензии к go?
Re[14]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.10.18 02:20
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Так почему у тебя претензии к go?


Никаких. Это ж ты чего-то возбудился на мой комментарий про мартышек
Re[9]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 03:31
Оценка: 4 (1)
Здравствуйте, kaa.python, Вы писали:

C>>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.

KP>Писать надежные сетевые приложения позволяет дохрена чего.
На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.

Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.

KP>А вот использовать мартышек в разработке, при этом получая что-то полезное, раньше ничего кроме PHP не позволяло. А теперь есть Go

Писать код на Go ничуть не проще, чем на других языках.
Sapienti sat!
Re[10]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.10.18 04:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.


Да, этого нет. Но оно надо ли? И оно, опять таки, не бесплатное.

C>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.


Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым

C>Писать код на Go ничуть не проще, чем на других языках.


Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.
Re[14]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 17.10.18 05:14
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>Веб на плюсах не взлетел.


А пытался? Где, когда?
Re[10]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 17.10.18 05:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.

KP>>Писать надежные сетевые приложения позволяет дохрена чего.
C>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.

Есть сегментированые стэки.

https://www.boost.org/doc/libs/1_68_0/libs/coroutine2/doc/html/coroutine2/stack/segmented.html
Boost.Coroutine2 supports usage of a segmented_stack, e. g. the size of the stack grows on demand. The coroutine is created with a minimal stack size and will be increased as required.


Плюс, даже без этой возможности — не забываем про резервирование адресного пространства/overcommit — по сути то же расширение по требованию.

C>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки


На Boost.Coroutine сотни тысяч запускаются без проблем
Автор: Evgeny.Panasyuk
Дата: 29.11.13
, причём на древнем ноутбуке, и это без segmented stack

C>так что нужно будет мастерить безстековые генераторы или что-то подобное.


Необязательно, но у них ещё есть другие плюсы.
Re[11]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 17.10.18 05:40
Оценка:
Здравствуйте, kaa.python, Вы писали:

C>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.

KP>Да, этого нет.

Нет, это есть.

C>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.

KP>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым

Достаточно посмотреть на код Asio с корутинами и без них, вопросы об их удобстве и необходимости сразу отпадут
Именно поэтому автор Boost.Asio добавил в Asio реализацию stackless корутин. Именно поэтому как только появилась Boost.Coroutine в Asio добавили соответствующую обвязку.
Именно поэтому автор Asio является автором нескольких предложений в стандарт по корутинам.
Именно из-за громоздкости асинхронного кода автор Asio показывает в своих презентациях как его упрощать, и проще всего выглядит решение на корутинах (будь то stackless или stackful).
Re[11]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 06:34
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

C>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.

EP>Есть сегментированые стэки.
В Golang от них отказались из-за неустранимых проблем с производительностью, если из-за невезения горячая функция попадает как раз на границу сегментов.

EP>Плюс, даже без этой возможности — не забываем про резервирование адресного пространства/overcommit — по сути то же расширение по требованию.

Игры с защитой памяти — достаточно дорогое и сомнительное удовольствие. На 10 тысячах потоков семафор mmap/mprotect в ядре будет раскалён до температуры термоядерного синтеза.

C>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки

EP>На Boost.Coroutine сотни тысяч запускаются без проблем
Автор: Evgeny.Panasyuk
Дата: 29.11.13
, причём на древнем ноутбуке, и это без segmented stack

Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.
Sapienti sat!
Re[8]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 06:41
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, reversecode, Вы писали:


R>>какая разница как он планируется если я говорю об имплементации переключения стека на асме

C>А что, как-то можно по-другому переключать?

написать кода по переключению можно по разному, да
можно на 2 строки можно на 22, можно на 2222 в периоде
но суть не в этом

R>>хотя гугл вместо этого мог просто написать библиотеку для С++ и получить тоже самое

C>Такие библиотеки были ещё так года с 89-го.

вот именно были, так зачем же гугл изобрел велосипед в виде другого языка ?

R>>впрочем я уже раскрыл коварный замысел гугла по созданию языка гоу что бы создать рабочие места бездомным бродягам как минимум в сша

C>Хватит бредить, а?

C>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.


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

зачем это было делать ? ответ более чем очевиден
в сша не достаток программистов, стартапы ростут как грибы в сезон, тянуть программистов из за океяна долго и дорого
а здесь под боком очень много бездомных и просто дураков которых нужно-можно чем то занять
учить их С++ дорого и не каждому это дается
что делать ? дать им язык которым можно так же говнокодить как и на ява скриптах или пижке
и уровень вхождения в который был бы минимален
получите гоу
Re[11]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 06:44
Оценка:
Здравствуйте, kaa.python, Вы писали:

C>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.

KP>Да, этого нет. Но оно надо ли? И оно, опять таки, не бесплатное.
На Go оно практически бесплатное — стек в любой момент легко можно переместить за счёт того, что GC отслеживает все указатели на нём. Так что горутина может начать со стеком всего в килобайт.

C>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.

KP>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым
Ну так можно и на ходулях ходить, столетиями шуты так делают. Речь идёт о том, что Go это делает простым и обыденным.

Ещё из плюсов Go — скорость компиляции. Boost.Asio компилируется ну, так скажем, неторопливо. Go позволяет просто писать "go run ..." и оно менее чем за секунду компилирует и запускает приложение.

C>>Писать код на Go ничуть не проще, чем на других языках.

KP>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.
И при это Go-шники делают такой же качественный код.
Sapienti sat!
Re[12]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 06:46
Оценка:
C>>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки
EP>>На Boost.Coroutine сотни тысяч запускаются без проблем
Автор: Evgeny.Panasyuk
Дата: 29.11.13
, причём на древнем ноутбуке, и это без segmented stack

C>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.

в гоу какие то особенные корутины ? они используют какие то особенные инструкции цпу ?
да нет же, все тоже что делается на С++ с корутинами сделано и в гоу, только спрятано в рантайме
кстати там же в proc.go и ссылка на архитектуру где по ссылке расписаны и ограничения этой архитектуры корутин
глобальный мютекс на список корутин
Re[13]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 07:00
Оценка:
Здравствуйте, reversecode, Вы писали:

C>>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.

R>в гоу какие то особенные корутины ?
Да. Так как язык имеет точный GC, то горутины начинаются с небольшого размера. При необходимости стек копируется в больший блок, при этом все указатели автоматически корректируются.

В С++ такое просто невозможно.

R>кстати там же в proc.go и ссылка на архитектуру где по ссылке расписаны и ограничения этой архитектуры корутин

R>глобальный мютекс на список корутин
Нет. Корутины находятся в P-local (процессорно-локальном) списке, мьютекс блокируется при создании системных потоков. В результате, планировщик при отдаче управления может обычно просто взять очередную сопрограмму из своего списка. Межпоточные блокировки нужны для work stealing — если у процессора нет своих задач, то он пытается их украсть от других процессоров.

Для желающих залезть в детали:
https://golang.org/src/runtime/proc.go#L3316 — newproc1 создаёт горутину.

В кратце, оно берёт инициализированную пустую структуру из локального списка (gfget#L3407), без всяких блокировок. Если локальный список пустой, то он пополняется из глобального (под блокировкой этого списка).

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

После всего этого, горутина добавляется в локальный runqueue (см. runqput#L4799), она lock-free. Затем управление передаётся обратно в вызвавшую функцию, которая продолжит себе работать.
Sapienti sat!
Отредактировано 17.10.2018 7:28 Cyberax . Предыдущая версия .
Re[11]: Go язык прёт?
От: C0x  
Дата: 17.10.18 07:06
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым


Десетилетия назад машины были одноядерными. Со временем ситуация начала меняться и появились многоядерные машины, на которых удобно стало гонять параллельные задачи.
Поэтому языки эволюционируют в соотвествии с требованиями железа.

KP>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.


Ну естественно на порядок ниже, т.к. в Го есть сборщик муссора, а в Си++ его нет. Поэтому 80% вопросов касательно управления паматью отпадает за ненадобностью.
Только вот я не понимаю в чем тут минус Го. В сборщике муссора?
Re[12]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 07:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kaa.python, Вы писали:


C>>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.

KP>>Да, этого нет. Но оно надо ли? И оно, опять таки, не бесплатное.
C>На Go оно практически бесплатное — стек в любой момент легко можно переместить за счёт того, что GC отслеживает все указатели на нём. Так что горутина может начать со стеком всего в килобайт.

корутина тоже может в С++ начать с любым стеком

C>>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.

KP>>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым
C>Ну так можно и на ходулях ходить, столетиями шуты так делают. Речь идёт о том, что Go это делает простым и обыденным.

C>Ещё из плюсов Go — скорость компиляции. Boost.Asio компилируется ну, так скажем, неторопливо. Go позволяет просто писать "go run ..." и оно менее чем за секунду компилирует и запускает приложение.


если буст собрать динамически или архивной либой будет тоже самое
но многие любят компилять все с нуля

C>>>Писать код на Go ничуть не проще, чем на других языках.

KP>>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.
C>И при это Go-шники делают такой же качественный код.

код такой не благодаря гошникам а благодаря типизированному языку гоу
Re[12]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 07:11
Оценка:
C0x>Только вот я не понимаю в чем тут минус Го. В сборщике муссора?

в создании не нужной сущности (самого языка) порог входа в который ниже плинтуса
Re[9]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 07:12
Оценка: 4 (1)
Здравствуйте, reversecode, Вы писали:

R>>>хотя гугл вместо этого мог просто написать библиотеку для С++ и получить тоже самое

C>>Такие библиотеки были ещё так года с 89-го.
R>вот именно были, так зачем же гугл изобрел велосипед в виде другого языка ?
Потому, что все эти библиотеки сложно использовать — кроме горутин ещё нужны каналы и полноценный планировщик. Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC.

Но при этом весь код на С++ должен писаться в стиле этой библиотеки, которая (в частности) заменит весь IO и будет требовать особых обёрток для вызова внешних функций.

Так что тут получается вопрос — нафиг вообще тогда С++ сдался?

C>>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.

R>их и на С++ можно писать, а то что изобрел гугл это спрятал корутины под капот рантайма гоу
Ещё каналы и планирование. Ну и полноценный точный GC. И полноценную модульность. И компиляцию со скоростью миллионов строк в секунду.

А так да, ничего нового.

R>что делать ? дать им язык которым можно так же говнокодить как и на ява скриптах или пижке

R>и уровень вхождения в который был бы минимален
Если вы говнокодите на С++, то не надо проецировать свои недостатки на других.
Sapienti sat!
Re[13]: Go язык прёт?
От: C0x  
Дата: 17.10.18 07:16
Оценка:
Здравствуйте, reversecode, Вы писали:


C0x>>Только вот я не понимаю в чем тут минус Го. В сборщике муссора?


R>в создании не нужной сущности (самого языка) порог входа в который ниже плинтуса


Погоди. Непойму никак твое возмущение с чем связано, с тем что теперь легко и просто писать сетевые приложения и так же легко и просто работать с байтовыми блоками данных и поэтому теперь станет выше конкуренция на рынке труда? Или всетаки язык дерьмо?
Re[12]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 17.10.18 07:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

EP>>Плюс, даже без этой возможности — не забываем про резервирование адресного пространства/overcommit — по сути то же расширение по требованию.

C>Игры с защитой памяти — достаточно дорогое и сомнительное удовольствие. На 10 тысячах потоков семафор mmap/mprotect в ядре будет раскалён до температуры термоядерного синтеза.

Память часто можно выделять заранее, защита памяти — это больше для успокоения на очень unhappy path.

C>>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки

EP>>На Boost.Coroutine сотни тысяч запускаются без проблем
Автор: Evgeny.Panasyuk
Дата: 29.11.13
, причём на древнем ноутбуке, и это без segmented stack

C>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.

А на десятках тысяч о которых ты говорил выше — будет несколько гигабайт, ну и?

C>Так что горутина может начать со стеком всего в килобайт.


Если память это настолько проблема, а корутин действительно много, то нужно брать stackless корутины — там минимальный размер одной корутины несколько байт — запускай хоть миллиарды
Re[13]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 07:32
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

C>>Игры с защитой памяти — достаточно дорогое и сомнительное удовольствие. На 10 тысячах потоков семафор mmap/mprotect в ядре будет раскалён до температуры термоядерного синтеза.

EP>Память часто можно выделять заранее, защита памяти — это больше для успокоения на очень unhappy path.
Ээээ....

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

C>>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.

EP>А на десятках тысяч о которых ты говорил выше — будет несколько гигабайт, ну и?
Это как бы немало.

C>>Так что горутина может начать со стеком всего в килобайт.

EP>Если память это настолько проблема, а корутин действительно много, то нужно брать stackless корутины — там минимальный размер одной корутины несколько байт — запускай хоть миллиарды
Но они требуют специального стиля написания.
Sapienti sat!
Re[14]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 07:50
Оценка:
ну не сетевые приложения, давайте не будем лукавить

язык дерьмо, ничего дальше написания парсинга и отправки хттп запрос ответов он не годится
этакая замена nginx для кастомизации, да и к тому уже луа прикрутили
язык для бедных с профитом для гугла закрыть недостаток специалистов в своих веб сервисах

порог вхождения в язык ниже плинтуса, что это значит ?
давайте прикинем по аналогии что будет если
каждый сможет стать медиком или президентом или министром всего за недельные курсы
ООоООООооо в стране появится много медиков, президентов и министров.... плохо ли это ??
текущие президент министры и медики должны бояться конкуренции ??
Re[14]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 07:55
Оценка:
https://golang.org/src/runtime/proc.go#L26
// Design doc at https://golang.org/s/go11sched
вся архитектура и ее органичения
Re[14]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 17.10.18 07:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Игры с защитой памяти — достаточно дорогое и сомнительное удовольствие. На 10 тысячах потоков семафор mmap/mprotect в ядре будет раскалён до температуры термоядерного синтеза.

EP>>Память часто можно выделять заранее, защита памяти — это больше для успокоения на очень unhappy path.
C>Ээээ....
C>Если у нас защита памяти используется для минимизации стеков, то тогда промахи по памяти будут частым явлением.

Совсем не обязательно частым. Скажем мы уменьшили изначальный стэк до такого размера что в одной из сотни тысяч корутин его не хватит. При отсутствии защиты мы и этого себе позволить не можем, ибо превышение лимита приведёт к расстрелу памяти, и поэтому приходится перезакладываться.
При наличии же защиты расстрела не будет, а цена unhappy path приемлема

C>>>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.

EP>>А на десятках тысяч о которых ты говорил выше — будет несколько гигабайт, ну и?
C>Это как бы немало.

Если у нас таки "реалистичный размер в 64Кб", то в варианте на Go сколько будет?

C>>>Так что горутина может начать со стеком всего в килобайт.

EP>>Если память это настолько проблема, а корутин действительно много, то нужно брать stackless корутины — там минимальный размер одной корутины несколько байт — запускай хоть миллиарды
C>Но они требуют специального стиля написания.

Благодаря макросам этот стиль структурно не сильно отличается от stackful корутин — это то что было уже давно.
А сейчас, в нескольких мейнстрим компиляторах уже реализованны предложения stackless, причём уже несколько версий назад.
Re[15]: Go язык прёт?
От: C0x  
Дата: 17.10.18 08:21
Оценка:
Здравствуйте, reversecode, Вы писали:


R>ну не сетевые приложения, давайте не будем лукавить


UDP, TCP без проблем прямо сейчас создаю на коленке. И работает.
Не я не против и могу вполне на Си такое колбасить, но это потребует больше времени и возни с либами (я кроссплатформенное решение делаю), ковыряния скорее всего в тонкостях работы разных либ.

R>язык дерьмо, ничего дальше написания парсинга и отправки хттп запрос ответов он не годится


Это типа "шуруповерт на батарейках дерьмо, ничего кроме закручивания маленьких шурупов в ДСП он не умеет"?

R>давайте прикинем по аналогии что будет если

R>каждый сможет стать медиком или президентом или министром всего за недельные курсы

Не нужно ничего сочинять и прикидывать, Не сможет каждый стать медиком! Так же не сможет каждый стать хорошим программистом.
И то что есть понятие "Индус" в программировании так это уже лет 20 как, еще со времён Интернет Бума в конце 90х. И на мой взгляд Го тут вообще капля в море.
Re[10]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 17.10.18 08:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Потому, что все эти библиотеки сложно использовать — кроме горутин ещё нужны каналы и полноценный планировщик. Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC.


Планировщик, каналы и прочая обвязка есть в Boost.Fiber.
То есть в Boost есть три библиотеки на тему stackful, начиная от низкого к более высокому уровню: Boost.Context, Boost.Coroutine, Boost.Fiber.
Re[16]: Go язык прёт?
От: reversecode google
Дата: 17.10.18 08:38
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Здравствуйте, reversecode, Вы писали:



R>>ну не сетевые приложения, давайте не будем лукавить


C0x>UDP, TCP без проблем прямо сейчас создаю на коленке. И работает.

C0x>Не я не против и могу вполне на Си такое колбасить, но это потребует больше времени и возни с либами (я кроссплатформенное решение делаю), ковыряния скорее всего в тонкостях работы разных либ.

R>>язык дерьмо, ничего дальше написания парсинга и отправки хттп запрос ответов он не годится


C0x>Это типа "шуруповерт на батарейках дерьмо, ничего кроме закручивания маленьких шурупов в ДСП он не умеет"?


объединим два вопроса,
значит гоу по вашему хорош для сетевого программирования
давайте определим где у вас в современном программировании используется сеть ?
webservice
gamedev
voip
iptv
blockchain

добавляйте, может я что то упустил ?
и в какой из этих сфер гоу уже более 50% ?

почти нигде кроме как на webservice гоу нет
ну еще в блокчаин пытаются его пихать

R>>давайте прикинем по аналогии что будет если

R>>каждый сможет стать медиком или президентом или министром всего за недельные курсы

C0x>Не нужно ничего сочинять и прикидывать, Не сможет каждый стать медиком! Так же не сможет каждый стать хорошим программистом.

C0x>И то что есть понятие "Индус" в программировании так это уже лет 20 как, еще со времён Интернет Бума в конце 90х. И на мой взгляд Го тут вообще капля в море.


я уже в теме отписывался о авторе fasthttp который ничего кроме гоу не знает в точности
специалисты которые умеют программировать но слабо разбираются в технологиях малопригоды
тоже самое что выучить весь алфавит и не уметь сказать ни одного слова
Re[15]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 08:45
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

C>>Если у нас защита памяти используется для минимизации стеков, то тогда промахи по памяти будут частым явлением.

EP>Совсем не обязательно частым. Скажем мы уменьшили изначальный стэк до такого размера что в одной из сотни тысяч корутин его не хватит.
Тогда напрасно тратим память на пустые стеки.

C>>Это как бы немало.

EP>Если у нас таки "реалистичный размер в 64Кб", то в варианте на Go сколько будет?
Столько, сколько нужно.
Sapienti sat!
Re[15]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 08:46
Оценка:
Здравствуйте, reversecode, Вы писали:

R>https://golang.org/src/runtime/proc.go#L26

Смотрим в книгу, видим фигу. Я уже указал детали — создание горутины не требует взятия блокировок, как и локальное планирование. Блокировки нужны при запуске нового системного потока и при stop-the-world GC.
Sapienti sat!
Re[17]: Go язык прёт?
От: C0x  
Дата: 17.10.18 08:53
Оценка:
Здравствуйте, reversecode, Вы писали:

R>Здравствуйте, C0x, Вы писали:


R>давайте определим где у вас в современном программировании используется сеть ?

R>webservice

У меня тут.

R>и в какой из этих сфер гоу уже более 50% ?


А причем тут эти метрики? Язык молодой достаточно. Поэтому мимо.

R>почти нигде кроме как на webservice гоу нет


А что его кто-то для чего-то другого рекомендует?
Да и очевидным минусом Го в сравнении с Си является GC, поэтому как никрути в некоторых областях ему двери закрыты сразу.

R>ну еще в блокчаин пытаются его пихать


Да пихать можно что угодно куда угодно. Можно например вот Си пихать в написание импорта-экспорта из баз данных. Нах. он там нужен только если с этим отлично даже VB справляется?


R>я уже в теме отписывался о авторе fasthttp который ничего кроме гоу не знает в точности


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

R>специалисты которые умеют программировать но слабо разбираются в технологиях малопригоды


Вот тут я тоже не очень понял твою мысль. То есть если чувак реально умеет программировать, знает Алгоритмы и Структуры данных, понимает где и как что нужно оптимизировать, то он "индус" что-ли?

Помоему как раз все наоборот: те кто умеют программировать те и пригодны.

R>тоже самое что выучить весь алфавит и не уметь сказать ни одного слова


Ты сам себе противоречишь. Умение программирование это как раз выучить алфавит и постоянно писать с его помощью.
Re[13]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 08:54
Оценка:
Здравствуйте, reversecode, Вы писали:

C>>На Go оно практически бесплатное — стек в любой момент легко можно переместить за счёт того, что GC отслеживает все указатели на нём. Так что горутина может начать со стеком всего в килобайт.

R>корутина тоже может в С++ начать с любым стеком
В С++ есть два варианта:
1) Располагать стеки на большом расстоянии друг от друга в виртуальной памяти и вешать sentinel-страницу в конец. При прикосновении к этой странице срабатывает защита памяти и дополнительно добавляет страниц в стек. Это работает не очень хорошо, так как промахи сегментации — вещь дорогая.

2) Сегментированные стеки. Компилятор вставляет в пролог и эпилог функции (или в место вызова) код, который может передвигать указатель стека между сегментами (в виде связного списка). Это тормозит из-за того, что эта проверка — дополнительное и дорогое ветвление, с косвенным доступом. В Golang от этого отказались примерно 5 лет назад из-за тормозов.

Всё, передвигаемые стеки в С++ невозможны.

C>>Ещё из плюсов Go — скорость компиляции. Boost.Asio компилируется ну, так скажем, неторопливо. Go позволяет просто писать "go run ..." и оно менее чем за секунду компилирует и запускает приложение.

R>если буст собрать динамически или архивной либой будет тоже самое
Не будет. Asio — header only.

Учим матчасть.
Sapienti sat!
Re[10]: каналы и GC
От: Sharov Россия  
Дата: 17.10.18 09:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

C> Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC.


Зачем gc нужен? Чтобы вручную не париться с каналами?
Кодом людям нужно помогать!
Re[18]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 09:02
Оценка:
Здравствуйте, C0x, Вы писали:

R>>почти нигде кроме как на webservice гоу нет

C0x>А что его кто-то для чего-то другого рекомендует?
C0x>Да и очевидным минусом Го в сравнении с Си является GC, поэтому как никрути в некоторых областях ему двери закрыты сразу.
Кстати, системный софт тоже неплохо пишется. Сказывается пара гениальных решений:
1) Возможность полной независимости от libc.
2) Очень практичная системная библиотека, предоставляющая доступ к многим низкоуровневым вещам.
Sapienti sat!
Re[11]: каналы и GC
От: Cyberax Марс  
Дата: 17.10.18 09:05
Оценка: 4 (1) +1
Здравствуйте, Sharov, Вы писали:

C>> Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC.

S> Зачем gc нужен? Чтобы вручную не париться с каналами?
Очень легко получить циклические ссылки.
Sapienti sat!
Re[12]: каналы и GC
От: so5team https://stiffstream.com
Дата: 17.10.18 09:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Очень легко получить циклические ссылки.


В каналах? Каким образом?
Re[19]: Go язык прёт?
От: C0x  
Дата: 17.10.18 09:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати, системный софт тоже неплохо пишется. Сказывается пара гениальных решений:


Есть примеры?
Я что-то пока не очень представляю драйвера написанные на Go. Да и зачем?
Да и темболее опять же во многих системных вещах нужно прямое управлению памятью.

C>1) Возможность полной независимости от libc.


libc так плоха?

C>2) Очень практичная системная библиотека, предоставляющая доступ к многим низкоуровневым вещам.


это есть в любом языке вроде, через использования врапперов над Сишными либами.
Re[13]: каналы и GC
От: Cyberax Марс  
Дата: 17.10.18 09:19
Оценка:
Здравствуйте, so5team, Вы писали:

C>>Очень легко получить циклические ссылки.

S>В каналах? Каким образом?
В коде, который их использует.
Sapienti sat!
Re[20]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 09:20
Оценка:
Здравствуйте, C0x, Вы писали:

C>>Кстати, системный софт тоже неплохо пишется. Сказывается пара гениальных решений:

C0x>Есть примеры?
Docker, однако.

C0x>Я что-то пока не очень представляю драйвера написанные на Go. Да и зачем?

Системный софт — это не только драйвера.

C0x>Да и темболее опять же во многих системных вещах нужно прямое управлению памятью.

В Go можно напрямую управлять памятью, в том числе и располагать объекты вручную.

C>>1) Возможность полной независимости от libc.

C0x>libc так плоха?
Да.

C>>2) Очень практичная системная библиотека, предоставляющая доступ к многим низкоуровневым вещам.

C0x>это есть в любом языке вроде, через использования врапперов над Сишными либами.
А в Go есть прямо в стандартной библиотеке.
Sapienti sat!
Re[21]: Go язык прёт?
От: C0x  
Дата: 17.10.18 09:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

C0x>>libc так плоха?

C>Да.

Чем?
Re[14]: каналы и GC
От: so5team https://stiffstream.com
Дата: 17.10.18 09:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Очень легко получить циклические ссылки.

S>>В каналах? Каким образом?
C>В коде, который их использует.

Каким боком это должно подтверждать выдвинутый ранее тезис: "Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC." ?
Re[22]: Go язык прёт?
От: Cyberax Марс  
Дата: 17.10.18 09:38
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>>>libc так плоха?

C>>Да.
C0x>Чем?
Если быть точным, glibc плоха. Если скомпилировать обычное приложение на машине с Ubuntu 18.04, то оно не запустится на Ubuntu 16.04 из-за того, что символы в glibc версированы. Сейчас есть musl libc и Alpine, на которых тоже можно собрать статические С++ приложения, но это требует немалых прыжков и ужимок.

С Golang можно тупо скопировать один файл приложения и оно запустится.

Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.
Sapienti sat!
Re[15]: каналы и GC
От: Cyberax Марс  
Дата: 17.10.18 09:39
Оценка:
Здравствуйте, so5team, Вы писали:

C>>В коде, который их использует.

S>Каким боком это должно подтверждать выдвинутый ранее тезис: "Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC." ?
Нужно было написать: "Хотя код, активно использующий каналы иногда бывает сложно писать без GC".
Sapienti sat!
Re[16]: каналы и GC
От: so5team https://stiffstream.com
Дата: 17.10.18 09:42
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

S>>Каким боком это должно подтверждать выдвинутый ранее тезис: "Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC." ?

C>Нужно было написать: "Хотя код, активно использующий каналы иногда бывает сложно писать без GC".

С таким же успехом можно было написать и "Хотя код, активно использующий динамическую память, иногда бывает сложно писать без GC".

К CSP-шным каналам отсутствие/наличие GC имеет очень косвенное отношение.
Re[23]: Go язык прёт?
От: C0x  
Дата: 17.10.18 10:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>С Golang можно тупо скопировать один файл приложения и оно запустится.


C>Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.


Кстати именно из за этого я и выбрал Го для своего проекта. Работаю на Винде, а собираю под линухи и копирую по фтп.
Re[31]: Go язык прёт?
От: StanislavK Великобритания  
Дата: 17.10.18 14:35
Оценка:
Здравствуйте, Hardballer, Вы писали:


SK>>Все равно не понятно. Без проблем можно кучу коннектов в одном потоке рулить. Как не крути потоки только лейтенси добавляют.

H>Добавляют только в том случае, если потоков больше физических ядер.
Вот и вопрос — нафига? Зачем иметь больше потоков, чем физических ядер?

H>Но это пока 384 ядра, года через 3-4 будет и 1024 физических ядер в рамках одного сервера.

Это совсем не противоречит тому, что я говорю. Я говорю, что потоков больше чем ядер быть не должно. Я не не говорил, что их должно быть меньше.
Если система проектирутеся так, что потоков больше, чем ядер, это всегда подразумевает как минимум переключение контекста и как максимум синхронизацию. И то и то — зло.

H>А мы к этому уже готовы сейчас, вот дайте такое железо-я это все эффективно, без переделки кода (чуть конфиги только крутану)-освою на все 100%.

H>Тема холиварная и все такое, поэтому дальше спорить не вижу смысла, но я уже сейчас готов к росту количества ядер в CPU в будущих серверах, все утилизирую начисто
Да нет, тут дело не в холиваре совсем. Честно я просто что-то не понию, вот и пытаюсь узнать. Может научусь чему-нить.
Re[23]: Go язык прёт?
От: m2l  
Дата: 17.10.18 18:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>С Golang можно тупо скопировать один файл приложения и оно запустится.

C>Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.
+1

И с внешними зависимостями здорово — тупо скопировал gohome и всё. Никаких развлечений с разными окружениями.
Re[11]: Go язык прёт?
От: m2l  
Дата: 17.10.18 18:18
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Планировщик, каналы и прочая обвязка есть в Boost.Fiber.

EP>То есть в Boost есть три библиотеки на тему stackful, начиная от низкого к более высокому уровню: Boost.Context, Boost.Coroutine, Boost.Fiber.
С тем же успехом все это достижимо и на чистом С, без плюсов и boost-а. Просто стоимость такого кода больше аналогичной функциональности в golang.
Re[23]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 18.10.18 00:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.

Когда-то кросс-компилировал C++ код под убунтой, это были кусочки для win32, lin 32, lin 64, mac i 64 и mac ppc 32, mac ppc 64- они складывались в жава апплет и оттуда дергались в зависимости от оси/браузера. Нужно было установить кросс-компиляторный build chain из официальной репы.
Re[26]: Go язык прёт?
От: chaotic-kotik  
Дата: 18.10.18 06:10
Оценка:
Здравствуйте, ·, Вы писали:


·> Не надо использовать блокировки в высокопроизводительных системах.


Большую глупость о высокопроизводительных системах написать сложно. Захват и освобождение uncontended мьютекса выполняется примерно за 10нс.
Re[12]: Go язык прёт?
От: chaotic-kotik  
Дата: 18.10.18 06:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

KP>>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.

C>И при это Go-шники делают такой же качественный код.

Побуду адвокатом дьявола (не имею ничего против Go). Недавно зашел в группу по golang в telegram. Вы бы почитали их обсуждения. Это какое-то днище. Люди не знают даже стандартной библиотеки Go нормально, у большинства очень узкий кругозор и какие-то очень странные представления об окружающем мире. Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB. Судя по всему, основной контингент там состоит из бывших PHP/Ruby/Python/etc программистов.
Re[19]: Go язык прёт?
От: chaotic-kotik  
Дата: 18.10.18 06:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>1) Возможность полной независимости от libc.


это скорее минус, что будешь делать если ABI linux изменится?
Re[15]: Go язык прёт?
От: chaotic-kotik  
Дата: 18.10.18 06:39
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Благодаря макросам этот стиль структурно не сильно отличается от stackful корутин — это то что было уже давно.

EP>А сейчас, в нескольких мейнстрим компиляторах уже реализованны предложения stackless, причём уже несколько версий назад.

У корутин в С++ есть очень большой минус — отладка. Стектрейсов либо нет, либо в них невозможно ничего понять. Многие инструменты отладки не работают нормально с stackful корутинами, valgrind и санитайзеры могут довать false positives.
Re[13]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 18.10.18 07:00
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>у большинства очень узкий кругозор и какие-то очень странные представления об окружающем мире.


У меня такое впечатление об идейных плюсниках. Огульно поливают всё, что не их божественный C++, значительная часть верует в исключительную скорость C++, при этом не знает базовых вещей CS как big-O, основные структуры данных и т.п.
Re[14]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 18.10.18 07:07
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>У меня такое впечатление об идейных плюсниках. Огульно поливают всё, что не их божественный C++, значительная часть верует в исключительную скорость C++, при этом не знает базовых вещей CS как big-O, основные структуры данных и т.п.


Высказал свое веское мнение спешиалистЪ, который Visitor освоил только проходя собеседование в 2016-ом году. Возможно, это мнение у вас сложилось поскольку вы общаетесь в среде себе подобных.
Re[15]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 18.10.18 07:13
Оценка:
Здравствуйте, so5team, Вы писали:

Тё>>У меня такое впечатление об идейных плюсниках. Огульно поливают всё, что не их божественный C++, значительная часть верует в исключительную скорость C++, при этом не знает базовых вещей CS как big-O, основные структуры данных и т.п.


S>Высказал свое веское мнение спешиалистЪ, который Visitor освоил только проходя собеседование в 2016-ом году. Возможно, это мнение у вас сложилось поскольку вы общаетесь в среде себе подобных.


О, типичный представитель нарисовался. Выучил названия, но ничего не понял.
Re[16]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 18.10.18 07:31
Оценка:
Здравствуйте, Тёмчик, Вы писали:

Тё>О, типичный представитель нарисовался.


Какие ваши доказательства?

Тё>Выучил названия, но ничего не понял.


Очень сложно понять как спешиалистЪ вроде вас, много лет говорящий про то, что он программирует на C++ и на Java, не знал про Visitor столько лет. Ладно бы вы на функциональных языках программировали, а про C++/Java только слышали краем уха. Так ведь нет.

Пожалуйста, объясните, как вам это удалось? Вероятно, работали в крупных конторах с хорошо налаженными процессами и эффективным менеджментом?
Отредактировано 18.10.2018 7:40 so5team . Предыдущая версия .
Re[13]: Go язык прёт?
От: C0x  
Дата: 18.10.18 07:43
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK> Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB. Судя по всему, основной контингент там состоит из бывших PHP/Ruby/Python/etc программистов.


Не знаю какую ты группу имеешь ввиду, возможно ту которая относится к курсу Go на Coursera. Я лично там писал что выбрал Го в частности из-за bbolt (аля boltDb).
Можешь смеяться сколько хочешь, а я вот объясню свою логику выбора: хочется не иметь НИКАКИХ внешних зависимостей в проекте! Хочется просто тупа скопировать 2 файла на новую VPS и сервис должен работать дальше, лучше и еще быстрее. Да вот такие у меня требования к момему собственному проекту! Хочу чтобы я тратил на развертываение 2 шага: купил VPS, скопировал файлы и запустил!

bbolt выбрал исключительно потому-что это первая ссылка которую выдает Гугл по встроенным базам в Го. По описанию я понял, что меня лично она устраивает. Искал какие-нибудь тесты, не нашел ничего толкового. Решил буду сам тестировать.


PS> Не нужно всех вокруг и в частности в сообществе Го считать идиотами. У многих есть конкретные требования и они стараются в них вписаться. А уж поверь и на Си и на SQL писать многие там тоже умеют. Я лично считаю признаком идиотизма и низкой квалификации если Сишник будет создавать Вэбсервис на Си, только потому-что он крутой Сишник.
Re[12]: Go язык прёт?
От: Sharov Россия  
Дата: 18.10.18 09:17
Оценка:
Здравствуйте, m2l, Вы писали:

m2l>С тем же успехом все это достижимо и на чистом С, без плюсов и boost-а. Просто стоимость такого кода больше аналогичной функциональности в golang.


А чем реализация в голанг на том же С будет лучше реализации на С для С?
Кодом людям нужно помогать!
Re[17]: Go язык прёт?
От: Тёмчик Австралия жж
Дата: 18.10.18 10:30
Оценка:
Здравствуйте, so5team, Вы писали:

Тё>>О, типичный представитель нарисовался.


S>Какие ваши доказательства?


Тё>>Выучил названия, но ничего не понял.


S>Очень сложно понять как спешиалистЪ вроде вас, много лет говорящий про то, что он программирует на C++ и на Java, не знал про Visitor столько лет. Ладно бы вы на функциональных языках программировали, а про C++/Java только слышали краем уха. Так ведь нет.


S>Пожалуйста, объясните, как вам это удалось? Вероятно, работали в крупных конторах с хорошо налаженными процессами и эффективным менеджментом?


Я Вам уже в который раз пытаюсь донести, что «знать про визитор» и «знать визитор»- две большие разницы. Примерно как Оля «знает про C++», а Петя «знает C++». Но Вы слишком узко-кругозорный, чтобы понять.

И кстати про C++ с Java- этим список далеко не ограничивается. Только вот на Go ещё не довелось.
Re[18]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 18.10.18 10:55
Оценка:
Здравствуйте, Тёмчик, Вы писали:

S>>Пожалуйста, объясните, как вам это удалось? Вероятно, работали в крупных конторах с хорошо налаженными процессами и эффективным менеджментом?


Тё>Я Вам уже в который раз пытаюсь донести, что «знать про визитор» и «знать визитор»- две большие разницы. Примерно как Оля «знает про C++», а Петя «знает C++».


Так вы, очевидно, не знали ни "про визитор", ни "визитор". Объясните, как вам это удалось?

Тё>Но Вы слишком узко-кругозорный, чтобы понять.


Еще раз, какие ваши доказательства? Вот про незнание о визиторе вы сами признались. Тут даже ничего доказывать не нужно. Выпады же в адрес собеседника нужно как-то обосновывать.

Тё>И кстати про C++ с Java- этим список далеко не ограничивается. Только вот на Go ещё не довелось.


Надо полагать, в этом списке почетное место занимает OCaml с Haskell-ем? Ну или хотя бы Scala? Или F#? А может Erlang?
Re[14]: Go язык прёт?
От: chaotic-kotik  
Дата: 18.10.18 11:03
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Здравствуйте, chaotic-kotik, Вы писали:


CK>> Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB. Судя по всему, основной контингент там состоит из бывших PHP/Ruby/Python/etc программистов.


C0x>Не знаю какую ты группу имеешь ввиду, возможно ту которая относится к курсу Go на Coursera. Я лично там писал что выбрал Го в частности из-за bbolt (аля boltDb).


https://t.me/gogolang

C0x>Можешь смеяться сколько хочешь, а я вот объясню свою логику выбора: хочется не иметь НИКАКИХ внешних зависимостей в проекте! Хочется просто тупа скопировать 2 файла на новую VPS и сервис должен работать дальше, лучше и еще быстрее. Да вот такие у меня требования к момему собственному проекту! Хочу чтобы я тратил на развертываение 2 шага: купил VPS, скопировал файлы и запустил!


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

C0x>bbolt выбрал исключительно потому-что это первая ссылка которую выдает Гугл по встроенным базам в Го. По описанию я понял, что меня лично она устраивает. Искал какие-нибудь тесты, не нашел ничего толкового. Решил буду сам тестировать.


boltdb то ладно, хотя и спорно, LMDB — супер стабильная библиотека, используется вообще везде, есть в любом дистрибутиве, в отличие от
как ты объяснишь ledis? это отдельный сервис, не встраиваемая библиотека

PS>> Не нужно всех вокруг и в частности в сообществе Го считать идиотами. У многих есть конкретные требования и они стараются в них вписаться. А уж поверь и на Си и на SQL писать многие там тоже умеют. Я лично считаю признаком идиотизма и низкой квалификации если Сишник будет создавать Вэбсервис на Си, только потому-что он крутой Сишник.


я такого не говорил
Re[15]: Go язык прёт?
От: C0x  
Дата: 18.10.18 11:20
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>https://t.me/gogolang


Это похоже другая. Я недавно подписался на курс по Go от МФТИ на курсере. У них там группа относительно самого курса, но периодически разные темы и вопросы всплывают, в частности и про базы.

C0x>>Можешь смеяться сколько хочешь, а я вот объясню свою логику выбора: хочется не иметь НИКАКИХ внешних зависимостей в проекте! Хочется просто тупа скопировать 2 файла на новую VPS и сервис должен работать дальше, лучше и еще быстрее. Да вот такие у меня требования к момему собственному проекту! Хочу чтобы я тратил на развертываение 2 шага: купил VPS, скопировал файлы и запустил!


CK>никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется с твоим приложением, но зависимостей никаких нет


В том то и дело, что статические зависимости и рантайм зависимости очень разные вещи. Одно дело когда у меня база, кэш и приложение это одно целое (один тупа файл), другое дело когда мне на новой VPS нужно развернуть и настроить сначало базу, потом еще засосать туда схему, а потом только развернуть приложение.

CK>а развертывание это всегда только копирование файла


Да ладно? Ну вот в частности развертывание скажем веб сервиса написанного не на Го или сях, это: 1. Развернуть Базу, 2. Развернуть кэш, 3. Развернуть NGinx и еще развернуть сам скриптовый интерпритатор, а только потом скопировать сами файлы. Теперь сравни это с копированием 1-2 файлов на чистую VPS.

CK>boltdb то ладно, хотя и спорно


Если есть какая либо инфа по boltdb, особенно почему спорно, то буду рад узнать, т.к. инфы толком пока мало, кроме своих тестов.

LMDB — супер стабильная библиотека, используется вообще везде, есть в любом дистрибутиве, в отличие от
CK>как ты объяснишь ledis? это отдельный сервис, не встраиваемая библиотека

Я хз если честно, ни с тем ни с другим дело не имел.
Re[15]: Go язык прёт?
От: C0x  
Дата: 18.10.18 11:23
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

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


И при этом все это я делаю на своей рабочей Windows станции в удобном для себя среде, а в итоге получаю 1 файл для Linux системы, который осталось скопировать через ssh и запустить.
Re[16]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 18.10.18 12:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Это как бы немало.

EP>>Если у нас таки "реалистичный размер в 64Кб", то в варианте на Go сколько будет?
C>Столько, сколько нужно.

Если это действительно так, тогда получаем квадратичную сложность
Re[14]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 18.10.18 12:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>2) Сегментированные стеки. Компилятор вставляет в пролог и эпилог функции (или в место вызова) код,


Специальный эпилог в код функции не вставляется. На unhappy path вставляется специальный адрес возврата в стек, на который переходит ret.

C>который может передвигать указатель стека между сегментами (в виде связного списка). Это тормозит из-за того, что эта проверка — дополнительное и дорогое ветвление, с косвенным доступом. В Golang от этого отказались примерно 5 лет назад из-за тормозов.


В Go будет точно такая же проверка в прологе и ветвление
Re[12]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 18.10.18 13:11
Оценка:
Здравствуйте, m2l, Вы писали:

EP>>Планировщик, каналы и прочая обвязка есть в Boost.Fiber.

EP>>То есть в Boost есть три библиотеки на тему stackful, начиная от низкого к более высокому уровню: Boost.Context, Boost.Coroutine, Boost.Fiber.
m2l>С тем же успехом все это достижимо и на чистом С, без плюсов

Непонятно при чём здесь C
Корутины много где реализуемы, да и вообще появились раньше C. А например Erlang с зелёными процессами — раньше Go. И?
Отредактировано 18.10.2018 13:12 Evgeny.Panasyuk . Предыдущая версия .
Re[15]: unhappy path
От: Sharov Россия  
Дата: 18.10.18 15:08
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>Специальный эпилог в код функции не вставляется. На unhappy path вставляется специальный адрес возврата в стек, на который переходит ret.


А что подразумевается под unhappy path?
Кодом людям нужно помогать!
Re[13]: Go язык прёт?
От: m2l  
Дата: 18.10.18 18:38
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Непонятно при чём здесь C

К тому, что "много где реализуемы"....
EP>Корутины много где реализуемы, да и вообще появились раньше C. А например Erlang с зелёными процессами — раньше Go. И?
Наличие в С++ библиотек, дающих корутины не приближает его к удобству и простоте многопоточного программирования на Golang.

И да, Ernalg конечно крут, но уж больно специфический даже для функциональных языков...
Re[13]: Go язык прёт?
От: m2l  
Дата: 18.10.18 18:44
Оценка:
Здравствуйте, Sharov, Вы писали:

S>А чем реализация в голанг на том же С будет лучше реализации на С для С?


1. Синтаксическим сахаром языка. К этому относится и неявный вызов планировщика.
2. GC позволяющим играться с памятью стеков и каналов.
3. Для golang это часть языка/стандартной библиотеки. Уже сделанная и работающая на всех платформах где работает язык.

И да, если задаться целью и затачиваться под конкретную задачу, С как более низкоуровневый инструмент даёт больше возможностей для оптимизации.
Re[14]: Go язык прёт?
От: so5team https://stiffstream.com
Дата: 18.10.18 20:05
Оценка:
Здравствуйте, m2l, Вы писали:

m2l>2. GC позволяющим играться с памятью стеков и каналов.


Как GC позволяет играться с памятью каналов?
Re[20]: Go язык прёт?
От: Cyberax Марс  
Дата: 18.10.18 23:28
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

C>>1) Возможность полной независимости от libc.

CK>это скорее минус, что будешь делать если ABI linux изменится?
ABI в Линуксе отлит в граните. Линус ругается матом на тех, кто его ломает.
Sapienti sat!
Re[13]: Go язык прёт?
От: Cyberax Марс  
Дата: 18.10.18 23:34
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Побуду адвокатом дьявола (не имею ничего против Go). Недавно зашел в группу по golang в telegram. Вы бы почитали их обсуждения. Это какое-то днище. Люди не знают даже стандартной библиотеки Go нормально, у большинства очень узкий кругозор и какие-то очень странные представления об окружающем мире. Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB.

Я тоже использую Bolt вместо SQLite или чего-то подобного. Просто из-за того, что оно позволяет всё построить статически без всяких внешних зависимостей. При появлении C-кода начинаются сразу проблемы, если на целевом узле нет нужных библиотек (наприме).
Sapienti sat!
Re[15]: Go язык прёт?
От: Cyberax Марс  
Дата: 18.10.18 23:36
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется с твоим приложением, но зависимостей никаких нет

Можно поднять своё зеркало зависимостей. У нас такое есть, так что локальные чистые билды строятся без всякого Интернета.

CK>а развертывание это всегда только копирование файла

Нет, если у софта есть зависимость от С-кода, то часто нужно будет обеспечить, чтобы были установлены нужные пакеты. А они все по-разному в разных ОС устанавливаются. И с собой сложно их просто запаковать из-за вечных проблем с версиями glibc.
Sapienti sat!
Re[21]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 19.10.18 00:45
Оценка: :)))
Здравствуйте, Cyberax, Вы писали:

C>ABI в Линуксе отлит в граните. Линус ругается матом на тех, кто его ломает.


Так он же вроде стал слишком нетолерастом и его практически изгнали. Туда же и ABI пойдет, нетолерастное это дело ABI

Как говорится

Содомитам – везде у нас дорога,
Транссексуалам – везде у нас почет.

Отредактировано 21.10.2018 13:32 kaa.python . Предыдущая версия . Еще …
Отредактировано 19.10.2018 0:58 kaa.python . Предыдущая версия .
Re[14]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 19.10.18 00:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я тоже использую Bolt вместо SQLite или чего-то подобного. Просто из-за того, что оно позволяет всё построить статически без всяких внешних зависимостей. При появлении C-кода начинаются сразу проблемы, если на целевом узле нет нужных библиотек (наприме).


О, может ты знаешь. У меня тоже BoltDB, но по ряду причин мне нужно её хранить исключительно в памяти (доиск RO в ряде случаев, чтоб его). Я что-то полистал документацию и такая простейшая фича присутствующая в SQlite отсутствует в Bolt. Есть какой-то простой способ добиться нужного эффекта?
Re[15]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 01:23
Оценка: 15 (1)
Здравствуйте, kaa.python, Вы писали:

KP>О, может ты знаешь. У меня тоже BoltDB, но по ряду причин мне нужно её хранить исключительно в памяти (доиск RO в ряде случаев, чтоб его). Я что-то полистал документацию и такая простейшая фича присутствующая в SQlite отсутствует в Bolt. Есть какой-то простой способ добиться нужного эффекта?

Без патча — никак. Если запатчить, то очень просто на Линуксе.

Нужно в db::Open ( https://github.com/etcd-io/bbolt/blob/master/db.go#L160 ) добавить код, который вместо os.Open будет использовать memfd_create (обёртка: https://github.com/justincormack/go-memfd ), если путь к файлу начинается с магического префикса.

Хотя более правильно добавить в bbolt работу с данными в памяти напрямую.
Sapienti sat!
Re[16]: Go язык прёт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 19.10.18 01:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Хотя более правильно добавить в bbolt работу с данными в памяти напрямую.


Мне нужно кроссплатформенное решение. Сейчас думаю то-ли на SQlite мигрировать (выглядит более разумно, так как реляционная база данных больше подходит под задачу), либо браться за переделку Bolt-а.
Re[17]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 02:49
Оценка:
Здравствуйте, kaa.python, Вы писали:

C>>Хотя более правильно добавить в bbolt работу с данными в памяти напрямую.

KP>Мне нужно кроссплатформенное решение. Сейчас думаю то-ли на SQlite мигрировать (выглядит более разумно, так как реляционная база данных больше подходит под задачу), либо браться за переделку Bolt-а.
По идее, запатчить bbolt должно быть несложно и поможет другим.
Sapienti sat!
Re[21]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 06:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>ABI в Линуксе отлит в граните. Линус ругается матом на тех, кто его ломает.


Линус уже не ругается матом, да и ABI никогда не был отлит в граните. Он иногда меняется. Обычно добавляется количество аргументов в системных вызовах. С точки зрения LSB это additive change, все ОК. Обратная совместимость при этом достигается за счет libC (для этого и нужно ее версионирование).
Re[16]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 06:51
Оценка:
Здравствуйте, C0x, Вы писали:


CK>>никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется с твоим приложением, но зависимостей никаких нет


C0x>В том то и дело, что статические зависимости и рантайм зависимости очень разные вещи. Одно дело когда у меня база, кэш и приложение это одно целое (один тупа файл), другое дело когда мне на новой VPS нужно развернуть и настроить сначало базу, потом еще засосать туда схему, а потом только развернуть приложение.


Ну это все самообман. Базу все равно нужно будет мигрировать, даже KV. Приложений рано или поздно может стать больше одного. В общем, проще сразу написать ansible playbook (например), а там уже все равно, есть runtime зависимости, или нет их.


C0x>Да ладно? Ну вот в частности развертывание скажем веб сервиса написанного не на Го или сях, это: 1. Развернуть Базу, 2. Развернуть кэш, 3. Развернуть NGinx и еще развернуть сам скриптовый интерпритатор, а только потом скопировать сами файлы. Теперь сравни это с копированием 1-2 файлов на чистую VPS.


Я правильно понял что у тебя в интернет торчит твой сервис на Go? Т.е. вместо Nginx или Apache в DMZ у тебя там все приложение целиком? Пакет net/http не подходит для того чтобы раздавать интернет трафик, JFYI
Re[14]: Go язык прёт?
От: mik1  
Дата: 19.10.18 06:54
Оценка: +1
Здравствуйте, m2l, Вы писали

m2l>И да, Ernalg конечно крут, но уж больно специфический даже для функциональных языков...


Если не секрет, что такого специфического в Эрланге?
Re[22]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 06:56
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

C>>ABI в Линуксе отлит в граните. Линус ругается матом на тех, кто его ломает.

CK>Линус уже не ругается матом, да и ABI никогда не был отлит в граните.
Всегда был.

CK>Он иногда меняется. Обычно добавляется количество аргументов в системных вызовах.

Хватит бредить.

CK>С точки зрения LSB это additive change, все ОК. Обратная совместимость при этом достигается за счет libC (для этого и нужно ее версионирование).

Хватит бредить.

В Линуксе гарантируется стабильность ABI на уровне системных вызовов. Статические приложения из 95-го в результате могут работать на Линуксе этого года. Можно даже взять старую ОС (типа Debian Potato) и запустить его на новом ядре.
Sapienti sat!
Re[17]: Go язык прёт?
От: C0x  
Дата: 19.10.18 07:11
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Ну это все самообман. Базу все равно нужно будет мигрировать, даже KV. Приложений рано или поздно может стать больше одного. В общем, проще сразу написать ansible playbook (например), а там уже все равно, есть runtime зависимости, или нет их.


В моем случае вообще ничего не нужно. Я копирую файл, запускаю с заданными параметрами коммандной строки и оно должно работать. Но тут у меня все надежды на то что bbolt такой каким я себе его представляю, а именно перетащил файл и нет проблем.

CK>Я правильно понял что у тебя в интернет торчит твой сервис на Go? Т.е. вместо Nginx или Apache в DMZ у тебя там все приложение целиком? Пакет net/http не подходит для того чтобы раздавать интернет трафик, JFYI



Пока у меня ничего не торчит, я еще локально дебажусь. А что не так с net/http и чем он плох для Restfull API наружу?
Вообще планирую fasthttp, т.к. по заявлениям многих Гошников он шустрее работает. Но опять же найти каких-то толковых тестов я еще не нашел, делаю все сам путем проб и ошибок.
Re[17]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 07:35
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Ну это все самообман. Базу все равно нужно будет мигрировать, даже KV. Приложений рано или поздно может стать больше одного. В общем, проще сразу написать ansible playbook (например), а там уже все равно, есть runtime зависимости, или нет их.

На этом самообмане мы построили миллиардную компанию.

CK>Я правильно понял что у тебя в интернет торчит твой сервис на Go? Т.е. вместо Nginx или Apache в DMZ у тебя там все приложение целиком? Пакет net/http не подходит для того чтобы раздавать интернет трафик, JFYI

Почему не подходит?
Sapienti sat!
Re[18]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 07:36
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Вообще планирую fasthttp, т.к. по заявлениям многих Гошников он шустрее работает. Но опять же найти каких-то толковых тестов я еще не нашел, делаю все сам путем проб и ошибок.

net/http вполне себе нормально работает, если не нужно масштабирование на 100500 параллельных запросов, которые читают файлы.
Sapienti sat!
Re[18]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 08:02
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Пока у меня ничего не торчит, я еще локально дебажусь. А что не так с net/http и чем он плох для Restfull API наружу?

C0x>Вообще планирую fasthttp, т.к. по заявлениям многих Гошников он шустрее работает. Но опять же найти каких-то толковых тестов я еще не нашел, делаю все сам путем проб и ошибок.

fasthttp — говно, он не поддерживает полностью спецификацию http, одному богу известно сколько там дыр безопасности
Re[19]: Go язык прёт?
От: C0x  
Дата: 19.10.18 08:03
Оценка: :)
Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, C0x, Вы писали:


C0x>>Пока у меня ничего не торчит, я еще локально дебажусь. А что не так с net/http и чем он плох для Restfull API наружу?

C0x>>Вообще планирую fasthttp, т.к. по заявлениям многих Гошников он шустрее работает. Но опять же найти каких-то толковых тестов я еще не нашел, делаю все сам путем проб и ошибок.

CK>fasthttp — говно, он не поддерживает полностью спецификацию http, одному богу известно сколько там дыр безопасности


OK спасибо за инфу.
Re[18]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 08:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

CK>>Я правильно понял что у тебя в интернет торчит твой сервис на Go? Т.е. вместо Nginx или Apache в DMZ у тебя там все приложение целиком? Пакет net/http не подходит для того чтобы раздавать интернет трафик, JFYI

C>Почему не подходит?

вот например поэтому — https://mmcloughlin.com/posts/your-pprof-is-showing
еще потому что тебе все равно нужен DMZ
Re[19]: Go язык прёт?
От: C0x  
Дата: 19.10.18 08:19
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>вот например поэтому — https://mmcloughlin.com/posts/your-pprof-is-showing


И это аргумент?

Вообщем-то в самой же статье и написано

net/http/pprof is awesome, just don’t leave your debugging information open to the world! Follow these precautions and you’ll be fine.

Re[19]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 08:25
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

C>>Почему не подходит?

CK>вот например поэтому — https://mmcloughlin.com/posts/your-pprof-is-showing
CK>еще потому что тебе все равно нужен DMZ
Хватит бредить уже. Займись лучше изучением матчасти.

Чем конкретно net/http не подходит, а не pprof?
Sapienti sat!
Re[19]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 08:25
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

C0x>>Вообще планирую fasthttp, т.к. по заявлениям многих Гошников он шустрее работает. Но опять же найти каких-то толковых тестов я еще не нашел, делаю все сам путем проб и ошибок.

CK>fasthttp — говно, он не поддерживает полностью спецификацию http, одному богу известно сколько там дыр безопасности
И сколько же их там?
Sapienti sat!
Re[20]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 10:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

CK>>fasthttp — говно, он не поддерживает полностью спецификацию http, одному богу известно сколько там дыр безопасности

C>И сколько же их там?



Are there known net/http advantages comparing to fasthttp?

Yes:

net/http supports HTTP/2.0 starting from go1.6.
net/http API is stable, while fasthttp API constantly evolves.
net/http handles more HTTP corner cases.
net/http should contain less bugs, since it is used and tested by much wider audience.
net/http works on Go older than 1.5.
Re[18]: Go язык прёт?
От: Sharov Россия  
Дата: 19.10.18 10:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>На этом самообмане мы построили миллиардную компанию.


aws или ...?
Кодом людям нужно помогать!
Re[20]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 10:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Чем конкретно net/http не подходит, а не pprof?


net/http подходит много для чего, просто в реальном проекте тебе нужно следующее

1. DMZ
2. Load balancing
3. Отдавать статику

это все тоже можно написать на go, но зачем, если есть nginx?
Re[20]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 10:15
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>Здравствуйте, chaotic-kotik, Вы писали:


CK>>вот например поэтому — https://mmcloughlin.com/posts/your-pprof-is-showing


C0x>И это аргумент?


думаешь это единственный модуль, добавляющий свои endpoints в http?
Re[21]: Go язык прёт?
От: C0x  
Дата: 19.10.18 10:19
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, Cyberax, Вы писали:


C>>Чем конкретно net/http не подходит, а не pprof?


CK>net/http подходит много для чего, просто в реальном проекте тебе нужно следующее


CK>1. DMZ

CK>2. Load balancing

А если это нафиг не нужно до какой-то поры, можно тогда net/http использовать?

Более того, чтобы сделать load balancing (если он реально нужен уже), то это вообще не проблема: покупается 3rd party сервис либо подымается свой сервак который собственно и балансирует. Но это никак не затрагивает виртуальные хосты, на которых крутится Го сервисы.

CK>3. Отдавать статику


Без проблем средствами net/http сейчас это делаю или про какую стату речь?

CK>это все тоже можно написать на go, но зачем, если есть nginx?


Смею предположить, может по тем же причинам что "зачем boltDB если есть MongoDB или Редиска?". Что-бы не тащить левых рантайм зависимостей в проект, тем самым ускоряя развертывание новых инстансов.
Re[21]: Go язык прёт?
От: C0x  
Дата: 19.10.18 10:24
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>думаешь это единственный модуль, добавляющий свои endpoints в http?


Возможно не единственный, но как это вообще мешает использованию http в продакшене?
То что решения нужно использовать с умом никто и не опровергал.
Re[21]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 10:55
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>>>fasthttp — говно, он не поддерживает полностью спецификацию http, одному богу известно сколько там дыр безопасности

C>>И сколько же их там?
CK>Are there known net/http advantages comparing to fasthttp?
Ну так и сколько же там дыр в безопасности-то?
Sapienti sat!
Re[19]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 10:56
Оценка:
Здравствуйте, Sharov, Вы писали:

C>>На этом самообмане мы построили миллиардную компанию.

S>aws или ...?
Нет, уже другую
Sapienti sat!
Re[20]: оффтоп
От: Sharov Россия  
Дата: 19.10.18 11:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, уже другую


Уже не в aws?
Кодом людям нужно помогать!
Re[21]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 11:02
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

C>>Чем конкретно net/http не подходит, а не pprof?

CK>net/http подходит много для чего, просто в реальном проекте тебе нужно следующее
CK>1. DMZ
DMZ — это вообще не софт, это способ организации сети. Учим матчасть.

CK>2. Load balancing

Не обязательно, но если это нужно, то этим будет заниматься выделенный HAProxy или специальная железка (NetScaler какой-нибудь). Нафиг nginx?

CK>3. Отдавать статику

На практике самый обычный net/http прекрасно засвечивает канал в 1Гбит.

Более того, к нему при необходимости прикручивается sendfile/splice и оно вообще всю передачу данных делегирует ядру. В следующей версии Go будет и поддержка kTLS из последних ядер. Мы через него передаём терабайты данных в кластере между узлами.

CK>это все тоже можно написать на go, но зачем, если есть nginx?

Остался только пункт:

4. Собственно само приложение.
Sapienti sat!
Re[21]: оффтоп
От: Cyberax Марс  
Дата: 19.10.18 11:03
Оценка: 4 (1)
Здравствуйте, Sharov, Вы писали:

C>>Нет, уже другую

S>Уже не в aws?
Не совсем. Тут всё сложно, меня как бы одолжили другой компании.
Sapienti sat!
Re[21]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 11:04
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

C0x>>И это аргумент?

CK>думаешь это единственный модуль, добавляющий свои endpoints в http?
https://www.youtube.com/watch?v=GTo592cukhY
Sapienti sat!
Re[22]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 13:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

CK>>1. DMZ

C>DMZ — это вообще не софт, это способ организации сети. Учим матчасть.
где я говорил что это что-то другое?

CK>>2. Load balancing

C>Не обязательно, но если это нужно, то этим будет заниматься выделенный HAProxy или специальная железка (NetScaler какой-нибудь). Нафиг nginx?
nginx не принципиален

CK>>3. Отдавать статику

C>На практике самый обычный net/http прекрасно засвечивает канал в 1Гбит.
C>Более того, к нему при необходимости прикручивается sendfile/splice и оно вообще всю передачу данных делегирует ядру. В следующей версии Go будет и поддержка kTLS из последних ядер. Мы через него передаём терабайты данных в кластере между узлами.
прикручивается, а в nginx он уже есть, кэширование тоже прикручивается, никто не спорит с этим
Re[22]: Go язык прёт?
От: chaotic-kotik  
Дата: 19.10.18 13:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

CK>>Are there known net/http advantages comparing to fasthttp?

C>Ну так и сколько же там дыр в безопасности-то?

я не знаю, но у него явно нет такой странички — https://www.owasp.org/index.php/SCG_WS_nginx
Re[16]: unhappy path
От: Evgeny.Panasyuk Россия  
Дата: 19.10.18 15:19
Оценка: 8 (1)
Здравствуйте, Sharov, Вы писали:

EP>>Специальный эпилог в код функции не вставляется. На unhappy path вставляется специальный адрес возврата в стек, на который переходит ret.

S>А что подразумевается под unhappy path?

Недостаточно памяти под фрейм текущей функции.
Re[14]: Go язык прёт?
От: Evgeny.Panasyuk Россия  
Дата: 19.10.18 15:22
Оценка:
Здравствуйте, m2l, Вы писали:

EP>>Непонятно при чём здесь C

m2l>К тому, что "много где реализуемы"....

С этим кто-то спорил?

EP>>Корутины много где реализуемы, да и вообще появились раньше C. А например Erlang с зелёными процессами — раньше Go. И?

m2l>Наличие в С++ библиотек, дающих корутины не приближает его к удобству и простоте многопоточного программирования на Golang.

Приближает
Re[23]: Go язык прёт?
От: Cyberax Марс  
Дата: 19.10.18 18:16
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>>>Are there known net/http advantages comparing to fasthttp?

C>>Ну так и сколько же там дыр в безопасности-то?
CK>я не знаю, но у него явно нет такой странички — https://www.owasp.org/index.php/SCG_WS_nginx
А зачем net/http эта страничка?
Sapienti sat!
Re[15]: Go язык прёт?
От: m2l  
Дата: 20.10.18 10:01
Оценка:
Здравствуйте, mik1, Вы писали:

M>Если не секрет, что такого специфического в Эрланге?


Функциональный язык, со своей системой типов. И сам синтаксис и абстракции скрытые под ним сильно отличаются от императивных языков.
Грубо говоря, как Go и С++ или как любой из них и SQL.
Re[15]: Go язык прёт?
От: m2l  
Дата: 20.10.18 10:02
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

m2l>>Наличие в С++ библиотек, дающих корутины не приближает его к удобству и простоте многопоточного программирования на Golang.


EP>Приближает


Это личный опыт программирования на обоих языках? Или теоретически рассуждения из знания одного?
Re[21]: Не используйте дефолтный http.Get ?
От: C0x  
Дата: 29.10.18 08:49
Оценка:
Вот я тут добавлю свою ложку дегтя в net/http с которой столкнулся как новичок.

Сегодня лезу на свой сервак, а он не открывается, тупа висит. Смотрю логи а там тысячи ошибок типа http://skrinshoter.ru/s/291018/wcSQpFrh

Видимо столкнулся с проблемой описываемой тут https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779
Re[22]: Не используйте дефолтный http.Get ?
От: Anton Batenev Россия https://github.com/abbat
Дата: 29.10.18 13:59
Оценка: +1
Здравствуйте, C0x, Вы писали:

C0x> Вот я тут добавлю свою ложку дегтя в net/http с которой столкнулся как новичок.

C0x> Сегодня лезу на свой сервак, а он не открывается, тупа висит. Смотрю логи а там тысячи ошибок типа http://skrinshoter.ru/s/291018/wcSQpFrh
C0x> Видимо столкнулся с проблемой описываемой тут https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779

Если ты столкнулся именно с этой проблемой, то go тут ни при чем. В любом языке, в любой библиотеке, всегда надо явно задавать таймауты обработки запросов.
Re[23]: Не используйте дефолтный http.Get ?
От: C0x  
Дата: 29.10.18 15:28
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, C0x, Вы писали:


C0x>> Вот я тут добавлю свою ложку дегтя в net/http с которой столкнулся как новичок.

C0x>> Сегодня лезу на свой сервак, а он не открывается, тупа висит. Смотрю логи а там тысячи ошибок типа http://skrinshoter.ru/s/291018/wcSQpFrh
C0x>> Видимо столкнулся с проблемой описываемой тут https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779

AB>Если ты столкнулся именно с этой проблемой, то go тут ни при чем. В любом языке, в любой библиотеке, всегда надо явно задавать таймауты обработки запросов.


Не всегда. В некоторых случаях хватает и дефолтовых.

C# HttpWebRequest.Timeout Property default value is 100,000 milliseconds (100 seconds).


В этой же статье говорится:

Some languages (e.g. Java) have the same issue, others (e.g. Ruby has a default 60 second read timeout) do not.


Вообщем если есть хоть какие-то таймауты по дефолту это уже значит, что скорее всего с утра открыв свой сайт (сервер) ты не обнаружишь что он тупа не отвечает.
Re[23]: Не используйте дефолтный http.Get ?
От: C0x  
Дата: 29.10.18 15:31
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, C0x, Вы писали:


C0x>> Вот я тут добавлю свою ложку дегтя в net/http с которой столкнулся как новичок.

C0x>> Сегодня лезу на свой сервак, а он не открывается, тупа висит. Смотрю логи а там тысячи ошибок типа http://skrinshoter.ru/s/291018/wcSQpFrh
C0x>> Видимо столкнулся с проблемой описываемой тут https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779

AB>Если ты столкнулся именно с этой проблемой, то go тут ни при чем. В любом языке, в любой библиотеке, всегда надо явно задавать таймауты обработки запросов.


Если уж мы сравниваем все доступные решения, то так же не припоминаю чтобы я задавал какие-то таймауты в NGINX. И сервер таки не зависал насмерть.
Re[24]: Не используйте дефолтный http.Get ?
От: Anton Batenev Россия https://github.com/abbat
Дата: 30.10.18 07:20
Оценка:
Здравствуйте, C0x, Вы писали:

C0x> Не всегда. В некоторых случаях хватает и дефолтовых.


Всегда. Дефолтные таймауты обычно заданы "пальцем в небо" и не адекватны (велики) решаемой задаче (плюс имеют свойство иногда пересматриваться). Время ответа среднестатистического веб-приложения должно быть в пределах 300 ms => запросы к сторонним сервисам должны выполняться за сопоставимое время или быстрее. Через 60/100 секунд ответ будет некому отдавать просто.
Re[25]: Не используйте дефолтный http.Get ?
От: C0x  
Дата: 30.10.18 08:56
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, C0x, Вы писали:


C0x>> Не всегда. В некоторых случаях хватает и дефолтовых.


AB>Всегда. Дефолтные таймауты обычно заданы "пальцем в небо" и не адекватны (велики) решаемой задаче (плюс имеют свойство иногда пересматриваться).


100 секунд я привел выше пример, это велико время или мало?

AB> Время ответа среднестатистического веб-приложения должно быть в пределах 300 ms


Ну вот ты сам и определил время, разве нельзя отсюда таймауты вывести и задекларировать как дефолт?
Re[26]: Не используйте дефолтный http.Get ?
От: Anton Batenev Россия https://github.com/abbat
Дата: 31.10.18 13:38
Оценка:
Здравствуйте, C0x, Вы писали:

C0x> AB>Всегда. Дефолтные таймауты обычно заданы "пальцем в небо" и не адекватны (велики) решаемой задаче (плюс имеют свойство иногда пересматриваться).

C0x> 100 секунд я привел выше пример, это велико время или мало?

В большинстве сценариев это очень большое время. Если мы говорим о сценарии, когда на пользовательский запрос под капотом приложения делается запрос к стороннему сервису (например, в микросервисной архитектуре), то время отклика даже по самым консервативным промышленным стандартам не должно превышать 10-15 секунд (это верхняя граница).

Под стандартами здесь я понимаю документы типа:

— ESD/MITRE (ESD-TR-86-278, "Guidelines for Designing User Interface Software", 1986)
— TAFIM ("Technical Architecture Framework for Information Management", 1996, том 8, "DoD Human Computer Interface Style Guide")
— MIL-STD 1472 (ревизия G, 2012)

C0x> AB> Время ответа среднестатистического веб-приложения должно быть в пределах 300 ms

C0x> Ну вот ты сам и определил время, разве нельзя отсюда таймауты вывести и задекларировать как дефолт?

Можно. Просто возникнет вопрос: "А почему 300, а не 400, или 200?". По этому берут некую цифру пальцем в небо, заведомо больше обычной длительности запроса. Значение 0, подразумевающее условно-бесконечный таймаут (на самом деле при разрыве tcp соединения время будет зависеть от настроек tcp keep-alive и еще ряда факторов) здесь ни чем не лучше и не хуже, хотя лично мне нравиться больше, т.к. позволяет быстрее прострелить себе ногу еще на тестинге до того, как ошибка положит production.
Re[27]: Не используйте дефолтный http.Get ?
От: C0x  
Дата: 31.10.18 13:40
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>т.к. позволяет быстрее прострелить себе ногу еще на тестинге до того, как ошибка положит production.


Видимо в этом и причина. Жаль что они сразу в документации это явно не декларируют, красными буквами.
Re[21]: Go язык прёт?
От: vdimas Россия  
Дата: 31.10.18 22:05
Оценка:
Здравствуйте, ·, Вы писали:

·>Я хочу разобраться почему меня, как программиста на ЯП, должна волновать разница stackless/stackfull?


Пока есть разница в синтаксисе, ты не сможешь не замечать различия.


·>В обычной жизни когда я пишу программу, я знаю, что размещение данных на стеке более эффективно работает на железе, т.к. менеджемент памяти на порядки проще, не нужно никакой динамики, куч памяти, подсчётов ссылок, сборки мусора и прочего, тогда как классическая работа с классическим стеком это просто инкремент/декремент одного регистра. Это всё влияет на производительность и мои решения о выборе конкретного механизма.


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


·>А вот если идёт жонглирование фреймами стека и их перемещение туда-сюда, то стек становится не стеком, а чёрт знает чем, и я перестаю понимать разницу — какая разница чем ЯП там манипулирует вунутре и как оно там называется — фрейм стека или объект?


Разница сохраняется. Независимо от техники реализации стека коротины тебе гарантируется локальность "стековых" данных для твоего логического процесса.
Re[22]: Go язык прёт?
От: vdimas Россия  
Дата: 31.10.18 23:00
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>yeld уже 13 лет. И они показали свою эффективнось

НС>И неэффективность. К примеру, как то раз в Решарпере производилась глобальная вычистка линка из кода. Как раз из-за тормозов при длинных цепочках итераторов.

Хы.
Помнится в году эдак 2005-м, когда я пытался рассуждать на тему, что вложенные yield порождают цепочки автоматов, чего только не наслушался... ))
Re[24]: Go язык прёт?
От: Somescout  
Дата: 01.11.18 06:01
Оценка:
ARK>Да. Один сборщик мусора сразу вычеркивает кучу применений. Операционные системы,

Если вы имеете в виду низкоуровневое программирование, то да, но там и C++ не особо подходит.

ARK> коробочный софт


WAT?

ARK> игры


Unity

ARK> софт для самолетов-машин-марсоходов-роботов


Посмотрите для чего используется Erlang.

ARK> ядра высокопроизводительных серверных систем (трейдинговых, поисковых и т.д.) — нигде здесь C# нет и никогда не будет.


Ниже уже ответили.
ARI ARI ARI... Arrivederci!
Re[6]: Go язык прёт?
От: Sheridan Россия  
Дата: 01.11.18 06:57
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Самая популярная платформа — Линукс! Почти половина разработчиков пишет под него. А, нет, больше! Там ещё есть такие платформы, как AWS, WordPress, Raspberry Pi, что надо тоже понимать, как Линукс. Что в сумме ещё процентов 50 собирает. Вендекапец наступил!


Ну так это почти только рсдн и держится ещо островком виндопоклонства, в окружении современного мира.
Matrix has you...
Re[23]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 02.11.18 18:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Хы.

V>Помнится в году эдак 2005-м, когда я пытался рассуждать на тему, что вложенные yield порождают цепочки автоматов, чего только не наслушался... ))

Ты даже не понял о чем я. Дело не в цепочках автоматов.
Re[3]: Go язык прёт?
От: CoderMonkey  
Дата: 03.11.18 02:56
Оценка:
Здравствуйте, smeeld, Вы писали:

S>сейчас начинает захватывать ниши других ЯП, пока выпихивает python, C++


По данным SO, за 9 лет он вырос с 0% до примерно 0.3%
Re[4]: Go язык прёт?
От: smeeld  
Дата: 03.11.18 10:49
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>По данным SO, за 9 лет он вырос с 0% до примерно 0.3%


Фтопку эти рейтинги и прочее всё такое. Говорил то, что сам наблюдаю вокруг.
Re[24]: Go язык прёт?
От: vdimas Россия  
Дата: 03.11.18 14:15
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Помнится в году эдак 2005-м, когда я пытался рассуждать на тему, что вложенные yield порождают цепочки автоматов, чего только не наслушался... ))

НС>Ты даже не понял о чем я. Дело не в цепочках автоматов.

Речь не о тебе, а о решарпере.
Re[26]: Go язык прёт?
От: vdimas Россия  
Дата: 03.11.18 14:32
Оценка:
Здравствуйте, ·, Вы писали:

·>А вот так "магически" и возвращается. Что, мол, место объявления корутины и место где елдится — связываются как-то неявно, несмотря на то что между ними есть промежуточные "простые" функции. Что-то вроде тредов по сути.


Не "что-то вроде тредов", а полноценные треды и есть.
Это кооперативная многозадачность, типа как в Windows 3.x на операциях ввода-вывода или при ожидании примитивов синхронизации.
Всей разницы, что переключение потоков выполняет не ос, а библиотека, т.е. такое переключение происходит без смены контекста исполнения, что на современных процах имеет нехилый профит.

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


·>Как я понял именно в них. Т.е. одна и та же функция может работать в разных условиях по-разному — асинхронно или нет.


Все ф-ии в своих логических потоках работают синхронно.
Асинхронным получается алгоритм с т.з. потоков уровня ОС.
Т.е. асинхронность возникает при отображении логических потоков на потоки ОС.
Но потоки ОС — они точно так же являются логическими по отношению к физически потокам и точно так же синхронные взаимодействующие алгоритмы в потоках ОС с т.з. физических потоков порождают асинхронный код.

В общем, если таким отображением не заморачиваться, не искать "священный грааль" правильных терминологий, то просто считай, что у тебя куча реальных потоков.
Просто переключение м/у ними чуть дешевле и предсказуемее, чем в случае потоков ОС.
Отредактировано 03.11.2018 20:29 vdimas . Предыдущая версия . Еще …
Отредактировано 03.11.2018 20:28 vdimas . Предыдущая версия .
Re[10]: Go язык прёт?
От: vdimas Россия  
Дата: 04.11.18 06:39
Оценка:
Здравствуйте, AlexRK, Вы писали:

НС>>Что, пуканчик зачесался?

ARK>Что, твоя «умная теория» дала трещину?

А критерии "сложности" какие?
Бывает сложность алгоритмическая, бывает информационная, бывает наведённая из-за разности моделей вычисления железа и ЯП.
Бывают еще DSL, где сложность языка общего назначения для окученной этим DSL области резко выше и т.д.

C# хорошо справляется с алгоритмической сложностью и с информационной.
С++ чуть лучше справляется с алгоритмической сложностью, но чудовищно хуже с информационной, т.к. привносит много собственной информационной сложности.
Зато из-за полного совпадения выч. модели С++ и современного мейнстримового железа на С++ проще решать "около-железные" задачи, которые на C# решать заметно сложнее.

Если же взять ассоциативные выч. системы, то на них С++ будет смотреться жалко, там будут рулить функциональные языки, т.к. их модель вычислений будет ближе к железу.

Примеров можно привести еще мильярд, но все они будут о том, что рассуждать о некоей абстрактной сложности бесполезно, ввиду многогранности этого понятия.
Re[25]: Go язык прёт?
От: Ночной Смотрящий Россия  
Дата: 05.11.18 12:14
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>>>Помнится в году эдак 2005-м, когда я пытался рассуждать на тему, что вложенные yield порождают цепочки автоматов, чего только не наслушался... ))

НС>>Ты даже не понял о чем я. Дело не в цепочках автоматов.
V>Речь не о тебе, а о решарпере.

В отличие от тебя я знаю в чем именно бла проблема.
Re[14]: Go язык прёт?
От: reversecode google
Дата: 12.11.18 17:42
Оценка:
C>Да. Так как язык имеет точный GC, то горутины начинаются с небольшого размера. При необходимости стек копируется в больший блок, при этом все указатели автоматически корректируются.

C>В С++ такое просто невозможно.


каким образом гоу корректирует эти указатели, есть ссылка на гоу код компилера/библиотеки этого места ?
и почему тоже самое нельзя сделать с теми же стекфул корутинами С++ ?
Re[15]: Go язык прёт?
От: Cyberax Марс  
Дата: 12.11.18 22:23
Оценка: 2 (1)
Здравствуйте, reversecode, Вы писали:

C>>Да. Так как язык имеет точный GC, то горутины начинаются с небольшого размера. При необходимости стек копируется в больший блок, при этом все указатели автоматически корректируются.

C>>В С++ такое просто невозможно.
R>каким образом гоу корректирует эти указатели, есть ссылка на гоу код компилера/библиотеки этого места ?
В Go объекты в стеке могут указывать только на объекты в стеке. Соответственно, нет никаких проблем найти все указатели: https://golang.org/src/runtime/stack.go — строка 1142.

R>и почему тоже самое нельзя сделать с теми же стекфул корутинами С++ ?

1) Нельзя гарантированно найти все указатели
2) Объекты в куче могут указывать на объекты в стеке
Sapienti sat!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.