Кстати, попробуйте тут описаны тулзы по конвертации jar файлов в нативный код: такие как Launch4j и packr. Если я понял ваша главная проблема загрузка JVM, попробуйте перегнать все в натив и может быть вам будет счастье.
Мыши кололись, но ели кактус. (с) Если вам придется пользоваться кривонаписанной криворукими разработчиками программой на C, вы будете в каждой статье тогда язык С обвинять? Найдите аналогичные тулы, которые не написаны на JVM, смените работу в конце концов, зачем же так мучится и тратить нервы.
то есть на компьютере, на котором абсолютно ничего нет
Ни биоса, ни ОС? Все сами всё с нуля написали за 1.5 часа?
ИМХО, это какое-то очень специальная олимипада соревноваться кто быстрее напишет на компе на котором вообще ничего нет. Какой в этом смысл? Можно, конечно, говорить что ты крут потому что можешь в блокноте написать программу в машинных кодах на память, без компиляторов, IDE и инета. Но ЗАЧЕМ? Зачем программировать на компе где ничего нет даже средств разработки? Просто потому что?
Справедливости ради 3d движков по ссылки три, а успешных в лучшем случае полтора. А пригодных для игр AAA-класса — ноль.
Ну из той же справедливости, если верить вики , то на чем-то кроме C++/C движков практически и нет (в частности в списке нет ни Go, ни D, ни Rust). Вообще это не совсем правильный критерий, использование ЯП в какой-то области далеко не всегда зависит от производительности и возможностей языка, основное все-таки наличие уже готовых разработок, большого количества разработчиков и т.п. Нечестно же сравнивать, например, кол-во игров для Андроида на Java и других языках, потому что понятно что у Java будет преимущества нативного ЯП.
аудио/видео кодеки, архиваторы
Ну, кстати нет, такие задачи тоже не числодробилки. Были у меня подобные задачи на Java, там тоже все упиралось в скорость диска, то есть пока архивированный поток читается/пишется, его успевают и разархивировать и обработать и заново заархивировать в параллельном потоке и ещё полно времени остается. P.S. Я не спорю, задачи где производительности Java может не хватить бывают, но их не так много как кажется, в большинстве случаев все (базы данных, кодеки, архиваторы, биг дата) всё равно чаще упирается в скорость диска или сети, то есть тормозит в первую очередь от кривой архитектуры или кривых рук.
Интересно, а как там решается вопрос лицензии GNU, которая запрещает линковку с закрытыми продуктами? Microsoft перепишет Linux заново или обходит это как-то по другому?
Есть специальные JVM для реал-тайм, где нет остановки мира от слова совсем
Есть проект Cassandra DB переписанной на C++ (http://www.scylladb.com/), так авторы заявляют о 10х кратном приросте производительности.
Ну, так то авторы, они и стократный прирост заявят. Если бы так просто было бы получить такой прирост никто бы даже не начинал писать Cassandra DB и ей подобные базы данных на Java. Опять-таки Hadoop и прочий BigData это как раз числодробилки.
P.S. Естественно, у Java тоже есть предел и для ряда задач C и С++ будут лучше, тем не менее есть очень много задач (в том числе по обработке данных) в которых разница между производительностью Java и C++ не так существенна, как разница в затраченных ресурсах разработчкиов. Собственно есть ряд задач где С лучше С++, а есть где рулит только ассемблер.
Там не в фичах дело, не знаю насколько это явно в Clion, но в Java IDEA умудряется практически угадывать что сейчас напишет программист и давать умные подстановки имен, типов и методов, что дико облегчает разработку, ни в одной другой IDEA такого удобства не видел. ИМХО, я вполне понимаю на что уходит производительность и меня такая "цена" вполне устраивает (лучше я куплю более дорогой комп, но буду на 20% продуктивнее, чем наоборот).
но мне правда интересно отношение коммьюнити Java к 1200 флагам для отладки оптимизации.
Во-первых, большинство экспертов сходятся что реально нужных флагов 5, максимум 10. Во-вторых, это равносильно тому что говорить раз в Linux (условно) выходит много фиксов безопсности — она дырявая OC, а в Win (условно) мало фиксов — она супернадежная. Хотя может быть ровно наоборот, те кто забили на безопаснсоть не выпускают фиксы в принципе.
Если в каком-нибудь Visual Basic'e или PHP первой версии никто не обсуждал оптимизация, это не потому что они были супер быстрыми, а потому что не было смысла что-то оптимизировать. В случае решение вроде Hadoop'а на сотню кластеров оптимизация даже на 10% даст минус 10 серверов, вполне логично что оптимизация важна. То есть вопрос вовсе не в том что JVM медленная, вопрос в том что оптимизация JVM дает вполне реальную прибыль...
Тормозит потому что в IntellijIDEA очень умная система автоподстановок и т.п. умных штук, IDEA очень часто догадывается о том что хочет программист, но это сжирает дофига ресурсов. Поотключать это можно и тормозить не будет, другое дело что это практически главное преимущество этой IDE. Тут несколько некоректно сравнивать IDEA с просто продвинутыми редакторами, так как в них всех умных штук просто нет.
на java не написано ни одного более-менее вменяемого браузера
А можно список языков, кроме С++, на которых написаны более-менее вменяемые браузеры? Насколько я знаю, на D, Go, Rust тоже не написано ни одного вменяемого браузера, тоже производительность виновата? Всех популярных вменяемых браузеров штук пять-шесть, наверное, да и то большая часть клоны друг друга.
Все очень просто, представьте вы работаете с Node.js или очень большим фреймворком в PHP, у вас в проекте уже сотни тысяч кода, которые импортируют сотни чужих модулей, которые состоят из миллионов строк кода и после использования "use super-duper-operators" в сотне мест как вашего кода, так и чужого поведение меняется на прямо противоположенное, там где был true стал false и наоборот. Вам придется потратить многие месяцы чтобы исправить все эти ошибки (если вы их вообще исправите).
С другой стороны в экосистеме нет ничего хуже когда половина фреймворков и библиотек работает с одним флажком, вторая половина с другим. По сути единственный способ это придумать новый язык и как-то убедить всех на него перейти. У всех старых языков: Java, C++, Php, JS есть свои проблемы из-за совместимости.
Да, но в Java статические типы как аргументов, так и результата и ошибку с использованием + сделать значительно сложнее (вот деление double на int реально выносит мозг когда про него забываешь/не заметишь). На самом деле, оператор + и — в JS работает куда веселее когда в одном из аргументов оказывается массив, объект, null, undefined и т.п. Пересказать не смогу, лучше посмотреть видео тут (про JS начинают говорить с 1:20). Ну или почитать эту статью.
Просто у JS и PHP как в анекдоте "в вашем спирте крови не обнаружено", языки (при всем к ним уважении) это одна большая Странность. Так уж сложилось исторически, я помню как девелоперы JS сами угорали от видео про "логику" сравнений и приведений типов в JS. P.S. Пишу и на JS и на PHP и нисколько не считаю их плохими, просто их создатели изначально не рассчитывали на появление Node.js или что на PHP будут писать фейсбук, а сейчас кое-какие вещи сложно уже исправить из-за обратной совместимости, увы. :(
Попробуйте заблокировать платеж биткоина, например. Да и какой-нибудь paypal лесом пошлет запрет отплаты в казино США от суда Нижних Васюков. И тем более не будет раскрывать виды деятельности каждого предприятия мира органам России.
Если вам нужна максимальная производительность и вы выбрали Java'у — то вы уже проиграли
Зависит от того чего нужна максимальная производительность, если числодробилка — да. Если основное узкое место системы запросы в базу данных — нет смысла брать ассемблер, высокоуровневый язык даст намного больше возможностей для оптимизации SQL запросов.
то первое — исправить невозможно вообще
Можно, можно. Вопрос прямых рук, можно организовать переиспользование объектов, ограниченное создание временных объектов и прочее, если память критична. На Java писали даже софт для сим карт, где не было сборщика мусора как факта.
А языки — это уже вторичное.
Конечно, речь шла о важности алгоритмов в повседневном программировании. В Java/C# большинство алгоритмов уже давно реализованы на уровне языка, проверены, много раз отлажены на производительность и нужно просто знать какие функции стоит использовать в том или ином случае. То есть знать возможности языка важнее чем алгоритмы. В более низкоуровневых языках (если в них нет большого количества уже реализованных алгоритмов в качества функций самого языка) наоборот знание алгоритмов важнее.
А как заблокировать любой перевод в любое инет-казино (в том числе зарубежное) в любой системе и валюте? Есть же вебмани, яндекс деньги, мастеркарты, биткоин, наконец. А инет-казино, включая заграничных, десятки тысяч. Можно заблокировать десяток счетов (и то не во всех системах), но десятки тысяч? Как минимум, это не самое легкое и надежное решение.
Тут может быть мы просто о разных языках говорим, в Java "узким местом" будут кривые запросы к базам данным или к сети, но редко конкретная библиотека, к тому же там особенно актуально про зло преждевременной оптимизацим, в 99% случаях важно решить задачу максимально просто и понятно (грубо говоря искать строки исключительно библиотекой самого языка), чем заботиться о производительности. А в оставшемся 1% проблемы решаются анализом готового приложения с профайлером.
В языке C или С++ вопросы оптимизации и алгоритмов, конечно, имеют совсем другое значение.
Ни биоса, ни ОС? Все сами всё с нуля написали за 1.5 часа?
ИМХО, это какое-то очень специальная олимипада соревноваться кто быстрее напишет на компе на котором вообще ничего нет. Какой в этом смысл? Можно, конечно, говорить что ты крут потому что можешь в блокноте написать программу в машинных кодах на память, без компиляторов, IDE и инета. Но ЗАЧЕМ? Зачем программировать на компе где ничего нет даже средств разработки? Просто потому что?
Ну из той же справедливости, если верить вики , то на чем-то кроме C++/C движков практически и нет (в частности в списке нет ни Go, ни D, ни Rust). Вообще это не совсем правильный критерий, использование ЯП в какой-то области далеко не всегда зависит от производительности и возможностей языка, основное все-таки наличие уже готовых разработок, большого количества разработчиков и т.п. Нечестно же сравнивать, например, кол-во игров для Андроида на Java и других языках, потому что понятно что у Java будет преимущества нативного ЯП.
Ну, кстати нет, такие задачи тоже не числодробилки. Были у меня подобные задачи на Java, там тоже все упиралось в скорость диска, то есть пока архивированный поток читается/пишется, его успевают и разархивировать и обработать и заново заархивировать в параллельном потоке и ещё полно времени остается.
P.S. Я не спорю, задачи где производительности Java может не хватить бывают, но их не так много как кажется, в большинстве случаев все (базы данных, кодеки, архиваторы, биг дата) всё равно чаще упирается в скорость диска или сети, то есть тормозит в первую очередь от кривой архитектуры или кривых рук.
достаточно
а их много, научные числодробилки, базы данных и nosql хранилища, поисковые системы, машинное обучение и нейроные сети и т.п.
Есть специальные JVM для реал-тайм, где нет остановки мира от слова совсем
Ну, так то авторы, они и стократный прирост заявят. Если бы так просто было бы получить такой прирост никто бы даже не начинал писать Cassandra DB и ей подобные базы данных на Java. Опять-таки Hadoop и прочий BigData это как раз числодробилки.
P.S. Естественно, у Java тоже есть предел и для ряда задач C и С++ будут лучше, тем не менее есть очень много задач (в том числе по обработке данных) в которых разница между производительностью Java и C++ не так существенна, как разница в затраченных ресурсах разработчкиов. Собственно есть ряд задач где С лучше С++, а есть где рулит только ассемблер.
Во-первых, большинство экспертов сходятся что реально нужных флагов 5, максимум 10. Во-вторых, это равносильно тому что говорить раз в Linux (условно) выходит много фиксов безопсности — она дырявая OC, а в Win (условно) мало фиксов — она супернадежная. Хотя может быть ровно наоборот, те кто забили на безопаснсоть не выпускают фиксы в принципе.
Если в каком-нибудь Visual Basic'e или PHP первой версии никто не обсуждал оптимизация, это не потому что они были супер быстрыми, а потому что не было смысла что-то оптимизировать. В случае решение вроде Hadoop'а на сотню кластеров оптимизация даже на 10% даст минус 10 серверов, вполне логично что оптимизация важна. То есть вопрос вовсе не в том что JVM медленная, вопрос в том что оптимизация JVM дает вполне реальную прибыль...
А можно список языков, кроме С++, на которых написаны более-менее вменяемые браузеры? Насколько я знаю, на D, Go, Rust тоже не написано ни одного вменяемого браузера, тоже производительность виновата? Всех популярных вменяемых браузеров штук пять-шесть, наверное, да и то большая часть клоны друг друга.
С другой стороны в экосистеме нет ничего хуже когда половина фреймворков и библиотек работает с одним флажком, вторая половина с другим. По сути единственный способ это придумать новый язык и как-то убедить всех на него перейти. У всех старых языков: Java, C++, Php, JS есть свои проблемы из-за совместимости.
P.S. Пишу и на JS и на PHP и нисколько не считаю их плохими, просто их создатели изначально не рассчитывали на появление Node.js или что на PHP будут писать фейсбук, а сейчас кое-какие вещи сложно уже исправить из-за обратной совместимости, увы. :(
Зависит от того чего нужна максимальная производительность, если числодробилка — да. Если основное узкое место системы запросы в базу данных — нет смысла брать ассемблер, высокоуровневый язык даст намного больше возможностей для оптимизации SQL запросов.
Можно, можно. Вопрос прямых рук, можно организовать переиспользование объектов, ограниченное создание временных объектов и прочее, если память критична. На Java писали даже софт для сим карт, где не было сборщика мусора как факта.
Конечно, речь шла о важности алгоритмов в повседневном программировании. В Java/C# большинство алгоритмов уже давно реализованы на уровне языка, проверены, много раз отлажены на производительность и нужно просто знать какие функции стоит использовать в том или ином случае. То есть знать возможности языка важнее чем алгоритмы. В более низкоуровневых языках (если в них нет большого количества уже реализованных алгоритмов в качества функций самого языка) наоборот знание алгоритмов важнее.
В языке C или С++ вопросы оптимизации и алгоритмов, конечно, имеют совсем другое значение.