LINUX.ORG.RU

Прокачаться в low-latency сетевом программировании и многопоточностях.


1

2

Писал сетевые приложения под linux с использованием select, epoll на C++. Многопоточность использовал pthreads и boost кросс-платформенно.

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

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

★☆

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

Есть пара книжек Таненбаума по ОС, но я бы посоветовал почитать Роберт Лав «Разработка ядра linux», и книги Марка Руссиновича (если увлекаешься виндами). А так, можно просто написать список вопросов по ОС и погуглить их.

nerdogeek
()

Можешь в качестве тренировки написать нормальный (без использования БД) FSAL_POSIX для GaneshaNFS, в идеале что бы это кластеризовалось, знаю одну не мелкую контору, которую это очень обрадует:)
Или, например, покоммитить в CEPHFS.
Ну попиши там руткиты под винду.

А вот за недостатком знаний, уже можно лазить в инет и книжки.

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

Ещё «Алгоритмы на с++» by Роберт Седжевик - неплохое чтиво, хотя, на первый взгляд, и офтопик.

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

batbko
()

посмотри сырцы libevent2.

anonymous
()

Устаревает кажные два-три года. То, что Дреппер 5 лет назад вещал, уже местами не только неактуально, но и неправда. Посему, читать «Intel® 64 and IA-32 Architectures Optimization Reference Manual», регулярно его обновляя.

Устройся в контору, где много данных перемещают - прокачаешься.

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

ТС-у подойдёт любая контора где есть хотя бы один программист

Писал сетевые приложения под linux с использованием select

использовал pthreads...

какие бывают примитивы синхронизации

anonymous
()

Можешь глянуть сорцы netmap. Правда не уверен, что это то, что нужно.

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

Устаревает кажные два-три года. То, что Дреппер 5 лет назад вещал, уже местами не только неактуально, но и неправда. Посему, читать «Intel® 64 and IA-32 Architectures Optimization Reference Manual», регулярно его обновляя.

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

Устройся в контору, где много данных перемещают - прокачаешься.

А такие есть? Только чтобы данные/возможность было в районе 1/10 хотябы. Я не видел такого.

anonymous
()

Писал сетевые приложения под linux с использованием select, epoll на C++.

Смешно. Выкинь плюсы и осиль уже сишку.

Многопоточность использовал pthreads и boost кросс-платформенно.

Т.е. ты просто писал сетевой код для говна? Никакая сеть даже один «поток» не прокачает.

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

Осиль матчасть перед тем как что-то юзать.

какие в винде

low-latency - ну ты понял.

какие во фре

Зачемн асиловать труп?

всякие там отличия и особенности

Зачем это нужно?

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

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

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

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

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

А так возми в скобочки слова «low-latency», «прокачка», «low-level» и не позорь их.

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

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

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

Информация это что? История успеха? Пошаговая инструкция вида «как стать крутым за 3недеил?»

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

Ждёшь куллстори - жди.

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

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

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

Т.е. ты просто писал сетевой код для говна? Никакая сеть даже один «поток» не прокачает.

Штуки 4 10-гигабитных адаптера заткнут весь канал памяти у младших E5. С запасом заткнут.

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

Штуки 4 10-гигабитных адаптера заткнут весь канал памяти у младших E5. С запасом заткнут.

точно? /me мерзко хихикает.

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

точно? /me мерзко хихикает.

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

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

Штуки 4 10-гигабитных адаптера заткнут весь канал памяти у младших E5. С запасом заткнут.

Что такое «канал памяти» - поясни.

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

Что такое «канал памяти» - поясни.

Ну так как речь идёт про:

Никакая сеть даже один «поток» не прокачает.

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

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

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

В сегодняшних реалиях ядро может прокачитвать 200гигов.

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

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

Если это шины и обвес, то тоже - кроме возможно каких-то особенностей о которых я не знаю.

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

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

В сегодняшних реалиях ядро может прокачитвать 200гигов.

200 гигов чего?

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

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

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

200 гигов чего?

Скорость доступа к l1.

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

Канал памяти даже, если у тебя тотальное копирование крнел->юзер->кернел в сегодняшних реалиях больше 5жилких гигов.

Обычно да не обычно - я создавал по этому поводу тред. На штеудах одно ядро покачивает 90%+ памяти, 2 ведра 100%. На говяных амд прокачивают лишь 4ведра. Скорость памяти в текущих реалиях 30гигов+. Я не знаю как там себя ведут хеоны со стопицот канальной памятью, но одно ведро 15гигов прокачает 100%. Думаю, что хеоны уже до полтиника доросли.

Мувать дейту имеет смысл в 2-3треда только, если твой код говно, либо в случаях особенностей подситемы памяти. Первый случай 99% - на второй кладут.

