Цитата(Enelar @ 25.6.2010, 01:51  ) |
| однопоточное приложение всегда быстрее многопоточного. |
а в Intel'е не знают. делают 8-ми, 16-ти ядерные процессоры ...
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Программирование под Unix/Linux > Сокеты для большого сервера |
| Автор: Anton Vatchenko 21.5.2010, 22:43 |
| Итак, имеем около 5 тысяч клиентов, которые висят на сервере через TCP. Изначально все было построено на модели 1 клиент - 1 поток, что уже не целесообразно. Поэтому хотелось бы узнать как на крупных серверах решают проблему: 1. Какая-то супер библиотека. 2. Асинхронные сокеты через select и затем перебор всех активных соединений if (FD_ISSET(..., ...)). Не так уж сложно перебирать 5 тысяч элементов и проверять установлен ли флаг, но это приходится делать без остановки - большой поток данных. Да и необходимо другие задачи выполнять. 3. Какая-то возможность получить только те соединения, на которых появились данные. |
| Автор: boostcoder 22.5.2010, 00:48 |
| асинхронные сокеты + epoll() |
| Автор: MAKCim 22.5.2010, 08:59 |
| не путайте понятия "асинхронный" и мультиплексируемый ;) по сабжу http://www.kegel.com/c10k.html |
| Автор: Anton Vatchenko 22.5.2010, 13:33 |
| Статья хорошая, но в ней ни к одному идеальному варианту автор не приходит. Насколько я понимаю, есть хорошие способы, чтобы решить проблему, и сделать код переносимым, но зачем описывать все способы? |
| Автор: Enelar 25.6.2010, 01:51 |
| однопоточное приложение всегда быстрее многопоточного. в структуре fd_set хранится набор битов где номер бита равен номеру сокета (4 бит равен 1, значит в сокете 4 пришло сообщение) Если проверять на наличие сообщений по 4 байта, если есть то в этих 4 по 2, по одному потом по битам. Выдерживает нагрузку 10к без проблем и еще куча всего остального вертится. |
| Автор: Alca 25.6.2010, 09:17 | ||
Серьезно? |
| Автор: borisbn 25.6.2010, 10:42 | ||
а в Intel'е не знают. делают 8-ми, 16-ти ядерные процессоры ... |
| Автор: MAKCim 25.6.2010, 11:38 |
| смотря как масштабируется задача имхо, на мой взгляд, самая масштабируемая стратегия - 1 поток, слушающий сокет и N рабочих потоков каждый со своим epoll |
| Автор: REZiaMIX 25.6.2010, 17:13 |
| libevent, boost::asio ;) |
| Автор: MAKCim 25.6.2010, 17:23 |
| REZiaMIX, это инструменты, тут же речь про стратегии |
| Автор: Enelar 26.6.2010, 15:57 |
| Я говорил именно про данную задачу. |
| Автор: REZiaMIX 29.6.2010, 10:56 | ||||
|
| Автор: kometa_75 17.2.2011, 15:44 | ||||
Извиняюсь за некропостинг, но как многоядерная архитекура "ускоряет" многопоточное приложение? Имеется в виду определённое автоматическое масштабирование системой, компилятором(нужное подчеркнуть) потоков на CPU core? ЗЫ. Говорю именно про потоки, а не нити, процессы и т.п. И да, не подразумевается использование никакого API для параллельных вычислений(OpenMP etc.) |
| Автор: MAKCim 17.2.2011, 16:35 | ||
каждый поток может работать параллельно с другими занимая одно из ядер cpu т. е. если cpu 16-ти ядерный, то, упрощая, 16 потоков будут работать параллельно |
| Автор: xvr 17.2.2011, 16:36 | ||
А кто же тогда 'потоки'? ('поток', он же thread, он же 'нить') |
| Автор: kometa_75 17.2.2011, 16:50 | ||||
В винде fiber и thread имеют отличия. В *nix действительно, разницы нет. Однако мой вопрос был задан отнюдь не в контексте какой-либо конкретной ОС. Повторюсь, кто и где встречал в спецификации от hardware/software вендоров что-нибудь типа one thread-one core? Меня серьёзно интересует эта тема, ничего конкретного я пока сам не нарыл. Восновном "должно быть лучше", "теоретически", "опыты показали"... |
| Автор: xvr 17.2.2011, 16:56 | ||
 Дальнейшее увеличение производительности потребует каких то революционных изменений в архитектуре (или вообще новых архитектур), а вот этого то как раз вендоры делать и не хотят, т.к. уже наелись 'революций' (безуспешных)  |
| Автор: kometa_75 17.2.2011, 17:13 | ||||
Ну я собственно что хотел сказать своим вопросом. Встречался неоднократно с мнением, что якобы многопоточное приложение более пропорционально масштабируется на многоядерной(НЕ многопроцессорной!!!) системе, нежели однопоточное. Ради интереса провёл много тестов, и не нашёл подтверждения этому предположению. Скажем так, всё было скорее всего наоборот. Понятное дело, что потоки нужны. Тот же epoll крайне рекомендуется делать в отдельном потоке. Как уже писали в этой теме, правильно надо масштабировать задачи. А то что чрезмерное увлечение(применять всегда и везде где только можно) потоками - неистребимое зло, сказано было уже давно и неоднократно. |
| Автор: xvr 17.2.2011, 21:18 | ||||||||
Разницы между многоядерной (действительно многоядерной, а не просто HyperThread'инговой!) и многопроцессорной системой быть не должно. Разница между ними чисто количественная (типа размеров и принадлежностей кэшей, задержки на их синхронизацию и пр). И настоящее многопоточное приложение действительно будет масштабироваться.
|
| Автор: kometa_75 18.2.2011, 11:26 | ||||||||
Позволю не согласиться. В многопроцессорной конфигурации однопоточное приложение не будет гарантировано задействовать все процессоры. Многопоточное - также. Для этого и созданы специальное API, компиляторы. С многоядерным процессором немного иначе. Тут нельзя однозначно определить как и по какому принципу нагрузка будет масштабирована на ядра.
Оно будет масштабироваться примерно также как и однопоточное. Хотя возможны вариации.
Что подразумевается под "в быту"? Вот реальный пример. Сервер для онлайн-игры. Имеется множество равнозначных игровых сессий. В каждой просчёт игрового своего мини-мира, физика, логика и т.п. Каждая сессия активна, т.е. не ждёт, а что-то вычисляет. Второй вариант, имеется совокупность зон-локаций. В каждой выполняется просчёт мира, мобов и т.д. Как видите, очень напрашивается идея организовать каждую сущность в отдельном потоке. Не буду приводить примеры из области параллельных вычислений. Их там достаточно. И классическая многопоточность там не используется.
Выигрыш от потоков, на мой взгляд, это исключительно выигрыш за счёт более рационального использования effective work time. Т.е. в основном это параллельное выполнение какой-либо задачи со своими нюансами основанными на времени выполнения. Сам поток никаким образом не "ускорит" программу, и отличное(от однопотоного приложения) масштабирование потоков на разные ядра-процессоры, как мне кажется, это необоснованный миф. |
| Автор: borisbn 18.2.2011, 13:47 | ||||
пожалуй, соглашусь
а вот тут... в linux, честно говоря, не знаю, а windows сама распределяет нагрузку по процессорам/ядрам, так что пруф-линк, пожалуйста. |
| Автор: xvr 18.2.2011, 14:04 | ||||||||||||||||||||||||||
Я бы даже сказал - гарантированно не будет
Есть простой тест - берем однокоровый/однопроцессорный вариант, запускаем тестируемую прогу. Смотрим загрузку процессора - если она не 100%, то распараллеливать тут нечего. Потом берем многокоровый/многопроцессорный сервер. Запускаем, смотрим загрузку - если она не 100% по всем корам, то налицо недоиспользование ресурсов, т.е. криво распараллелено (либо нужна большая нагрузка - больше клиентов или подобное). Если все ок, сравниваем скорость работы. Должна повысится пропорционально количеству коров/процессоров
 По сути это несколько независимых процессоров, собранных на одном кристалле. И на них потоки отличным образом ложатся. Термин 'масштабируются потоки' тут несколько неуместен, масштабировать можно все приложение целиком, путем создания в нем стольких потоков, сколько есть процессоров. Тогда будет достигнута максимальная производительность и загрузка аппаратуры. |
| Автор: MAKCim 18.2.2011, 14:21 | ||
я даже больше скажу на программном уровне даже на уровне ядра будет обычное представление cpu0, cpu1, cpu2, ... и не суть важно, cpu0 - это процессор или физическое ядро, или логическое ядро (hyper threading) |