какой ЯП больше подходит для многопоточности?

[оlbaneс]

скажем к примеру спамер или типа того. на каком популярном ЯП это будет проще и дешевле сделать?

[Kaimi]

c# наверное

[razb]

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

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

[BrainDeaD]

тоже считаю c#. копай namespace Threading.

[оlbaneс]

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

[Retimiled]

нет языка который рулит в многопоточности.... затачивали же для этого "GO" и другие типа Erlang но чегото они тяжко приживаются!

[mr.The]

мне так по отзывам казалось, что перл рулит.
С/С++, C#, Delphi, .NET, Asm
так что перл бы тебе подсказали в другом разделе.

а тут да, c#, или (о боже!) делфи.

[Tigger]

так что перл бы тебе подсказали в другом разделе.


Kaimi кодит на перле, а тоже посоветовал C#.

Хотя я тоже больше за С# )

[M_script_]

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

[Qwazar]

C#, Java, для твоей цели лучше даже Java, т.к поставил на сервер (*NIX или Win - неважно), запустил и забыл.

[slesh]

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

[оlbaneс]

так что перл бы тебе подсказали в другом разделе.

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

[slesh]

2 оlbaneс а зачем тебе потоки? Если спам, то быстрее через неблокируемые сокеты делать всё. И потом для обработки ставить по 2 потока на 1 ядро проца.

Для примера. Писал софт для коннекбек прокси. который на 4-х ядернике запускал 8 потоков. И он держал > 40k коннектов одновременных больше не проверяли. При этом обеспечивал 20k потоков спама. (т.е. софт спамящий с 4-х серверов спамил в 5к потоков с каждого) И всё довольно нормально проходило. При этом всё работало под Win2k3 и прога написана на Си
Так что тут особо не нужды делать потоки. да и потоки - это зло потому что не всегда они смогут дать производительность. К томуже их ограниченное кол-во может быть. Так что ток Win2k3 норм всё давало.

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

[W!z@rD]

F#

ты решил подобрать ЯП для задачи?

Быть может стоит попытаться переделать задачу под тот ЯП с которым ты знаком?
Дольше будешь язык изучать нежели самой задачей.

[login999]

2 оlbaneс а зачем тебе потоки? Если спам, то быстрее через неблокируемые сокеты делать всё. И потом для обработки ставить по 2 потока на 1 ядро проца.

Для примера. Писал софт для коннекбек прокси. который на 4-х ядернике запускал 8 потоков. И он держал > 40k коннектов одновременных больше не проверяли. При этом обеспечивал 20k потоков спама. (т.е. софт спамящий с 4-х серверов спамил в 5к потоков с каждого) И всё довольно нормально проходило. При этом всё работало под Win2k3 и прога написана на Си
Так что тут особо не нужды делать потоки. да и потоки - это зло потому что не всегда они смогут дать производительность. К томуже их ограниченное кол-во может быть. Так что ток Win2k3 норм всё давало.

Единственное что тебе подойдет так это тока:
1) небольшое кол-во потоков для работы с сетью с основой на неблокируемых сокетах
2) относительно не большое кол-во потоков для генерации пакетов отправки.
т.е. чтото типа
Потоки работы с сетью берут разлоченый пакет, отправляют его, и лочат.
А потоки генерации видя залоченный пакет генерят в нем всё и разлачивают его.
И далее по кругу. Пойдет хорошо для мыльного спама.
А те потоки которые с сетью. они смотрят - если пакет залочен, то ничего не
+1 За неблокирующиеся сокеты. Многопоточность против них (в сетевых задачах) отсасывает. Вот только один нюанс - для того чтобы НОРМАЛЬНО на них писать то и кодер нужен НОРМАЛЬНЫЙ (как минимум)...

[nerezus]

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

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

В питоне и руби есть проблема с GIL - с одной стороны это решает часть проблем с синхронизацией, с другой неоптимально на многоядерных системах(грузит 1 ядро).
На threading несколько сотен потоков у меня было лимитом из-за этого.
Питон содержит очень хорошие вещи как twisted и cogen.

Есть варианты с Java и C#. Плохого ничего не скажу. Но кода больше по сравнению с питоном и руби.

Что касается C++, то тут все зависит от фреймворка. Либо от наличия кучи ЛИШНЕГО времени при отсутствии фреймворка.

Вариант с потоками удобнее, чем select/etc.

[warkk]

Угу, C#

[Jingo Bo]

какой ЯП больше подходит для многопоточности?
Ну раз так, то читай "Средства параллельного программирования на языке АДА":)

[scrat]

ADA