как такое может быть?

Можно так написать, что и 200% медленнее будет работать.

А насколько, примерно, хороший код на асме быстрей сишного в среднем?

Зависит от архитектуры. См. IA64

Скорость работы программ на ассемблере может быть более 50% медленнее, чем программ на ... как это может быть, если си сам транслируется в тот же самый ассемблер?

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

ну, допустим, если брать x86? Она ведь самая распространенная?

Насколько в общем случае, приблизительно, грамотный код на си будет медленней грамотно оптимизированного, качественного кода на асме?

Проблема в том, что качественный код на асме сложно написать. Компилятор:

• расчитывает, что выгодно помещать в регистры, а что нет;
• определяет и оптимизирует критические пути в коде;
• выравнивает функции, циклы, инструкции по выгодным адресам;
• выворачивает наизнанку и разворачивает циклы;
• выбирает наиболее выгодные инструкции и переупорядочивает их с целью максимально загрузить все модули процессора;
• и т.д.

Но компилятор один раз написали и он делает хорошо для большого количества кода, а человеку вот это всё надо делать самому. Это просто мало когда выгодно (может быть проще чем заставить компилятор генерировать нужные инструкции в некоторых случаях) из-за высокой трудоёмкости.

Напомню Java быстрее Fortran на 10%, видимо и си обойдет

Нафига на ту помойку ходишь, сиди на этой. Тут хотя бы царь пояснит.

А как же тогда Колибри ОС, смысл ее писать на асме, если можно было бы писать на Си, компилятор ведь тогда лучше сделает, и будет это быстрее чем писать код на асме человеком?

Как всегда возникает вопрос: какую задачу решает автор темы, чтобы задумываться о производительности?

Есть такие индивиды, что маются от безделия на уровне «высоких материй», оставаясь при этом не более результативными чем школьники в своих копаниях в сортах покемонов...

я решаю задачу: стоит ли учить асм или нет:). Интересно ли это и будет ли профит:) На си я в данный момент скептически смотрю, его скорость по сравнению с JS, если исходить из тестов, которые я нашел в сети, не впечатляет совершенно. Это, по разным оценкам 5-10 раз, а в некоторых случаях выигрыша вообще нет. Я подумал, что уж если влезать в низкоуровневое дерьмо, то профит должен быть хотя бы раз в 500, как минимум.

Я подумал, что уж если влезать в низкоуровневое дерьмо, то профит должен быть хотя бы раз в 500, как минимум

В таком случае я ответственно гарантирую - асм тебе изучать не требуется :) Я вот знал ассемблер микроконтроллеров PIC и AVR, они простые были, но я решил что правильнее писать на Си, потери эффективности я не обнаружил.

Где-то можно не зная ассемблер написать на самых обычных инструкциях наивный алгоритм который будет в разы быстрее любого компилятора, а где-то можно измучаться с simd и грамотным использованием конвееров и кэшей и в разы проиграть наивному алгоритму на C. Серебряной пули нет, язык ничего не гарантирует, любое «такое» «может быть» запросто, никаких общих случаев нет.

Всё что нужно помнить об оптимизациях - что о них нужно забыть и писать понятный высокоуровневый код. И только ЕСЛИ будет медленно, и только гам ГДЕ будет медленно можно написать АЛЬТЕРНАТИВНЫЙ вариант на асме, симд интринсиках и всём таком прочем. Обязательно только альтернативный поскольку 1) хитрый оптимизированный код ВСЕГДА нужно проверять эталонным понятным, 2) понятный рано или поздно имеет шанс сравняться с ним по скорости, 3) интринсики а тем более ассемблер работают далеко не на всех платформах

На асме сейчас в основном пишут не из-за того, что кусок кода на нем будет работать быстрее С, а для того, чтобы сделать вещи, которые на С сделать нельзя. Например, thunk'и в JIT-компиляторах (легковесные вызовы функций из сгенерированного кода в код рантайма), или просто для вызова кода с отличающейся calling convention, код перехватывающий системные вызовы (см. valgrind), ядерный/микроконтроллерный код работающий с перифирией

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

В общем, назрел еще вопрос. Насколько в общем случае, приблизительно, грамотный код на си будет медленней грамотно оптимизированного, качественного кода на асме?

Мне вот интересно, ты реально думаешь, что кто-то проводил подобные исследования, результатами которых будет здесь делиться? :-) Лол :-) Ну и встречный вопрос, ответ на который будет ответом и на твой вопрос :-) Как ты думаешь, способен ли человек обыграть в шахматы машину? :-)

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

