LINUX.ORG.RU

Царю про 10к в надежде перевести дискуссию в конструктив

 ,


11

10

Я не думаю, что кого-то можно впечатлить принципиальной возможностью запустить 10к потоков для обслуживания клиентов. Когда говорят про встанет раком, имеют в виду неоправданную потерю производительности.

Если ты готов померять реальный перформанс, пиши, я налабаю на еполле аналоги твоих тестовых серверов, чтобы не ты один тратил своё время. Меня например больше в всего в контексте этого спора интересует, как поведёт себя сервер с 10к потоков например на 4 ядрах против еполльного на одном таком же ядре, в вариантах без локов и с.

Результаты исследования можешь запостить на ЛОРе и восстановить честь среди пятизвездочных 😝

Начало дискуссии где-то рядом в удаленных по инициативе какого-то наркомана.

PS скорее всего я отвечу не раньше ночи или следующего утра.

★★★★★
Ответ на: комментарий от eao197

Я говорил про методологию ведения дискуссии многими ЛОРовцами, а не про качество царской методологии тестирования. Методологию тестирования вообще недопустимо обсуждать без оговаривания кучи условий, что бы сделать понятным, что конкретно мы меряем.

Вот остановись на минуту и посмотри, что ты делаешь. Я вел разговор о методе ведения дискуссий, ты съезжаешь на «ну его же микробенчмарк - говно». Говно его бенчмарк или нет, не имеет никакого отношения к тому, что я сказал. Посмотри, ты опять это делаешь, ты съезжаешь с темы которую я развивал из-за своего неприязненного отношения к царю. Не надо так. Это называется biased thinking.

Я не царь, у меня не стоит цели улучшать климат на отдельно взятом «техническом» ресурсе, поэтому когда я увижу, что продолжать пытаться донести мысль бесполезно - я просто прекращу комментировать. Будут люди думать, что я слился или нет - мне как-то до лампочки =).

DiKeert ★★
()
Ответ на: комментарий от i-rinat

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

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

DiKeert ★★
()
Ответ на: комментарий от eao197

Царь. Важно. По поводу "обрабки данных внутри треда".

Идём далее, убогие потуги про «обработка внутри тредов повлияет на что-то». Не повиляют.

Причина проста. Любая, дополнительная, работа внутри треда( которая там вообще быть не обязана - об этом я писал выше. В данном ситуации балабол уже слился, но я просто позволяю ему балаболить) ни на что не повлияет. И причина проста.

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

Таким образом неважно сколько будет исполнятся тред до его блокировки - оверхед это не увеличит. Оверхед берётся только в момент переключения тасков, а их(переключения) увеличение работы не добавляет.

anonymous
()
Ответ на: комментарий от eao197

Царь. Важно. По поводу балабольства.

Меня, как и, полагаю, ТС-а интересует стоимость этого подхода.

Вот это настолько фееричное заявление.

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

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

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

Проблемы колхозников и прочих «давно непрограммистов» меня не волнуют. Здесь обсуждается конкретная тема, а то, что ты, как и твой собрат в неё не осилите, как и в язык на котором пишите - это к делу не относится.

И ваши отмазки на тему, что «мы не осилили потому, что в продакшене это не нужно», либо «мой сосед вася не осилил и я не осилил» - не работают. Тебе никто не заставляет использовать что-то - тебя просят осилит.

А если ты не осилил - твои отговорки никого не волнуют. Сиди в своём болоте и не квакай на те темы, которые выходят за рамки твоих глупых представлений о мире. Всё просто.

anonymous
()
Ответ на: комментарий от makoven

Царь.

Блокируется не соединение, а поток, не? Пиши в них до того, как он будет заблокирован, либо пиши из другого места.

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

anonymous
()
Ответ на: Царь. от anonymous

Блокировка на то и нужна, что тебе нечего делать до получения данных

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от DiKeert

Царь.

«ну его же микробенчмарк - говно».

Это убогая потуга, которая не стоит ничего. В обоснование сей потуги он кидает абстрактную и необоснованную херню вида «не коррелирует с реальностью», что есть не более чем сотрясание воздуха. Никаких свидетельств в пользу отсутствия этой корреляции он не предоставил, а значит он по умолчанию обделался.

А его отношение ко мне ясно и понятно. Разбирал я его тут: Доступно видео докладов с C++ Russia 2017 (комментарий)

Вам, объективным людям, не хочется в этом верить, но надо поверить. Это простые балаболы. Они не хотят ничего понимать, они не хотят ничего объяснять - они хотят одного - строить из себя экспертов. Объяснять им что-то бессмысленно.

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

Сейчас их защищает то, что они ретранслируют известные в широких кругах поверья. Публике они кажутся «защитниками справедливости», а тот, кто высказывает что-то отличное от общепринятых представлений - по умолчанию клеймится «идиотом».

Поэтому убеждать всех, что общепринятое представление не является истинным - не особо эффективно. Люди это будут защищать до последнего. А вот выпилить и свести на ноль авторитет все «защитников» возможно. Ведь в массе своей публика не может защитить свои представления и подобные персонажи и выступают в роли это защиты.

anonymous
()
Ответ на: комментарий от makoven

Я почему спрашиваю. Сетевых библиотек и фреймворков огромное множество. Интересно, как такое приняо делать in the wild. Не все же из них написаны на select/epoll

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 3)
Ответ на: Царь. от anonymous

И что это, простите, за use case такой, когда серверу надо только слушать? И только услышав - реагировать. Эдакий поломанный walkie-talkie поверх полноценного дуплексного канала. На ум приходит только http-server (без поддержки websockets)

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от anonymous

Эдди регистрируйтесь заново

anonymous
()
Ответ на: комментарий от DiKeert

Вот остановись на минуту и посмотри, что ты делаешь.

Отличный совет. На себя применить его почему не попробовали?

Я вел разговор о методе ведения дискуссий, ты съезжаешь на «ну его же микробенчмарк - говно».

Вообще-то это LOR и здесь все ходы записаны. Было: я задал несколько конкретных вопросов Царю о его реализации бенчмарка. Тут появляетесь вы и отвечаете мне на конкретные вопросы Царю простыней текста о том, как неправильно LOR-овцы ведут себя по отношению к этому самому Царю.

Вот не надо так.

Методы ведения дискуссии самим Царем давно известны и попытка делать это в конструктивном русле становится попыткой играть в шахматы с голубем. Вот прям свежее доказательство: Царю про 10к в надежде перевести дискуссию в конструктив (комментарий) Больной придурок выдумал, что где-то когда-то он меня уделал и что открыл глаза на это всему человечеству. Хотя если вы дадите себе труд походить по его же ссылкам, то ваше мнение может сильно отличаться от того, что говорит сам Царь.

eao197 ★★★★★
()
Ответ на: комментарий от makoven

Царь.

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

Блокировка - это блокировка операции, а не сокета. Если у тебя висит рид на сокете - тебе ничего не мешает в него писать.

При появлении сообщения от одного - должен как-то разослать это сообщение всем остальным (понятное дело, не дожидаясь когда блокировка у них спадет сама)

Сокет никак не связан с потоком, в котором он живёт. Ничего и нигде ждать не надо.

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

И когда к тебе приходят данные из любого клиента - ты вызываешь эту функцию и - всё работает.

Ну и самое главное - я не призываю тебе сувать обработку в 10050 тредов. Тема вообще не об этом.

anonymous
()
Ответ на: комментарий от DiKeert

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

Давайте вы подтвердите свои слова конкретными цитатами, в которых, по вашему мнению, Царь прав.

Ибо вот, например, что я вижу:

Идём далее, убогие потуги про «обработка внутри тредов повлияет на что-то». Не повиляют.

