>МОЖЕТ!!! Да может же! А проверки характерные для managed кода куда денутся?Испарятся?
>как делает это Си компилятор.
Зато си-компилятор не втюхивает с ножом к горлу всяческие проверки, сбор мусора и т.п..И - да, за счет этого вполне можно пальнуть себе в пятку если програмер дятел (buffer overrun, etc).Но если он не дятел - он может скажем заранее проверить данные и - тогда совсем не обязательно молотить лишнюю проверку где-то в глубоком цикле работающем с этим буфером например.А вот jit совсем не обязан знать что прогер вон там уже проверил входные данные и посчитал заранее что все ок, а поскольку managed то он никак не может допустить выход за пределы буфера и прочая.А значит-тупо воткнет проверок и т.п., просадив скорость в эти самые разы, т.к. половину цикла займут проверки на вшивость и прочая а не полезная деятельность.
>А также JIT например ничего не мешает профилировать методы на лету, инлайнить
>наиболее часто выполняющиеся, а не все и т.п.
Ага, только вот думать он не научится.И потому ради соблюдения managed может набить каких-нить проверок и костылей там где этого по факту было не надо.
>JIT может автоматически распараллеливать циклы на многопроцессорных машинах.
Это не только JIT может.И?Кстати а что если сишники-сиплюсплюсники тоже отпрофилируют и заинлайнят?Они то с включенным мозгом могут это и получше безмозглой железяки сделать в принципе.Или вообще читерство: мелкий кус на асме оптимизнуть.Вон кодеки-когда скорости мало - програмеры творят чудеса.И в итоге - рантайм детект типа проца и пинок в горячих циклах аккуратно оптимизнутого кода на асме под конкретные процы(как минимум, конкретные типы SIMD-команд).Кусочки небольшие, т.к. только для самых горячих циклов.Ну а фигли, когда хочется HD в реалтайме декодить а проца ну никак не хватает - еще и не так разопрешься :D. И какой там jit, оно простым сям то в пару раз может вставить влегкую.Я вон как-то компилил XVID "чисто на си" и сравнивал vs "C+asm вставки".Как-то не впечатлило.В смысле, сишная версия очень тормозная оказалась супротив "обычной" где си+асм.
>И отрыв от Си все дальше и дальше.
Ну так побейте вон сишную версию того же quicklz хотя-бы на яве.И хрен с ней с параллельностью, хоть на 1 ядре для начала - слабо?А то по бенчам авторов либы явистая версия сливает сишной в 2.5-3 раза при равных условиях.Жабисты злобно прошипели что дескать авторы оной либы не владеют явой и ... свалили в кусты.Вместо того чтобы выдать на гора переписанную ими версию либы "от тех кто явой владеет" которая бы натянула сишную версию, как это было ими разрекламлено :).Кстати если у вас не кластер а просто многопроцессорник - иногда распараллеливание дурную шутку играет, отравляя кэши процессора(ов) и т.п. - в итоге порой просаживая скорость вместо выигрыша.Такие приколы тоже бывают.
А так - у меня есть H.264 файлик который мой процессор еле-еле декодирует в реалтайме юзая x264 (с его си+асм вставками).А давайте вы его на яве натянете?Ведь вы же так круто оптимизируетесь на много ядер?У меня как раз 2 ядра у проца - нормально вполне.Ну и посмотрим как там jit по скорости - неукладывание в реалтайм в таком случае сразу видно, хи-хи.Не хотите? :D
>Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее.
Пожалуйста - сгенерите.Вон тот же quicklz - достаточно простой и при том чувствительный к скорости проца и памяти алгоритм.И планка известна - сишная версия.В отличие от абстрактного соревнования сам с собой при котором как ни ползи к финишу а номер 1 всяко будешь, тут вон результат "чемпиона мира по бегу" как точка отсчета есть.
>У вас пока получается 2+2=5, изучайте арифметику, а также азы компиляции и
>оптимизации.
Пока что любители тыкать в букварь не провели одинаковых честных сравнений :).В итоге в теории оно может и круто.А на практике доказать?В честном бенче?Почему жабисты или соревнуются сами с собой (рекорды ставят) или драпают в кусты?Это подозрительно... %)