Учить С и учить asm той платформы, под которую в основном будешь писать - обязательно, решать тут просто нечего. Будешь ли писать на них? Зависит от специализации. Можно ли не писав на С или asm хотя бы что-нибудь, но пробежавшись по учебникам обзорно понимать? Едва ли.

Он и там есть.

Сомнительное заявление.

стоит ли учить асм

Да, без вариантов.

Прогеры, умеющие в asm, вымерли. Остались питоно-макаки.

Аж передёрнуло от ужаса, представив как в древние времена горы энтерпрайзного говнокаода были на ассемблере, а не жабе етц.

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

Кроме того, знание ISA (instruction set architecture) идёт рука об руку с пониманием, как работает процессор (его микроархитектура), и даже без профилирования часто можно сказать, почему тот или иной подход будет плохо работать.

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

А как же тогда Колибри ОС, смысл ее писать на асме

Исключительно для самообразования и повышения асм-скила.

• приблизительно, грамотный код на си
• грамотно оптимизированного, качественного кода на асме

Певое добиться не сложно, второе — невиданный в дикой природе зверь. Выводы сделай сам.

способен ли человек обыграть в шахматы машину?

онон, ну ты сравнил.

давай я поправлю твой некаректный вапрос: «способен ли человек обыграть в шахматы програмизда, нопесавшего канпелятор?»

давай я поправлю твой некаректный вапрос: «способен ли человек обыграть в шахматы програмизда, нопесавшего канпелятор?»

Способен :-) А вот ассемблерный или шахматный выхлоп получается лучше у машины :-) Так что всё корректно :-)

Я тоже не согласен, сравнение совершенно кривое. Человеку, между прочим, даже арифметические операции в уме (скажем, с 4-х значными числами), даются не особо хорошо, если он не аутист, но он может написать арифметику, которая за него будет считать это говно. С другой стороны, трудновато будет реализовать компилятор, который будет сам писать арифметику.

Иными словами, компьютер может играть лучше человека, но, компьютер не способен написать программу, которая будет играть лучше человека (или, лучше компьютерной программы, написанной человеком).

Кстати, поигрался сейчас с хелловордами на nasm, они выдают бинари в сотни и тысячи раз меньше, чем аналоги на си, это о чем-то, да говорит.

он может написать арифметику, которая за него будет считать это говно

Ты всё правильно понял :-) И сам же пришёл к тому умозаключению, которое мне хотелось до тебя донести:

компьютер может играть лучше человека

В этом то и сила интеллекта - создавать инструменты, которые позволять превзойти физические ограничения :-) Например, самолёт :-) Ну и , в частности, поэтому до сих пор придумывают тонны высокоуровневых языков программирования, т.к. будучи удачно спроектированным, компилятор такого языка сможет автоматически выдавать лучший машкод при меньших усилиях :-)

Попробуй сравнить что-то длиннее хелловоролда и, как результат, больше по объёму дефолтно линкуемых gcc либ.

В этом то и сила интеллекта - создавать инструменты, которые позволять превзойти физические ограничения

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

Я еще раз повторюсь.

Повторение - мать учения :-) Ты начал сравнивать две существующих программы для существующего оборудования - сравнивать компиляторы C и Ассемблера:

Насколько в общем случае, приблизительно, грамотный код на си будет медленней грамотно оптимизированного, качественного кода на асме?

... а пришёл к задаче создания ещё не существующиего искусственного интеллекта :-) :

Когда человек сможет написать некий генератор игр(нечто более общее, чем просто игра), который сможет писать программы, типа игры в шахматы, в шашки, в покер и тп, без участия человека

Факт же в том, что на сегодняшний день существуют программы, созданные существующими людьми для существующего железа, способные уделать любого существующего человека в шахматы так же легко, непринуждённо и автоматически, как и уделать в части генерации машинного кода :-) Чтобы решить эти узкоспециализированные задачи генерации какого-то узкоспециализированного выхлопа не нужно создавать искусственный интеллект, достаточно железа с быстрой арифметикой :-)

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

Факт в том, что этим «ни ахти каким суперизобретением» пользуются практически все существующие ныне программисты, включая тебя самого :-)

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

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

Компилятор для начала надо написать.

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

Бесспорно, если в круг задач программиста входит эффективная(в смысле — быстрая и не требовательная к ресурсам) реализация какой-то задачи, то тут нет сомнения, что он должен иметь представление о железе и низкоуровневых вещах, но программирование не сводится к такой эффективности, более того, трудней всего в программировании не оптимизация, а построение модели.

