Кто не знает в 7 версии виртуальная машина сможет обрабатывать целый ряд языков программирования, помимо явы. И при том совместимость с написанными ранее библиотеками останется. Что это сулит? Падение зарплат Java программистов? или вымирание java и заменой его более быстрым для написания языком?
Идиоты пишут статьи. Потом далекие люди начинают гадать
Если абстрагироваться производительности, то джава однозначно рвет все остальные платформы (.нет в том числе) в очень больших проэктах, которые живут многие многие годы, и в которых многа многа строчек кода.
Швидкість виконання коду не зміниться так як з всіх мов код інтерпретується як джавабайткод і вже лише його виконання буде впливати на швидкодію.
Вчера в radio-t состоялась интересная дискуссия на тему «C++ отстой? Ну, не совсем и совсем нет», в том числе и про Java и про всякие Python вспоминали.
никто не спорит, но есть часть товарищей, которые упорно доказывают, что «правильная» виртуальная машина == панацея. И что джава в конечной скорости переплюнет С++ (хорошо хоть с простым си не пытаются сравнивать:))
Странные характеристики «Java быстрее С++» или наоборот.
Странные сравнения дрели и отвертки. Это разные инструменты, с разными областями применения. Джава быстра в разработке, тормозит в исполнени. С++ наоборот. Каждый выбирает, что ему важнее.
ЯП, более удобные и новые переводчики для новых железок. Расслабтесь, мы в Нирване...
вот прямо вот так:) «Разгромит»:)Ну, а уж подобрать специальный тестовый пример, в котором современная JVM разгромит конкретный современный популярный C/C++ рантайм не так уж и нереально.
только вот примеров кроме синтетических тестов, как т сам выразился никто не приводит.
Ну, а уж подобрать специальный тестовый пример, в котором современная JVM разгромит конкретный современный популярный C/C++ рантайм не так уж и нереально.
Ну так может быть что бы не быть голословным подберешь?
Указанный Вами тест, по-моему, не адекватен и вот почему. Он сравнивает самые быстрые реализации относительно быстрых вычислительно сложных алгоритмов. И тут, верояно, почти каждое слово важное....
А то что, Java проигрывает в синтетических тестах — так кому это на самом деле важно?
Это был не тест, а real world задача, причем далеко не первая подобная в моей практике.
В-третьих, специфика решаемых задач, возможно, не позволяет java показать свою мощь. Например, как я слышал, JVM следит за статистикой выполнения программы и в некоторых случаях, основываясь на ней, умеет перегенерировать некоторые куски кода в более быстрые. Понятно, что на C/C++ такая джедайская техника не доступна в принципе. Или тот же сборщик мусора. Судя по всему, одним из плюсов использования сборщика является то, что объекты, выделенные близко по времени в коде, будут находиться близко в памяти, что повышает шансы на то, что они вместе попадут в кэш CPU, а это может оказаться критически важно, особенно в многопоточной среде. Только вот такие особенности проявляются на значительно больших объёмах данных, большем времени работы и, возможно, более многопоточной среде. Соответствует это специфике применения Java сегодня? По-моему вполне. Так что оптимизация ведётся, в общем-то, в верном направлении. А то что, Java проигрывает в синтетических тестах — так кому это на самом деле важно? Вам шашечки или ехать надо?
ну с этим точно никто спорить не будет. Сейчас придут джависты и скажут, что память в современном мире стоит копейки и поэтому не стоит ее экономить:) и соответственно ее во внимание принимать не следует:)
Ну вообще я сам джавист, и с этим в общем согласен, но бывают задачи когда нужно в процессить большие обьемы данных, и чем больше в памяти закешируешь тем лучше, вот тут и появляються проблемы с джавой.
Ну и я удивлюсь если кто то будет доказывать что джава экономна по памяти. Помоему это самая жрущая память платформа.
ну с этим точно никто спорить не будет. Сейчас придут джависты и скажут, что память в современном мире стоит копейки и поэтому не стоит ее экономить:) и соответственно ее во внимание принимать не следует:)
Но даже ваш пример про массив объектов — уж очень редкий частный случай.
Это скорее обозначает что для программистов джава очень редко встречаються задачи, когда нужно написать максимально быстрый и экономный по ресурсам код.
В моем случае мне нужно было хранить в обьекте тройку числовых филдов разных типов, то есть в С++ никакой таблицы виртуальных переходов не было бы. Поскольку данный масив был очень большим, у меня в памяти для джава помещалось значительно меньше обьектов (в раза два), и это все очень плохо сказывалось на производительности алгоритма. То есть решение конкретно этой проблемы заключаеться в том что бы все числовые значения держать в разных масивах, но это уже workaround вокруг недостатка языка.Ну, а про лишнюю память совсем смешно. В C++ метаданные вообще не хранятся, да? Т.е. где находится таблица виртуальных функции объекта код угадывает?
Ну и я удивлюсь если кто то будет доказывать что джава экономна по памяти. Помоему это самая жрущая память платформа. Сравнение c с другими можно посмотреть например здесь: shootout.alioth.debian.org/u64q/java.php
2eugene_n
Это не бага. Это фича.И почему, если это фича, вдруг таки появилось ключевое слово restrict? А появилось оно, чтобы компилятор мог генерировать более оптимальный код. Компилятору труднее понять семантику, чем программисту. Понятно, что пример про многопоточность несколько надуманный. Просто это простой способ показать важность возможности/не возможности побочных эффектов при выполнении кода. Но знание того, что побочных эффектов нет, позволяет оптимизировать и однопоточный код. Простой пример приведен в en.wikipedia.org/wiki/Restrict
Ну, а про лишнюю память совсем смешно. В C++ метаданные вообще не хранятся, да? Т.е. где находится таблица виртуальных функции объекта код угадывает? Или когда программист выделеят массив в N байт, выделяется ровно N байт памяти, да? А потом когда выполняется
Повернись Живим
anonymous
Yura Peskov
Александр Колосов
crypto5
delete []pзнания о том, сколько памяти освободить тоже берутся напрямую из астрала?
Другой пример: компилятору C/C++ очень трудно было автоматически распараллелить почти любую работу по потокам.
Это не бага. Это фича. И эта фича состоит в том, что поведение программы определяется во время компиляции, Потому, что такой код можно ручками разбить на несколько потоков/процессоров, а наоборот — проблематично.
И ктстати очевидно что с конкатенацией тоже нужно смотреть на конкретные случаи, например:
String s = "";
for(int i = 0; i < n; i ++) {
s += i;
че то делаем
}
никакого StringBuilder-a или StringBuffer-a юзаться не будет.
Очевидно есть примеры в одну и другую стороны. Например недавно была задача, нужно было сохранять масив обьектов класса в файл и потом оттуда вытаскивать, на С++ понятно сохранил row memory в файл, потом вытащил сделал каст, в джава это все займет много больше операций. Ну и к тому же в джава любой обьект занимает + толи 8 то ли 12 байт уже не помню точно к размеру его полей.
Не соглашусь. По-моему, сейчас среднестатистический компилятор/среда выполнения популярного языка в вопросах оптимизации значительно умнее среднестатистического же программиста. И эта разница со временем будет только расти! Более того, чем более высокий уровень абстракции используется, тем больше остаётся свободы компилятору для оптимизации.Чем выше абстракция, тем ниже эффективность выполнение, мне кажется.
Другой пример: компилятору C/C++ очень трудно было автоматически распараллелить почти любую работу по потокам. Рассмотрим простую реализацию memcpy:
void my_ memcpy (void* dst, const void* src, size_t count) {
for(; count; count--)
{
*(char*)dst = *(char*)src;
dst++; src++;
}
}
Можем ли мы для больших значений count для ускорения разбить работу на несколько потоков для утилизации нескольких ядер? А неизвестно! Потому что dst и src могут указывать на пересекающиеся области памяти. (Понятно, что это упрощенный пример, где проверку сделать легко, но эта проверка основывается на понимании семантики операции.) При копировании массивов на более высокоуровневых языках такой проблемы нету. Там легко проверить, одна и та же это ссылка или нет. Да в C сейчас можно использовать ключевое слово restrict. Но это опять-таки заставляет думать программиста, а не компилятор.
ИМХО единственное что реально угрожает java — это платформа.Net.
Скажем, пример с СтрингБилдером для конкатенации строк в цикле, по сути, компилятор и сам создает стрингбилдеры и конкатенирует, но эффективнее создать его заблаговременно и самому добавлять строки.
По поводу скорости самой java — обратите внимание что byte code во время выполнения компилируется в машинный код
Тут всё дело в том КАК компилируется. См. выше, если тип указан явно, интерпретатору байткода нужно делать меньше телодвижений, соответственно скорость больше. Кстати, именно поэтому среднестатический паскалевский компилятор в вакууме, быстрее сишного — типизация строже.
Поэтому скорость выполнения Java программы вполне соизмерима со скоростью выполнения не оптимизированной C++ программы, написанной средней руки программером.очень голословное утверждение. Не говоря уже о том, что сравнивать надо Ceteris paribus. ТОесть одинаковые условия.
При желании и на пхп хороший программсит может сделать быстрее, чем слабый программист на си.
Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода.
Они там как раз и пытаются в
Другое дело, что без нормальной ИДЕ все эти динамические языки годяться только чтобы маленькие быстро скриптики сочинять.
По поводу скорости самой java — обратите внимание что byte code во время выполнения компилируется в машинный код, плюс JVM выполняет кучу оптмизация при компиляции. Поэтому скорость выполнения Java программы вполне соизмерима со скоростью выполнения не оптимизированной C++ программы, написанной средней руки программером.
Кто не знает в 7 версии виртуальная машина сможет обрабатывать целый ряд языков программирования, помимо явы.
Вроде уже сто лет как. en.wikipedia.org/...i/JVM_languages
Это сулит поднятие з.п. java — программистов. Т.к. одну и ту — же работу за счёт новых Я.П. можно будет сделать быстрее, значит ещё большее количество народу захочет иметь java — программистов у себя в штате
Только для этих новых ЯП нужны программисты на этих новых ЯП. Java-программист не станет автоматически знатоком лиспа или питона от того, что этот лисп или питон будет работать на JVM.
Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода. + Чует моё сердце, что расширения этих языков будут писаться на java
+1
А то я скорость выполнения никак с Java не связываю;)
Ну вот опять начинается. А с каким языком из перечисленных в вашем профайле вы связываете скорость? С интерпретаторами ПХП и Питона?;)
Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода. + Чует моё сердце, что расширения этих языков будут писаться на java
А можно объяснить что такое скорость выполнения кода? А то я скорость выполнения никак с Java не связываю;) И не надо кричать про кривые руки программистов. Потому как если так кричать, то их прямых ни у кого не имеется, парадокс получается.
Падение зарплат Java программистов?
Это сулит поднятие з.п. java — программистов. Т.к. одну и ту — же работу за счёт новых Я.П. можно будет сделать быстрее, значит ещё большее количество народу захочет иметь java — программистов у себя в штате
Вымирание java и заменой его более быстрым для написания языком?
Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода. + Чует моё сердце, что расширения этих языков будут писаться на java
быстрые и очень быстрые для написания языки (для маленьких проектов) уже давно как имеются, а воз и нынче там.
Bogdan Shyiak
Сашко
Виталий Мигов
Alex
35 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів