Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Общие вопросы > Кто быстрее


Автор: HellanD 17.7.2006, 20:59
Обясните мне!!
Дело в чем сначала и в АСМ и в С создается обектный файл который потом превращается в набор нулей и едениц (машинные коды), а разве они разные по скорости работы???
Почему же говорят что програмы на АСМ производительнее???
Не правильно ли думать что программы на АСМ быстрее компилятся и только и того??!
Спасибо за ответ
  

Автор: nikitao 17.7.2006, 21:05
HellanD,  нет асма быстее по определению, т к язык низкого уровня, а С высокого. smile  

Автор: HellanD 17.7.2006, 21:24
Цитата

 нет асма быстее по определению, т к язык низкого уровня, а С высокого.  


Дело в чем сначала и в АСМ и в С создается обектный файл который потом превращается в набор нулей и едениц (машинные коды), а разве они разные по скорости работы???
Какая разница между машинными кодами сделанными с помощью С и АСМ???? И там 0 1 и здесь!!! 

Автор: Void 17.7.2006, 21:33
Афигеть. Господа, а вам не приходит в голову, что любую задачу можно и на ассемблере и на Си закодировать несчетным множеством различных способов? И что выяснение самого оптимального из них — практически невыполнимая задача и мы можем довольствоваться только приближением к оптимуму?
Ассемблер дает больше возможностей для оптимизации, но, с другой стороны, сложность современных процессоров такова, что ручная оптимизация сколько нибудь значительных кусков кода займет очень много времени. ЯВУ позволяют программисту сосредоточиться на более эффективной алгоритмической оптимизации, а рутинный и изобилующий подводными камнями процесс кодогенерации под конкретный процессор компилятор берет на себя.
Цитата(nikitao @  17.7.2006,  23:05 Найти цитируемый пост)
С высокого.

Спорно smile 

Автор: sergejzr 17.7.2006, 21:34
Дело в том, что си "состоит" из стандартных конструкций.
Например в си можно получить или остаток от деления, или результат. В асме можно получить одним действием и то и другое. 
 

Автор: Void 17.7.2006, 22:49
sergej.z, функция div в stdlib.h. Уверен, большинство компиляторов соптимизирует ее именно до той самой инструкции. 

Автор: dumb 18.7.2006, 00:40
имелось ввиду то, что если ты захочешь поколдовать и с целой частью и с остатком, то компилер вряд ли догадается не делать второе деление.

ps. вроде как незнание не освобождает от ответственности? - провокация холивара. smile 

Автор: Void 18.7.2006, 00:49
Цитата(dumb @  18.7.2006,  02:40 Найти цитируемый пост)
если ты захочешь поколдовать и с целой частью и с остатком, то компилер вряд ли догадается не делать второе деление.

Недооцениваешь возможности современных компиляторов smile
Код
#include <cstdio>
#include <cstdlib>

int main() {
    int a = rand(), b = rand();
    int quot = a / b, rem = a % b;
    printf("%d %d\n", quot, rem);
}

Intel C++ 9.0 выдал вот такой код:
Код
;;;    int a = rand(), b = rand();
        call      _rand                                         ;5.10
        mov       esi, eax                                      ;5.10
        call      _rand                                         ;5.22
        mov       ecx, eax                                      ;5.22
;;;    int quot = a / b, rem = a % b;
        mov       eax, esi                                      ;6.17
        cdq                                                     ;6.17
        idiv      ecx                                           ;6.17
        push      edx                                           ;6.30
        push      eax                                           ;6.30
        push      OFFSET FLAT: ??_C@_06A@?$CFd?5?$CFd?6?$AA@    ;6.30
;;;    printf("%d %d\n", quot, rem);
        call      _printf

MSVC 8.0 тоже не подкачал. 

Автор: sergejzr 18.7.2006, 00:49
Void прав. Функция есть такая. (результат и остаток вырешиваются автоматом одно без другого не имеет смысла).
Маленькие кусочки кода можно ассемблером оптимировать, но когда касается более менее комплексных проектов...
Получается, что из за особенностей языка иногда приходится перекраивать весь дизайн. 

