Поддерживаю вашего оппонента. Мне тоже показалось, что клиент берёт на себя слишком много. Сервер — это полное состояние бизнес-логики, а клиент — лишь её отображение. Клиент «нажимает кнопки» — отправляет заявки на действия, сервер проверяет возможно ли выполнение такого действия в текущем состоянии, и если точно такой же заказ, пусть даже и как часть мультизаказа, есть, то отвергает заявку и даже не шлёт клиенту, а просто помещает в список отвергнутых заявок клиента, который клиент, если хочет может запросить, т.к. он только отображатор.
Спасибо. Нашёл ещё github.com/facebook/folly/tree/master/folly/fibers.
Я темой корутин интересовался давно — в 2008-м писал eDonkey-клиента на IOCP (правда там не корутины, а callback hell, но вобщем понятно), в 2013 написал свой фреймворк поверх бустовых корутин, включавший собственный корутиновый http-клиент. Потом забросил, а недавно обнаружил boost::fibers. Хочется разобраться во всём современном зоопарке, поэтому и интересно найти максимум библиотек на эту тему.
Отличная статья!
Я тоже эксперементирую с использованием корутин, но уже встроенных в boost::asio stackfull-корутин. Кстати, там у меня получилось определить свой контекст, который не испльзует strand-ы, а только напрямую io_service. Получается весьма шустро, да — по прикидкам около 5 гигабит в секунду на одно ядро (пока негде проверить). Только я стараюсь делать ещё более эффективно, в частности избегаю аллокаций.
В контексте этого, хотелось бы узнать более подробные цифры — какой входящий/исходящий трафик обслуживал Ваш сервер на этих 70-90% ядра?
А ещё в том коде из тестов для boost::asio есть лишние аллокации памяти — при использовании толстых boost::bind и shared-указателей.
При желании, можно было бы переделать это пример, чтобы показать, что asio не так плох. Но вообще итак понятно, что boost::asio лучший вариант по переносимости, качеству абстракций и сервисов из коробки. Тем более, что тесты, думаю, показали вполне удовлетворительный по скорости результат работы даже неоптимального кода для asio.
Супер! По описанию, клиент сделан умно и очень верно. Код тоже интересно было бы увидеть. У меня есть немного вопросов по реализации, если можно:
1. Так ли нужны strand-ы? У меня стойкое ощущение, что можно было бы обойтись одним потоком, обслуживающим boost::asio::io_service — код, думаю, проще без strand-ов. Нагрузка на процессор там минимальная, OpenSSL хеши считает очень быстро.
2. boost::asio подразумевает массированное использование callback-ов. Боролись ли вы с этим, не было ли попытки использовать корутины, чтобы асинхронный код выглядел последовательным, а не разорванным на несколько callback-ов?
3. Сколько человековремени ушло на разработку клиента?
Спасибо.
А по мне — хорошо написано. Опечатки можно вытерпеть, в наше время связный интересный текст уже ценность. Из всего прочитанного вывод и совет студентам и школьникам. Чтобы не путешествовать по всем этим кругам адам, изучайте программирование как оно есть и участвуйте в олимпиадах. Тогда сразу и всегда на работе будете заниматься программированием (Yandex, Google...).
В вашем типичном для отечественного программиста случае менеджер — тот, кто не придерживается кодекса. Конечно жертвовать не надо, но не потому что никто не умрёт, а потому что у этого конкретного менеджера нет чести.
Народ, расскажите о своём опыте — доводилось ли вам работать в таких командах. И где они были. Я в России работал в очень многих местах и заметил, что морально чистые отношения сохраняются очень недолго, и в маленьких командах. Такие команды с необходимостью успешны. Это самые счастливые моменты моей работы. Но рано или поздно появляется проныра с широкими локтями, подлиза под начальника, эффективные менеджеры… И вскоре никакой чести не остаётся. Интересно — это только мне так не везёт, или по-другому у нас не бывает?
Ну ок. Я не настаиваю, просто забываю везде писать, что имхо. Я противоречий своей модели работы ума просто не встречал. Она ещё немного сложнее чем просто наличие подсознания. Если и пытаюсь что-то навязать, то только из побуждений помочь :).
Вообще, сложно представить что-то что априори не находится в подсознании. Я вот как-то читал про какого-то гения-инженера (может быть Тесла или Эдисон) — он просто очень пристально рассматривал окружающий мир в моменты простоя — кладку дома, узоры на коре дерева и прочие природные и рукотворные детали, которые могли откладываться в подсознании как какие-то эскизы схем инженерных решений, а потом подсознание могло их вытолкнуть. При этом можно считать, что такого решения не могло быть в подсознании потому что оно вообще новое в конструировании.
А в наше время говорить о том, что подсознанию недостаточно пищи вообще не приходится.
Замечу, что мы никак не определяли подсознание, кроме тех самых признаков как оно работает. Тут надо быть осторожнее, а то сразу найдутся опровергатели его наличия. Не будем указывать место где оно находится и материал, из которого оно состоит :).
Мы просто можем ввести в нашу модель мира такой условный объект и описать его свойства. Практика и изучение умных/гениальных людей будет подтверждать его наличие, что яркий ум работает именно так.
Вобщем, не соглашаться в этом смысле с существованием подсознания означает не соглашаться с тем, что ум работает именно так.
Очень интересная статья, спасибо.
Я молодости тоже достаточно глубоко погружался в вопросы работы своего ума, в последние годы только пользуюсь тем, что тогда наработал.
Да, 7 — объектов — это примерный предел количества абстракций, которые можно держать в голове. Если это понимать и воплощать в практике, это очень сильно повлияет на код (ООП-шники — читайте Буча). Отсюда, наверное, так любимый и мной минимализм. Кстати, у меня на рабочем месте меньше 7 вещей, нет сумки и когда я передвигаюсь по городу, в карманах менее 7 объектов. Это как-то разгружает мышление. Видимо, ум иногда на мгновение переключается в режим контроля этого аспекта (а все ли вещи на месте, ничего не забыл взять с собой) — и легко справляется с задачей, не впадая в стресс. В программном коде это сплошь и рядом.
Я, кстати, верю в подсознание, не согласен с тем, что подъём продуктивности — это просто временное расширение кеша. Период подъёма продуктивности — это период получения идей из подсознания, которые оно уже переварило и вытолкнуло к своей поверхности. Период тупления и формальной осады сознанием задачи, который предшествует периоду сверхпродуктивности — это рациональный анализ и загрузка задачи в иррациональное подсознание. Только подсознание может генерировать идеи, сознательно это делать невозможно (привет ТРИЗу) — алгоритмы получения идей слабы и генерируют только копии, некоторый класс идей, заложенный алгоритмом.
Много лет назад я прочитал технику передачи сложных вопросов на обработку подсознанию, кратко: сначала осада, потом медитация, ещё раз всё обдумываем, представляем подсознание (например — будто мы в тёмной комнате, в которой есть дверь, за которой свет и огонь — там мощная машина, которая многим занята и может поработать с нашей задачей), мы отдаём туда весь груз нашей проблемы и мысленно просим решить), спим. С утра или днём — сверхпродуктивность. После анализа идей цикл можно повторить.
А гениальность — это умение работать с подсознанием, в том числе умение грамотно загрузить информацией из сознания (гениальные люди могли непрерывно обдумывать, или специфично рассматривать и т.п.), а также умение применить результаты работы (гении записывают, подвисают во время прихода идей и убегают работать и т.п.).
Ещё много можно писать, не люблю. :) Очень рад видеть здесь людей, находящихся на этой волне.
Как много настоящих мыслей! Спасибо, брат, многое систематизировал. Я проработал в нескольких крупных известных компаниях. И понял, что только «написание ядер», причём с достойной целью, будет давать смысл моему существованию. Кстати, когда меня эксплуатируют, меня это бесит, что со мной не так?
Да, именно жизнь без смысла, или со смыслом, полученным самообманом, становится уродливой, больной. Что для отдельного человека, что для компании.
А комментарии, думаю, будут с другой стороны. Штампованные такие, верные. Ну это предсказуемо. Как же объяснить себе отсутствие своей жизни? Но от меня тебе большое спасибо.
> Но здесь вышла некоторая заминка связанная с нежеланием gcc принимать на вход выход команды ls через конвейер.
xargs? В крайнем случае xargs -d"\n":
find… | xargs -d"\n" gcc -c -x c++ -I
Да, тоже пришлось качнуть исходники и посмотреть QSortFilterProxyModel. Сделано достаточно наивно — сортируется синхронно прямо внутри QSortFilterProxyModel::sort.
Меня как раз интересуют Qt-шные модели для больших объёмов данных (несколько миллионов). Тут однозначно будет подвисание. Для сортировки дополнительным потоком, да, придётся писать свою AsyncSortProxyModel.
Думаю, она вполне может работать так: считывать данные из нижлежащей модели последовательно блоками, сортировать считанный блок, затем слиянием добавлять элементы из нового отсортированного блока к множеству уже отсорированных элементов и нотифицировать GUI. Для пользователя это будет выглядеть так: после того как он инициировал сортировку, элементов в таблице становится мало и их количество постоянно растёт не замораживая GUI. Он сможет промотать скролл к концу таблицы, после этого появятся новые элементы и скролл отодвинется от конца.
GroupProxy будет требовать сортировки? Я не изучал этот вопрос, но как в Qt решается вопрос сортировки, ведь время на неё существенно зависит от размера исходной модели? Сортировать GUI-потоком точно нельзя.
Что такое O(0)? Наверное, вы имели ввиду O(1) — константа по отношению к количеству элементов в исходной модели.
Думаю, нужно рассмотреть три параметра: n — количество элементов в исходной модели, k — количество проксей на пути к вью, l — количество элементов, отображаемых во вью. Количество действий для отображение при правильно спроектированных прокси должно вести себя как O(k*l), т.е не расти с ростом n. Т.к l — число маленькое (обычно не более 30), то с каждой новой прокси будет добавляться незначительное для задач GUI количество операций.
Я темой корутин интересовался давно — в 2008-м писал eDonkey-клиента на IOCP (правда там не корутины, а callback hell, но вобщем понятно), в 2013 написал свой фреймворк поверх бустовых корутин, включавший собственный корутиновый http-клиент. Потом забросил, а недавно обнаружил boost::fibers. Хочется разобраться во всём современном зоопарке, поэтому и интересно найти максимум библиотек на эту тему.
Я тоже эксперементирую с использованием корутин, но уже встроенных в boost::asio stackfull-корутин. Кстати, там у меня получилось определить свой контекст, который не испльзует strand-ы, а только напрямую io_service. Получается весьма шустро, да — по прикидкам около 5 гигабит в секунду на одно ядро (пока негде проверить). Только я стараюсь делать ещё более эффективно, в частности избегаю аллокаций.
В контексте этого, хотелось бы узнать более подробные цифры — какой входящий/исходящий трафик обслуживал Ваш сервер на этих 70-90% ядра?
При желании, можно было бы переделать это пример, чтобы показать, что asio не так плох. Но вообще итак понятно, что boost::asio лучший вариант по переносимости, качеству абстракций и сервисов из коробки. Тем более, что тесты, думаю, показали вполне удовлетворительный по скорости результат работы даже неоптимального кода для asio.
1. Так ли нужны strand-ы? У меня стойкое ощущение, что можно было бы обойтись одним потоком, обслуживающим boost::asio::io_service — код, думаю, проще без strand-ов. Нагрузка на процессор там минимальная, OpenSSL хеши считает очень быстро.
2. boost::asio подразумевает массированное использование callback-ов. Боролись ли вы с этим, не было ли попытки использовать корутины, чтобы асинхронный код выглядел последовательным, а не разорванным на несколько callback-ов?
3. Сколько человековремени ушло на разработку клиента?
Спасибо.
Вообще, сложно представить что-то что априори не находится в подсознании. Я вот как-то читал про какого-то гения-инженера (может быть Тесла или Эдисон) — он просто очень пристально рассматривал окружающий мир в моменты простоя — кладку дома, узоры на коре дерева и прочие природные и рукотворные детали, которые могли откладываться в подсознании как какие-то эскизы схем инженерных решений, а потом подсознание могло их вытолкнуть. При этом можно считать, что такого решения не могло быть в подсознании потому что оно вообще новое в конструировании.
А в наше время говорить о том, что подсознанию недостаточно пищи вообще не приходится.
Мы просто можем ввести в нашу модель мира такой условный объект и описать его свойства. Практика и изучение умных/гениальных людей будет подтверждать его наличие, что яркий ум работает именно так.
Вобщем, не соглашаться в этом смысле с существованием подсознания означает не соглашаться с тем, что ум работает именно так.
Я молодости тоже достаточно глубоко погружался в вопросы работы своего ума, в последние годы только пользуюсь тем, что тогда наработал.
Да, 7 — объектов — это примерный предел количества абстракций, которые можно держать в голове. Если это понимать и воплощать в практике, это очень сильно повлияет на код (ООП-шники — читайте Буча). Отсюда, наверное, так любимый и мной минимализм. Кстати, у меня на рабочем месте меньше 7 вещей, нет сумки и когда я передвигаюсь по городу, в карманах менее 7 объектов. Это как-то разгружает мышление. Видимо, ум иногда на мгновение переключается в режим контроля этого аспекта (а все ли вещи на месте, ничего не забыл взять с собой) — и легко справляется с задачей, не впадая в стресс. В программном коде это сплошь и рядом.
Я, кстати, верю в подсознание, не согласен с тем, что подъём продуктивности — это просто временное расширение кеша. Период подъёма продуктивности — это период получения идей из подсознания, которые оно уже переварило и вытолкнуло к своей поверхности. Период тупления и формальной осады сознанием задачи, который предшествует периоду сверхпродуктивности — это рациональный анализ и загрузка задачи в иррациональное подсознание. Только подсознание может генерировать идеи, сознательно это делать невозможно (привет ТРИЗу) — алгоритмы получения идей слабы и генерируют только копии, некоторый класс идей, заложенный алгоритмом.
Много лет назад я прочитал технику передачи сложных вопросов на обработку подсознанию, кратко: сначала осада, потом медитация, ещё раз всё обдумываем, представляем подсознание (например — будто мы в тёмной комнате, в которой есть дверь, за которой свет и огонь — там мощная машина, которая многим занята и может поработать с нашей задачей), мы отдаём туда весь груз нашей проблемы и мысленно просим решить), спим. С утра или днём — сверхпродуктивность. После анализа идей цикл можно повторить.
А гениальность — это умение работать с подсознанием, в том числе умение грамотно загрузить информацией из сознания (гениальные люди могли непрерывно обдумывать, или специфично рассматривать и т.п.), а также умение применить результаты работы (гении записывают, подвисают во время прихода идей и убегают работать и т.п.).
Ещё много можно писать, не люблю. :) Очень рад видеть здесь людей, находящихся на этой волне.
Да, именно жизнь без смысла, или со смыслом, полученным самообманом, становится уродливой, больной. Что для отдельного человека, что для компании.
А комментарии, думаю, будут с другой стороны. Штампованные такие, верные. Ну это предсказуемо. Как же объяснить себе отсутствие своей жизни? Но от меня тебе большое спасибо.
xargs? В крайнем случае xargs -d"\n":
find… | xargs -d"\n" gcc -c -x c++ -I
Меня как раз интересуют Qt-шные модели для больших объёмов данных (несколько миллионов). Тут однозначно будет подвисание. Для сортировки дополнительным потоком, да, придётся писать свою AsyncSortProxyModel.
Думаю, она вполне может работать так: считывать данные из нижлежащей модели последовательно блоками, сортировать считанный блок, затем слиянием добавлять элементы из нового отсортированного блока к множеству уже отсорированных элементов и нотифицировать GUI. Для пользователя это будет выглядеть так: после того как он инициировал сортировку, элементов в таблице становится мало и их количество постоянно растёт не замораживая GUI. Он сможет промотать скролл к концу таблицы, после этого появятся новые элементы и скролл отодвинется от конца.
Думаю, нужно рассмотреть три параметра: n — количество элементов в исходной модели, k — количество проксей на пути к вью, l — количество элементов, отображаемых во вью. Количество действий для отображение при правильно спроектированных прокси должно вести себя как O(k*l), т.е не расти с ростом n. Т.к l — число маленькое (обычно не более 30), то с каждой новой прокси будет добавляться незначительное для задач GUI количество операций.