Pull to refresh

Comments 92

Все рассказы о производительности java натыкаются на одну смешную истину: на java не написано ни одного более-менее вменяемого браузера. Вот когда напишут — вот тогда можно будет посмотреть, кто быстрее. Без всяких кивков в сторону gc, "неправильно готовят" и т.д.
До этого момента java идёт в одном ряду с другими "песочными" языками класса перла, питона, руби и т.д., которые хороши для мелкоприкладной разработки но совершенно не готовы к системам с требованиями высокой производительности.
Количество браузеров, написанных на той или иной платформе — это очень странная метрика популярности. Последние лет 10 речь в мире идет про серверную Java, поэтому я плохо понимаю, что вы тут такое вообще написали :)
На чистом С и фортране тоже ни одного браузера.
UFO just landed and posted this here
на java не написано ни одного более-менее вменяемого браузера

А можно список языков, кроме С++, на которых написаны более-менее вменяемые браузеры? Насколько я знаю, на D, Go, Rust тоже не написано ни одного вменяемого браузера, тоже производительность виновата? Всех популярных вменяемых браузеров штук пять-шесть, наверное, да и то большая часть клоны друг друга.
Автор комментария выше, скорее всего пенял на производительность GUI Java приложений, в частности, популярных IDE. Я с ним согласен, работаю только в vim или sublime, т.к. IDE на Java для меня очень прожорливые, жрут ресурсы как игры 2008 года. Тот же Sublime с плагинами под IDE работает в разы быстрее как с обычными задачами, так и с задачами с файловой системой и с сетью.
IDEA жрет много ресурсов из-за умных автоподстановок и прочих умных плюшек, При желании можно все отключить, но тогда главные плюсы IDEA теряются.
UFO just landed and posted this here
а ещё можно разрабатывать на компьютере мощнее чем микроволновка
UFO just landed and posted this here
Справедливости ради, микроволновка — достаточно мощный прибор, впрочем, как и чайник… :)
ладно, а сколько на java написано 3d движков? сколько HFT систем в бекенде исползуют java? вы видели GUI которые написаны на java и которые тормозят? мне неизвестны числодробилки/реал-тайм (привет GC) приложения на java, в основном java исползуется для написания приложений которые большую часть времени ждут I/O (диск/сеть), если я не прав, прошу меня поправить :)
По моему скромному мнению java популярна по причине легкости обучения и относительной сложностью выстрелить себе в ногу.
P.S.
Есть проект Cassandra DB переписанной на C++ (http://www.scylladb.com/), так авторы заявляют о 10х кратном приросте производительности.
ладно, а сколько на java написано 3d движков?

достаточно
мне неизвестны числодробилки/реал-тайм

а их много, научные числодробилки, базы данных и nosql хранилища, поисковые системы, машинное обучение и нейроные сети и т.п.
привет GC

Есть специальные JVM для реал-тайм, где нет остановки мира от слова совсем
Есть проект Cassandra DB переписанной на C++ (http://www.scylladb.com/), так авторы заявляют о 10х кратном приросте производительности.

Ну, так то авторы, они и стократный прирост заявят. Если бы так просто было бы получить такой прирост никто бы даже не начинал писать Cassandra DB и ей подобные базы данных на Java. Опять-таки Hadoop и прочий BigData это как раз числодробилки.

P.S. Естественно, у Java тоже есть предел и для ряда задач C и С++ будут лучше, тем не менее есть очень много задач (в том числе по обработке данных) в которых разница между производительностью Java и C++ не так существенна, как разница в затраченных ресурсах разработчкиов. Собственно есть ряд задач где С лучше С++, а есть где рулит только ассемблер.
Да-да, играл я в игрушки на Jave. Тот же Wurm-онлайн. Графика середины 2010-х, а ресурсы кушает как последний фаркрай.
Есть и другие проекты на Jave — Salem Online, Hafen — у всех у них БОЛЬШИЕ проблемы с графикой и очень большие с прожорливостью.
Так что, про триДэ на яве — не надо, нет его вменяемого.
.Net? Та же Java только в профиль. Очень активно используется в игроиндустрии.
достаточно

Справедливости ради 3d движков по ссылки три, а успешных в лучшем случае полтора. А пригодных для игр AAA-класса — ноль.
Есть специальные JVM для реал-тайм, где нет остановки мира от слова совсем

Есть с предсказуемой задержкой (до 1мс). При этом Oracle разработку таких версий свернул в 2012, а у других вендоров версия JVM в лучшем случае седьмая (у IBM), а то и вообще шестая (JamaicaVM). Плюс версии эти дорогии, так что для ускорения работы уютненькой питерской Идейки подходят слабо. А тем у кого есть деньги зачастую проще взять сишника с опытом.
Если бы так просто было бы получить такой прирост никто бы даже не начинал писать Cassandra DB и ей подобные базы данных на Java.

Ну, Майнкрафт же написали.
Опять-таки Hadoop и прочий BigData это как раз числодробилки.

Тут нужно понять, что вы понимает под числодробилками. Я думал это скорее всякие аудио/видео кодеки, архиваторы, всякие мат. библиотеки. Тут плюсы и фортран все-таки вне конкуренции.
http://lessthanoptimal.github.io/Java-Matrix-Benchmark/runtime/2015_07_XeonQuad/
http://stackoverflow.com/questions/529457/performance-of-java-matrix-math-libraries

Другое дело что мне не известно ничего написанного не на C++/C/Fortran, что работало бы быстрее. Хотя нет, вру CLR имеет первый старт субьективно побыстрее, в остальном у него даже скорость GUI не лучше, хотя GUI у него некроссплатформенный и гвоздями прибит к WinAPI. А объяснение простое — нулевая стоимость абстракций — это не пустой звук, а здесь у "сей" ("плоских" и с "крестами") конкурентов пока нет. В теории Rust еще может к ним может когда-нибудь добавиться. При этом Rust объективно сложнее Java.
Справедливости ради 3d движков по ссылки три, а успешных в лучшем случае полтора. А пригодных для игр AAA-класса — ноль.

Ну из той же справедливости, если верить вики , то на чем-то кроме C++/C движков практически и нет (в частности в списке нет ни Go, ни D, ни Rust). Вообще это не совсем правильный критерий, использование ЯП в какой-то области далеко не всегда зависит от производительности и возможностей языка, основное все-таки наличие уже готовых разработок, большого количества разработчиков и т.п. Нечестно же сравнивать, например, кол-во игров для Андроида на Java и других языках, потому что понятно что у Java будет преимущества нативного ЯП.
аудио/видео кодеки, архиваторы

Ну, кстати нет, такие задачи тоже не числодробилки. Были у меня подобные задачи на Java, там тоже все упиралось в скорость диска, то есть пока архивированный поток читается/пишется, его успевают и разархивировать и обработать и заново заархивировать в параллельном потоке и ещё полно времени остается.
P.S. Я не спорю, задачи где производительности Java может не хватить бывают, но их не так много как кажется, в большинстве случаев все (базы данных, кодеки, архиваторы, биг дата) всё равно чаще упирается в скорость диска или сети, то есть тормозит в первую очередь от кривой архитектуры или кривых рук.
Я на каждом языке, который начинаю изучать, пишу задачу вычисления простых чисел (алгоритм по определению). Чистой воды числодробилка получается. Так вот, сравнение скорости с другими языками:
Java: Delphi -> 2: 1 (Intel), 6: 1 (AMD Vishera)
Java: C# -> 1: 1.25 (Intel), 1.75: 1 (AMD Vishera)
Обратите внимание на разницу при смене архитектуры. Не видел, чтобы кто-то сравнивал скорость одного кода на нескольких разных машинах, а это важно. Тестят всё на эталоне. JIT даёт огромное преимущество в сравнении с заточенным под одну архитектуру нативным кодом.
справедливости ради
суперуспешный майнкрафт написан на джаве, все волками выли от тормозов, пишут патчи для оптимизации, но играют
У вас с аргумента жЫр стекает.
все ваши аргументы рассыпаются после поверки IDE.
Все лучшее, что есть — построено на опыте IntellijIDEA, пупсик
И тормозит на больших проектах, как бы я не обожал Clion
Тормозит потому что в IntellijIDEA очень умная система автоподстановок и т.п. умных штук, IDEA очень часто догадывается о том что хочет программист, но это сжирает дофига ресурсов. Поотключать это можно и тормозить не будет, другое дело что это практически главное преимущество этой IDE. Тут несколько некоректно сравнивать IDEA с просто продвинутыми редакторами, так как в них всех умных штук просто нет.
Да ладно. KDevelop и Qt Creator предлагают +- тот же самый набор фич.
Там не в фичах дело, не знаю насколько это явно в Clion, но в Java IDEA умудряется практически угадывать что сейчас напишет программист и давать умные подстановки имен, типов и методов, что дико облегчает разработку, ни в одной другой IDEA такого удобства не видел. ИМХО, я вполне понимаю на что уходит производительность и меня такая "цена" вполне устраивает (лучше я куплю более дорогой комп, но буду на 20% продуктивнее, чем наоборот).
И как это реализовано? Магией или всё-таки фичами?)
У меня само написание кода занимает не такой большой промежуток времени. Конечно иногда доводится строчить код практически безостановочно, но в среднем у меня ощущение, что тобы ускориться на 20% надо чтоб код набирался сам и мгновенно.
Кроме того, особо крупные проекты там тормозят(тормозили?) даже на топовой конфигурации. И что? Двухпроцессорник собирать? На ноуте даже не мечтать IDE запустить?
Если холиварить, то на С++ оно наверняка бы не тормозило. Я уверен. Если холиварить с самим собой, за те же деньги и время на С++ подобное написать наверняка невозможно. Что возвращает нас к вопросу о том, что у каждого языка своя ниша, и утверждение Java круче C++ (как и обратное) смысла не имеет. Но любой кулик, как известно, своё болото хвалит...
а вы сколько багов против них завели?
Завел в основном фич реквесты, под багами комметирую, привожу способы воспроизведения, etc.
На протяжении всего интервью подчеркивается то, что, чтобы Java была по-настоящему высокопроизводительной ее нужно тонко настраивать под каждую конкретную систему, что неприемлимо для десктоп-приложений.
Где вы такое увидели? Как раз наоборот, Java имеет преимущество перед нативным кодом в плане подстраивания под систему. Смотрите мой коммент выше.
Нужно понимать, что джава занимает свою нишу и не предоставляет программисту низкоуровневых фич для написания браузеров или ОС. Хотя тенденции идут к тому, что в 10-ке (думаю конец 2017 года уже будут тестовые сборки) программисты получат низкоуровневые фичи. Вплоть до инлайна машинных кодов в методы классов и дешевый вызов функций из нативных библиотек. Что сделает реальностью написание браузера на джаве.
А ставить на один уровень джаву с перлам и питонами — попахивает любительством в области разработки ПО. Я бы вас еще понял, если сравнение шло с Go, D или подобными ЯП.
Зато на java написан Elasticsearch, который мы сейчас используем на большом кластере. Ничего, работает, я бы сказал отлично :) Можете сказать, что если переписать его на, то мы сэкономили бы парочку серверов. Но нет, он есть только на джаве.
Хотел сказать "переписать его на ваш любимы язык"
UFO just landed and posted this here
Кстати, это на десктопе нет, а как же J2ME (земля пухом) и андроид? Не знаю как на андроиде, там всё-таки можно взять C/C++, но J2ME? А как же Opera Mini? Там было даже немного яваскрипта :D
Да ей наверно до сих пор пользуются. И это на кирпичиках с около 2мб хипа. Как раз "более-менее вменяемый браузер" на java :)
и давно у вас браузер — мерило всего? Вообще, налицо недопустимая для технически грамотного человека подмена понятий
не написано браузера — значит почему-то «не готовы к системам highload»