Никак [/thread]

Как вебмакака?

Кстати говоря, в веб программировании, как раз, скорость вычислений не имеет определяющего значения. Там производительность измеряется не в скорости вычислений, а в способности обрабатывать большое количество запросов в единицу времени. Это, по-сути, ортогональные задачи, вторая связана с асинхронностью и масштабированием. То есть, вместо того, чтобы оптимизировать обработку запроса на конкретной машине, можно просто распределить вычисления по разным машинам. Примерно такой же подход применяется и в современных суперкомпьютерах.

Это с одной стороны. Так сказать в целом, то есть уже предполагается что разработчик имеет неплохую квалификацию и пишет более-менее быстрый код, не совершает совершенно глупых ошибок. Приведу конкретный пример: по событию нажатия на кнопку должно происходить скрытие, ну скажем сотни элементов(элементарное применение фильтров). На событие клика вешается обработчик, в котором каждый элемент, которые должен скрываться ищется с помощью, скажем $(), затем применяются какие-то классы к нему. Потом ещё пару раз ищется этот же элемент также и применяется что-то ещё. И это самый элементарный пример, в таком цикле могут быть поиски тысяч элементов, такое часто встречается на сайтах, люди потом удивляются что же тормозит, а тормозит такое массовое обращение к DOM. И это всё при том, что скрываемые элементы заранее могут быть известные в 90% случаев, то есть искать их даже не нужно. Но человек, с позволения сказать программист, он даже не знает разницу между хранением ссылки и поиском по довольно сложным структурам, откуда ему знать?

PS: и довольно часты случаи такого обращения что.куда.нибудь.штука.классная.великолепно.сделать('ой как хорошо'). Причём не единичного, а скажем для разных полей, в цикле и тд. И это при том, что на месте «нибудь» и «классная» могут быть даже не объекты, proxy для чего-нибудь тяжёлого. Опять же, если бы человек имел квалификацию, знал хотя бы что такое ссылки и указатели, то такой бодяги бы не писал. А знать что есть ссылки и указатели - это обязательно иметь хотя бы маломальский опыт работы с ними.

люди потом удивляются что же тормозит, а тормозит такое массовое обращение к DOM

Вообще то, обращение к DOM как таковое тут не столь критично. Тут критична будет перерисовка. То есть, ф-ции типа document.getElenent*, не создают тормозов, тормоза идут от того, что, например, вместо того, чтобы сформировать сразу, программно какой то блок, а затем зараз его отрисовать, человек перерисовывает каждый из элементов этого блока по отдельности.

Но, я бы не сказал, что это все так уж сильно относится к низкоуровневым вещам. Такие навыки и без того приходят с опытом.

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

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

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

И нет, такие навыки не приходят с опытом, есть не мало людей, точнее большинство, имея стаж в 10 лет и более продолжают писать такое говно. Причём потом ещё создают фреймворки и продвигают их на корпоративном уровне(вон гляньте на polymer хотя бы). Увы, опыт не компенсирует низкую квалификацию отсутствие мозга. Он помогает только, если человек расчёт вширь и вглубь, например начинает писать на С что-нибудь где-нибудь.

неправда. не вымерли ещё. но питоно-макак много, да.

ну да. зачем оптимизировать код, если можно поставить сервер помощнее? или два сервера, или три, или стопицот? зачем юзеру быстрая загрузка - пусть купит комп помощнее. зачем экономить ресурсы - пусть все закупают железо. и дешёвая вебмакака будет клепать говносайты пачками за китайскую лапшу.

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

ну да. зачем оптимизировать код, если можно поставить сервер помощнее? или два сервера, или три, или стопицот?

Ты, наверное, не поверишь, особенно если учесть твои познания в экономике, но зачастую такой подход действительно оправдан экономически. Алсо эти два подхода не являются взаимоисключающими.

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

наверное, поэтому большие и серьёзные компании, у которых дофига серверов, нанимают хороших программистов на С, а мелкие и дешёвые - вебмакак с кулинарного техникума.

Я усилю утверждение предыдущего оратора. При должном подходе, это экономически более выгодно. Это следует из простого расчета: сегодня стоимость мощного компа стоит значительно меньше труда программиста, тем более высококвалифицированного.

большие и серьёзные компании, у которых дофига серверов

У больших серьезных компаний основная направленность сейчас как раз идет на распределенные вычисления. Пример — гугл. Язык программирования как таковой тут не при чем.

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

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

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