Сколько центральных процессоров необходимо, прежде чем Erlang быстрее, чем однопоточный [закрытый] Java
4 ответа
так как это арифметическая большая рабочая нагрузка, и вы уже сделали работу по разделению кода на отдельные служебные процессы, вы не получите многого от Эрланга. Ваша работа, кажется, удобно подходит для Java. Эрланг хорошо разбирается в крошечных транзакциях - таких как msg переключение или обслуживание статических или простых динамических веб-страниц. Нет... в последнее время - на предприятии, где работает с номерами или с базами данных.
Тем не менее, вы можете использовать Erlang в качестве переключателя MSG :D это то, что делает couch-db :P
-- отредактируйте --
Если вы переместите свои арифметические операции в Erlang async-IO драйвер erlang будет так же хорош, как и языковые перестановки -- но с 24 процессорами, возможно, это не будет иметь большого значения; база данных erlang процедурна и поэтому довольно быстра -- это может быть использовано в вашем приложении, обновляющем 100 сущностей на каждую транзакцию.
Система исполнения erlang должна быть смесью C и C++, потому что (a) эмулятор erlang написан на C/C++ (вы должны где-то начать), (b) вы должны поговорить с ядром, чтобы сделать async file io и network io, и (c) некоторые части системы должны быть быстрыми - например, бэкэнд системы базы данных (амнезия).
-- обсуждение --
с 24 процессорами в 6-ядерной * 4 процессорной топологии с использованием общей шины памяти -- у вас есть 4 NUMA сущности (процессоры) и одна центральная память. Вы должны быть мудрыми в этой парадигме, многопроцессорный подход с общим доступом может убить вашу шину памяти.
Для того, чтобы обойти это, необходимо создать 4 процесса с 6 потоками обработки и связать каждый поток обработки с соответствующим ядром в соответствующем процессоре. Эти 6 потоков должны выполнять совместную многопотоковую работу -- Эрланг и Lua делают это врожденно -- Эрланг делает это жестко, так как у него есть полнопоточный планировщик как часть своего рабочего времени, который он может использовать для создания стольких процессов, сколько Вы захотите.
Теперь, если бы вы разделили свои задачи на 4 процесса (по 1 на физический процессор), вы были бы счастливы, однако вы запускаете 4 Java VM, выполняющих (предположительно) серьезную работу (фуу, по многим причинам). Проблема должна быть решена с лучшей способностью нарезать кубики и кубики.
Выходит OTP система Эрланга, она была разработана для резервных надежных сетевых систем, но сейчас она движется в сторону одномашинных NUMA-совместимых процессоров. У нее уже есть кик-асс эмулятор SMP, и в скором времени она станет известна и NUMA. С такой парадигмой программирования у вас гораздо больше шансов насытить свои мощные серверы, не убивая при этом свою шину.
Возможно, эта дискуссия была теоретической, однако, когда вы получите топологию 8x8 или 16x8, вы также будете к ней готовы. Итак, мой ответ заключается в том, что когда у вас более 2-х -- современных -- физических процессоров на материнской плате, вам, вероятно, следует подумать о лучшей парадигме программирования.
В качестве примера основного продукта после обсуждения здесь: SQL Server от Microsoft - это NUMA-сервер уровня процессора на уровне SQL-OS , на котором построен движок базы данных.
Вопрос скорости, когда речь идет о языках программирования, столь же сложен, как и вопрос. Защитники Java могут указывать на множество областей и утверждать, что они самые быстрые, и они были бы на 100% верны. Защитники Рубина/Питона указывают на другой набор параметров и утверждают, что они быстрее, и они также были бы правильными. Тогда адвокаты Эрланга указывают на параллельные соединения и утверждают, что они самые быстрые при работе с сотнями или тысячами параллельных соединений или вычислений, и это тоже не было бы ошибкой.
Глядя на базовое описание рассматриваемого проекта, мне кажется, что Эрланг идеально подошел бы вам. Не зная подробностей, я бы сказал, что на самом деле это была бы чертовски простая программа для Эрланга, которая действительно могла бы быть сделана в очень короткое время
.Если вы получаете 100 в секунду, но они берут по 100 в секунду, как это может продолжаться? Может быть, я неправильно понял эту часть, но в любом случае, если это не тысячи или миллионы запросов в секунду, ваш код синхронизации не должен занимать много времени. Если это так, то вы делаете что-то не так, возможно, блокировка во время выполнения всей работы или что-то в этом роде.
Для многопоточного кода переход на язык еще более высокого уровня, вероятно, является ошибкой. Даже если вы пишете часть приложения на erlang или что-то вроде того, что многопоточность должна быть на Java или перейти на C++, если производительность действительно становится проблемой
.Сравнили ли вы стоимость нового оборудования со стоимостью переобучения персонала в Эрланге и перекомпоновки вашего программного обеспечения на новом языке?
Я бы не стал недооценивать расходы на переобучение себя (или других) и расходы на наем людей, хорошо знакомых с Эрлангом (которых будет труднее найти , чем людей, говорящих на Java). Серверы, очевидно, стоят с точки зрения стоимости их хранения/питания/обслуживания и т.д., но они все равно намного дешевле, чем квалифицированный персонал. Если вы можете сделать прогресс и оставаться масштабируемым при использовании ваших текущих навыков, я подозреваю, что это самый прагматичный подход.