Если собрался покупать то тут не важно на чем реализовано, а скорее важно как и под какую платформу. Если собрался сам писать, то пиши на том что лучше знаешь и опять же зависит от платформы под какую собрался писать, я бы порекомендовал джаву или питон, а вообще дело вкуса (мб кому то на асме удобно =) ). п.с. название темы немного некорректно ибо многопоточность реализована практически во всех ЯП и нету никакого смысла затачивать под нее определенный язык )
нет языка который рулит в многопоточности.... затачивали же для этого "GO" и другие типа Erlang но чегото они тяжко приживаются!
C#, Java, для твоей цели лучше даже Java, т.к поставил на сервер (*NIX или Win - неважно), запустил и забыл.
Вообще самую большую скорость тебе дадут тока те языки которые напрямую работают с функциями системы (если корректно написано всё). Но тут уже будет всё зависеть от платформы. Если не нужна многоплатформенность то мне кажется Си тут подойдет очень хорошо. Темболее если дело связано с сетью, то можеш не думать про язык. Потому что скорость сети полюбому меньше скорости проца. Другое дело гемор писать всё. Языки типа явы и шарпа дают тебе сразу много возможностей без лишних трудностей. Но за это ты будеш платиться скоростью.
в том же разделе и пхп интересно, что нерезус скажет. видишь какой разброс интересный получился - квазар вон яву советует. меня интересует чтобы было много, очень много потоков.
2 оlbaneс а зачем тебе потоки? Если спам, то быстрее через неблокируемые сокеты делать всё. И потом для обработки ставить по 2 потока на 1 ядро проца. Для примера. Писал софт для коннекбек прокси. который на 4-х ядернике запускал 8 потоков. И он держал > 40k коннектов одновременных больше не проверяли. При этом обеспечивал 20k потоков спама. (т.е. софт спамящий с 4-х серверов спамил в 5к потоков с каждого) И всё довольно нормально проходило. При этом всё работало под Win2k3 и прога написана на Си Так что тут особо не нужды делать потоки. да и потоки - это зло потому что не всегда они смогут дать производительность. К томуже их ограниченное кол-во может быть. Так что ток Win2k3 норм всё давало. Единственное что тебе подойдет так это тока: 1) небольшое кол-во потоков для работы с сетью с основой на неблокируемых сокетах 2) относительно не большое кол-во потоков для генерации пакетов отправки. т.е. чтото типа Потоки работы с сетью берут разлоченый пакет, отправляют его, и лочат. А потоки генерации видя залоченный пакет генерят в нем всё и разлачивают его. И далее по кругу. Пойдет хорошо для мыльного спама. А те потоки которые с сетью. они смотрят - если пакет залочен, то ничего не
F# ты решил подобрать ЯП для задачи? Быть может стоит попытаться переделать задачу под тот ЯП с которым ты знаком? Дольше будешь язык изучать нежели самой задачей.
+1 За неблокирующиеся сокеты. Многопоточность против них (в сетевых задачах) отсасывает. Вот только один нюанс - для того чтобы НОРМАЛЬНО на них писать то и кодер нужен НОРМАЛЬНЫЙ (как минимум)...
=) У перла некрасиво сделано имхо с шаредами. + язык устарел. В питоне и руби есть проблема с GIL - с одной стороны это решает часть проблем с синхронизацией, с другой неоптимально на многоядерных системах(грузит 1 ядро). На threading несколько сотен потоков у меня было лимитом из-за этого. Питон содержит очень хорошие вещи как twisted и cogen. Есть варианты с Java и C#. Плохого ничего не скажу. Но кода больше по сравнению с питоном и руби. Что касается C++, то тут все зависит от фреймворка. Либо от наличия кучи ЛИШНЕГО времени при отсутствии фреймворка. Вариант с потоками удобнее, чем select/etc.