Представлен (http://blog.robovm.org/2013/01/robovm-001-released.html) первый выпуск проекта RoboVM (http://www.robovm.org/), в рамках которого развивается реализации системы AOT-компиляции (http://ru.wikipedia.org/wiki/AOT-%D0%BA%D0�... байткода Java в машинный код платформ ARM или x86, позволяющей преобразовывать Java-программы в исполняемые файлы, выполняемые без использования виртуальной машины Java и без интерпретации байткода. Дополнительно проектом развивается набор runtime-библиотек для обеспечения выполнения Java-программ в окружениях iOS, Mac OS X и Linux. Код компилятора (https://github.com/robovm/robovm) распространяется под лицензией GPLv2, а код runtime-компонентов под лицензией Apache 2.0.
Изначальной целью разработки проекта является намерение предоставить разработчикам возможность разработки программ, написанных на языке Java, в виде обычных приложений для платформы iOS, имеющих доступ к Cocoa Touch API (https://developer.apple.com/technologies/ios/cocoa-touch.html) и другим программным интерфейсам iOS. Доступ к API осуществляется благодаря созданию прослойки Objective-C Bridge, позволяющей обращаться к объектам Objective-C из кода на языке Java. В настоящее время большинство вызовов UIKit уже оттранслированы для использования в Java. Тем не менее, кроме iOS система в равной мере поддерживает генерацию исполняемых файлов для Mac OS X и Linux.В runtime-библиотеках использована реализация классов java.lang, java.util, java.io и т.п., развиваемая платформой Android. В библиотеках RoboVM по возможности используется как можно больше стандартных классов Android, а также поддержка OpenGL ES API, что позволяет создавать RoboVM-программы для iOS на основе уже существующих приложений для платформы Android, совместно используя код в обоих вариантах приложения. Для трансляции байткода Java в машинный код используются наработки проекта LLVM. Для разработки программ допускается использование стандартного интегрированного окружения Eclipse Java IDE, для которого подготовлен специальный плагин (http://download.robovm.org/eclipse/).
URL: http://blog.robovm.org/2013/01/robovm-001-released.html
Новость: http://www.opennet.me/opennews/art.shtml?num=35919
Главная проблема жавы - это не jit, а gc. И его это не исправит.
+1
Программа - это дополнение ума машины умом человека.
А вот дополнение ума человека умом машины - это деградация.
> Программа - это дополнение ума машины умом человека.
> А вот дополнение ума человека умом машины - это деградация.Это человек должен машине прислуживать, что ли? Заговариваешься.
> +1
> Программа - это дополнение ума машины умом человека.
> А вот дополнение ума человека умом машины - это деградация.Я чё-то пропустил, когда у машины ум появился?
Intel Core i7 Extreme Edition, могёт смоделировать как бы Пьер Безухов охарактеризовал
работы ранних Германских мастеров изобразивших квантовую неопределённость и кота Шреденгера.
Куда уж там. Еще даже не разобрались толком, что это вообще такое — ум.
Это скорее к религии)
Ум это нечто, что может само-обучаться, все. Ни больше, ни меньше.
P.S. Про нейросети и бла-бла-бла можете не упоминать, оно один черт по заранее заданным алгоритмам работает.
А то, что по заранее заданным алгоритмам работает внезапно не может самообучаться? О_о
> А то, что по заранее заданным алгоритмам работает внезапно не может самообучаться?Внезапно - нет.
Внезапно в мозгу заложены необходимые механизмы для самообучения.
Внезапно ни один человек без обучения не научился говорить
Внезапно эта способность стремительно теряется после 6 лет и у некоторых почти равна нулю лев 40-50
Способность к обучению, и уж тем более способность говорить, не является признаком ума.
Ну уж Вы хватили. Способность говорить, как раз и является.
Правда, надо иметь ввиду, что способонсть иммитировать речь - нет.
> Ну уж Вы хватили. Способность говорить, как раз и является.Ум - это способность формировать задачу так, что непонятным остаётся только решение.
Ум - это способность давать ответ так, что не возникает дополнительных вопросов.
>Ум это нечто, что может само-обучаться, все.Вы на самом деле считаете, что дополнение аксиоматики сделанными из нее выводами хоть как-то тянет на определение ума?
> Ум это нечто, что может само-обучаться, все. Ни больше, ни меньше.Смотря чему обучаться.
Можно взять лабиринт, программа путем подбора найдет путь в этом лабиринте, и запомнит.
Потом натравить программу на этот же лабиринт - программа сразу его пройдет по старому пути.
Уже можно кричать "вау, оно самообучается!".
С умом проще - тест Тьюринга и вперёд ;-)А вот с сознанием гораздо сложнее. Эти вещи почему-то путают, но они существуют отдельно.
Сама возможность эмуляции сознания вообще под большим вопросом.P.S.
А многие философы(не западные конечно) считают, что сознание может существовать только в единственном экземпляре. Типа синглтона ;-)
> Сама возможность эмуляции сознания вообще под большим вопросом.Сознание эмулируется у всех животных с мозгом, но разной степени слоности. Кто сказал, что собака не считает себя разумной?
> Кто сказал, что собака не считает себя разумной?Как это "кто"? Собака и сказала.
На текущий момент ПРЯМОЙ связи между мозгом и сознанием не установлено.
Мозг - это самый важный орган центральной нервной системы, что ничего не говорит о сознании.
Нет мозга - нет сознания.
> Программа - это дополнение ума машины умом человека.
> А вот дополнение ума человека умом машины - это деградация."Властилин" Пожинателей (#MassEffect) порабащает комментаторов OpenNET :)
Какой еще пластилин-пожиратель? :)
сам хоть понял, что сказал?
Иногда GC это главная проблема C++, оттого что там его нет.
> Иногда GC это главная проблема C++, оттого что там его нет.man boehm-gc. Однако факт в том что на C++ можно писать без gc, без (даже потенциальных) утечек и не испытывая никакого дискомфорта, так что gc не нyжен.
> Иногда GC это главная проблема C++, оттого что там его нет.А игроделы например не в курсе и именно поэтому им и пользуются. Потому что медвежьи услуги - не рулят.
> А игроделы например не в курсе и именно поэтому им и пользуются.Особенно на Android, создавая казуальные игры, ага.
> Особенно на Android, создавая казуальные игры, ага.На то и казуальщина чтобы писаться кем попало, на чем попало, на коленке. А как только надо что-то похожее на производительность и реалтаймность - ява сразу идет нафиг.
>Особенно на Android, создавая казуальные игры, ага.которые умудряются тормозить там, где к примеру гта летает.
Вы что-то имеете против gc вообще - или только gc конкретно в Java?
Новость о вообще или о java?
Если так, тогда о какой из реализаций GC в Java речь? В HotSpot (виртуальная машина, используемая в OpenJDK и Oracle JDK) их несколько на выбор.
Спасибо, я в курсе. Ты это зачем-то сказал или так, поддержать разговор?
> Новость о вообще или о java?ok, значит только в java. Тогда вы против какого gc в java конкретно? Почему? Или тоже против всех? - Почему?
Главная проблема жавы - это Oracle :)
Главная проблема Oracle - это жава ;-)
Гравная проблема- это факт наличия самой java и оракла... так и по отдельности
JIT тоже создаёт немалую нагрузку, причем на память тоже.
> JIT тоже создаёт немалую нагрузку, причем на память тоже.Он генерит довольно пухлый и не сильно оптимизированный код. Сильно оптимизировать он не может - требования по памяти и времени работы напрягут. Если gcc на момент компила может выжрать несколько гиг для глобальной оптимизации - всем пофигу. А вот на телефоне скушать столько в рантайме - уже не вариант...
> Он генерит довольно пухлый и не сильно оптимизированный код.Не обязательно. В JVM HotSpot есть две реализации JIT: client и server. Client генерирует менее оптимальный код, но быстро. Server работает дольше, но зато хорошо оптимизирует. В любом случае, компилируются только те методы, которые вызываются достаточно часто (остальные интерпретируются). С некоторых пор появился еще режим многоуровневой компиляции, в котором выполняется сначала быстрая компиляция, после чего наиболее часто выполняемые части кода перекомпилируются с полной оптимизацией. В любом варианте есть эффект "разогрева": приложение достигает максимальной производительности только через некоторое время работы.
> Главная проблема жавы - это не jit, а gc. И его это не исправит.GC старается как может, на то он и GC. А вот новоявленные Java-программисты из бывших C++ и VBA-программистов не хотят знать то, что для создаваемых в программе объектов нужно растягивать жизненные циклы в идеале на всё время жизни программы и не плодить лишних. Тогда и память не будет потребляться и у GC работы почти не будет. А то привыкли всё списывать на кривую архитектуру, а сами не бельмеса не понимают.
> GC старается как может, на то он и GC. А вот новоявленные Java-программисты из бывших C++ и VBA-программистов не хотят знать то, что для создаваемых в программе объектов нужно растягивать жизненные циклы в идеале на всё время жизни программы и не плодить лишнихАктивнее использовать глобальные объекты, что ли? Потрясающая архитектура, да.
GC сделан для удобства программиста, а не наоборот, и если это удобство оборачивается тем, что его нужно особо ублажать - это уж слишком."If Java had true garbage collection, most programs would delete themselves upon execution."
Проблема в том, что жабный сборщик мусора ужасен, есть значительно лучшие реализации. Например, сборщики мусора в питоне или некоторых реализациях лиспа.
> Активнее использовать глобальные объекты, что ли? Потрясающая архитектура, да.Нахрена глобальные-то? Достаточно кэшировать использованные объекты и когда нужно переиницилизировать и использовать их опять вместо создания новых.
> Достаточно кэшировать использованные объекты и когда нужно переиницилизировать и использовать их опять вместо создания новыхОтличная работа для человека, которому нечем заняться. Почему бы не научить жабовский GC этому?
>> Достаточно кэшировать использованные объекты и когда нужно переиницилизировать и использовать их опять вместо создания новых
> Отличная работа для человека, которому нечем заняться. Почему бы не научить жабовский
> GC этому?В JetBrains один раз научили: http://habrahabr.ru/post/147552/
Вы, вероятно, из тех "программистов", которые мечтают об IDE с большой красной (или синей - по вкусу) кнопкой посередине: "Сгенерировать программу которую я только что придумал!" ;-)А остальным "нечем заняться" и они сами программы пишут :-)
Я люблю творческую работу, а не рутинную, которая шаблонна, повторяет себя и поддается алгоритмизации, отчасти оттого, что человек выполняет ее неоптимально и с кучей ошибок.
Повторная инициализация объектов без их разрушения - один из видов такой работы, которая реально делается сборщиками мусора в Лиспе. Такие низкоуровневые, по сути, вещи iZEN предлагает делать руками - и это в языке Java с претензией на ООП и высокие абстракции.
у Java есть разные сборщики мусора. Например есть G1. Раз Вы так бодро рассуждаете на эту тему, я так понимаю вы попробовали разные? =)
>> GC старается как может, на то он и GC. А вот новоявленные Java-программисты из бывших C++ и VBA-программистов не хотят знать то, что для создаваемых в программе объектов нужно растягивать жизненные циклы в идеале на всё время жизни программы и не плодить лишних
> Активнее использовать глобальные объекты, что ли? Потрясающая архитектура, да."Глобальные объекты"? Это что ещё за "глобальные объекты"?
> "If Java had true garbage collection, most programs would delete themselves upon
> execution."
> Проблема в том, что жабный сборщик мусора ужасенКакой из? Для какой задачи? Конкретнее, пожалуйста. В JRE есть несколько GC с разными стратегиями работы.
> , есть значительно лучшие реализации. Например, сборщики мусора в питоне или некоторых реализациях лиспа.
Опять ни слова о конкретной реализации. Какие именно сборщики мусора занчительно лучше жавовских, в чём конкретно и почему?
Интересно, сможет ли он так Scala скомпилировать. Теоретически, сможет.
естественно сможет - оно же не с самим языком работает, а с байт-кодом. Вообще, насколько я понимаю, это полный аналог майкрософтовского NGEN
Только не следует ожидать, что это будет работать быстрее, чем JIT. Сильная сторона Java (HotSpot VM) — динамические оптимизации, зависящие от поведения программы во время выполнения. Например, HotSpot может связать напрямую или даже встроить вызов виртуального метода, если обнаружится, что во время выполнения обычно используется одна и та же реализация. Встраивание метода, в свою очередь, делает возможными дальнейшие оптимизации. На случай "не как обычно" добавляется быстрая проверка. Таким образом, виртуальный вызов в Java может быть быстрее, чем в C++, и возможно это только за счет компиляции во время выполнения.Подробнее про оптимизации в HotSpot JVM: https://wikis.oracle.com/display/HotSpotInternals/Performanc...
> виртуальный вызов в Java может быть быстрее, чем в C++, и возможно это только за счет компиляции во время выполнения.Интересно, таблица виртуальных методов в C++ поддерживается в рантайме? И насколько часто C++ программисты пользуются возможностью позднего связывания кода (на стадии выполнения)?
> C++ программисты пользуются возможностью позднего связывания кода (на стадии выполнения)?Это ты dlopen() так умно обозвал? :)
A кто вам сказал что он знает что такое dlopen() ?
> [XPEH 23:32] A кто вам сказал что он знает что такое dlopen() ?И тут не прошло и 2 часов как...
> [iZEN 00:45] А что такое dlopen()?
XPEH получает +5 к скиллу телепатии! Эпично!
А что такое dlopen()?
http://www.freebsd.org/cgi/man.cgi?query=dlopenя так понимаю что ты freebsd упоминаешь чтобы умнее казаться и не более.
зыж
азен, запомни, чтобы дотянуть хотя бы до средненького специалиста в java, нужно быть также и специалистом в С/С++.
иначе ты просто не сможешь знать как именно работает твоя программа (не говоря уже про jni, nmi,…итд)
> http://www.freebsd.org/cgi/man.cgi?query=dlopenЭто не то "позднее связывание", которое есть в ООП-программе.
> я так понимаю что ты freebsd упоминаешь чтобы умнее казаться и не более.
Не только. Я ей ещё и пользуюсь. Правда дома. На работе у меня Windows XP.
> зыж
> азен, запомни, чтобы дотянуть хотя бы до средненького специалиста в java, нужно
> быть также и специалистом в С/С++.Про C ещё куда ни шло, но знание C++ прививает отвратительные практики программирования, часто вредные, чем полезные, для Java-программистов.
> иначе ты просто не сможешь знать как именно работает твоя программа (не говоря уже про jni, nmi,…итд)
JNI использовал и буду использовать (если ещё раз доведётся) совместно с программированием в/на Delphi под Windows. В C++ я не считаю себя специалистом и не хочу им быть.
>> http://www.freebsd.org/cgi/man.cgi?query=dlopen
>Это не то "позднее связывание", которое есть в ООП-программе.это то связывание, которое есть в freebsd. более того, в posix.
>Не только. Я ей ещё и пользуюсь. Правда дома. На работе у меня Windows XP.no comments
>Про C ещё куда ни шло, но знание C++ прививает отвратительные практики программирования, часто вредные, чем полезные, для Java-программистов.
>JNI использовал и буду использовать (если ещё раз доведётся) совместно с программированием в/на Delphi под Windows. В C++ я не считаю себя специалистом и не хочу им быть.ты извини конечно, но только что ты упал ниже трухина.
хочешь ты того или нет, но С/С++ — это стандарт. без них нельзя даже рассуждать о посикс, юникс, фс и тд.
зыж
а вообще ты даже не выпадаешь из статистики, т.к. хуже дельфийных программистов образованы только программеры на жабе и бейсике.
>>> http://www.freebsd.org/cgi/man.cgi?query=dlopen
>>Это не то "позднее связывание", которое есть в ООП-программе.
> это то связывание, которое есть в freebsd. более того, в posix.Это не то связывание и к ООП, в частности к таблице виртуальных методов, не имеет никакого отношения.
>>Про C ещё куда ни шло, но знание C++ прививает отвратительные практики программирования, часто вредные, чем полезные, для Java-программистов.
>>JNI использовал и буду использовать (если ещё раз доведётся) совместно с программированием в/на Delphi под Windows. В C++ я не считаю себя специалистом и не хочу им быть.
> ты извини конечно, но только что ты упал ниже трухина.Спасибо, капитан Очевидность. Я и так в аду. Повсюду мерзкий глючный код на C++. :))
> хочешь ты того или нет, но С/С++ — это стандарт.
Стандарт это C. C++ — это эмулятор ООП в те времена, когда не было достойных быстрых альтернатив с понятным синтаксисом и семантикой. C++ призван унаследовать всё ПО, которое когда либо было написано на C.
> без них нельзя даже рассуждать о посикс, юникс, фс и тд.
Они реализованы не на C++, к счастью. Да и JNI обеспечивает связь только с плоским С API, но никак не с C++. Для задействования C++ объектов в Java требуется писать обёртку на C.
> зыж
> а вообще ты даже не выпадаешь из статистики, т.к. хуже дельфийных программистов образованы только программеры на жабе и бейсике.Хороший Delphi- или VB-программист гораздо лучше посредственного C++ программиста.
>Интересно, таблица виртуальных методов в C++ поддерживается в рантайме?ха, и оно ещё критикует С++. с такими то знаниями. почитай хоть для начала то http://en.wikipedia.org/wiki/Virtual_method_table
зыж
2Tav
>> виртуальный вызов в Java может быть быстрее, чем в C++, и возможно это только за счет компиляции во время выполнения.во-первых это брехня, т.к. vtable в С++ строится на этапе компиляции, конкретный адрес проставляется уже на этапе выполнения. http://www.intuit.ru/department/pl/plintro/12/2.html
и это никак не может быть медленнее, когда vtable строится житом, а потом ещё и подставляется.
во-вторых, (для дальнейшего развития) для уменьшения зависимости от дорогостоящих вызовов из vtable придумали различные методики, чтобы отказаться от vtable и подставлять конкретный адрес на этапе линковки. пример (чтоб было понятно и вантузятнику) — ATL, где классы объявляются с declspec(novtable) http://msdn.microsoft.com/ru-ru/library/w4baz6ss.aspx
И ЕСЛИ ВЫ ПОДУМАЕТЕ (не много ли я прошу от жабиста?), то поймёте почему выбор позднего связывания абсолютно избыточен в рантайме.
просто быдлокодить безусловно легче использования шаблонов.
ну а ставить подобные «достижения» в заслугу — это просто ханжество и лицимерие. быдлокодте себе на здоровье, но без фанатизма (хотя это может быть просто недостаток системных знаний, тогда пока(!!!) сори).
у минусующего кроме эмоций сказать было нечего?
понимаю.
только это не закроет брешь в ваших знаниях.
а они у тебя есть? или только понты, оскорбления и преходы на личности, и не желание слушать других ?
Нервный стиль вашего комментария и переход на личности (позволю себе тоже) создает впечатление, что вы ощущаете со стороны обсуждаемой технологии угрозу обесценивания накопленных вами знаний и опыта.> во-первых это брехня, т.к. vtable в С++ строится на этапе компиляции, конкретный адрес проставляется уже на этапе выполнения.
Речь же шла о возможности автоматически встроить (inline) вызываемый виртуальный метод, и, как следствие, еще и выполнить более глубокие оптимизации, пересекающие границы изначальных процедур.
> подставлять конкретный адрес на этапе линковки.
Для этого на этапе линковки этот адрес должен быть известен. Смысл же полиморфизма типов и позднего связывания (основы ООП) в том, что конкретная реализация вызываемого метода зависит от типа объекта-получателя и (в общем случае) известна только во время выполнения.
> просто быдлокодить безусловно легче использования шаблонов.
Можете называть это так, но я предпочитаю больше думать об алгоритмической корректности кода и меньше отвлекаться на рутинные технические детали. А вам рекомендую для всего использовать ассемблер.
>[оверквотинг удален]
> во-первых это брехня, т.к. vtable в С++ строится на этапе компиляции, конкретный
> адрес проставляется уже на этапе выполнения. http://www.intuit.ru/department/pl/plintro/12/2.html
> и это никак не может быть медленнее, когда vtable строится житом, а
> потом ещё и подставляется.
> во-вторых, (для дальнейшего развития) для уменьшения зависимости от дорогостоящих вызовов
> из vtable придумали различные методики, чтобы отказаться от vtable и подставлять
> конкретный адрес на этапе линковки. пример (чтоб было понятно и вантузятнику)
> — ATL, где классы объявляются с declspec(novtable) http://msdn.microsoft.com/ru-ru/library/w4baz6ss.aspx
> И ЕСЛИ ВЫ ПОДУМАЕТЕ (не много ли я прошу от жабиста?), то
> поймёте почему выбор позднего связывания абсолютно избыточен в рантайме.Ну вот и ответ: "От таблицы виртуальных методов _и_позднего_связывания_кода_ в программе на C++ ПРИНЯТО_ОТКАЗЫВАТЬСЯ". Тогда о чём вообще речь? "В C++ на самом деле в работе ненастоящий полиморфизм, иначе вас ждут жестокие тормозааааа".
> просто быдлокодить безусловно легче использования шаблонов.
> ну а ставить подобные «достижения» в заслугу — это просто ханжество и
> лицимерие.А вот это уже обсирание ОСНОВ ООП, а не только языков ООП-программирования.
> быдлокодте себе на здоровье, но без фанатизма (хотя это может
> быть просто недостаток системных знаний, тогда пока(!!!) сори).Ну а вы, так и быть, пишите на своём недо- ООП-языке C++. (Чем это отличается от программирования на C, только вот, неясно.)
>Ну вот и ответ: "От таблицы виртуальных методов _и_позднего_связывания_кода_ в программе на C++ ПРИНЯТО_ОТКАЗЫВАТЬСЯ".ты дурак? или в принципе плохо-обучаем?
vtable создаётся ля любого класса, содержащего хоть один виртуальный метод.
азы. см. тут http://www.intuit.ru/department/pl/plintro/12/2.html
>На этапе компиляции строится таблица виртуальных методов, а конкретный адрес проставляется уже на этапе выполнения.
>Тогда о чём вообще речь?речь о том, что при помощи шаблонов и множественного наследования можно получить ВСЕ преимущества позднего связывания на этапе линковки, при этом значительно уменьшив код и увеличив производительность до уровня голого С.
зыж
>> ну а ставить подобные «достижения» в заслугу — это просто ханжество и лицимерие.
>А вот это уже обсирание ОСНОВ ООП, а не только языков ООП-программирования.это обсирание невеж, которые не зная С++ (а ты уже признался что не знаешь выше в #59) каким-то боком претендуют на его сравнивание с чем либо.
ты невежа, айзен. при чём это не оскорбление, это голый факт.
> Только не следует ожидать, что это будет работать быстрее, чем JIT. Сильная
> сторона Java (HotSpot VM) — динамические оптимизации, зависящие от поведения программы
> во время выполненияКак показывает практика, никакой магии там нет - java почти всегда проигрывает нативному коду. Фанбои жавы ой как любям всюду тыкать вот этим:
> Например, HotSpot может связать напрямую или даже встроить вызов виртуального метода
Однако толку от этого ноль без палочки, зато лишний расход CPU в рантайме, вместо однократного при сборке как в нормальных языках.
Магия начинается, когда вы пишите какую-то вычислительную функцию, использующую, например, геометрические абстракции из java.awt.geom и не беспокоитесь о том, что создаете много локальных объектов и используете позднее связывание, поскольку JIT разберет объекты в стек и встроит их методы, превратив полиморфный код, написанный в терминах точек, прямоугольников и т. п. в примитивную арифметику. Т. е., можно спокойно сосредоточиться на алгоритме и на ясности кода.> зато лишний расход CPU в рантайме, вместо однократного при сборке как в нормальных языках.
Это мешает для часто запускаемых и относительно недолго работающих приложений, но совершенно не является проблемой на серверах.
>Магия начинается, когда вы пишите какую-то вычислительную функцию, использующую, например, геометрические абстракции из java.awt.geom и не беспокоитесь о том, что создаете много локальных объектов и используете позднее связывание, поскольку JIT разберет объекты в стек и встроит их методы, превратив полиморфный код, написанный в терминах точек, прямоугольников и т. п. в примитивную арифметику. Т. е., можно спокойно сосредоточиться на алгоритме и на ясности кода.это идиотизм.
и начинается он тогда, когда кто-то на тематическом форуме пишет это и думает что я буду рад использовать тормоза его программы каждый раз, когда JIT разбирает его объекты на моих вычислительных системах только потому, что ему не хотелось думать.
Во-первых, я уже написал, что это проблема для десктопных приложений, но не проблема на серверах, где JVM довольно успешно используется. Во-вторых, время программиста дороже. В-третьих, не "не хотелось думать", а хотелось больше думать об алгоритмической корректности кода и меньше отвлекаться на рутинные технические детали.
всё это глупость чистой воды.
это на вашу подготовку как жабиста было затрачено меньше средств, это да.
а вот процесс реализации алгоритмов что в С++, что в java одинаков. при условии что вы владеете знаниями этих языков одинаково.
уменьшение расходов на подготовку и распространение ПО — вот всё что бралось в расчёт при проектировании подобных систем.зыж
>Во-первых, я уже написал, что это проблема для десктопных приложений, но не проблема на серверах, где JVM довольно успешно используется.на серверах ещё и не такой крап увидишь… особенно в застенках ынтырпрайза.
что абсолютно не делает из халтуры что-то более ценное.
Не соглашусь. Я не "жабист", я просто знаю преимущества и недостатки технологии и имею какие-то представления о принципах работы JVM.А разработка одного и того же на (говоря только об объектно-ориентированных языках) C++, Java или на чем-то уровня Smalltalk (например, Ruby) — разное дело. Конечно, если речь идет о сортировке целых чисел, разницы не будет. Но если разрабатываемая программа предполагает различные уровни абстракции, разница становится существенной. Вообще, способность выражать абстракции — очень важное качество языка.
>Не соглашусь.как будет угодно.
>Я не "жабист", я просто знаю преимущества и недостатки технологии и имею какие-то представления о принципах работы JVM.вы не можете знать преимущества и недостатки не имея более-менее полных системных знаний.
это видно по вашим ответам. вы ни разу не видели как именно логика вашего приложения проецируется в машинное представление.
да вы даже не в курсе выше были vtable и принципов её формирования
(дам пруф на базовые знания ещё раз http://www.intuit.ru/department/pl/plintro/12/2.html
На этапе компиляции строится таблица виртуальных методов, а конкретный адрес проставляется уже на этапе выполнения.)
а когда я завёл речь, что при помощи шаблонов можно отказаться от vtable и её оверхеда, при этом оставив и функциональность, и уменьшив размер кода, вы вообще не поняли о чём речь.
> На этапе компиляции строится таблица виртуальных методов,
> а конкретный адрес проставляется уже на этапе выполнения.)Там плохо и упрощенно описано. Адрес не "не проставляется уже на этапе выполнения". Там сложнее. В википедии лучше описано:
"... Для каждого класса, имеющего хотя бы один виртуальный метод, создаётся таблица виртуальных методов. Каждый объект хранит указатель на таблицу своего класса. Для вызова виртуального метода используется такой механизм: из объекта берётся указатель на соответствующую таблицу виртуальных методов, а из неё, по фиксированному смещению, — указатель на реализацию метода, используемого для данного класса. При использовании множественного наследования или интерфейсов ситуация несколько усложняется за счёт того, что таблица виртуальных методов становится нелинейной..."
а в большинстве случаев и используются всякие интерфейсы. Так что все еще усложняется и я не удивлюсь если Вы не поймете, что могут существовать такие методы и приемы оптимизации, которые можно провести только анализируя непосредственное исполнение программы и которые невозможно вычислить на этапе обычной компиляции.
>Так что все еще усложняется и я не удивлюсь если Вы не поймете, что могут существовать такие методы и приемы оптимизации, которыекоторые начинают вызывать те методы, которые вам не требуются? :D
я как раз очень много этим занимался.
более того как раз по-этой причине и привёл (народ вообще не понял о чём речь :D) выше одну из методик (множественное наследование плюс шаблоны классов), которые позволяют уменьшить vtables или отказаться от них полностью.запомните, нет никакой оптимизации в процессе позднего связывания. этот вид шаманства придумали неучи. есть только выбор необходимого (и достаточного) типа/объекта.
если этот процесс нуждается в оптимизации в жабе, то это только говорит о саксбайдезигн и не более.
"нет никакой оптимизации в процессе позднего связывания" - расскажите это разработчикам Явы и процессоров Itanium & Elbrus. Думаю, они вправят вам мозги, уж они то всяко лучше вас разбираются и в Яве и в плюсах
Вы, конечно, извините, но какие в джаве свойства выражать абстракции, которых нет в плюсах? Насколько я помню, там как раз наоборот - длинные многословные вызовы, явно описывающие всё в делалях. Это на плюсах можно библиотекой паттерн-матчинг сделать :-)
> Вы, конечно, извините, но какие в джаве свойства выражать абстракции, которых нет
> в плюсах? Насколько я помню, там как раз наоборот - длинные
> многословные вызовы, явно описывающие всё в делалях. Это на плюсах можно
> библиотекой паттерн-матчинг сделать :-)Например, в Java есть дженерики (generics, настраиваемые типы), которые не есть шаблоны (как в C++), обеспечивают то же самое "обобщённое программирование" плюс ещё проверку на типовую безопасность (type safety) на стадии компиляции.
> всё это глупость чистой воды.
> это на вашу подготовку как жабиста было затрачено меньше средств, это да.
> а вот процесс реализации алгоритмов что в С++, что в java одинаков.
> при условии что вы владеете знаниями этих языков одинаково.
> уменьшение расходов на подготовку и распространение ПО — вот всё что бралось
> в расчёт при проектировании подобных систем.Вы не считаете затрат на компилирование проекта на C++ и Java. Для Java компиляция будет в несколько раз быстрее, программист получит результат быстрее, сможет отлаживать, исправлять код быстрее. Достаточно сравнить время компиляции таких равноценных по объёму строк исходных текстов проектов, как OpenOffice и Eclipse Classic, чтобы заплакать от горя, почему OOo такой монстр.
> что абсолютно не делает из халтуры что-то более ценное.
Пока что на C++ лучше, чем на Java, не написали то, что требуется бизнесу.
извини айзен, но после вот этого http://www.opennet.me/openforum/vsluhforumID3/88358.html#59 — практически признания тобой своего невежества, я даже нихочу тратить на твои рекламные лозунги своё время.
> извини айзен, но после вот этого http://www.opennet.me/openforum/vsluhforumID3/88358.html#59
> — практически признания тобой своего невежества, я даже нихочу тратить на
> твои рекламные лозунги своё время.Новых знаний в C++ нету. Рекламными лозунгами не разбрасываюсь.
Смешно читать про то как какой то студент хочет чтоб ему на яве чет там написали нетормозное, хотя сам только что еле выбрался из главы про сортировки. Ему бы рассказать про распределенные гриды на яве и почему большая проблема сделать это на плюсах, но даю 100% что этот студент даже поленится глянуть в гугле что это такое - он же уже все знает, а "профессор лопух"
набор ничего не значащих терминов, начитавшегося сми школьника.
хорошо что вы не были моим студентом, никогда бы не доучились.
зыж
>Ему бы рассказать про распределенные гриды на яве и почему большая проблема сделать это на плюсах, но даю 100% что этот студент даже поленится глянуть в гугле что это такое - он же уже все знает, а "профессор лопух"BIONIC это расскажите https://boinc.berkeley.edu/trac/wiki/DevProjects
перед потерей лица и своих 100%.
набор ничего не значащих терминов :) - я рад что учился не у Васможет ваши студенты напишут на ++ что нибудь типа http://www.oracle.com/technetwork/middleware/coherence/overv... ?
или http://www.slideshare.net/buzdin/gemfire-in-memory-data-grid ?тогда возможно я озабочусь Биоником ;)
> Магия начинается ... поскольку JIT разберет объекты в стек и встроит их методыСмешно, как вы даже не оптимизации, а стандартное поведение компилятора C/C++ считаете магией. Я в свое время переписывал модули для одной GIS с жавы на C++ - там этой геометрии завались было. Получил прирост 3.5x на ровном месте, такие дела.
> Это мешает для часто запускаемых и относительно недолго работающих
> приложений, но совершенно не является проблемой на серверах.Для идиотов никакие генетические проблемы платформы не являются проблемой. Для решения задачи нужно 10 серверов вместо двух? Пожалуйста, главное что мы наслушались какая жава ынтерпрайз. Студенты на плюсах пишут более эффективные приложения и быстрее, чем бородатые дядьки с кучей сертификатов на жаве, пытаясь обогнуть все ее косяки и тормоза? Да не может быть, нам же сказали что java экономит время программистов.
>> Магия начинается ... поскольку JIT разберет объекты в стек и встроит их методы
> Смешно, как вы даже не оптимизации, а стандартное поведение компилятора C/C++ считаете
> магией. Я в свое время переписывал модули для одной GIS с
> жавы на C++ - там этой геометрии завались было. Получил прирост
> 3.5x на ровном месте, такие дела.Простой компиляцией в нэйтив?
Вы не понимаете, что такое позднее связывание? Если на этапе компиляции не известно, какая именно реализация абстрактного метода может быть вызвана, компилятор C++ не сможет этот вызов соптимизировать и тем более встроить. В примере с функцией, выполняющей высисления с абстрактными геометрическими объектаими, конкретные типы этих объектов могут быть определены клиентским кодом и могут быть известны только во время выполнения.
> динамические оптимизации, зависящие от поведения программы во время выполнения.предсказание предсказаний! :)
Refal, 1967, Валентин Турчин, суперкомпиляция
> Refal, 1967, Валентин Турчин, суперкомпиляцияО да, вместо того, что посчитать сколько будет два яблока плюс два яблока,
они там начнут считать молекулярную массу каждого, потом посчитают ср. кв. отклонение,
потенциал заряженности эл.-магнт. поля и выведут через разность потенциалов на
поле Галуа, что получилось 3.8131415 яблок. И спишут 18% как погрешность вычислений,
на естественное испарение жидкости.
Всё верно. Только вместо "эл.-магнт." надо было "торсионного" писать.
Динамическую загрузку (и выгрузку) классов куда дели? Reflection? Без этих важных фич - это не Java, а некоторое слабое подобие.
вау, интересны бенчмарки - неужели быстрее будет? сомневаюсь, ибо GCно если так, если быстрее - то неужели можно будет писать быстрые программы на жабке без потребление памяти GCшкой??? тогда однозначно эпик вин
> вау, интересны бенчмарки - неужели быстрее будет? сомневаюсь, ибо GCВ лучшем случае, сократится время запуска приложений. Все остальное будет хуже (объяснил выше).
> но если так, если быстрее - то неужели можно будет писать быстрые программы на жабке без потребление памяти GCшкой??? тогда однозначно эпик вин
AOT-компиляция не отменяет необходимости в сборке мусора.
Есть еще GCJ (AOT-компилятор Java в составе GCC).
> Есть еще GCJ (AOT-компилятор Java в составе GCC).он не молодёжный
[по сравнению с тем что сделали в Subject]
А ещё есть Excelsior JET
http://en.wikipedia.org/wiki/Excelsior_JET
Ура! Ура! Ура! Теперь можно откомпилить i2p и после бинарник встраивать в ботнеты, предварительно краптанув и навесив прот!
> Ура! Ура! Ура! Теперь можно откомпилить i2p и после бинарник встраивать в
> ботнеты, предварительно краптанув и навесив прот!Я думаю что если у вас не хватало за столько лет умишка запустить gcj - ботнетом являетесь разве что вы сами :)
Годное начинание. Я бы NetBeans с удовольствием собрал в виде native-программы с родным для линя интерфейсом.
Главная проблема Явы в том, что она глупая и поощряет глупых программистов чувствовать себя программистами
какая глупость