LINUX.ORG.RU

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

 ,


11

10

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

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

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

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

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

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

только я не понимаю, нахрена тебе моя экспонента для оптимизации кэшей

Что ты несёшь? Вот ответь мне. Всё же похоже понимаю твою проблему и в очередной раз прошу ответить в личку.

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

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

например ту же задачу теплопроводности

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

Если ты согласен - я могу тебе предложить 2 вида условия. Я тебе о них написал. Согласен - вперёд.

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

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

Почему с вами так сложно? Я убеждаю вас для того, чтобы дать вам же возможность меня в будущем победить. Все условия - пожалуйста. Нет. Зачем.

Я даже не знаю зачем я это делаю. Хочешь дальше играться в свои 37тактов и считать, что это стоит больше нуля? Пожалуйста. Вот за что вы со мною так?

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

Фу такими быть. Убиваете вы мою веру в людей.

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

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

я не хочу соревноваться с тобой, епрст!!!

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

с 5-го раза (я уж со счета сбился) понятно?

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

Давая тебе объясню. Дело в том, что вычисления(не в твоём случае) могут оказаться и оказываются быстрее той же оперативной памяти.

вау, открытие!!! кэши быстрее оперативки!!!!!!!!!!!!!!!!!!!!!!!111111

ну а еще что такого ты знаешь? дед мороз есть или нет?

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)

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

* подумал, что конкретно этот человек пытается сказать (я конечно могу ошибаться в своем понимании)

* заслуживает ли это внимания?

* даже если это заслуживает внимания, стоит ли потенциальный результат потраченных усилий?

* окей, кажется результат заслуживает усилий.

* пройдемся по имеющимся данным еще раз, держа в голове то, о чем напомнили.

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

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

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

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

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

Этого уже должно быть достаточно для понимания того

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

Для меня было очевидно, что ты имеешь ввиду своим комментом.

Ну и самое главное то, что царь ответил про vm задолго до твоего ответа

Ну извини, не слежу особо за тредом, не видел этот ответ, не стал бы дублировать своим, если бы увидел.

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

Эт чо, философские дискуссии в царетредах? Обычно тут принято писать простыни бесполезного нытья, кидания какашками и псевдотехнического текста.

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

Я б не писал ничего, если бы не получилось философской дискуссии, поп-деть за жизнь я за всегда за. Тем более после пятничной чарки крафтового 8.5% за за счет фирмы.

псевдотехнического текста

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

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

Вот тебе твоя простыня ^_^

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

Так «обычное поведение» совершенно не интересно

Именно поэтому я так нелюблю, что трут царетреды. Сделали бы какую-нибудь скрытую секцию, доступную только по прямому URL и прятали бы туда, было бы намного интереснее. Кто хочет - идет туда и страдает/наслаждается, кто не хочет - видит рафинированный ЛОР. Блин, вот за такие треды я и полюбил ЛОР в свое время.

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

Я с его вопроса про vm сразу понял, что человек не в теме про то как адресные пространства переключаются

Если вы такой понятливый, то может хоть вы объясните, каким образом переключение адресных пространств относится к переключению нитей в рамках одного процесса?

А то вот Царь слился.

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

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

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

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

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

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

Ахринеть, у Царя почитатели.

Вы его код где-нибудь когда-нибудь видели? Пользовались? Может поделитесь ссылочкой?

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

Начнём с того, что в этой теме код у него и у тс, лол. А закончим тем, что речь не о коде а о знании мат части, это главное. Кстати, ваша узость миышления меня поразила ещё в том треде, где вы с царём по теме const в плюсах срались.

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

знании мат части
Царь

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

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

Начнём с того, что в этой теме код у него и у тс, лол.

Ну и как вы оцениваете этот код Царя?

А закончим тем, что речь не о коде а о знании мат части, это главное.

И как же проверяется знание матчасти? Разговорами на LOR-е в стиле «это не влияет»?

Кстати, ваша узость миышления меня поразила ещё в том треде, где вы с царём по теме const в плюсах срались.

В какой именно?

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

Код доказал, слова царя про 10к.

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

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

Код доказал, слова царя про 10к.

Как интересно. Во-первых, покажите, кто здесь утверждал, что модель N:N на 10k не будет работать?

Во-вторых, меня и, полагаю, staseg и i-rinat интересует эффективность решения N:N на 10k нитях. Что по этому поводу говорит Царь или его код?

В-третьих, тот же DiKeert признал, что код Царя не имеет смысла.

В-четвертых, я вас спросил про то, как вы лично оцениваете код Царя. Ну просто чтобы понять, относится ли ваше почитание Царя только к тому, что он пишет на форуме или это и на царский код распространяется.

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

Был бы признателен, если бы вы ссылку привели. Ну или как-то сузили пространство для поиска.

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

Если вы такой понятливый, то может хоть вы объясните, каким образом переключение адресных пространств относится к переключению нитей в рамках одного процесса?

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

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

В данном вопросе Царь прав.

Однако, линуксовый планировщик плохо дружит с большим количеством ожидающих выполнения нитей, а остальной линукс иногда от балды будит спящие по делу нити (см. spurious wakeup, или проблемы с epoll/accept после форков). Это пагубно сказывается на производительности. Спасает либо уверенность, что треды большую часть времени будут заблокированы на IO и не попадут в очередь на выполнение большим скопом (что показал тот сервер с 10к нитями, но что при очень интенсивном IO и дорогих multiqueue карточках не до конца верно), либо волшебство вроде переключения нити в обход планировщика и принудительный саспенд нити до такого переключения. Последнее волшебство уже начинает сильно напоминать зелёные треды.

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

Мне кажется или в этом треде появился кто-то действительно компетентный, в отличие ото всех остальных, и умеющий в человеческую речь, в отличие от царя?

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

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

Я говорил про преключение тредов в рамках подхода N:N, которого нет в моделях N:1 и N:M. Поэтому сохранение регистров при переключении тредов — это дорогая операция, поскольку в подходах N:1 и N:M ее нет вообще.

Я не заострял внимания читателей именно на том, что речь идет про противопоставление N:N и N:1/N:M, предполагая, что спор идет именно об этом.

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

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

В данном вопросе Царь прав.

Это прекрасно. В особенности потому, что я нигде не говорил, что переключение нитей дороже переключения процессов.

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

Вы мой кумир, очень хорошо все изложили, мне лень так тщательно это делать.

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

Вообще, этот регистрант первый ответил на реальную проблему заданную ещё в этой теме.

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

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

ммм?

а как насчет tlb miss? стэки-то у всех нитей разные вроде, а тлб на интеле какой-то неприлично маленький емнип, при том, что нитей у нас over 10k?

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

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

Это не совсем так, и поэтому эксперт вас пытается поймать.

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

А то, что она не «дорогая» - это следствие того, что запись и сохранение регистров ничего не стоят.

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

По поводу этого. Раз вы разбираетесь в кишках планировщика линукса.

Если добавить между блокировками на ИО какой-то кусок кода, который выполняется 1/10000 доли секунды. Будут ли происходить переключения в тот момент, когда нить выполняет этот кусок кода.

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

Так это, либо нет.

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

а как насчет tlb miss? стэки-то у всех нитей разные вроде, а тлб на интеле какой-то неприлично маленький емнип, при том, что нитей у нас over 10k?

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

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

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

Я говорил про преключение тредов в рамках подхода N:N, которого нет в моделях N:1 и N:M. Поэтому сохранение регистров при переключении тредов — это дорогая операция, поскольку в подходах N:1 и N:M ее нет вообще.

В Ваших рассуждениях есть логическая ошибка: из присутствия операции Вы делаете вывод о её дороговизне.

sizeof(mcontext_t) на моей машине равен 256, с учётом всех напиханных туда padding-ов и выравниваний. Три обычных вызова функций с учётом создания фрейма и выравнивания rbp уже запишут в память больше, чем весь контекст, необходимый для переключения треда.

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

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

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

Это прекрасно. В особенности потому, что я нигде не говорил, что переключение нитей дороже переключения процессов.

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

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

а как насчет tlb miss? стэки-то у всех нитей разные вроде, а тлб на интеле какой-то неприлично маленький емнип, при том, что нитей у нас over 10k?

Но полностью tlb не сбрасывается. Конечно, промах из-за стека и каких-то локальных данных будет, но при использовании epoll те же промахи будут при доступе к локальным данным/буферам определённого соединения.

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

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

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

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

Если добавить между блокировками на ИО какой-то кусок кода, который выполняется 1/10000 доли секунды. Будут ли происходить переключения в тот момент, когда нить выполняет этот кусок кода.

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