Реально же одно ядро 100% прокачает сеть, если нет - тебя треды не спасут, а уж о low-latency не стоит говорить. Тут у тебя решение одно - добро пожаловать в кернелспейс.

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

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

Скорость доступа к l1.

Ты ведь знаешь, что L1D всего 32 кб, он сбрасывается при каждом context switch, и в него данные по DMA не попадают?

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

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

Ты ведь знаешь, что L1D всего 32 кб, он сбрасывается при каждом context switch, и в него данные по DMA не попадают?

А причем тут это - ты спросил я ответил. Ядро может читать много - другое дело ограничение не ведра.

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

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

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

Дано: 40гигабит, контроллер памяти, который прокачивает минимум 30гб в текущих реалиях. Одно ведро, которое в любом случае 50% имеет. Что тут и куда по твоей логике упрётся.

Заодно поведай мне устроство компьютера - мне интересно.

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

Дано: 40гигабит, контроллер памяти, который прокачивает минимум 30гб в текущих реалиях. Одно ведро, которое в любом случае 50% имеет. Что тут и куда по твоей логике упрётся.

Часть трафика будет тратится на общение контроллера и памяти. Теоретические 30гб существуют в теории, подобраться к ним можно только в синтетическом тесте. В реальности 4 штуки 10GE-контроллера будут делать почти случайный доступ. Плюс процессору нужно эти данные сначала считать, а потом записать, а часто ещё и sata'шному контроллеру надо будет за теми же данными в память подлезть.

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

Контроллер памяти на современных интелах встроен в процессор, 10% LLC доступно для DDIO (это когда трафик с железки идёт не в память, а сразу в кэш). Латентность и way'ность LLC гораздо лучше, чем у памяти. Таким образом, если успевать выгребать данные из этих 10 процентов, то можно сэкономить на записи в память девайсом и последующим чтением процессором. Одним ядром это не сделать, уж поверь.

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

Часть трафика будет тратится на общение контроллера и памяти.

Да, та часть, которую ведро не прокачает.

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

Да и вреальном коде можно, только это сложно - это уже проблема говнокода.

В реальности 4 штуки 10GE-контроллера будут делать почти случайный доступ.

Кто это проектировал?

Плюс процессору нужно эти данные сначала считать, а потом записать, а часто ещё и sata'шному контроллеру надо будет за теми же данными в память подлезть.

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

Контроллер памяти на современных интелах встроен в процессор

Да, ибо он был всегда говно и протух на заре коре2.

10% LLC доступно для DDIO (это когда трафик с железки идёт не в память, а сразу в кэш).

Хорошо. Что мешает их читать? Запилить в общем случае обходя память это сложно из-за х86проблем - пилят ли?

Латентность и way'ность LLC гораздо лучше, чем у памяти.

Это тоже логично и понятно.

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

Это уже кернелспейс проблемы и рядовой ваяйщик туда даже не лезит.

Одним ядром это не сделать, уж поверь.

Ну какбэ одно ведро читает из llc по определнию минимум реально в 10раз быстрее, чем теоретически пишут твои сетевухи. Почему не сделать? Т.е. в другую часть кеша мы записывать теоретически успеваем с 5-тикратным запасом - в чем проблема?

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

У тебя есть личный положительный пример использования хотя бы одного 10GE на полную катушку? Чтобы трафик гигабайт в секунду пёр, и твой софт успевал его обрабатывать?

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

Ну отдолжи мне пару 10ге - я попробую, потом верну - авось что-то путное выйдет. Для софта гигабайт - смешно. Больше, чем 1 ширпотребный недо ge не юзал, поэтому я с тобой и не спорю.

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

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

Ну отдолжи мне пару 10ге - я попробую, потом верну - авось что-то путное выйдет.

Ну приезжай ;)

08:00.0 Ethernet controller: Solarflare Communications SFC9020 [Solarstorm]
08:00.1 Ethernet controller: Solarflare Communications SFC9020 [Solarstorm]

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

Ну вот достань капчу Nasdaq'а в день, когда фейсбук на IPO вышел, и попробуй написать парсилку протокола и ордербук, чтобы queueing'а не было (т.е. чтобы латентность была постоянной и не увеличивалась под нагрузкой). FIX - протокол простой, ордербук тоже не самый сложный софт. Если такое осилишь, то, считай, разбогател.

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

Ну приезжай ;)

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

Ну вот достань капчу Nasdaq'а в день, когда фейсбук на IPO вышел, и попробуй написать парсилку протокола и ордербук

Что такое капча и ордербук?

чтобы queueing'а не было (т.е. чтобы латентность была постоянной и не увеличивалась под нагрузкой).

Нагрузка - это сколько? Сколько должна быть латентность.

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

Не люблю текст - слишком сложно избыточно и непрофитно, да и противоречит быстроте и латентности.

Что такое ордербук я не знаю - расскажи. Меня не особо интересует богаство пока, а опыт запила - да.

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