LINUX.ORG.RU
ФорумTalks

Развенчан миф о преимуществе в скорости C перед языками высокого уровня


0

0

http://www.awprofessional.com/articles/printerfriendly.asp?p=486104&rl=1

C, как писали авторы Керниган и Ритчи, не является языком высокого уровня. За прошедшие со времени создания C 30 лет он утратил свое преимущество в виде написания программ в виде инструкций, близких к машинным. В статье приводятся примеры исследований, проводившихся около 2000 года с рекомпилятором Dynamo, и показавших, что компиляция-во-время-выполнения может давать код на 10-20% более эффективный по скорости, чем статическая компиляция. Причина в том, что виртуальные машины могут применять определенные оптимизирующие методики, недоступные статическим компиляторам.

Компиляторы C также физически не могут инлайнить функции, описанные в другом файле, а между тем затраты на вызов функции на многих архитектурах процессоров очень высоки и для коротких методов порой время потраченное на вызов функции оказывается больше, чем проведенное в теле самой функции. ЯВУ же могут инлайнить такие вызовы в рантайме.

Поэтому программы на таких языках высокого уровня, выполняющихся в виртуальной машине, как Java, в эпоху современных процессоров могут вполне соперничать по скорости с программами на C.

anonymous

>Поэтому программы на таких языках высокого уровня, выполняющихся в виртуальной машине, как Java, в эпоху современных процессоров могут вполне соперничать по скорости с программами на C.

пиар и провокация флейма. Хотя можно померять, с какой скоростью начинает сосать жаба, когда у ей память заканчивается :)

geek ★★★
()

Не верю.. Очередное сенсационное разоблачение, оказавающееся на поверку мыльным пузырём..

MiracleMan ★★★★★
()
Ответ на: комментарий от MiracleMan

Доли правды конечно есть, JIT-компиляция действительно может подстраиваться под текущую архитектуру. Реальная ситуация показывает, что си превосходит только ассемблер.

anonymous
()
Ответ на: комментарий от anonymous

>Ну нафиг! Весь QNX на жабу переписывают!.. =)

Хорошая шутка.. :-)))

MiracleMan ★★★★★
()
Ответ на: комментарий от anonymous

>Доли правды конечно есть, JIT-компиляция действительно может подстраиваться под текущую архитектуру. Реальная ситуация показывает, что си превосходит только ассемблер.

Это да.. Но тут также не стоит забывать и об эффективности и качестве самого кода.. Именно так, да.. о реальных ситуациях всё верно сказано..

MiracleMan ★★★★★
()

> Компиляторы C также физически не могут инлайнить функции, описанные в другом файле

Поэтому будем использовать ассемблерные вставки :)

unnamed
()
Ответ на: комментарий от schumen

>Твою бы настырность, да в мирное русло =)

Это Шома виноват. тфа раза удалял новость

anonymous
()

> В статье приводятся примеры исследований, проводившихся около 2000 года с рекомпилятором Dynamo, и показавших, что компиляция-во-время-выполнения может давать код на 10-20% более эффективный по скорости, чем статическая компиляция.

... а может и не давать, зависит от ситуации. И чё?

anonymous
()

> Компиляторы C также физически не могут инлайнить функции, описанные в другом файле

Ложь. Ultra C умел это 10 лет назад. В GCC планируется такая фича.

tailgunner ★★★★★
()

Полубаян.
Динамическая компиляция принципиально мало отличается
от динамической или отложенной линковки.

Время первых прогонов каждой функции будет больше, чем у
статически оптимизированного кода.

zaregazza
()
Ответ на: комментарий от hatefu1_dead

> ада же делает упор на надежность, а не на скорость.
особенно в real-time системах )))
про аду вернее сказать на надёжность и скорость

И вообще я понять не могу, КАК C может быть быстрее ассемблера? Что за бред? Сами же называете "C - ассемблер высокого уровня". Как ассемблер высокого уровня может быть быстрее ассемблера низкого уровня? к тому же грамотный asm-программист в сложных случаях даст фору любому C - компилятору (имеется ввиду только скорость выполнения программы).

ksicom
()
Ответ на: комментарий от ksicom

> И вообще я понять не могу, КАК C может быть быстрее ассемблера? Что за бред?

Как два байта переслать. Читал Брукса? У него приводился пример, что большая нетривиальная прога на PL/I была быстрее аналогичной проги на Ассемблере (в 1.5 раза, кажется). Оптимизирующие компиляторы рулят.

> грамотный asm-программист в сложных случаях даст фору любому C

_такие_ сложные случаи редки. И они не попадают в бенчмарки из-за своей редкости :)

tailgunner ★★★★★
()
Ответ на: комментарий от ksicom

>Как ассемблер высокого уровня может быть быстрее ассемблера низкого уровня?

Ассемблер не делает за программиста оптимизацию. ЯВУ - делают.

Если писать тяп-ляп - то ЯВУ, в среднем, конечно, будет медленнее. Если писать, воююя за каждый такт - то _можно_ на ассемблере анписать быстрее, чем на ЯВУ. Но средний продвинутый программист при реальных затратах времени на проект на ЯВУ напишет код более быстрый, чем на асме.

Практический пример. Мой опыт программирования на O'Caml == 0. Первую же тестовую программу, вычисление функции Аккермана от трёх аргументов, я пишу на нём за 7 минут, включая поиск информации по языку в Интернете. Программа работает сразу и правильно. Размер программы 13 строк пространной записи. 244 байта.

На Ассемблере x86 мой опыт программирования составляет года три или четыре. Эту же функцию я пишут минут 10. Потом ещё около 35 минут отлаживаю. В итоге, где-то через час имею результат. Программа в 47 строк и 865 байт.

В итоге программа на O'Caml работает в полтора быстрее :D

KRoN73 ★★★★★
()
Ответ на: комментарий от ksicom

>Как ассемблер высокого уровня может быть быстрее ассемблера низкого уровня?

Ты статью то по ссылке читал? Там написано, что в современном проце одномоментно находится на исполнении|в кэшах|конвейерах около 150 инструкций. Нет ни одного человека, который был бы способен оптимизировать такое количество исполняющегося кода. Только компилятор. Поэтому ассемблер сасет.

anonymous
()
Ответ на: комментарий от anonymous

> Реальная ситуация показывает, что си превосходит только ассемблер.

А как же lisp (в реализациях cmucl и sbcl)? Луговский пожрет ваш мозг.

anonymous
()
Ответ на: комментарий от geek

>пиар и провокация флейма. Хотя можно померять, с какой скоростью начинает сосать жаба, когда у ей память заканчивается :)

...примерно с такой же скоростью с какой и С, когда у него закончится память.

lexius ★★
()
Ответ на: комментарий от anonymous

>Нет ни одного человека, который был бы способен оптимизировать такое количество исполняющегося кода. Только компилятор.

Даже компилятор не поможет в абсолютном случае.

В наше время эффективный порядок кода может различаться даже в зависимости от того, что процессор делал перед запуском программы :) Именно в зависимости от конвейеров и т.п.

KRoN73 ★★★★★
()

Где-то когда-то прочитал такую мысль: никакой компилятор не может быть быстрее ассемблера, потому что мы всегда можем заставить его выдать ассемблерный код (gcc -S, например), а потом этот код ещё руками оптимизировать. :)

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

> потому что мы всегда можем заставить его выдать ассемблерный код (gcc -S, например)

Это правда.

> а потом этот код ещё руками оптимизировать. :)

А это пиздеж.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.