при этом куча бирж работает на java, есть такие вещи как disruptor и chronicle, люди умеют обрабатывать миллион сообщений в секунду на этой самой яве, а вы явно не в теме. Сайт LMAX-exchange вам в помощь.

Последний раз, когда я видел высказывание «на яве нельзя работать с финансами», это было в блоге чувака, который… нигде сам не работает, а свои сведения почерпнул, сходив на интервью в фирму, где на яве таки работали с финансами.

И вообще это просто язык.
Уже запущенное и некоторое время работающее приложение на Java может и не очень медленно работает. Сложно сравнивать если не иметь полного аналога написанного на другом языке. Но когда мне надо провести некую операцию, которая займет 1 минуту, а для этого надо 1 минуту подождать пока запустится JVM и поднимет это самое приложение — это полный маразм. Поэтому любые десктопные приложения на Java по возможности идут в лес. А серверные… с серверными проблема не столько с производительностью, сколько с прожорливостью. Мелкое ненагруженное приложение, которое по идее должно спокойно жить на виртуалке с 128Мб памяти внезапно начинает требовать в 3-4 раза больше только из-за того оно на Java, а не на C++.
Всё зависит от задач, но в большинстве серверных случаев, такие затраты на память с лихвой окупаются простотой разработки и лёгкостью поддержки.
Легкость поддержки — это, видимо, со стороны разработчика. Ибо со стороны админа таки поддерживать в живом виде проект на джаве намного сложнее, чем проект на… на чем угодно другом. А простота разработки — это не моя проблема. Мне не важно на сколько было сложно написать софт, который компания купила и мне теперь его надо хостить.
Почему столько минусов? Всё же чистая правда. JRE уже много лет шпыняют за очень медленный старт. .NET решает эту проблему продуманной модуляризацией и оффлайн компиляцией модулей. Что же касается Java, то сначала Sun, а теперь Oracle только обещают. Поэтому GUI приложения и не пишут на Java, несмотря на весьма хорошую кроссплатформенность: юзер не будет ждать 3-5 секунд после клика на иконку приложения.
С памятью получше, аккуратным тюнингом можно добиться разумных цифр, но до С++, конечно, далеко.
Это вы у меня спрашиваете? ;)
3-5 секунд? Хм… я не заметил, чтобы мои Java-окна так тормозили, да и вообще не заметил, чтобы тормозили. Что я делаю не так?
JVM стартует 0.2-0.5 секунд с обычного HDD. Вспомним хабрасоревнование от BarsMonster. Это Java и как раз быстрая вычислительная задача. Люди соревновались из доли секунды (это включая старт JVM). Парень на третьем месте каждый тест впихнул в 0.23 секунды. Поэтому пассаж про одну минуту мне абсолютно непонятен.
Я не тестами занимаюсь. Я сеть с тремя сотнями юзеров поддерживаю. И вижу, что таки если приложение написано на джаве, то оно стартует (что на маке, что под виндой) в разы, если не на порядки, дольше, чем если оно нативное. Такова жизнь.
А что за приложения?
Просто приложения на джаве обычно гигантские: IDE-шки всякие, сервера приложений. А нативные приложухи обычно поменьше. И они обычно несоизмеримы: если бы какая-нибудь нативная IDE обладала всеми возможностями джавовой, то не факт, что она запускалась бы быстрее. Так-то студия тоже долго стартует, хоть и не на джаве.
Таки да, сложно сравнивать разные аппликушки. У меня тут по роду занятий не IDE и не сервера приложений, а всякие научные аппликушки. Каждая — единственная в своем роде. И все тормознутые до жути.
Хотя, конечно, нельзя сбрасывать со счетов вероятность, что их всех пишут левой ногой. По крайней мере багов в них море.
За плечами имею богатый опыт разработки на различных языках и могу абсолютно точно сказать что большинство проблем производительности связано с банально неоптимальным кодом на уровне работы с данными. Причем, такие «косяки» не зависят от языка.
Что интересно, именно такие горе-программисты первыми начинают искать выход в «волшебных» параметрах виртуальных машин, настройках GC и прочих подкапотных настройках.
И других стеках технологий)
Диагностировать проблемы к сожалению редко кто пытается. По тыку пальца хотят решение. Беда не только программистов.
Было бы интересно узнать о сравнении производительности JVM и CLR. Преимущества и недостатки, узкие места обоих.
Если коротко, то в большинстве простых сценариев — одинаково. В сложных Java Runtime посильнее — JIT мощнее гораздо. Банально, в него гораздо больше сил вложено.
Есть еще вариант .NET с нативной компиляцией, но там тоже пилить и пилить. И натив и RyuJIT — пока сырые. Там несколько лет работы еще нужно.
но есть вариант с C# unsafe: берешь и оптимизируешь руками :)
кстати, отстутствие техники динамической деоптимизации как HotSpot'e компенсируется тем, что все методы по-умолчанию в C# — невиртуальные, а при нехватке мощного инлайнера — ручное указание методов для этих целей.
В общем, решения есть..
да, про невиртуальность — сущая правда. В HotSpot для этого сделали спекулятивную оптимизацию: если рантайм видит только одну реализацию метода и не видит overrid-а, то он считает, что метод — невиртуальный (финальный) и генерит оптимальный код. Если же в какой-то момент приходит другая реализация того же метода, то HotSpot делает доептимизацию.
Учитывая, что IL сам по себе намного продвинутее Java байткода — c custom value types, не участвующими в сборке мусора, true generics без приведения типов, unsafe блоками кода с прямой манипуляцией указателями — я не понимаю, как JVM изначально может быть сильнее. На чем основано ваше утверждение?
UFO just landed and posted this here
в Java каждая вещь, связанная с выравниванием памяти, должна поддерживаться JVM.
Так в .NET (и это не сахар C#'a) можно спокойно выранивать структуры, чтобы предотвратить False Sharing.
Для Java пришлось ждать аннотации @Contended.
Oracle полировал VM

Это да. И сил много было брошено. Однако не все так гладко. Тот самый кейс с False Sharing'ом до 2011 года мог вызывать проблемы при маркировке объектов для GC.
Этим .NET перестал страдать, начиная c .NET 2.0 (а это 2006 год).
CLR Windows only. Преимущество это или недостатки каждый решает сам.
Честно говоря, не понимаю, почему все так агрессивно минусуют аргументы выше? За ними кроется вполне очевидная чья то боль, хоть и развернуты они не совсем полностью.
Ни в коем разе не пытаюсь судить что лучше/хуже, но есть один простой факт, который меня очень давно озадачивает: Задумайтесь, про любой иной язык/платформу кроме как Java/JVM, вы видите СТОЛЬКО выступлений, статей, размышлений, документации про супер-флаги (1200 штук, прекрасно), единственная цель которых это оптимизация?
Так может быть это свидетельствует о развитом коммьюнити?
И о существующей и ни кем не отрицаемой проблеме.
Забавно, вас тоже минуснули, видимо не всеми настолько не отрицаемой. :)
Хотя вот например общаясь со знакомыми Java разработчиками, слышу от них что они правда не видят никакой необычности во всём этом.
Нет, совсем логично, я забыл упомянуть, что я имел ввиду конкретно desktop приложения, за что скорее всего и словил минусов. Чуть выше мы с товарищем обсуждали именно desktop приложения на java, на примере IDE. А так мой комментарий действительно выглядит как троллинг.
Ммм, то есть вы понимаете, что этим утверждением, автоматически утверждаете и что все остальные коммьюнити развиты меньше? Если не секрет, а насколько меньше они развиты?
UPDATE: Ладно, извиняюсь, не хочу начинать здесь святых войн, но мне правда интересно отношение коммьюнити Java к 1200 флагам для отладки оптимизации.
Они развиты меньше в разы. В Европе и странах СНГ существует примерно десяток больших Java-конференций: Devoxx, JavaZone, JFokus, JavaLand, Geekout, Geekon, JEEconf, Joker, JPoint.
Можете ли вы назвать какие-нибудь европейские Community-driven конференции по C/C++, Python, Ruby, .NET или любой другой конкретной технологии, собирающие например, по тысяче человек?
Нашел сайт Lanyrd, конечно не самый точный подсчет, не знаю я размеров конференций, да и попадаются мультинаправленные конференции, но цифры интересные:
http://lanyrd.com/topics/javascript/ — past events: 1994.
http://lanyrd.com/topics/ruby/ — past events: 863.
http://lanyrd.com/topics/java/ — past events: 769.
http://lanyrd.com/topics/python/ — past events: 795.
http://lanyrd.com/topics/net/ — past events: 323.
О, спасибо за ссылки! Это интересно, на самом деле. Показывает тренды. Хотя больших конференций там мало.
Мультинаправленные большие есть, но на них много разных технологий.
По поводу JavaScript — да, это действительно самое быстрорастущее сообщество. Очень много фреймоворков и направлений, у каждого — свое сообщество :)
Дело даже не в конференциях, а скорее в том, что вбив в гугл вопрос практически любой сложности по джаве, можно за пару минут найти ответ, а чаще несколько и с примерами кода. На любой чих есть документация, сотни тысяч библиотек от именитых компаний вроде того же гугла или племени апачей, готовых решать за программиста (почти) любые проблемы.
В той или иной степени все это есть и в других языках, но никогда не видел чего-то настолько обширного, исключительно по своим наблюдениям.
но мне правда интересно отношение коммьюнити Java к 1200 флагам для отладки оптимизации.