Причина проста. Любая, дополнительная, работа внутри треда( которая там вообще быть не обязана - об этом я писал выше. В данном ситуации балабол уже слился, но я просто позволяю ему балаболить) ни на что не повлияет. И причина проста.

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

Где здесь хоть какие-то технические аргументы? Почему кто-то должен верить в слова Царя о том, что «не повлияет»? Это утверждение прямо противоречит здравому смыслу и объективным наблюдения, а именно:

  • переключение тредов — это дорогая операция, поскольку ОС должна сохранить изрядное количество регистров текущей нити и восстановить значение регистров для другой нити;
  • когда новый тред начинает выполнять чуть больше операций, чем тупой вызов одного сискола на котором тред вновь уснет, повышается вероятность существенной перезагрузки кэша процессора. Поскольку новому треду не нужны данные в кэше от старого треда, а нужны свои, которые начинают подгружаться из RAM (или кэшей следующих уровней, если вам повезет). Чем дольше работает каждый тред и чем больше тредов у нас в наличии, тем дороже оказывается переключение тредов именно из-за подтаскивания данных каждого треда в кэш процессора. Именно поэтому нужно, чтобы тред делал хоть какую-то полезную работу, чтобы данный эффект проявился;
  • когда тред делает какую-то полезную работу, то, скорее всего, он будет аллоцировать себе память. Аллокация памяти в многопоточной программе — это дорогая операция, особенно, если указатели на какие-то объекты мигрируют между тредами (т.е. объект был создан на нити A, а освобождает его нить B). Для того, чтобы снизить влияние аллокатора памяти придется иметь дело с какими-то локальными аллокаторами, а это еще больше удорожает решение с множеством потоков.

Все это очевидно для тех, кто хоть сколько-нибудь имел дело с многопоточностью. Но тут появляется Царь, который просто говорит, что «это ни на что не повлияет». Аргументируя свою точку зрения терминами «балаболка», «лсный» и доказательствами типа «да я тебя уже давно с говном смешал».

О какой методологии дискуссии с Царем вы здесь пытаетесь рассуждать, справедливый вы наш? Может вам еще 20 не исполнилось.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Т.е. это:

Да, у меня низкая квалификация, и я вообще уже давно не программист.

В контексте:

одно от царя, которое требует использования либо -std=c++1z, либо расширений GCC, второе мое, низкоквалифицированное, работающее в рамках C++14.

Тут враньё - задачу он не решил. Просто его убогий хелворд( в котором он натыкал форфан везде констекспров) один из компилятор более-менее оптимизировал. Это не решение. Он там 10раз игнорировал этот факт сливаясь.

Где неспособность решить задачу была оправдана низкой квалификацией и тем, что пациент уже «давно не программист»?

А так же это: Доступно видео докладов с C++ Russia 2017 (комментарий) и прочие перлы.

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

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

anonymous
()
Ответ на: Царь. Важно. По поводу тредов. от anonymous

В чём тогда смысл c10k? Если всё умело?

Царь, то совсем придурок или старательно притворяешься?

c10k problem — это уже лет 20 как задача на эффективность обслуживания 10k подключений, а не на возможность этого самого обслуживания.

Так что никого здесь не интересует то, что ты можешь создать 10k нитей. Ибо 10k нитей в том же офтопике можно было создавать со времен первых Win NT, ограничение тогда было лишь в объеме RAM.

Людей интересует, насколько эффективно твое решение с 10k нитями.

eao197 ★★★★★
()
Ответ на: Царь. от anonymous

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

Понял. Вполне разумно. Спасибо. И, впринципе, выходит даже несколько проще чем машина состояний и select

Но не получается ли так, что в случае плотного двустороннего общения между сервером и клиентом (например, сетевые игры), проблема 10к соединений реашется используя 20к потоков? Где один поток читает, а второй пишет

makoven ★★★★★
()
Ответ на: комментарий от makoven

