Почему C быстрее Java (с точки зрения Java-разработчика)
В листе рассылки Git развернулась дискуссия о том, как язык программирования высокого уровня снижает производительность приложения, в связи с обсуждением JGit. Дискуссия особенно интересна, потому что в ней принимали участие программисты, эксперты высочайшего уровня как в C, так и в Java. Один из них — Шон Пирс (Shawn O. Pearce), известный Java-программист из компании Google, активный коммитер в Eclipse, соавтор Git и автор Java-имплементации Git под названием JGit. В своём сообщении он назвал реальные ограничения, с которыми сталкивается высококвалифицированный разработчик, пытаясь написать эффективный Java-код, сравнимый по производительности с максимально оптимизированным кодом C. Хотя письмо датируется апрелем 2009 года, но некоторые аргументы Шона до сих пор не потеряли актуальность.
List: git
Subject: Re: Why Git is so fast (was: Re: Eric Sink’s blog — notes on git,
From: «Shawn O. Pearce»
Как было сказано ранее, мы сделали много маленьких оптимизаций в коде Git на C, чтобы добиться реально высокой производительности. 5% здесь, 10% там, и внезапно ты уже на 60% быстрее, чем был раньше. Нико [Питре], Линус [Торвальдс] и Джунио [Хамано] — все они потратили определённое время в последние три-четыре года для оптимизации отдельных фрагментов Git, исключительно для того, чтобы он работал максимально быстро.
Языки программирования высокого уровня в определённой степени скрывают машину, так что мы не можем проводить все эти оптимизации.
Например, JGit страдает от отсутствия mmap() , а при использовании Java NIO MappedByteBuffer, нам всё ещё нужно делать копию во временный массив byte[] , чтобы получить возможность реальной обработки данных. В Git на C нет такого копирования. Конечно, в других языках высокого уровня метод mmap может быть поудобнее, но все они также склоняются к сборке мусора, и большинство языков пытаются связать управление mmap со сборщиком мусора «для безопасности и простоты».
JGit страдает также от отсутствия unsigned типов данных в Java. Есть много мест в JGit, где нам действительно нужен unsigned int32_t или unsigned long (машинное слово максимального размера) или unsigned char , но эти типы данных просто отсутствуют в Java. Преобразование байта в int, просто чтобы представить его как unsigned, требует дополнительной операции & 0xFF для обнуления sign extension.
JGit страдает от отсутствия эффективного способа представить SHA-1. В коде C можно просто написать unsigned char[20] и сразу скопировать строку в память к контейнеру. В Java byte[20] будет стоить дополнительно 16 байт памяти, и доступ к ним будет дольше, потому что сами эти байты находятся в другой области памяти от контейнера. Мы пробуем обойти это за счёт преобразования из byte[20] в пять int’ов, но это стоит дополнительных машинных инструкций.
Git на C принимает за данность, что операция memcpy(a, b, 20) предельно дёшева при копировании содержимого памяти из дерева (inflated tree) в объект структуры. В JGit приходится платить большой штраф за копирование этих 20 байтов в пять int’ов, потому что позже эти пять int’ов обходятся дешевле.
В других языках программирования высокого уровня тоже отсутствует возможность пометить тип как unsigned. Или заставляют платить похожие штрафы за хранение 20-байтного бинарного массива.
Нативные для Java коллекции (collection types) стали для нас настоящей ловушкой в JGit. Мы использовали типы java.util.* в удобных случаях, и вроде бы почти решили проблему со структурой данных, но они, как правило, работали гораздо хуже, чем запись специализированной структуры данных.
К примеру, у нас был ObjectIdSubclassMap для того, что должно было выглядеть как Map . Только он требовал, чтобы тип Object, который вы используете как «значение», происходил от ObjectId, поскольку данное представление объекта работает одновременно как ключ и как значение. Это вызывает настоящий кошмар при использовании на HashMap . (Если кто не знает, ObjectId — это JGit’овский unsigned char[20] для SHA-1).
Как раз пару дней назад я написал LongMap , более быстрый вариант HashMap , для хэширования объектов по индексам в упакованном файле. Здесь то же самое, стоимость упаковки в Java для конвертации long (самого большого целого) в объект, пригодный для стандартного HashMap типа, была довольно высока.
И сейчас JGit по-прежнему работает медленнее, когда речь идёт об обработке коммита или объекта дерева, где нужно следить за связями объекта (object links). Или когда происходит вызов inflate() . Мы тратим гораздо больше времени на эти процедуры, чем делает git на C, хотя мы пытаемся спуститься как можно на более низкий уровень, насколько вообще позволяет byte[] , избегая копирования чего бы то ни было и избегая выделения памяти, когда только возможно.
Что характерно, JGit выполняет операцию rev-list —objects –all примерно вдвое дольше, чем это делает Git, на проекте вроде ядра Linux, а index-pack для файла размером около 270 МБ тоже длится примерно вдвое дольше.
Обе части JGit настолько хороши, насколько у меня хватает знаний для их оптимизации, но мы реально находимся во власти JIT, и любые изменения в JIT могут привести к ухудшению (или улучшению) наших показателей. В отличие от Git на C, где Линус Торвальдс может менять целые фрагменты кода на ассемблере и пробовать разные подходы.
Так что да, есть практический смысл в создании Git на языке высокого уровня, но вы просто не сможете получить там такую же производительность или строгий расход памяти, как у Git на C. Вот чего вам стоят абстракции высокоуровневого языка. Однако, JGit работает вполне нормально; достаточно быстро для того, чтобы мы использовали его как как сервер git внутри Google.
P.S. Сообщение Шона Пирса написано в 2009 году и автор не учитывает изменений, сделанных в Java 1.7. Например, Java сейчас использует escape analysis, чтобы избежать резервирования памяти в куче, когда это возможно.
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 | Java -server | C++ | C++, -O2 | PHP | Python 2.6 | Python 3.1 | Perl 5.8 | Ruby 1.8 | Ruby 1.9(?) |
| Время исполнения, сек | 5,3 | 2,8 | 8,5 | 2,6 | 62 | 91 | 145 | 91 | 207 | ~30 |
| Производительность, % | 160 | 303 | 100 | 327 | 14 | 9 | 6 | 9 | 4.11 | 28 |
Время исполнения — на P4-1.8Ггц.
Производительность — относительно производительности базового кода на C++.
Добавлен столбец с запуском Java-кода с ключём «-server». После перехода с «long» на «int» (повторюсь, int в java такой же как и long в c++ на 32bit-arch) он начал давать прирост в производительности почти вдвое.
Столбец с Ruby 1.9 на моём железе не тестировался, результат перенесён через сравнение с производительностью Python’а на той же машине.
И, чтобы не быть голословным, тестовый код.
Java, Test01.java (int в Java то же что и long в C++):
package ru.dchekmarev.test.performance;
public class Test01 public static void main(String[] args) // long start = System.currentTimeMillis();
int r = 0;
for ( int i = 0; i < 10000; i++) for ( int j = 0; j < 10000; j++) r = (r + (i * j) % 100) % 47;
>
>
System.out.println( «answer: » + r);
// закомментировано, т.к. замеры делаются из командной строки
// System.out.println(«run time (millis): » + (System.currentTimeMillis() — start));
>
>
Python, Test01.py (вынос кода в функцию ускоряет работу кода почти вдвое, отдельная же инициализация range() на моей машине даёт порядка 5% производительности):
def test():
r = 0
for i in range(0, 10000):
for j in range(0, 10000):
r = (r + (i * j) % 100) % 47
test()
print ( «answer: » , r)
Perl, Test01.pl (обновлено, с range работает на 25% быстрее против c-подобного синтаксиса for):
$r = 0;
# старый вариант, C-подобный синтаксис
# for ($i = 0; $i < 10000; $i++) # for ($j = 0; $j < 10000; $j++) <
for my $i (0..9999) for my $j (0..9999) $r = ($r + ($i * $j) % 100) % 47;
>
>
print «answer: $r\n»;
Вот здесь приведён красивый пример на Perl, но, мне кажется, такой вариант уже слишком специфичен.
r = 0
for i in 0..10_000 do
for j in 0..10_000 do
r = ( r + ( i * j ) % 100) % 47
end
end
puts «answer: #»
Вот здесь в комментариях обсуждают решение на erlang.
Как видите, ничего сложного: два цикла и математическое выражение. Вычислительная задача в чистом виде.
мой оригинал — там старая версия статьи, а также информация об версиях использованного ПО и результаты тестов из консоли.
Ещё раз повторюсь: каждый язык имеет свою нишу, своих поклонников и свои задачи, с решением которых он справляется лучше других.
PS: а вообще, нет смысла загоняться и меряться чем бы то ни было, производительность самого языка важна для достаточно узкого круга задач, т.к. в общем случае, системы, библиотеки и прочая обвязка нынче несоизмеримо тяжелее самой вычислительной задачи.
Какой язык имеет большую производительность: Javа vs C
Java и C — это два мощных и популярных языка. В большинстве случае в и нтерпретируемые языки, такие как Java , работают чуть медленнее, чем неинтерпретируемые, такие как С. Однако не всегда верх берет производительность. Разрабатывать на Java в большинстве случаев будет стоить намного дешевле, чем на С, хотя бы потому , что разрабатывать нужно будет только одну программу, а не несколько одинаковых, но под разные операционные системы.
При это м д ля конечного пользователя разница в производительности между программой на Java и программой на C заметна не будет. Во-первых, потому что сама разница состоит в долях секунд ы или нескольких секундах, что для пользователя незаметно. Во-вторых, потому что у конечного пользователя на производительность программы влияют дополнительные факторы, например , ресурсная мощность его устройства или скорость подключения интернета.
Таким образом, большинство разработчиков приходит к тому, что , раз разница по времени производительности небольшая, конечный пользователь эту разницу не видит, а разработка на Java стоит дешевле, поэтому и выбирают разработку на Java. Это утверждение верно для тех случаев, когда в разработке не нужно использовать специфические возможности языка С. Например, если разрабатывать новую операционную систему, ядро операционной системы, драйвер для операционной системы или приложение, в котором нужно напрямую воздействовать на память или ядро компьютера, тогда тут выбор однозначно остановится на языке С, потому что Java не справ ится с такими задачами.
Поэтому сравнивать производительность и выбирать между «Java vs C» нужно по ситуации.
Заключение
Производительность « Java vs C » — это условность , которая не всегда влияет на выбор языка для разработки. Java позволяет быстро и «дешево» разработать достаточно быстрое приложение. За это и любят данный язык, хотя он обладает своеобразными минусами и , по сравнению с С , иногда уступает в производительности.
Язык С любят за стабильность, надежность и устойчивость к нагрузкам. На нем сложнее, дольше и «дороже» писать, чем на Java , о днако этот язык способен выполнить то, что Java не под силу.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.