Во-первых, большинство экспертов сходятся что реально нужных флагов 5, максимум 10. Во-вторых, это равносильно тому что говорить раз в Linux (условно) выходит много фиксов безопсности — она дырявая OC, а в Win (условно) мало фиксов — она супернадежная. Хотя может быть ровно наоборот, те кто забили на безопаснсоть не выпускают фиксы в принципе.
Если в каком-нибудь Visual Basic'e или PHP первой версии никто не обсуждал оптимизация, это не потому что они были супер быстрыми, а потому что не было смысла что-то оптимизировать. В случае решение вроде Hadoop'а на сотню кластеров оптимизация даже на 10% даст минус 10 серверов, вполне логично что оптимизация важна. То есть вопрос вовсе не в том что JVM медленная, вопрос в том что оптимизация JVM дает вполне реальную прибыль...
Но вы же понимаете, что все эти флаги не с потолка взялись, они кому-то понадобились. Кто-то таки наступил на грабли, прошел все корнер-кейсы, тестил java на таких нагрузках, которые есть лишь у десятка компаний во всем мире. Некоторые флаги позволяют jvm-инженерам отлавливать такие concurrency-баги, которые встречаются у 1 пользователя из миллиона. И, в отличие от многих других платформ, эти баги действительно фиксят.

