Здравствуйте, VladD2, Вы писали:
VD>Дотнет не ява. В нем можно смело делать не виртуальные функции. Да в общем то и Яве можно. Более того. При наличии всего исходного кода (мсила или байткода) можно проанализировать его и сделать спекулятивные предположения о том, что виртуальные вызовы излишни (а это так в 90%) и устранить их. Интересно что Ява 1.4.2 уже делает это в некоторых случаях. Об этом же написано в описании проетка Интела — Star Jit.
Делает это не JIT, а HotSpot. Причем делает гораздо больше, чем просто раскрытие однозначно невиртуальных функций.
VD>Ну, профелируется это пого только в планах... но все же... Джит-компиляция не занимает не так много времени. Так что на скорости работы большинства программ это не отражается. Профилировка теоже не постоянно будет идти (да и ее можно выключать). За-то ее результат может существенно улучшить скорость.
В HotSpot'е профилируется уже лет эдак 4-5. И именно на основе профайл-информации некоторые виртуальные вызовы раскрываются в следующую конструкцию:
if (variable instance_of class_a)
{
class_a.foo(); // здесь понятное дело инлайн
}else{
variable.foo();
}
Подобная замена происходит если variable в >80% (примерно. точной цифры конечно же не знаю) является объектом класса class_a. Если в какой-то момент HotSpot поймет, что эта цифра уже не 80%, то произойдет откат оптимизации.
VD>В моем тесте было дцать отдельных тестов и конфигурация. Тут же я так и не понял что и где тестировалось.
Был выполнен один тест. Тот, исходник которого в статье. Вернее я сделал два теста, с использованием VCL и консолького приложения. Могут вот еще собрать все в таблицу:
VCL wo — VCL с оптимизацией
VCL w/o — VCL без оптимизации
Cons wo — консольное приложение с оптимизацией
Cons w/o — консольное приложение без оптимизации
В VCL приложении тестовый код выполнялся в обработчике нажатия на кнопку.
У меня просто есть возможность делать этот тест, я его сделал. Без каких-либо выводов с моей стороны.
Здравствуйте, adb, Вы писали:
VD>>Дотнет не ява. В нем можно смело делать не виртуальные функции. Да в общем то и Яве можно. Более того. При наличии всего исходного кода (мсила или байткода) можно проанализировать его и сделать спекулятивные предположения о том, что виртуальные вызовы излишни (а это так в 90%) и устранить их. Интересно что Ява 1.4.2 уже делает это в некоторых случаях. Об этом же написано в описании проетка Интела — Star Jit.
adb>Делает это не JIT, а HotSpot.
А что такое по твоему HotSpot?
adb> Причем делает гораздо больше, чем просто раскрытие однозначно невиртуальных функций.
Я вроде о том же.
adb>В HotSpot'е профилируется уже лет эдак 4-5.
Только тлку с него ноль. Про планы — это я про дотнет. Надеюсь там это даст лучший результат.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Eugene Danilenko, Вы писали:
ED>Был выполнен один тест. Тот, исходник которого в статье. Вернее я сделал два теста, с использованием VCL и консолького приложения. Могут вот еще собрать все в таблицу:
VD>А что препятствует? Не, ну, я еще понимаю аргументы о ЖЦ. Но джит? У него даже приемущество есть. Он же может оптимизировать под конкретный процессор. Уже сейчас оптимизация лучше чем у компиляторов С++ 90-ых кодов. И думаю не загорами время когда они сравняются.
Препятствует практика, которая показывает, что Java уходит в глубокий своп при больших аллокациях памяти (как это было сказано в одном из сообщений выше). И что значит компиляторы С++ 90-х годов? GCC 3.3.2 и VC 7.1 свежи как розы в букете на 8 марта. Не-е-т, простите, я не понимаю, как managed код со всеми своими вносящими избыточность наворотами может быть быстрее unmanaged при устранении этой самой избыточности в run-time.
Ладно, хватит мне спорить. Я сам как-нибудь это досконально проверю, и будет тогда у народа Yet Another Comparison Paper.
Здравствуйте, dextery, Вы писали:
VD>>А что препятствует? Не, ну, я еще понимаю аргументы о ЖЦ. Но джит? У него даже приемущество есть. Он же может оптимизировать под конкретный процессор. Уже сейчас оптимизация лучше чем у компиляторов С++ 90-ых кодов. И думаю не загорами время когда они сравняются.
D>Препятствует практика, которая показывает, что Java уходит в глубокий своп при больших аллокациях памяти (как это было сказано в одном из сообщений выше).
Это не подтверждается опытом разработчиков использующих Ёджиби и Джэспэ.
D> И что значит компиляторы С++ 90-х годов?
То и значит.
D> GCC 3.3.2 и VC 7.1 свежи как розы в букете на 8 марта.
Видимо потому что они появились намного позже 90-ых.
D> Не-е-т, простите, я не понимаю, как managed код со всеми своими вносящими избыточность наворотами может быть быстрее unmanaged при устранении этой самой избыточности в run-time.
Да где избыточность то? Я еще соглашусь, что С++ позволяет за счет хаков оптимизировать отдельные вещи. Но на счет изсбыточности это сказки про белого бычка.
D>Ладно, хватит мне спорить. Я сам как-нибудь это досконально проверю, и будет тогда у народа Yet Another Comparison Paper.
Можеш даже присоедениться кнашим тестам и научно доказать вред этой избыточности.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А что такое по твоему HotSpot?