Автор: Void 18.7.2006, 00:52
Я не склонен преуменьшать роль ассемблера. Многие оптимизации, особенно связанные с использованием SIMD-инструкции современным компиляторам не по плечу. Даже могучий «интеллект» ICC способен провести их только в некоторых простых случаях. Но “premature optimization…” и далее по тексту smile 

Автор: dumb 18.7.2006, 02:25
Цитата(Void @  18.7.2006,  00:49 Найти цитируемый пост)
Недооцениваешь возможности современных компиляторов


с горкой пепла на голове пошел сносить TC2.0... smile

а есть тут такие, кто пользуется в "серьезных разработках" современными компиляторами? smile

ps. насколько я понял, наши точки зрения на вопрос "asm vs HLL" абсолютно совпадают, посему ой. 

Автор: SergeCpp 18.7.2006, 08:15
Randall Hyde

The Great Debate

http://webster.cs.ucr.edu/Articles/GreatDebate/index.html

In English...

7,240,406 посещений с 1 января 2000 

Автор: Sardar 18.7.2006, 11:25
Не умирающая тема  smile 

На асме можно написать код к скорости которого обычному компилеру не приблизиться. НО! у человека просто физически не хватить "мозга" удержать всё это в голове, появиться фактор лени, когда вместо того что бы положить блок константных строк в память и строить сылки на участки программист просто копирует части строк собирая новую строку. Строки наиболее вредная, рутинная работа, потому упомянул smile

Цитата(sergej.z @  17.7.2006,  20:34 Найти цитируемый пост)
Например в си можно получить или остаток от деления, или результат. В асме можно получить одним действием и то и другое. 

Опять же физически у человека не уложиться в голове какие оптимизации можно провести. Когда выполняеться часть вычислений, а затем спустя пару десятков инструкций "на другую тему", былое значение "случайно" оказываеться в регистре и пользуеться. Другими словами вычисление нескольких формул может перемешаться, если компилер уверен какие там будут значения. Человеку не реально (нет я нисколько не сомневаюсь в ваших способностях smile ) отслеживать в уме более 3-5 "вычислений" одновременно. Компилер, если это не ad-hoc на коленке как раньше, а по теории, может всё и главное компилер совершенствуеться, прога с кажды разом становиться быстрей (перекомпилируеться) smile

А главное свет не сошёлся клином на х86 ахитектуре, где мало регистров. Попробуйте на каком нибудь RISC с доброй сотней регистров написать  чего нибудь эффективно. Вот имено там появляеться больше свободы для компилера, когда он экономит не на паре инструкций (ловля блох), а вообще на логике исполнения.

Про не переносимость и не говорю, один раз напсал, спустя пару лет код умрёт, если только это не какая нибуть утилита. Да и та умрёт, запарит к ней возвращаться когда код перестанет укладываться в голове.

P.S. писал на асме под 8051(2) микроконтроллеры, также под соверменный ez80 (тоже контроллер и веб сервер), ну енто нафих  smile   

Автор: bsa 22.7.2006, 22:47
Писал и пишу на ASM Z80. Если честно - надоело. Но альтернативы ассемблеру нет.
Написание большого проекта на ASM не представляет большой проблемы. Есть три минуса: время на написание, время на отладку и непереносимость. Есть плюс - скорость работы готового продукта.
Много времени уходит на начало создания проекта - на написание всех базовых функций... На последнем этапе программа, в основном, состоит из вызовов процедур, условных переходов вперед и циклов - переходов назад.
Я лично на 100% уверен, что идеально оптимизированные программы на C (или другом языке высокого уровня) (если конечно не писать на си, как на ассемблере) и ASM будут работать с разной скоростью (в пользу последнего). Ну не существует идеальных компиляторов с языков высокого уровня! С другой стороны, а оно того стоит? Разве стоит полгода работы то, что можно сделать за неделю/месяц, но работать будет на 20% (а то и меньше) медленнее? Имхо, нет. 

Автор: Mayk 23.7.2006, 19:29
Кстати. Ставлю десятку, что код на си получается в частности медленнее, чем на асме, потому что сишный код транслируется в асм.

Если бы процессоры могли исполнять инструкции си, но не ассемблера, то было бы наоборот(сишный код исполнялся бы быстрее).

 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)