Пойнт в том, что такое количество флагов свидетельствует о взрослости платформы (Возьмем к примеру GCC, "wc — l" показал 2500+ флагов).
А то, что про эти флаги говорят и рассказывают — как раз эффект очень развитого коммьюнити.
Каждый язык хорош на своем месте и для своих задач.
В Оракле тоже были сотни параметров. Потом в процессе матерения их количество уменьшалось.
Он становился все более самонастраивающимся.
В идеале ни у сервера БД, ни у ОС, ни у Джава машины параметров быть не должно.
Она сама должна себя оптимизировать и настраивать. Наверное Джава к этому когда нибудь придет.
идет. все движется в сторону сложных эвристик.
а потом сингулярность и сильный ии. и все)
Думаю, дело в том, что если лабать самый простой и идеоматичный Java-код, он будет довольно неторопливым. Этому способствует стандартная библиотека, которая щедро аллоцирует развесистые объекты и копирует память с места на место. Как результат — 95% Java-кода работает медленно. Когда происходит затык, люди идут в Гугл или на конференции изучать производительность.
С другой стороны, на Java можно писать очень быстрое ПО, но так почти никто не делает, потому что выходит едва ли проще, чем писать на том же C++.
Некоторые пишут, что на C++ то же самое: простой код программистов "от сохи" очень неэффективный. Я не согласен с этим: стандартная библиотека C++, общая идеоматика и паттерны гораздо экономичнее, чем в Java.
Да будет срач! Забудем о том, что у каждого языка своя ниша и будем кричать "Жаба тормозит!!!11!!" и "С++ сложна! Java быстрее ассемблера если правильно прогреть JVM!!!111!".
Если вы думаете, что фраза про нишы отменяет любые аргументы, это не так. Нишы эти пересекаются и на задачах, попадающих в пересечения, вполне можно производить сравнения.