Не очень хочу вмешиватся, но всеже. Можно я вам примерчик из жизни подкину, для размышления?! Вот имеем мы устройство отдающие некие данные (собственное состояние например или результат работы - в человеко-читаемом виде ) по uart. Вы цепляетесь двумя клиентами и читаете данные. Как Вы думаете информации полученная клиентами будет одинаковая?

Silerus ★★★★
()
Последнее исправление: Silerus (всего исправлений: 1)
Ответ на: комментарий от anonymous

Это не решение. Он там 10раз игнорировал этот факт сливаясь.

Царь, ты пользуешься тем, что эту переписку давно снесли в мусор. А ведь там сперва обговаривалось, как проверить, что строка была получена в compile-time. Договоренность была такая: если содержимое строки можно проверить через static_assert, то значит конкатенация строки выпонена в compile-time.

Решение, удовлетворяющее этому требованию, и было показано. В рамках стандартного C++14.

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

Вот и аргументы в стиле Царя. Давай, что-то ты мало вывалил, неужели говно закончилось?

eao197 ★★★★★
()
Ответ на: комментарий от Silerus

..по uart.. Вы цепляетесь двумя клиентами и читаете данные. Как Вы думаете информации полученная клиентами будет одинаковая?

Подозреваю скажет, что /dev/ttyS0 занят другим процессом. Если вторым клиентом подключиться

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 3)
Ответ на: комментарий от eao197

Почему кто-то должен верить в слова Царя о том, что «не повлияет»? Это утверждение прямо противоречит здравому смыслу и объективным наблюдения, а именно:

Это было ясно определено, балаболка. Было определено а) переключение контекста(таска) может быть инициировано только тиком шедуллера - опровержение ты выкатил? Нет. Что-то ещё, что может инициировать это переключение у тебя есть? Нет.

Так же было определено то, что тики шедуллера являются крайне редкими. У тебя опровержение есть? Нету. В лужу.

переключение тредов — это дорогая операция, поскольку ОС должна сохранить изрядное количество регистров текущей нити и восстановить значение регистров для другой нити;

Херня номер один. Переключение контекста не является дорогой операцией. То, что ты пытаешься тут ретранслировать - то совершенно другое, а именно переключение контекста vm. Между тредами этого не происходит.

Манипуляция номер раз. Перед тем как кукарекать о каком-то переключении балабол должен связать «увеличение работы» с переключением. Пока балабол этого не сделал - все потуги в адрес переключений несостоятельны.

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

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

Опять какой-то бред «вероятность, хернороятность» - это мусор без единого основания.

Поскольку новому треду не нужны данные в кэше от старого треда, а нужны свои, которые начинают подгружаться из RAM (или кэшей следующих уровней, если вам повезет)

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

Треды будут выполняться последовательно. И балабол либо выкатывает основания для того, что они будут исполнятся как-то по другому, либо сливается.

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

Полная херня. В очередной раз балабол не определил того, что с какого вдруг бадуна взялось какое-то переключение тредов. Что его инициирует? Шизофрения?

когда тред делает какую-то полезную работу, то, скорее всего, он будет аллоцировать себе память. Аллокация памяти в многопоточной программе — это дорогая операция, особенно, если указатели на какие-то объекты мигрируют между тредами (т.е. объект был создан на нити A, а освобождает его нить B). Для того, чтобы снизить влияние аллокатора памяти придется иметь дело с какими-то локальными аллокаторами, а это еще больше удорожает решение с множеством потоков.

Опять какая-то херня убогая. В любом случае выполнение полезной работы будет не однопоточной. Такой она является в том же нгинксе. Поэтому ни о какой «однопоточной» логике в рамках коммуникации между обработчиками и тем же глобальным контекстом быть не может.

Ну и далее балабол пытается ретранслировать очередную херню, которое где-то услышал. Хип является thread_local везде по умолчанию. Удаление «не своей памяти» никак не зависит от кол-ва нитей.

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

Цена же самой блокировки и прочее никак не зависит от кол-ва тредов.

