LINUX.ORG.RU
Форум — General  

Почему Java на Linux работает медленнее, чем на Windows ?

 , , , ,


0

2

UPDATE. Проблема с долгим запуском Minecraft в Linux решена здесь. (перенос на ext4 раздел)

Добрый вечер! Возник вопрос по поводу Java. Дело в том, что на линуксе она слегка заторможенная. В Windows все java-программы загружаются и работают шустро, нареканий нет.

Чтобы сразу стало понятно о чем я, приведу пример на игре Minecraft: в Windows игровой клиент MC загружается примерно за 40-50 секунд. Тем временем в линуксе тот же клиент, с теми же модификациями и настройками загружается +-3 минуты. Такое падение производительности распространяется на все java-приложения, запускаемые в Linux.

Я не представляю, в чем может быть проблема… может, к java надо передать какие-то специальные оптимизирующие аргументы, кто знает. Или у линукса какие-то свои особенности выделения ресурсов для программ ?

$ java -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

Дистр, ядро: Arch Linux x86_64 Linux 5.4.23-1-lts
Графический драйвер (хз, может это как-то влияет): nvidia-390xx-lts
Никакие настройки и конфиги java не менялись, все работает с коробки

Изменения:

UPD 1. Проведен тест использования jre 8 241 вместо 172. Результата нет.

UPD 2. Запуск с параметрами -Dsun.java3d.opengl=true Прироста производительности нет.

UPD 3. Покопаюсь в драйверах и, в частности, в OpenGL. Мне кажется именно тут какой-то подвох



Последнее исправление: aleksei2000 (всего исправлений: 4)
← пользовательский юнит в автозагрузку
Linux и поддержка планшетов - все плохо! →
  1 2 →
Ответ на: комментарий от DllMain

  1. Системную джаву зачастую собирают невменяемые люди. То же относится и ко всем джавным пакетам. Хороший пример - Debian. Разработчики Debian вообще не понимают, что у Java есть собственная пакетная система, и она не пересекается с пакетной системой GNU/Linux - одному пакету в Debian в реальности может соответствовать два в джаве и наоборот. Есть приложения, которым каждый раз нужно пересобирать все зависимости с патчами, без этого они не работают. И так далее, и тому подобное. Разрабочтики Debian хотят, чтобы разработчики Java-приложений соблюдали правила Debian. Как правило, Java-разработчикам наплевать на Debian, никто не знает их правил, и никто тем более не собирается их соблюдать.

  2. Изменение системной джавы может разрушить приложение.

  3. Изменение переменных окружения в ОС или любых других настроек может разрушить приложение. Пример: кто-то включил IPv6, половина джава-приложений тут же развалилась, т.к. во-первых у джавы по жизни были проблемы с IPv6. Во-вторых, никто из разрабов прикладного софта не расчитывал, что IP может не подходить по регулярке 3цифры.3цифры.3цифры.

  4. Разработчики софта не могут смотреть за всеми дистрибутивами линукса. По факту - обычно вообще не смотрят ни на какой, кроме того, что у них на работе на серверах. Поэтому никто не будет ни следить за проблемами из пункта 2, ни тем более чинить их.

Единственный нормальный способ, который не тратит у разработчиков лишнего времени (т.е. единственный способ вообще) - иметь self-contained сборку «всё своё тащу с собой». Такую сборку можно запускать на любой операционной системе (не только GNU/Linux), она игнорирует почти все системные настройки кроме самых essential, она несёт с собой все библиотеки кроме glibc на линуксах и Visual C++ Rutime на винде, и так далее.

stevejobs ★★★★☆
()

Проблема решена

Кто бы мог подумать, но виновником всех тормозов оказался дофига медленный драйвер NTFS-3G. Папка ~/.minecraft у меня была симлинком на папку майна на системном диске Windows, который монтировался с помощью ntfs-3g. (сделано это было для синхронизации игры в двух ОС) Ну вот и пали у меня все подозрения на то, что тысячи ресурс-файлов майна грузятся с ntfs раздела, к тому же смонтированного не проприетарным драйвером.

Решение проблемы: Перенес папку .minecraft с раздела ntfs на раздел ext, добавил пару полезных флагов в fstab’е для ext4 (noatime,nodiratime).

Результат: Minecraft стал загружаться в 3 раза быстрее, даже быстрее чем из винды.

aleksei2000
() автор топика
Последнее исправление: aleksei2000 (всего исправлений: 2)
Ответ на: Проблема решена от aleksei2000

Minecraft стал загружаться в 3 раза быстрее, даже быстрее чем из винды.

ЧиТД :) Java почти во всех приложениях быстрее работает в Linux.

anonymous
()
Ответ на: Проблема решена от aleksei2000

Кто бы мог подумать, но виновником всех тормозов оказался дофига медленный драйвер NTFS-3G.

Да ты гений.

crutch_master ★★★★★
()

Скачай tlauncher и проверь. Установи его и в винду, и в линукс. Нативная версия есть для обеих систем. Установи туда одинаковые версии майнкрафта и запусти с одинаковыми настройками. И отпишись. Кстати, у тебя линукс и винда на одном диске хоть? И что за диск? Если это hdd, то линукс может оказатся геометрически ближе шпинделю. Там скорость ниже.

anti_win ★★
()
Ответ на: комментарий от stevejobs

Нет, про преимущества подхода я понимаю. Кажется, я где-то видел нечто, компилирующее код на джава в натив

DllMain
()
Ответ на: комментарий от stevejobs

Я ставил JDownloader с системной OpenJDK. В конце концов после встроенного автообновления он перестал работать. А версия с интегрированной Oracle Java до сих пор работает.

anonymous
()
Ответ на: комментарий от anonymous

на самом деле, было бы клёво, если бы разработчики дистрибутивов разбирались в Java-разработке и могли всё это адекватно поддерживать. Но джаве уже больше 20 лет, линуксам и того больше, а воз и ныне там

по сути, всё что не касается C/C++ в инфраструктуре GNU/Linux поддерживается спустя рукава - у Python та же петрушка. Один эпический переход на python 3 чего стоит. И у руби - вспомните боль от установки GitLab не из докерного образа. Постоянно всё поломаное.

stevejobs ★★★★☆
()
Ответ на: комментарий от stasolog

Разве что без модов. Условная тяжелая сборка будет грузиться хоть на 100 ядерном ПК с 5 гигагерцами 10+ минут.

peregrine ★★★★★
()
Ответ на: комментарий от stevejobs

У Python всё нормально. Но да, боль что apt-get в той же ubuntu не может так же хорошо управлять версиями python-а, как conda.

peregrine ★★★★★
()
Ответ на: комментарий от aleksei2000

64-Bit Server VM

Вот это может играть на скорость запуска жабы.

peregrine ★★★★★
()
Ответ на: комментарий от stevejobs

И у руби - вспомните боль от установки GitLab не из докерного образа. Постоянно всё поломаное.

Много лет стоит работающий gitlab из apt-репозитория. Обновился уже через много версий, сейчас на текущей. 2 года назад поднял ещё один, тоже самое. Вообще ничего не сломалось, недавно psql обновил до новой версии (скрипты обновления подсказали)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← пользовательский юнит в автозагрузку
General
Linux и поддержка планшетов - все плохо! →