0 / 0 / 0
Регистрация: 25.01.2010
Сообщений: 19
|
|
1 | |
Правда что С быстрее чем С++?11.02.2010, 21:21. Показов 4746. Ответов 26
Метки нет (Все метки)
Имеется в виду на исполнении, а не на момент компиляции...
Наверняка такая тема уже была, но я не нашёл, если дадите ссылку также буду презнателен!
0
|
11.02.2010, 21:21 | |
Ответы с готовыми решениями:
26
Что может быть быстрее, чем math sqrt? Быстрее чем цикл C# работает быстрее чем С++ C программа компилируется быстрее чем C++ |
0 / 0 / 0
Регистрация: 25.01.2010
Сообщений: 19
|
|
11.02.2010, 22:48 [ТС] | 21 |
Эм, я слышал есть асемблерная вставка в Си и если на каком-то участке Си делает немного больше чем хотелось бы можно воспользоватся ею. А насчёт сравнения автамобился и черепахи, я согился бы если ты имел в виду скорость написания программы только в точности да на оборот (си -автомобиль).
0
|
Почетный модератор
7393 / 2639 / 281
Регистрация: 29.07.2006
Сообщений: 13,696
|
|
11.02.2010, 22:50 | 22 |
zim22, я код не читал. Допустим, в это примере асм быстрее. В моем примере асм не быстрее. А что это значит? Значит, фраза, что "асм еще быстрее" - вранье Правильно будет сказать - "в некоторых случаях асм еще быстрее". Смотри. Выше исключение из твоего правила. Могу еще 10 привести, но мне лень )
Добавлено через 51 секунду Chernomor, да ассемблерные вставки делать можно. Но я пока общался с человеком имел ввиду чистый С ). Хотя, в большинстве случаев так и делается - критичный для скорости код пишется на ассемблере. Чаще всего на ассемблере пишется математическая логика, сложные многочисленные рассчеты. И тут, действительно, ассемблер чаще всего выигрывает.
0
|
11.02.2010, 22:52 | 23 |
Си++ условно можно считать более медленным, чем Си в основном из-за того, что Си++ обладает гораздо бОльшей библиотечной поддержкой (я имею в виду то, что включено в стандарт). Есть шаблоны, которые позволяют, например, легко работать со списками. Но их реализация слишком универсальная и, например, у программиста нет возможности контролировать процесс выделения памяти. Если мы строим одновременно 10 списков (т.е. добавляем по одному элементу в каждый список по очереди), то в конечном итоге память разляжется так, что элементы разных списков будут лежать не подряд для каждого списка, а вперемешку. И в дальнейшем работа с одним списком из-за того, что он "дырявый", может оказаться медленней из-за того, что такая раскладка памяти плохо укладывается в кэш. Понятно, что для нормального приложения такая магия седьмого порядка не нужна, но там, где требется выжать 100% аппаратной мощности это окажется весьма критичным.
Ещё одной проблемой с точки зрения проивзодительности является обработка исключительных ситуаций. А точнее не сама обработка, а лишний код, который строится в каждой процедуре для того, чтобы этот механизм работал в соответствии со стандартом. Хотя современные компиляторы эту проблему решают достаточно хорошо (т.е. дополнительные расходы сводятся к минимуму), но такое есть не на всех архитектурах Навскидку больше не могу назвать конструкции ЯЗЫКА (а не библиотечной поддержки), где Си++ в чём-то принципиально уступал бы Си. Что касается ассемблера. На таких простых архитектурах типа i386, компилятор, как правило даёт код по скорости близкий к ассемблеру. Но когда в архитектуре заложены сложные аппаратные возможности (аппаратная накрутка циклов, всякие векторные и матричные операции, предикатные коды, ещё там куча всего), то компилятор, как правило, не в состоянии выжать максимум производительности в боевых режимах: для этого требуется профилирование и куча настроечных опций. Поэтому высокопроизводительные библиотеки обычно пишут либо полностью на ассемблере, либо с использованием ассемблерных вставок. Однако может случиться и так, что компилятор выдаст код лучший, чем на ассемблере, потому что компилятор "знает" про некоторые особенности архитектуры, которые сложно учесть при ручном программировании. Например, если идёт обработка нескольких массивов впермешку, то компилятор может разместить эти объекты в памяти так, чтобы данные при чтении-записи лучше проходили через кэш (чтобы не было выбивания данных из кэша). Для этого нужно хорошо себе представлять, как устроен кэш на конкретной версии процессора.
1
|
depict1
281 / 146 / 4
Регистрация: 11.07.2009
Сообщений: 606
|
|
11.02.2010, 22:53 | 24 |
0
|
11.02.2010, 22:57 | 25 |
zim22, по поводу твоего кода. Сильно зависит, какой ты использовал компилятор и с какими опциями. Может ты вообще оптимизации не включил
Добавлено через 3 минуты Вот ещё. Узкое место Си++ - это шаблоны. Когда компилятор видит шаблонную функцию, то он не вправе делать inline-подстановку, потому что в другом модуле может быть специализация шаблона (о которой компилятор не знает). Многие современные компиляторы используют режимы "вся программа" (когда в объединённом виде компилируется все модули, а не помодульная сборка), но для такого режима как правило достаточно маленького чиха, чтобы оптимизатор отваливал от многих ситуаций. Ассемблерная вставка вполне может быть этим "чихом"
0
|
Модератор
12458 / 7482 / 1753
Регистрация: 25.07.2009
Сообщений: 13,762
|
|
11.02.2010, 23:19 | 27 |
По-моему вообще неблагодарное занятие - сравнивать языки программирования. Каждый хорош в определённой ситуации. Писать какой-нибудь органайзер (типа аутлук) на ассемблере - занятие такое же бестолковое, как на том же С++ программулинку, которая должна в полтора килобайта помещаться и при этом решать какую-то параноидально критичную по времени задачу...
0
|
11.02.2010, 23:19 | |
11.02.2010, 23:19 | |
Помогаю со студенческими работами здесь
27
Sin быстрее чем из math.h Правда что new очень медленная? Правда ли, что все цифры равны Почему код, написанный на С++, в разы быстрее работает с большим объемом памяти, чем с маленьким? Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |