EvilChild wrote: > C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно > C>быстрее .NET. > А можно подробнее?
Есть программа на Java и C# — поиск "похожих" объектов в длинном списке.
Объекты — это некие "хэши" биометрических данных (если быть точным,
геометрии руки), причем еще для каждого хэша хранится история (20 штук
предидущих хэшей). "Похожесть" двух хэшей определяется достаточно
сложно, поэтому программа сначала строит для этого списка индекс, а
потом ищет с его помощью.
В общем, примерно 300 килобайт запутаного кода. У производителя он
изначально был только на C#, я его полуавтоматически перевел на Java.
Я тестировал сколько будет строится индекс для большой базы. При
использовании Sun JDK 1.4 и .NET FW2 лидировал .NET FW примерно с 30%
отрывом. После перехода на 1.6 скорость Java-версии стала примерно на
10% больше.
Здравствуйте, Cyberax, Вы писали:
C>Я тестировал сколько будет строится индекс для большой базы. При C>использовании Sun JDK 1.4 и .NET FW2 лидировал .NET FW примерно с 30% C>отрывом. После перехода на 1.6 скорость Java-версии стала примерно на C>10% больше.
EvilChild wrote: > C>Я тестировал сколько будет строится индекс для большой базы. При > C>использовании Sun JDK 1.4 и .NET FW2 лидировал .NET FW примерно с 30% > C>отрывом. После перехода на 1.6 скорость Java-версии стала примерно на > C>10% больше. > На 10% больше чем .NET'ная?
Да, больше чем .NETная. Хотя надо будет с .NET FW3 потестить.
Здравствуйте, IT, Вы писали:
IT>Думаю, что избавление от виртуальных методов позволяет не останавливать на них оптимизацию и, например, инлайнить, а иногда и полностью устранять вызов методов.
В том то все и дело, что дает это что-то только если речь идет местах где вызовы используются для сложения или сравнения. Даже в алгоритме сортировки такая оптимизация дает не более 30% выигрыша. А в средней ОО-программе вообще речь идет о долях процента.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Выигрыш есть достаточно заметный, так как branch instruction очень C>эффективно оптимизируется предсказателем переходов. У нас там в C>большинстве случаев она займет один-два такта.
Это голосвловные утверждения.
C>Сильно быстрее он никогда, собственно, и не был. Просто некоторые вещи у C>MS были более качественно оптимизированы. Ну и во фреймворке от MS C>меньше используется виртуальных вызовов из-за необходимости их явно C>указывать.
Ну, так в итоге быстрее? Далее без труда можно сделать вывод о том, что вопрос этот излишне раздувается и его важность преувеличивается.
C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно C>быстрее .NET.
Тесты в студию. Обсудим.
>> ОО-программе их применение просто незаметно. C>Заметны, очень даже заметны.
Мой опыт говорит об обратном. Е тебя есть что-то чем ты можешь обосновать свое мнение?
C>А вообще, inlineing (не только виртуальных методов) — это самая C>эффективная оптимизация.
Это чушь. Большинство методов выполняют столь большой объем работ, что время на вызов просто нивелируется.
Я уже устал повторять, что время вызова влияет только в тех случаях если в методах выполняются микроскопические операции (занимющие еденицы инструкций). А такие опрерации обычно завернуты в разные библиотеки и фрэйворки. В прикладном коде их практически нет. Соотвественно влияние инланинга очень незначительное.
Инлайнинг рулит в пенисометрии, но на практике он далеко не так ощутим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Смысл? Рантайм то тот же.
Не тот же делегаты похоже ускорились.
Проблема в том, что это все треп. Надо смотреть реальные тесты. Там столько мест где могут быть расхождения. Скажем используемые контейнеры, или качество эша.
И вообще, то снова разговор о каких-то мало заметных на глаз величинах и каком-то редко-встречающемся коде. Основной код приложений — это работа с довольно большими объектами. И там вся эта лабуда мало ощутима.
Просто товарищь Киберакс имеет нехилый такой пунктик в области быстродействия и явно не может адекватно оценивать этот вопрос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали: C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно C>быстрее .NET.
... C>После перехода на 1.6 скорость Java-версии стала примерно на C>10% больше.
Самому то не смешно? 10% это значительно? Уверен, что качетсво хэш-фукнций и различие алгоритмов в хэш-таблицах влияет намного больше.
К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, x-code, Вы писали:
VD>>Поясни, а с чего это для тебя стало поводом? XC>я не хочу чтобы функция при первом вызове работала дольше чем при последующих.
А ничего что ты в упор разницы незаметишь?
XC>хотя, честно сказать, я серьезно C# не занимался, мне просто стало интересно почему пошла такая тенденция перехода к виртуальным машинам.
Уж точно не из-за скорости запуска ехе-шников.
Тут дело в том, что на безопасных языках со сборкой мусора писать быстрее и легче. А это реальное конкуретное приемущество.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
>>> Ну потому как зоопарк возник, нет обобщенного AST, .>>Ну почему — есть и такая штука, обобщённое AST на "все случаи жизни" — это XML.
K>Не, есть штука ещё обобщённее — Лисп
VladD2 wrote: > C>Выигрыш есть достаточно заметный, так как branch instruction очень > C>эффективно оптимизируется предсказателем переходов. У нас там в > C>большинстве случаев она займет один-два такта. > Это голосвловные утверждения.
Собствено, с чем именно ты споришь? С тем, что branching медленнее
косвенного перехода?
> C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно > C>быстрее .NET. > Тесты в студию. Обсудим.
Сложно. Кусок кода достаточно большой, да еще и под NDA.
А микротесты тебе не нравятся.
Что предлагаешь?
>> > ОО-программе их применение просто незаметно. > C>Заметны, очень даже заметны. > Мой опыт говорит об обратном. Е тебя есть что-то чем ты можешь > обосновать свое мнение? Моим опытом
> C>А вообще, inlineing (не только виртуальных методов) — это самая > C>эффективная оптимизация. > Это чушь. Большинство методов выполняют столь большой объем работ, что > время на вызов просто нивелируется.
get/set методы...
А вообще, история с qsort и std::sort как бы вообще никем не оспаривается.
VladD2 wrote: > C>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно > C>быстрее .NET. > ... > C>После перехода на 1.6 скорость Java-версии стала примерно на > C>10% больше. > Самому то не смешно? 10% это значительно? Уверен, что качетсво > хэш-фукнций и различие алгоритмов в хэш-таблицах влияет намного больше.
На 10% быстрее .NETовой.
> К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации.
А как ты мой код так видишь через 1000 километров?
Этот код вообще был не мой, а предоставлен вендором устройства. Там я
при переписывании вообще ничего не трогал, за исключение банальных
подстановок контейнеров и прочей ерунды.
Здравствуйте, Cyberax, Вы писали:
>> Самому то не смешно? 10% это значительно? Уверен, что качетсво >> хэш-фукнций и различие алгоритмов в хэш-таблицах влияет намного больше. C>На 10% быстрее .NETовой.
Вижу, не глухой. Ты внимательнее читай.
>> К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации. C>А как ты мой код так видишь через 1000 километров?
Я тебя знаю.
C>Этот код вообще был не мой, а предоставлен вендором устройства. Там я C>при переписывании вообще ничего не трогал, за исключение банальных C>подстановок контейнеров и прочей ерунды.
Вот "ерунда" может оказать очень значительное влиятие.
Для сравнения именно JIT-ов это негодится. Тут нужно иметь полностью идетничные алгоритмы (вплоть до контейнеров). А еще лучше сравнивать не только показатели, но и генерируемый ассебленый код. Вот только как его на Яве полчить я не знаю. Это на дотнете то проблематично.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: >> > К тому же это не ОО-код. А какие-то Киберакс-лайк оптимизации. > C>А как ты мой код так видишь через 1000 километров? > Я тебя знаю.
> C>Этот код вообще был не мой, а предоставлен вендором устройства. Там я > C>при переписывании вообще ничего не трогал, за исключение банальных > C>подстановок контейнеров и прочей ерунды. > Вот "ерунда" может оказать очень значительное влиятие.
Тут более интересно ускорение JVM — оно примерно на 30% быстрее стало
работать по сравнению со старой версией.
> Для сравнения именно JIT-ов это негодится. Тут нужно иметь полностью > идетничные алгоритмы (вплоть до контейнеров). А еще лучше сравнивать не > только показатели, но и генерируемый ассебленый код. Вот только как его > на Яве полчить я не знаю. Это на дотнете то проблематично.
Ассемблерный код при желании получить можно, надо только собрать JVM с
поддержкой отладки.
Здравствуйте, Cyberax, Вы писали:
C>Тут более интересно ускорение JVM — оно примерно на 30% быстрее стало C>работать по сравнению со старой версией.
Еще раз повторяю, никаких выводов из таких поверхностных тестов сделать нельзя.
Может они подправили хэш-табличку или еще что.
C>Ассемблерный код при желании получить можно, надо только собрать JVM с C>поддержкой отладки.
Ну, это гемор на который лично я не решусь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Тут более интересно ускорение JVM — оно примерно на 30% быстрее стало > C>работать по сравнению со старой версией. > Еще раз повторяю, никаких выводов из таких поверхностных тестов сделать > нельзя. Может они подправили хэш-табличку или еще что.
Это вряд ли. Только что проверил — хэши для строк, байтовых массивов, и
BigDecimal'ов совпадают.
> C>Ассемблерный код при желании получить можно, надо только собрать JVM с > C>поддержкой отладки. > Ну, это гемор на который лично я не решусь.
Аналогично. Хотя можно попробовать скачать скомпиленую версию из проекта
OpenJDK, но я с ним еще не разбирался.
Здравствуйте, Cyberax, Вы писали:
>> C>А вообще, inlineing (не только виртуальных методов) — это самая >> C>эффективная оптимизация. >> Это чушь. Большинство методов выполняют столь большой объем работ, что >> время на вызов просто нивелируется. C>get/set методы...
Так тривиальные get/set инлайнятся даже в отладочной сборке в .NET (пару раз обламывался в дебаггере) — JVM не инлайнит такое?
По идее должен.
Вообще было бы прикольно глянуть сводную таблицу run-time оптимизаций, которые выполняют CLR и JVM — никто не натыкался?
now playing: Sinthetix — Neurotoxin (feat. MC Mecha)
Здравствуйте, IT, Вы писали:
C>>>А Sun JDK 1.6 теперь по некоторым моим тестам работает значительно C>>>быстрее .NET.
EC>>А можно подробнее?
IT>Это действительно так. Особенно сильно вырывается вперёд серверный вариант. Это заметно даже по шустрикам на нашем сайте.
Если нам не помогут, то мы тоже никого не пощадим.