Основная проблема балаболки в том, что он ретранслирует то, не понимая даже что. Все эти проблемы растут по мере увеличения кол-ва РАБОТАЮЩИХ ПОТОКОВ.

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

anonymous
()
Ответ на: комментарий от eao197

Царь.

c10k problem — это уже лет 20 как задача на эффективность обслуживания 10k подключений, а не на возможность этого самого обслуживания.

Доказательства в студию.

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

anonymous
()
Ответ на: комментарий от anonymous

переключение контекста(таска) может быть инициировано только тиком шедуллера

То есть при частоте тиков в 100Hz сервер может обработать максимум 100 подключений в секунду по твоей логике?
Даже если опустить тот факт, что это полный бред и в современном ядре существуют динтики, которые инициируются по нужде, а не по таймеру, то заставляет задуматься о эффективности твоего решения.

Максимальное разрешение таймера — 1000Hz. Тысяча клиентов в секунду. Очень эффективно, лол.

mersinvald ★★★★★
()
Ответ на: комментарий от makoven

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

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

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

Silerus ★★★★
()
Ответ на: комментарий от anonymous

Треды будут выполняться последовательно.

И как это влияет простите на подгрузку данных из памяти?

У нас в ядре уже появился идеальный планировщик с идеальной стратегией кэширования страниц, который знает когда и сколько будет выполняться каждый поток и какие именно страницы он запросит?

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от makoven

Но не получается ли так, что в случае плотного двустороннего общения между сервером и клиентом (например, сетевые игры), проблема 10к соединений реашется используя 20к потоков? Где один поток читает, а второй пишет

Слишком абстрактно. Этому ничего не мешает.

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

Если вопрос в том - за что я агитирую. Я агитирую за отправку сокетов в помойку.

anonymous
()
Ответ на: комментарий от Silerus

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

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 2)
Ответ на: комментарий от mersinvald

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

Silerus ★★★★
()
Ответ на: комментарий от mersinvald

О боже, что ты несёшь, балабол.

То есть при частоте тиков в 100Hz сервер может обработать максимум 100 подключений в секунду по твоей логике?

Моя логика чётко и ясно написана. Переключения происходят на блокировках, а переключения по тикам - это то, что инициирует переключения акромя блокировок.

Добавляя работу между блокировками - это никак не виляет на кол-во переключений под блокировками. А тики шедуллера - это единственное, что может прервать тред.

Очередной малообразованный и невменяемый балабол.

anonymous
()
Ответ на: комментарий от anonymous

Я понял за что ты агитируешь и в эту тему не лезу) Просто заметил, что тут собрались достойные господа и решил невзначай попытать их метафизическими вопросами)

А в Го, интересно как оно синтаксически устроено? Одна горутина заблокирована чтением из канала, а вторая в него пишет?

makoven ★★★★★
()
Ответ на: комментарий от mersinvald

И как это влияет простите на подгрузку данных из памяти?

Почему вы все такие тупые? Ты мне объясни?

Каким образом ты будешь обрабатывать соединения в одном потоке? Правильно - последовательно. Значит, при последовательном выполнении тредов результат эквивалентен последовательному выполнению обработчиков.

У нас в ядре уже появился идеальный планировщик с идеальной стратегией кэширования страниц, который знает когда и сколько будет выполняться каждый поток и какие именно страницы он запросит?

Скудоумие и шизофрения. Что я могу на это сказать.

Зачем вы, невмеянемые домохозяйки, лезете в те темы, которые находятся за пределами вашего понимания? Ты перепутал разделы.

anonymous
()
Ответ на: комментарий от makoven

А в Го, интересно как оно синтаксически устроено? Одна горутина заблокирована чтением из канала, а вторая в него пишет?

Понятия не имею.

anonymous
()
Ответ на: комментарий от anonymous

Не знаешь что ответить @ Обосри собеседника

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

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

Я тебе не только обосрал, вернее я тебе не обосрал а написал то, что есть на самом деле.

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

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

anonymous
()
Ответ на: Царь. от anonymous

Доказательства в студию.

Доказательство чего?

Если мы говорим о c10k, которая имеет отношение только к сокетам и их обработке( т.е. чтении и записи в них), то каких хреном ты пытаешься приплести сюда какую-то обработку данных? Ответишь?

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

А как-же порнхаб)

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от eao197

Царь, ты пользуешься тем, что эту переписку давно снесли в мусор.

Кидай цитатки оттуда - вперёд. Выкатывай своё решение. К удалённым у тебя доступ, в отличии от меня, есть.

А ведь там сперва обговаривалось, как проверить, что строка была получена в compile-time.

Неверно, опять балаболка пытается ставить какие-то левые условия. Задача стояла чётко и ясно - «С++ не может в компилтайм конкат», да и вообще в компилтайм строки.

Ты выкатил херню, которая нихрена не компилтайм, а компилтайм в одном случае - в котором тебе просто повезло. Поэтому я и выкатил то, что на самом деле является компилтаймом.

anonymous
()
Ответ на: комментарий от anonymous

DiKeert, поскольку вы начали играть адвоката Царя, то могли бы вы вот из этого потока сознания выделить хоть какие-то технические аргументы, вокруг которых можно дискутировать? Ибо у меня это не получается.

Особенно прекрасно вот это:

Херня номер один. Переключение контекста не является дорогой операцией. То, что ты пытаешься тут ретранслировать - то совершенно другое, а именно переключение контекста vm. Между тредами этого не происходит.

Что за vm, откуда vm, каким боком здесь какая-то vm? хз...

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Кидай цитатки оттуда - вперёд.

Да пожалуйста. Вот с чего все началось:

-----

> Уже давно могут, с тех пор как variadic templates появились.

Нет, нельзя. Нельзя во время компиляции выполнить конкатенацию нескольких литералов в один с помощью «variadic templates» и утверждать с помощью static_assert о длине получившегося литерала. Не можно скомпилировать что-то вроде:

int main(int argc, char *argv[])
{
  const char domain[] = "linux.org.ru";
  auto dynamic = dynamic_domain_name_at_compile_time("linux", "org", "ru");
  static_assert(sizeof(dynamic) == sizeof(domain), "oops");

  return 0;
}

Теперь попробуй докажи обратное. Но ты не сможешь.

----- Ну и следом: -----

Т.е. если ты хочешь доказать то, что в C++ можно генерировать строчки во время компиляции, напиши, пожалуйста dynamic_domain_name_at_compile_time() такую, что результат конкатенации переданных ей аргументов можно оценить во время компиляции с помощью static_assert.

-----

На что и последовали решения. Подробности остались, например, здесь.

Ну а вот два твоих решения: https://godbolt.org/g/HcDQLD и https://godbolt.org/g/tnDvAJ

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Доказательство чего?

Того, что ты болтал про c10k. Это же элементарно.

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

Эти глупые потуги глупых балаболов. Чтение и запись - есть основные и единственные операции над сокетами.

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

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

Тебе уже сказали зачем тут нужны треды. И почему к обработке данных они отношения не имеют. Обработку ты можешь пускать на скольки угодно тредах - пожалуйста.

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

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

Мне нахрен не упало разоблачать вас, либо что-то ещё. Мне насрать. Просто нехрен при мне и в мой адрес болтать.

anonymous
()
Ответ на: комментарий от anonymous

Чтение и запись - есть основные и единственные операции над сокетами.

Еще раз, для полных дебилов: чтение и запись не пойми чего никому не всралось. Вообще. Только когда к чтению и записи добавляется какая-то осмысленная обработка, только тогда проблема 10k приобретает смысл.

eao197 ★★★★★
()
Ответ на: комментарий от i-rinat

Занялся бы чем-нибудь полезным, что ли.

Так каникулы же)

itn ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.