Вполне может, например, оказаться, что ниша языка N полностью покрывается языками M и P (или даже одним M), причем M и P превосходят язык N в соответствующих задачах. И тогда вполне можно объявлять язык N ненужным.

Или может оказаться что ниша некоего языка Q никому нафиг не нужна.
Java и C++ имеют свои преимущество и недостатки. Каждый из них находит свое применение и довольно широкое. Java безопаснее и обычно быстрее в разработке, C++ обычно быстрее. Это не значит что какой то язык лучше или хуже.
Мне кажется, что правильно подмечено, что работа над перформансом не начинается с подбора флажков хотспота, и не с понимания внутренностей jvm. Перформанс начинается с правильного выбора алгоритмов и структур данных, а это не относится к языку. В .net и в unmanaged языках побольше степеней свободы в выборе структур данных (java приблизится к решению этой проблемы к 10ке, когда value types допишут).
Тем, кто приходят на доклады про jvm performance, стоит помнить, что понимание внутренностей vm может помочь выжать последние несколько процентов с java приложений, в некоторых редких случаях — починить некие паталогические проблемы, но для большинства задач хватит перформанса со всеми настройками по умолчанию, лишь бы код был написан разумно.
Да и вообще, перформанс волнует небольшое количество разработчиков в процентном отношении, чаще людей волнует функциональность их приложения, то простота и корректность написания той функциональности, которую требует заказчик.
Java и C++ — разницу хорошо видно в сравнении Cassandra и ScyllaDB. Сцилла быстрее в 10 раз, но зато и писали её дольше во столько же раз :)
Я думаю некорректно сравнивать это таким образом. Разница в быстродействии между ними обусловлена в первую очередь не языком, а архитектурой процесса обработки запросов. В Cassandra — это SEDA (https://en.wikipedia.org/wiki/Staged_event-driven_architecture), что позволяет хорошо регулировать нагрузку на систему, что в свою очередь, дает возможность получить устойчивую работу системы под разной нагрузкой. Но, при этом приводит к многоэтапной обработке каждого запроса, большому количеству внутренних очередей, и, как следствие, переключений контекта и невысокое быстродействие.
В scylla — процесс обработки запроса построен по Seastar (http://www.scylladb.com/technology/architecture/) — оптимизирован для разделения задач по корам и сетевым картам. Как следствие, количество переключений контекста сильно минимизировано, можно достичь большого красивого быстродействия. Особенно в ситуации, когда синтетический тест ставится на наборе данных полностью помещающемся в память.
Последние несколько лет работаю с этим чудесным языком, и вполне доволен им. Я решал задачи с projecteuler.net на разных языках, и разница в производительности между c / java у меня получалась от 10% до 30%, согласитесь это не такая уж и большая разница. А наличие в java из коробки коллекций позволяет к ряду задач находить решение на порядок быстрее (можно легко реализовать кэширование вычислений или с BigDecimal можно оперировать большими числами).
Если у вас проблемы с производительностью на java, то скорее всего вы что-то делаете не так.
Ну либо задача стоит такая, что вам приходится выжимать эти несчастные доли процента перфоманса из приложения. Однако какой бы нагруженный BigData/HFT проект ни был, перфоманс начинается с архитектуры. Аминь.
У нас тут своя, нехорошая история с GC.
Поставили как-то кластер Elasticsearch на десяток машин, при этом решили посмотреть, как будет вести себя G1. Кластер работал… пару дней, дальше перезапуск, из-за появлявшейся тормозящей кластер ноды по каким-то до сих пор невыясненным причинам.
Симптом: все потоки для балков прожигали время в таблице TheadLocal.ThreadLocalMap.table. Судя по дампам, таблица разрасталась и имела большой диапазон идущих подряд Entry, на которых как раз спотыкается цикл в методе ThreadLocalMap.expungeStaleEntry() (видимо тот самый цикл, что unlike Knuth). Вычеркнуть пытался ReentrantReadWriteLock всего лишь свой readHolds. Ну и вообще, в хот-тредах эластика часто появлялись методы ThreadLocalMap, вроде getEntryAfterMiss(), долго работающие с этой разросшейся таблицей.
На GC не думали, конечно, искали баги в коде… пока не сменили сначала на дефолтовый, потом на CMS. В обоих случаях проблем не было, только при G1 проявлялась такая проблема. Гадай теперь, что виновато: алгоритмы, тюнинг или железо.
На днях только закончили страдать с этой проблемой, а так да, надо бы. Вот только джава оракловая, как того рекомендует Elasticsearch.
Заведите баг. Потому что без вашего фидбэка они там как слепые котята — у них же в тестовой среде вряд ли есть боевой кластер Elasticsearch.
Мы в Одноклассниках периодически шлем им баги. И эти баги фиксятся. Вот, например, баги от apangin.
Sign up to leave a comment.