C++ и Java: сравнительный анализ
Два лучших языка программирования в настоящее время — это C++ (детище Бьерна Страуструпа) и Java (появившийся под влиянием C++ и разработанный Джеймсом Гослингом). У обоих этих чрезвычайно популярных языков есть преимущества и недостатки.
Проанализируем, в чем они превосходят друг друга, а в чем — уступают. А в конце определим победителя: где какой язык окажется предпочтительнее по определенным критериям.
C++ был задуман как гибрид возможностей двух составляющих: 1) абстракции низкоуровневых языков и 2) межплатформенной переносимости высокоуровневого C (дедушки очень многих языков программирования).
C был очень привлекателен как язык высокого уровня да еще и работал с приличной скоростью. Но это не объектно-ориентированный язык, а значит — помимо прочих недостатков, у него:
- Механизмы работы класса на самом деле не могли быть инкапсулированы внутри дизайна класса. А это противоречит современному принципу разработки программного обеспечения: внутренние составляющие того, как что-то работает, должны быть инкапсулированы.
- Отсутствие абстракции означало отсутствие иерархий классов. Поэтому хороший код нельзя было использовать повторно так, чтобы это имело смысл.
Эти недостатки языка С появились, когда объектно-ориентированное программирование (ООП) было еще относительно неизвестной концепцией в мире программного обеспечения. С развитием ООП возникла потребность в C, а также языке, построенном на принципах ООП.
Ответом стал C++, который произошел от языка C, поэтому программисты легко переходили с C и подобных ему языков на C++.
Достоинства
Этот язык предоставляет программисту больше свободы. Если C допускал передачу по ссылке только с использованием указателей, то C++ позволяет изменять значения всех типов другой функции, просто предоставляя в нее адрес значения.
А еще язык допускает применение синтаксического сахара. Например, реализация указателей делает интуитивно понятным изменение значений с помощью локальных переменных, имя которых точно отражает их назначение. При написании кода в ассемблере регистры выглядят неоднозначно: легко забыть, для чего каждый из них был нужен.
А на C++ программист получает доступ к индексам массива объектов (каждый с собственными переменными) и устанавливает изменяющуюся переменную в качестве локального указателя. Допущение перегрузки операторов позволяет здесь сравнивать различные объекты, как если бы они были примитивными типами.
Недостатки
Предоставленная программисту свобода предполагает ответственное написание кода. Например, каждый фрагмент динамически выделенной памяти должен быть освобожден программистом.
Другие недостатки в иерархии классов связаны с возможностью наследования класса от более чем одного класса. Бывает непонятно, какие родительские поля или функции вызываются.
А еще процесс компиляции делает язык менее платформонезависимым, чем другие.
Достоинства
Java произошел от языка C, поэтому опыт работы с любым подобным ему языком облегчит переход. Этот язык чрезвычайно платформонезависимый. Так что беспокоиться о том, будет ли он компилироваться на нескольких разных машинах, не нужно.
Использование классов тестирования — одно из лучших достоинств Java (или любых программных пакетов, позволяющих писать код Java).
При тестировании кода на C++ используют заглушки (фрагменты кода, вызываемые из другого модуля) и драйверы (фрагменты кода, вызывающие другие модули с потенциальными данными).
Драйверы размещаются, как правило, в обычном исходном файле. Ведь программист должен правильно настроить класс тестирования, чтобы тщательного его протестировать. При наличии класса тестирования у программиста несколько экземпляров одного и того же объекта. Причем у каждого из них собственные параметры и каждый должен вести себя по-своему.
В интегрированной среде разработки типа Netbeans программист тестирует несколько классов с помощью разных классов тестирования. При этом нет необходимости каждый раз переделывать исходный код под потребности текущих тестов.
Недостатки
Java создавался под влиянием C++, но некоторые источники потенциальных проблем здесь были устранены. Например, в языке:
- реализован сборщик мусора;
- запрещено множественное наследование;
- отсутствуют указатели (для всего, что не считается объектом);
- отсутствует передача по ссылке (кроме объектов, массивов, списков массивов и других структур данных).
Это в итоге делает язык менее удобным: программисту неизбежно придется прикладывать большие усилия, чтобы что-то работало.
А использование сборщика мусора при отсутствии возможности простого прототипирования каждой функции делает его более медленным языком, чем C++.
Какой же язык лучше: C++ и Java?
Это зависит от того, чего намерен достичь программист.
Выполнение кода на C++ будет быстрее, чем на Java (хотя современные компьютеры настолько быстры, что большинство коммерческих приложений можно написать на Java: клиенты об этом даже не узнают). Так что C++ будет подходящим выбором там, где время имеет значение.
Например, при проектировании программного обеспечения для военной техники, оборудования для Роскосмоса/НАСА или полиции.
Java предпочтительнее для всего, что надо сделать платформонезависимым. Графический пользовательский интерфейс проще разработать для Java, поэтому Java лучше подходит для взаимодействия с клиентами.
В целом оба языка превосходны, но думаю, что C++ следует преподавать в школе раньше, чем Java. Слишком многое инкапсулировано в Java, оставляя программиста в неведении о том, что происходит внутри.
Что лучше: Java или C? Сравнительная характеристика, плюсы и минусы
Все, кто хоть немного знаком с программированием, знают, что Java и семейство С — это титаны в своей отрасли. И просто ответить, что лучше : Java или C, не получится. Эти языки имеют настолько широкое применение, что выбор между ними должен происходить только под какую-то конкретную задачу, а не в широком смысле.
Изучив эти два языка, вы точно сможете сказать, что понимаете в программировании достаточно. Потому что реализовать на этих языках можно практически что угодно. Поэтому , если вы решаете, что лучше изучать : Java или С , — изучите оба , это даст вам техническое преимущество перед теми, кто остановился только на одном.
Хоть эти языки и являются широко применяемыми и в некоторых случаях могут реализовать один и тот же проект, все же это разные языки. Поэтому о б их различиях и сходствах мы сегодня напишем, а вы уже решите сами , что для вас лучше : Java или С.
Краткий обзор Java и С
- С++;
- С#;
- Objective-C.
Что лучше в скорости и простоте : Java или С
- библиотека стандартных шаблонов;
- GNU C;
- Boost;
- BDE;
- Loki;
- ASL и много других.
- Wicket;
- Vaadin;
- Spring;
- Play;
- Hibernate;
- GWT;
- Blade и др.
Исследования популярности этих языков
Что лучше по популярности — Java или С , — можно посмотреть в открытых источниках в сети. Ест ь много исследовательских сайтов, которые занимаются подобными вычислениями по различным критериям. Однако из всей подобной информации можно вынести следующее:
В последнее десятилетие прослеживается общая тенденция снижения популярности у обоих языков. Это связывают с тем, что набирают популярность другие более современные языки, такие как: JavaScript, Питон, Swift, Руби и др. — эти языки «перетягивают» часть возможностей на себя. Однако при общей тенденции снижения прослеживается более высокая популярность у Java, чем у Си. Но в т о ж е время, если рассматривать все семейство С-языков, то видно , что в совокупности они все равно занимают лидирующие позиции.
Как используются в реальной жизни
- некоторые операционные системы;
- различные настольные приложения на разных платформах;
- библиотеки машинного обучения;
- различные приложения с трудной графической обработкой;
- в телеприставках и автомобилях;
- и др.
- очень многие веб-приложения выполнены именно на Java;
- некоторые мобильные приложения;
- облачные приложения;
- игры;
- в автомобилях;
- используют для анализа данных;
- и др.
Кроссплатформенность Java и С
Тут и кроется одно из главных их отличий. К примеру, приложение на Си , скомпилированное в одной операционке, не будет функционировать на другой ОС. Чтобы этого достичь, потребуется перекомпиляция приложения для другой ОС.
А приложение на Java будет работать везде, где установлена виртуальная машина Java , и от вида операционной системы работа приложения не зависит.
Поэтому в плане кроссплатформенности Java будет получше , чем Си.
Что лучше по производительности : Java или С
Как — то так получается, что точно измерить , что будет лучше по производительности — Java или С , — достаточно трудно. Потому что в одних ситуациях это будет С, а в других — Java.
Но в общем принято считать, что приложения на Си будут работать немного быстрее, потому что им не требуется интерпретация. А у приложений на Java много времени уходит на интерпретацию. Но в т о ж е время ВМ Java при интерпретации проводит оптимизацию кода, что увеличивает производительность самой программы. Поэтому может получиться такая ситуация, что код Java будет работать быстрее, чем плохо оптимизированный код на C.
Еще немного небольших отличий между Java и С
- Близость к железу. Си считается более близ ким к оборудованию, чем Java .
- Поиск ошибок. В Java проверка на ошибки происходит в автоматическом режиме, в С программисту придется проверять их наличие.
- Безопасность для памяти. Более безопасным при работе с памятью считается Java, так как она не манипулирует памятью. С — наоборот, способен манипулировать памятью, а значит , страдает ее безопасность при выполнении программ на Си.
Заключение
Информация, которую мы привели, должна помочь ответить на вопрос: « что лучше для вас : Java или С » . Оба эти языка достаточно мощные и имеют широкое применение , чтобы к ним присмотреться. Поэтому если вы стоите перед выбором, что лучше и легче изучить : Java или С, то тут ориентироваться нужно на то, в какой сфере вы планируете программировать. А в плане сложности изучения — они оба н еп ростые языки. Синтаксис у них немного похож, так как Java берет Си за основу. Поэтому имеет смысл изучить один, а потом и другой. В любой последовательности это будет одинаково полезно.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Java против C#: какой язык производительнее в реальных проектах?
Сегодня мы познакомимся с одним опытом, при помощи которого усердный автор, Джефф Когсвелл, попытался рассмотреть производительность кода Java и C# «в реальных условиях». Этот опыт можно считать приглашением к анализу производительности двух языков, ведь полученные автором результаты не претендуют на абсолютную объективность. Но, учитывая соперничество и популярность затронутых в статье языков, надеемся, что материал станет для читателя вкусной пищей для размышлений.
Автор подготовил специальные тесты и решил проверить, какой из этих языков окажется лучше «в реальных условиях»
Давайте сравним Java и C# — два языка программирования, каждый из которых имеет широкий круг поклонников, но вместе с тем и яростных противников. Несмотря на все те прения, которые разворачиваются в онлайне, сложно найти четкие критерии, позволяющие оценить реальную производительность каждого из этих языков.
Какой смысл я вкладываю в понятие «реальный»? Дело в том, что меня не интересует еще один тест, скрупулезно вычисляющий значение числа Пи до миллиона знаков. Я хочу поговорить о решении прикладных задач на языке: какой язык мне выбрать, если требуется ежедневно выдавать клиентам миллионы веб-страниц? Какой из языков сильнее при выборке информации из базы данных и динамической сборке веб-страниц? Именно такая статистика обычно интересует технического специалиста, выбирающего подходящую платформу.
Прежде чем перейти к тестам, давайте определимся с терминологией. Когда вы пишете код Java, вы обычно планируете использовать его на виртуальной машине Java (JVM). Иными словами, ваш код компилируется в байт-код, а этот байт-код работает под управлением JVM. C#, в свою очередь, обычно работает в общеязыковой исполняющей среде (CLR) от Microsoft. C#, как и Java, компилируется в байт-код.
Java и C# — это просто языки. Теоретически вы могли бы писать код Java для исполняющей среды Microsoft CLR, а также код C# для JVM. Действительно, на работу с виртуальной машиной Java ориентирован и ряд других языков, в частности Erlang, Python и др. Самые распространенные языки, рассчитанные на работу с CLR (кроме C#), — собственный язык Microsoft Visual Basic.NET, а также майкрософтовская разновидность C++, называемая C++.NET. Общеязыковая исполняющая среда также поддерживает некоторые менее распространенные языки — уже упомянутый выше Python и F#.
Две эти исполняющие среды содержат фреймворки, представляющие собой наборы классов. Такие наборы для JVM были написаны в Oracle/Sun, а для CLR — в Microsoft. У Oracle есть платформа Java с разнообразными API. Фреймворк Microsoft .NET — это огромный набор классов, обеспечивающих разработку для CLR. На самом деле, многие специалисты называют всю систему просто .NET, а не CLR.
Мы не будем сравнивать языки как таковые. Нас интересуют лежащие в их основе исполняющие среды. Но мы заинтересованы не только и не столько быстродействием этих сред, сколько производительностью фреймворков. Поэтому я выполню несколько сравнений, но в итоге нам все равно придется соотнести яблоки с яблоками.
Например, вы вполне можете написать собственный HTTP-слушатель на C# или Java, а потом просто отправить клиенту динамически сгенерированную HTML-страницу. Но на практике почти никто не пишет низкоуровневых HTTP-слушателей; обычно мы стремимся использовать имеющиеся HTTP-серверы. Большинство веб-приложений на C# работают на базе майкрософтовского сервера IIS.
C другой стороны, серверный код на Java может работать с несколькими разными серверами, в частности Apache HTTP и Tomcat. Кстати, сервер Tomcat был специально разработан для взаимодействия с серверным кодом Java. Мы, конечно, хотели бы сравнивать сопоставимые величины, но в то же время должны сохранить реалистичность эксперимента. Скорее всего, отклик будет зависеть от сервера, а одни серверы работают быстрее других. Хотя HTTP-серверы технически и не входят в состав исполняющей среды, они применяются практически всегда, поэтому их производительность нельзя не учитывать. В первом тесте мы обойдемся без этих стандартных инструментов, а напишем собственные небольшие HTTP-серверы. Во втором случае мы опробуем подобные тесты с аналогичными HTTP-серверами, чтобы получить более точную и полную картину.
Еще одна проблема — это статические файлы, я собираюсь обойтись в данном опыте без них. Некоторые читатели могут со мной не согласиться, но при современных архитектурах, если вам требуется высокая скорость работы со статическими файлами, написанными на JavaScript или CSS, их просто можно загрузить на облачный сервер, данные которого тиражируются во всей стране. Далее по DNS-конфигурации определяем, какой сервер расположен ближе всего к клиенту, и отсылаем данные весьма быстро. Именно поэтому я собираюсь пропустить эту часть. Вдобавок, если вас интересует максимальная производительность, вы не будете нагружать ваше веб-приложение выдачей статических файлов, а постараетесь выполнять в нем только самую необходимую работу: считывание баз данных, сборка динамического контента и т. п.
Замечание об аппаратном обеспечении
Я хочу гарантировать, что применяемое в тестах оборудование привносит в опыт минимальное количество посторонних переменных факторов. На той машине, где я занимаюсь разработкой, стоит масса дополнительных программ, в частности многочисленные сервисы, которые запускаются автоматически и отхватывают процессорное время. В идеале следовало бы выделить под процесс Java или C# целое процессорное ядро, но, к сожалению, выделение ядер происходит иначе. Вы можете ограничить зону действия процесса одним ядром, но не можете «не допустить» в это ядро другие процессы. Поэтому я выделяю для опыта крупные серверы на Amazon EC2, системы которых можно считать базовыми. Поскольку здесь мы не собираемся сравнивать Linux и Windows, а C# ориентирован преимущественно на Windows (если не учитывать проект Mono, который мы и не будем учитывать), все тесты будут выполнены в Windows.
С клиентской стороны требовалось обеспечить, чтобы результаты не искажались из-за сетевых задержек. Единственная задержка могла испортить итоги всего теста. Поэтому я решил исполнять клиентский и серверный код на одной и той же машине. Итак, я не могу «заставить» операционную систему выделять по ядру на процесс, но могу заключить каждый процесс в своем ядре, что я и сделал.
Сбор результатов
Результаты хронометрировались на клиентской стороне. Делая это, лучше всего отследить время и сохранить его, потом по мере необходимости снова отмечать время, и так до конца теста. Лишь по окончании работы выполняются все подсчеты. Кроме того, я не выводил на консоль никаких данных до полного завершения теста. Распространенная ошибка, которую совершают в подобных тестах: в определенных точках отбираются значения времени, в каждой точке подсчитывается разница во времени, после чего результаты выводятся на консоль. Консоли работают медленно, особенно если их требуется прокручивать. Итак, работаем до конца, а потом вычисляем разностные значения и выводим данные на экран.
Клиентский код
Фактически неважно, какой код мы используем в качестве клиентского — важно последовательно задействовать его во всех тестах. Клиентский код будет имитировать работу браузера и измерять, сколько времени требуется на доставку страницы с сервера. Для этого можно использовать C# или Java. Я остановился на C#, поскольку в нем есть очень простой класс WebClient и несложный класс-таймер.
Первый тест: слушание HTTP
Начнем. Мы протестируем код, который просто открывает HTTP-слушатель и рассылает динамически сгенерированные веб-страницы.
Сначала попробуем Java. Мы можем реализовать описанную задачу несколькими способами, но я хотел бы обратить внимание на два подхода. Во-первых, попробуем открыть слушатель TCP/IP на порте 80 и дождаться входящих соединений. Это очень низкоуровневый метод, при котором мы будем пользоваться классом Socket. Другой интересующий нас вариант — использование класса HttpServer. Вот почему я собираюсь воспользоваться этим классом: если мы действительно хотим сравнить скорость Java и C#, без участия Веба, то можно применить некоторые базовые индикаторы, не связанные с работой в Интернете. Так, можно написать два консольных приложения, которые будут оперировать подборкой математических уравнений и, возможно, также выполнять кое-какой строковый поиск и конкатенацию — но это уже другая история. Здесь нас интересует Веб, поэтому займемся HttpServer и его эквивалентом на C#.
Сразу же я обнаружил одну аномалию: выполнение любого запроса в Java-версии длится почти в 2000 раз больше. На обработку 5 запросов при получении строки из CLR-программы, использующей класс HttpListener, ушло около 17 615 тактов процессора, а на 5 аналогичных запросов с применением сервера Java и класса HttpListener было израсходовано 7 882 975 тактов. Если выразить это соотношение в миллисекундах, то имеем 2 миллисекунды на 15 запросов на сервере C# и 4045 миллисекунд на сервере Java.
Добавив на сервер Java некоторую отладочную информацию, я выяснил, что сама функция, занятая ответами на входящие запросы и рассылкой данных, работает довольно быстро — ни разу не приближаясь даже к показателю в 3 секунды. Вероятно, узкое место расположено где-то во фреймворке Java, при отправке данных обратно к клиенту. Но такая проблема отсутствует при обмене информацией с клиентом C#.
Чтобы докопаться до сути проблемы, я решил перейти на другой Java-клиент. Отказался от сравнительно тяжеловесного класса HttpServer, а взамен создал простой сокет, слушающий TCP/IP — для этого воспользовался классом ServerSocket. Вручную создал строку заголовка и основной текст, совпадающий с отправленным в версию на C#.
Ситуация значительно улучшилась. Могу запускать множество тестов; выполняю 2000 запросов один за другим, но не собираю данных о времени, пока не завершатся все 2000 вызовов к серверу Java. Потом осуществляю аналогичный процесс с сервером C#. В данном случае время измеряется в миллисекундах. На 2000 запросов к серверу Java уходит 2687 миллисекунд. На 2000 запросов к серверу на C# тратится 214 миллисекунд. C# по-прежнему гораздо быстрее.
Поскольку сохраняется такая значительная разница, мне ничего не оставалось, кроме как испробовать версию Java на сервере Linux. Я воспользовался сервером «c1.medium» на Amazon EC2. Установил оба упомянутых класса Java и получил фактически такие же скорости. Класс HttpServer тратит около 14 секунд на обработку 15 запросов. Плоховато.
И, наконец, чтобы быть абсолютно уверенным, я написал на Java эквивалентную клиентскую программу, получающую данные. Временные показатели существенно не изменились.
Второй тест: полнофункциональный сайт
Как я уже указывал, мы редко пользуемся самодельными HTTP-серверами. Программисты, работающие с C#, обычно прибегают к IIS. У приверженцев Java есть несколько вариантов, в частности, Tomcat. В моих тестах я использовал именно эти два сервера. В варианте с C# я задействовал платформу ASP.NET MVC 4, работающую на IIS 8. Применил два метода: в первом случае возвращал HTML-строку от самого контроллера; во втором — возвращал представление, содержащее справку даты/времени.
В тестах Java можно применять два похожих метода. Можно работать с сервлетом, возвращающим информацию на HTML, либо возвращать результаты на странице JSP. Эти методы аналогичны приемам C#, в первом из которых задействуется контроллер, а во втором — представление. Можно было бы применить более новые Java Faces или любые другие фреймворки; оставляю эти задачи всем заинтересованным для самостоятельного изучения.
Контроллер C# просто возвращает HTML-строку. При прогоне моего клиентского теста с 2000 итераций на него уходит 991 миллисекунда. Опять же, гораздо быстрее, чем версия с сокетом Java.
Та версия приложения C#, которая работает с представлением, создает полнофункциональную HTML-страницу, соответствующую всем стандартам. Здесь есть элементы HTML, head, meta, title, body и внутренний элемент div, содержащий текст «The date and time is» с указанием даты и времени. Дату и время мы получаем в экземпляре DateTime.Now, динамически записывая эту информацию при каждом запросе.
Прогон клиентского теста (2000 итераций) в такой версии с представлением занимает 1804 миллисекунды; примерно вдвое дольше, чем напрямую. Напрямую мы возвращаем более краткий HTML, но если увеличить HTML до размеров, сопоставимых с вариантом-представлением, разница практически отсутствует; длительность колеблется в пределах 950—1000 миллисекунд. Даже при добавлении динамической записи даты и времени процесс существенно не замедляется. В любых условиях версия с представлением выполняется примерно вдвое дольше, чем версия с контроллером.
Перейдем к Java. Сервлет не сложнее, чем контроллер C#. Он просто возвращает строку, содержащую HTML-страницу. На возврат 2000 экземпляров уходит 479 миллисекунд. Это примерно вдвое быстрее, чем с контроллером C# — действительно впечатляет.
Возврат JSP-страницы также происходит очень быстро. Как и в случае с C#, второй вариант протекает дольше первого. В данном случае на возврат 2000 экземпляров расходуется 753 миллисекунды. Если добавить к JSP-файлу вызов, возвращающий дату, заметной разницы не возникает. На самом деле, на сервере Tomcat явно выполняется какая-то оптимизация, так как в последующих попытках на возврат 2000 экземпляров тратится уже 205 миллисекунд.
Заключение
Эти результаты кажутся мне довольно интересными. Я много лет профессионально занимался программированием на C#, мне неоднократно говорили, ссылаясь на личный опыт, что .NET — одна из самых быстрых существующих сред исполнения. Но эти тесты свидетельствуют об обратном. Разумеется, они минимальны; я не делал никаких крупных вычислений, активных запросов к базе данных. Возможно, я еще проведу тесты с базой данных и уточню результаты. Но в моем опыте Java побеждает с явным преимуществом.
Производительность C++ vs. Java vs. PHP vs. Python. Тест «в лоб»
/update/ Статья обновлена по результатам обсуждения. Поправлен код Python (около 40% ускорения), написан код на Perl и Ruby (но меня терзают смутные сомнения, что с ruby я что-то сделал неправитьно), поправлен код на Java (на моей машине корректнее тестировать int, а не long. к тому же int в Java эквивалентен long в C++).
Вопрос производительности (скорости работы) различных языков часто всплывает в комментариях, на форумах, часто необоснованные :). Встречаются статьи, в которых авторы приводят примеры, где выигрывает реализация на том или ином языке.
После прочтения очередной статьи мне захотелось самому разобраться «здесь и сейчас». Сначала захотелось сравнить Java и C++ (не верил я, что в вычислительных тестах ява может догнать и обогнать cpp). 10 минут и простой код на C++ и яве готов: простой цикл и математические операции. После написания теста подумал и перевёл их на php и python. Позже добавился код на perl и ruby.
Итак, пару слов о тесте:
Алгоритм синтетический, долгий цикл (двухуровневый) и в нём вычисление математического выражения. Таким образом оценивается вычислительная производительность самого языка (интерпретатора или скомпилированного кода), никаких привязок к качеству реализации тех или иных библиотек, никаких внешних сервисов, никаких системозависимых операций (диск, сеть, графика).
1) Мне нравится ява и я честно предполагал, что результаты будут лучше. Обновлено: long в 64-х битных системах работает значительно быстрее. При работе с int в 32-х битных системах Java значительно ускоряется (на моей машине быстрее, чем C++, видимо, JVM оптимизирует исполнение по умолчанию)
2) Я догадывался, что php будет медленней C++ и Java, но не думал, что он окажется быстрее Perl.
3) Предполагал, что Python будет сопоставим с PHP, но ошибся. Видимо, стандартная поставка PHP лучше оптимизирует исполнение кода.
4) Я совсем не знаком с Ruby, код взят из одного из комментариев. Причём использован код 1, так как у меня он работает быстрее чем код 2. Возможно, это также связано с тем, что у меня 32bit-система.
5) Я достаточно уважительно отношусь к различным языкам программирования, эта статья ни одним из углов не нацелена на разжигание холиваров. Каждый язык имеет свою нишу и своих поклонников.
Тесты запускались по 5 раз минимум, чтобы избежать случайных всплесков. Запускались из консоли и как «nice -n -9», то есть с максимальным на данный момент приоритетом в системе.
Чтобы не заставлять вас читать всю статью, сразу приведу краткие результаты.
Диаграмма (обновленная): 
Старый вариант здесь
На диаграмме слолбец с Ruby частично прозрачен по причине того, что на моей машине скрипт Ruby исполнялся неприлично долго, в то время как в комментарии указано, что скрипт исполняется в 4 раза быстрее скрипта на Python — я в замешательстве.
Столбец с Python прозрачен, так как при включении psyco скрипт ускоряется более чем в 10 раз. Проверил на своей машине. Но это, с моей точки зрения, хак, не отражающий собственную производительность языка.
Столбец с PERL, как могут заметить старожилы, теперь идёт вровень с Python 2.6. Причиной этому послужила смена кода с C-подобного синтаксиса на использование range. Дополнительную производительность (около 12%) можно получить использовав директиву «use integer;», но это, по-моему, тоже хак.
Добавлен столбец с запуском Java-кода с ключём «-server». После перехода с «long» на «int» (повторюсь, int в java такой же как и long в c++ на 32bit-arch) он начал давать прирост в производительности почти вдвое.
Столбец с Ruby 1.9 на моём железе не тестировался, результат перенесён через сравнение с производительностью Python’а на той же машине.
И, чтобы не быть голословным, тестовый код.
Java, Test01.java (int в Java то же что и long в C++):
Python, Test01.py (вынос кода в функцию ускоряет работу кода почти вдвое, отдельная же инициализация range() на моей машине даёт порядка 5% производительности):
Perl, Test01.pl (обновлено, с range работает на 25% быстрее против c-подобного синтаксиса for):
Вот здесь приведён красивый пример на Perl, но, мне кажется, такой вариант уже слишком специфичен.
Вот здесь в комментариях обсуждают решение на erlang.
Как видите, ничего сложного: два цикла и математическое выражение. Вычислительная задача в чистом виде.
мой оригинал — там старая версия статьи, а также информация об версиях использованного ПО и результаты тестов из консоли.
Ещё раз повторюсь: каждый язык имеет свою нишу, своих поклонников и свои задачи, с решением которых он справляется лучше других.
PS: а вообще, нет смысла загоняться и меряться чем бы то ни было, производительность самого языка важна для достаточно узкого круга задач, т.к. в общем случае, системы, библиотеки и прочая обвязка нынче несоизмеримо тяжелее самой вычислительной задачи.