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

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

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

Афигеть. Господа, а вам не приходит в голову, что любую задачу можно и на ассемблере и на Си закодировать несчетным множеством различных способов? И что выяснение самого оптимального из них — практически невыполнимая задача и мы можем довольствоваться только приближением к оптимуму?
Ассемблер дает больше возможностей для оптимизации, но, с другой стороны, сложность современных процессоров такова, что ручная оптимизация сколько нибудь значительных кусков кода займет очень много времени. ЯВУ позволяют программисту сосредоточиться на более эффективной алгоритмической оптимизации, а рутинный и изобилующий подводными камнями процесс кодогенерации под конкретный процессор компилятор берет на себя.

Спорно  

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

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

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

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

Недооцениваешь возможности современных компиляторов 

Intel C++ 9.0 выдал вот такой код:

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

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

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

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

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

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

Randall Hyde

The Great Debate

"Will Compilers Ever Produce Code as Good as an Expert Assembly Language Programmer?"

In English...

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

Не умирающая тема   

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


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

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

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

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

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

Это сообщение отредактировал(а) bsa - 22.7.2006, 22:50

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

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