Так это, либо нет.

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

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

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

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

А закончим тем, что речь не о коде а о знании мат части, это главное

АААААААААА
Да здравствуют диванные теоретики!

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

Но полностью tlb не сбрасывается. Конечно, промах из-за стека и каких-то локальных данных будет, но при использовании epoll те же промахи будут при доступе к локальным данным/буферам определённого соединения.

при использовании epoll можно использовать huge pages, а вот можно ли использовать huge pages, если у нас 100К нитей? ведь емнип страницу можно замапить только целиком, и такому процессу придется отдать 100К*2М=200Гбайт, причем большая часть байтов будет пустой

ну и даже при 10К нитей все равно 20Гбайт оперативы на пустое приложение, не?

я тут предполагаю, что стеки нитей должны быть в *разных* страницах; конечно, им можно и обычные (4Кбайт) страницы выдать, но тогда страниц будет существенно больше, чем при epoll, и больше tlb миссов

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

Интересное нашлось в Интернетах:

You cannot rely on Linux's scheduler to magically make thread context switching significantly cheaper than process context switching. In my experience, without manual tuning the scheduler doesn't do a good job at achieving CPU affinity, so threads tend to bounce around a lot. A typical server has lots of background processes taking small amounts of CPU time, and unless you pin processes to specific cores, you'll see that the costs of context switching and thread switching don't significantly differ in practice, unfortunately.

Цитата, правда, от 2012-го года. Может что-то существенно улучшилось за прошедшее время.

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

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

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

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

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

Могли бы вы поделиться каким-нибудь бенчмарками на эту тему?

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

Ты начинаешь нарушать условия.

ведь емнип страницу можно замапить только целиком, и такому процессу придется отдать 100К*2М=200Гбайт, причем большая часть байтов будет пустой

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

А если переполниться - насрать.

я тут предполагаю, что стеки нитей должны быть в *разных* страницах; конечно, им можно и обычные (4Кбайт) страницы выдать, но тогда страниц будет существенно больше, чем при epoll, и больше tlb миссов

Осталось только определить влияние тлб-мисов на результат.

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

при использовании epoll можно использовать huge pages, а вот можно ли использовать huge pages, если у нас 100К нитей? ведь емнип страницу можно замапить только целиком, и такому процессу придется отдать 100К*2М=200Гбайт, причем большая часть байтов будет пустой

Если мы пишем программу на 100к тредов, то мы должны аккуратно использовать стек и о 2мб стека на поток мы можем только мечтать. В целом, 64кб обычно хватает, если программировать аккуратно и не делать лишних рекурсий / больших буферов на стеке.

я тут предполагаю, что стеки нитей должны быть в *разных* страницах; конечно, им можно и обычные (4Кбайт) страницы выдать, но тогда страниц будет существенно больше, чем при epoll, и больше tlb миссов

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

Если я правильно помню, виртуальная память связана со стеком только через guard-страницу, которая позволяет автоматически растить стек или отслеживать переполнение стека сегфолтом.

Документация boost::context, кстати, достаточно интересная в плане того, какие бывают способы управления стеком.

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

И причиной этих поверий были времена форков

дорогой царь. ты вопиюще некомпетентен.

пруф в топике, есичо

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

переключения - это притянутое за уши свойство

переключения (обычно их называют системными вызовами) являются основным тормозом любого современного серверного приложения

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

неправильно понимаешь

но и в споре с царём ты неправ процентов на сто

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

You cannot rely on Linux's scheduler to magically make thread context switching significantly cheaper than process context switching

это так

но зачем ты постишь цитаты, смысл которых не понимаешь?

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

Переключение нитей сейчас в Linux-ах при условии отсутствия тысяч активных нитей в очереди — настолько же дешевая

предлагаю забанить этого юзера за 4.2

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

Если я правильно помню, виртуальная память связана со стеком только через guard-страницу, которая позволяет автоматически растить стек или отслеживать переполнение стека сегфолтом.

да-да, я про в том числе это

если у нас стек ну пусть даже 40Кб (с гвард-страницей), то это 10 страниц, а нитей у нас 10К, значит всего 100К страниц, это 400МБайт

в то время как с epoll нам huge pages на тот же объем оперативы потребуется всего лишь 200 штук (емнип они по 2Мб), что емнип tlb miss-ы исключит или близко к тому, не?

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