Линус Торвальдс опубликовал (http://www.linuxfoundation.org/news-media/blogs/browse/2009/...) заметку о все большем усложнении работы, когда требуется получить предсказуемый результат от GCC, без вмешательства оптимизатора. Отмечается, что компилятор становится слишком умным, что мешает использованию Си в роли высокоуровневого ассемблера, так как все труднее и труднее предсказать какой результирующий код будет сгенерирован.При тестировании на машине с многоядерным CPU архитектуры Nehalem, написанная для уменьшения числа зависимостей кода GIT реализация алгоритма хэширования SHA1 на языке Си с использованием ассемблерных вставок, оказалась быстрее оптимизированного вручную варианта на языке ассемблер, поставляемого в составе пакета OpenSSL.
URL: http://www.linuxfoundation.org/news-media/blogs/browse/2009/...
Новость: http://www.opennet.ru/opennews/art.shtml?num=22968
си теперь быстрее асьмы? не верю...
как бы да, получилось быстрее из-за автоматического распараллеливания.
Это говорит лишь об их умении программить на асме...
Ведь итоговый код все равно получается фактически на нем...Т.е. имеется ввиду, что компилятор сумел соптимизировать код круче человека.
>Ведь итоговый код все равно получается фактически на нем...Наверное он в машинном коде в конце концов получается, и в свою очередь ещё и от процессоров зависит на которых будет исполняться.
Неправда ваша, не читали вы исходники.Ассемблер там, ассемблер. Просто он в виде макросов и разворачивается в много-много ассемблера по месту использования макроса.
ручное там распаралеливание
понимаете ли, всё зависит от кода а не от языка, уверен что Вы не напишите парсер XML на асме, который будет быстрее чем перловый.
в языке перл нет xml парсера. Xml парсеры реализуются сторонними библиотеками.
какое это имеет значение? если парсер реализован для перла он что не перловый?
>какое это имеет значение? если парсер реализован для перла он что не
>перловый?для перла парсер XML не реализован - реализован доступ к библиотекам парсера.
а библиотека парсера, это что не реализация парсера для перла?
библа сишная (вернее например сишная. и так много всяких парсеров xml уже есть. и dom, и sax. помоему и на перле что-то есть). и реадизована для си. а в пёрле биндинги.и если задаться целью, то на асме можно написать очень быстрый парсер.
с другой стороны, на пёрле тоже можно написать (расширив его на си в котором ассемблерные вставки :-D)
>библа сишная (вернее например сишная. и так много всяких парсеров xml уже
>есть. и dom, и sax. помоему и на перле что-то есть).
>и реадизована для си. а в пёрле биндинги.
>
>и если задаться целью, то на асме можно написать очень быстрый парсер.
>
>с другой стороны, на пёрле тоже можно написать (расширив его на си
>в котором ассемблерные вставки :-D)например сишная или например перловая, какая разница. на перле нарсить XML быстрее чем на асме(смотря конечно как написать на асме, но сомневаюсь что здесь есть такие таланты), если хочешь поспорить давай спорить реальным кодом.
спорить? о чём? читай пост внимательней.
в асме есть теже готовые библиотеки и примитивы всех основных типов (не так много как в пёрле или с/с++, но всё-таки). и писать на нём конечно сложнее, но не так страшен чОрт, как его малюют. опять же, из асма с таким же упехом можно вызывать сишную библу. даже быстрее - биндинг не нужен.
зы:
если что, то я асм 3-и года преподавал. основной его плюс - абсолютная свобода в манипулировании памятью, что очень важно для скорости в такой вещи, как например построение dom и парсинг. sax конечно проще будет в perl (да и саксов там уже не мало). а вот если Вы сами парсер будите реализовывать, то ещё не известно кто быстрей - Вы на пёрле или я на асме. а уж у кого более быстрый парсер получиться - лично я не сомневаюсь.
Суть моего высказывания в следующем:
Быстреее работает тот код который качественей, а не на каком языке написан, и если писать какую нибудь сложную задачу на асме и на каком нибудь скриптовом языке (в пример я привёл перл), то с большой уверенностью могу сказать что вы не оптимизируете код на асме так чтобы он работал быстрее скриптового языка, для котого уже было создано решение давно и только оптимизировалось с годами.
И если человек удивился что C работает быстрее асма, то вероятно ничего не понимает в предмете о котором говорит.
Всё зависит от качества кода и сложности поставленной задачи.
>Быстреее работает тот код который качественей, а не на каком языке написанабсолютно согласен.
но, если код написан качественно на более низкоуровневом языке (что сложнее), то он будет эффективнее, чем такой же по качеству код на более высокоуровневом языке.
поэтому всегда идет компромис между скоростью разработки и качеством.
есть пословица к этому случаю - лучшее, враг хорошего.
> Быстреее работает тот код который качественей, а не на каком языке написан,Не совсем так. Корректнее сказать что можно и на асме написать говнокод, сольющий даже перлу. Но один и тот же кусок писаный на сях и на перле нормальными програмерами в случае сей скорее всего будет заметно шустрее перлового.При том поклонники скриптоязыков а также жаб и дотнетов почему-то всегда бубнят про возможности оптимизации.Проблема только в том что случаи когда это тормозилово натягивает си(++) редки и в основном - за счет лажи тех кто на сях писал, а не за счет того что "%s - круче чем си".А вот мифические оптимизации почему-то так и остаются мифами в основном.
Только недавний пример: yum, кусок шыта писаный на питоне - на (виртуальной) машине с 128 мегов тормозит чтопиндец а при установке чего-то большого, типа пых-пыха еще и валится иногда по нехватке памяти. Это что, чисто чтобы установить софт в консольке теперь 128 метров порой - мало?! А почему в тех же условиях работает apt-get, писанный IIRC на сях++?И не тормозит...
Когда нужно написать сложный алгоритм (например парсер регулярных выражений), если ты будешь писать код с нуля на асме, в любом случае получится говнокод, так как человеку тяжело (или даже не возможно) в голове представить все команды которые передаются процессору, на более высокоуровневых языках компилятор (или препроцессор) оптимизирует код лучше человека. Конечно же это не правило, а исключение для случаев когда алгоритм достаточно сложный.
>компилятор (или препроцессор) оптимизирует код лучше человекате чудеса оптимизации, которые вы подразумеваете, остаются мечтой.
компилятор не способен улучшить алгоритм, он только может сделать его чуть-чуть быстрее - развернуть, отбросить лишние операции копирования или сравнения - чем компилируя прямо по написанному.
>так как человеку тяжело (или даже не возможно) в голове представить все команды которые передаются процессоруТут все зависит от конкретного программера и его опыта. Если ты пишешь преимущественно на си/перле/чем-то еще более высокоуровневом чем асм, тогда да. А если пишешь на ассемблере постоянно, а не только куски программ, которые нужно оптимизировать, то вполне вероятно, что код получится качественный. Но, повторюсь, опыта надо будет побольше, чем у программера на Си или других языках, чтобы не получился говнокод. Язык формирует мышление.
У ассемблера есть некая проблема - человеку трудно глобально соптимизировать использование регистров в большом куске кода например.А компилерам пофиг - они железные.Поэтому асм годится для написания небольших кусков.А вот большие простыни на нем - уныло.Потому что локальности видно а вот как оно глобально... весь мозг сломаешь.Я если что видел довольно большие проекты на асме.Это выглядит ужасно и почти не поддается поддержке после достижения некоего критичного размера.В итоге разумный юзеж ассемблера нынче - это маленькие проекты на несколько Кб (однокристалки, etc) или - вставки в критичных к скорости местах.
>например сишная или например перловая, какая разница. на перле нарсить XML быстрее
>чем на асмеА на асме дернуть ту же сишную либу парсящую XML? :D
Если вы хотите сравнить скорость кода писаного на асме с скриптоподелкой - думаю и идиоту понятно что потенциально аккуратно выписаный машинный код рвет бредядину из машинных команд в которую в конечном итоге трансформируется (так или иначе) перловый скрипт как тузик грелку(процессор не умеет выполнять скрипты - на него пойдет поток команд, как ни крути, как этот поток получится - вопрос номер два).Если сравнивать перл + сишную либу, тогда, очевидно надо сравнить и асм + сишную либу.К досаде перловщиков, выигрыш по времени разработки будет не столь уж велик.К досаде ассемблерщиков, выигрыш будет мизерным - т.к. основную часть работы будет делать сишная либа и выиграть тупо не на чем :).Хотя если у кого шило в ... - можно попытаться критичные куски парсера на асм переписать.Вот тут можно выиграть наверное.Возможно даже в несколько раз, если окажется что компилер генерит крайне похбный код в каких-то критичных к скорости местах.Осталось только найти ассемблерщиков мечтающих копаться в XMLном гумне :)
Нет, не перловый. В данном контексте "перловый" означает "написанный на Перле", а модули для Перла пишутся на чём угодно.
хм, а если парсер написан на перле с использованием сишной библиотеки, то он становится сишным?
естественно.
сам парсер (движок) в библиотеке.
и подозреваю, что создатели этой библиотеки о пёрле и не задумывались.
в пёрле Вы используете парсер, а не пишите его.звучит Ваш постулат примерно так - если я на жабе пишу прогу с использованием mysql, то mysql написан на java.... ну бред же.
>естественно.
>сам парсер (движок) в библиотеке.
>и подозреваю, что создатели этой библиотеки о пёрле и не задумывались.
>в пёрле Вы используете парсер, а не пишите его.но сам перл написан на C, значит и весь перловый код можно назвать сишным, ведь он исполняется с помошью C кода. так выходит
>
>звучит Ваш постулат примерно так - если я на жабе пишу прогу
>с использованием mysql, то mysql написан на java.... ну бред же.
>бред конечно, но это не я придумал
но программа на пёрле - текстовой файл, который ещё надо обработать (отпарсить если хотите), а потом выполнить.
его конечно можно перевести с С и скомпилить, но Вы видели в какие сишные исходники он после превращается? масса избыточного кода.
>какие сишные исходники он после превращается? масса избыточного кода.А потом еще сишный компилер то же самое сделает :).Сишные компилеры тоже не паиньки, если глянуть что оно там генерит, удивляешься количеству бреда... но процессору то похрен, он железный.А где скорость роляет (кодеки, например) - бред заменяется на асмовую вставку.С соотв. выигрышем в скорости.
>хм, а если парсер написан на перле с использованием сишной библиотеки, то
>он становится сишным?Очевидно да - черную работу делает сишная либа.Если хочется сказать что перл крут по скорости - напишите именно на нем.Иначе неубедительно - быстрым то был все-таки си в его либе :).А то что ее из какой-то тормозилки дернули - ну, дернули и дернули.Хоть из шелскрипта дергайте, кому какое дело?
>>хм, а если парсер написан на перле с использованием сишной библиотеки, то
>>он становится сишным?
>
>Очевидно да - черную работу делает сишная либа.Если хочется сказать что перл
>крут по скорости - напишите именно на нем.Иначе неубедительно - быстрым
>то был все-таки си в его либе :).А то что ее
>из какой-то тормозилки дернули - ну, дернули и дернули.Хоть из шелскрипта
>дергайте, кому какое дело?Значит когда я пишу на перле, и использую сишную библиотеку, я могу сказать что я пишу на C. верно?
>Значит когда я пишу на перле, и использую сишную библиотеку, я могу
>сказать что я пишу на C. верно?Нет, вы не пишете на си. Но вы пользуетесь результатами труда сишных програмеров. По-моему, все просто как дважды два. Только это не ваша заслуга. Легко быть большим, стоя на плечах гигантов... только зачем при этом делать вид что это ваша заслуга?Быстрые и эффективные алгоритмы писали не вы и не на перле.Тогда - какого?
то Вы утвержадаете что код который я получу не является перловым потому что используется сишная либа, то теперь утверждаете что код не является сишным(я разделяю именно эту точку зрения), Вы определитесь в конце концов.
>то Вы утвержадаете что код который я получу не является перловым потому
>что используется сишная либа,Как бы логично что код сишной либы - не код на перле, да?И именно *парсер XML* - не на перле в итоге.То есть, конечно, можно и на перле без сей его наверное написать.Но его скорость работы будет скорее всего сильно сдристывать сишной либе, а т.к. это еще и геморрой да еще и с таким паршивым результатом - так обычно не делают.Как не пишут парсер XML на асме.Но технически вполне можно.Только на перле тормозно а на асме долго и геморройно.
>то теперь утверждаете что код не является сишным
Перловый код сишным не является, это и идиоту понятно.Но простите, вы что, написали *парсер XML* на перле?Нет?Все-таки вызывается сишный код?Ну надо же.
>(я разделяю именно эту точку зрения), Вы определитесь в конце концов.
А что тут определяться?И зачем пытаться жонглировать фразами?Все просто как дважды два.Есть перловый скрипт.Не являющийся парсером XML а всего лишь оболочкой от сосиски.Дергающий местами сишные либы, которые то и быстро распарсят XML.Быстрая работа сишных либ - это заслуга сишных либ.А вовсе не перла.Более того - те же самые сишные либы можно дернуть и откуда-то еще.Хоть из ассемблерной программы, елки!
> си теперь быстрее асьмы?Вообще-то в половине случаев всегда был и будет, в другой половине даже близко не стоит.
> си теперь быстрее асьмы? не верю...Иногда такое возможно - человеку трудно в большом масштабе отслеживать например глобальное использование регистров и т.п. - поэтому на большом куске кода компилер может обыграть человека.Но вот вылизать до байтика код в конкретном месте может только человек.Поэтому вещи критичные к скорости - это си с маленькими вставками асма.Не верите?Посмотрите как написаны все популярные кодеки ;).
Интересно что на этот счет скажет Тео? Может быть алгоритм в OpenSSH более надёжен в плане безопасности?
Совсем дурной, да?
Про криптографию только в кино читал?
SHA-1 он и у финского парня SHA-1.
Если "разный уровень безопасности", то это не SHA-1 а что-то другое.
Хотя какая нафик безопасность у SHA-1 - это уже не криптофункция.
Думаю, он имел в виду другое. А именно то, что _реализация_ этого алгоритма в OpenSSL более выверена в плане отсутствия уязвимостей.
>Думаю, он имел в виду другое. А именно то, что _реализация_ этого
>алгоритма в OpenSSL более выверена в плане отсутствия уязвимостей.Уязвимости в SSH, в смысле реализации? Там код то строк в 200, не вызывают криптофункции лишнего "мяса" (библиотек), все только стандартное, т.к. переносимость важнее.
Описался, SHA-1, а не SSH.
LOLWUT?В оригинальной статье ни слова о том, что Линусу нравится оптимизация GCC. Наоборот, "it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever". То есть за оптимизацию он не хвалил, а наоборот, ругал, поскольку его C-код настолько низкоуровненвый, что компилятор C использовался "as a glorified assembler" (собственно, в комментариях на ЛОРе указали и на ассемблерные вставки в том числе)
>"it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever"ну и как перевести эту фразу?
оказалось, для того чтобы получить хорошие результаты нужно бороться с тем что компилятор пытается умничать
Похоже на то, что Линус просто так иронизирует.
в этой статье я тоже не нашёл ни слова о том, что Линусу нравится оптимизация GCC. Наоборот, "Линус Торвальдс опубликовал заметку о все большем усложнении работы, когда требуется получить предсказуемый результат от GCC, без вмешательства оптимизатора. Отмечается, что компилятор становится слишком умным, что мешает использованию Си в роли высокоуровневого ассемблера, так как все труднее и труднее предсказать какой результирующий код будет сгенерирован.". То есть за оптимизацию он не хвалил, а наоборот, ругал...
Линус считает C просто средством написания переносимого ассемблерного кода, а не самостоятельным языком. И только в этом свете ему не нравится, как компилятор изменяет его код в попытке оптимизировать. Он не имеет ввиду, что GCC плохо оптимизирует код или что оптимизации кода это плохо вообще. Он имеет ввиду только данный конкретный случай.
просто для действительно сильного специалиста лучшая оптимизация - это он сам.
а для подавляющего большинства середнечков характерно следующее (если вообще оптимизацией занимаются. на прикладном уровне и метод пузырька - новое слово в науке и технике) - оптимизируют в одну сторону, а оптимизатор компилятора в другую. а врезультате то что получилось совместными действиями. очень многие серьезные специалисты в прикладном программировании даже рекомендуют дебагерную инфу не убирать - типа овчинка выделки не стоит, а вот в поддержке очень сильно поможет.
короче - уметь надо. (вот новость, правда? :-D)
А можно посмотреть на этих "специалистов"? Особенно с последними рекомендациями?
>в прикладном программировании даже рекомендуют дебагерную инфу не убирать - типа
>овчинка выделки не стоит, а вот в поддержке очень сильно поможет.хех, я тоже такое читал =)))
да вот книжку забыл. (аргументы помню, иногда применяю, но ведь нужен пруфлинк :-D)
лет 10 назад. там описывалась обработка исключительных ситуаций, SEH и т.д. (для виндов правда). автор - признанный тестировщик.
ладно. найду, ссылку скину.
>Линус считает C просто средством написания переносимого ассемблерного кода, а не
>самостоятельным языком.Более того, его таковым считает еще целая орава народа.Как минимум - иногда :)
Это товальдус ещё не програмил на джава.
Он бы на питоне попрограммил. Я б купил попкорна и почитал потом его комментарии.
>Он бы на питонеТочно? Проверял?
Когда ему надо было быстро написать инструмент, он писал на Perl+shell, потом библиотеки и критичные куски "подтянули" на C. http://www.ohloh.net/p/git/analyses/latest - "в начале", думаю, перла было больше.
---
По поводу заголока: автор новости, надо полагать, не совсем понял, о чём речь. Ведь раз быстрее "чисто ассемблерной реализации", значит gcc круут.
Интересно, если отключить оптимизацию, можно получить предсказуемый результат, или оно того не стоит?
>Он бы на питоне попрограммил.А может лучше сразу на брейнфаке?Зачем ограничиваться полумерами? :)
>компилятор становится слишком умным
>все труднее и труднее предсказать какой результирующий код будет сгенерированмне страшно. вот, откуда начнётся восстание машин
>>компилятор становится слишком умным
>>все труднее и труднее предсказать какой результирующий код будет сгенерирован
>
>мне страшно. вот, откуда начнётся восстание машинПолзи на кладбище - то что С генерит для DSP читать лет уж 10 никто не может ... однако ракеты летаютЪ :)
PS: Хммм .... "Булава" ? OMFG!!!! :)
PPS: Для слабых нервом - там не из за электроники, там из за того что в России толковых токарей не осталось, одни менеджеры ...
>Ползи на кладбище - то что С генерит для DSP читать лет
>уж 10 никто не может ... однако ракеты летаютЪ :)Весь вопрос в том кто еще поползет, полетит, поплывет, ... на него по милости электроники.
И так, JFYI: для DSP обычно генерится крайне дерьмовый код.Кажется, Ti (?) или кто-то еще из известных производителей DSP честно предупреждает, что для получения обещанных ими параметров одними сями дескать не обойдетесь, асм вам в руки.>PPS: Для слабых нервом - там не из за электроники, там
>из за того что в России толковых токарей не осталось, одни менеджеры ...Тем не менее, софтварные методы нынче используются для управления много чем.И думается мы еще не раз пожалеем о допущенных багах.
>Линус Торвальдс опубликовал (http://www.linuxfoundation.org/news-media/blogs/browse/2009/...) заметку о все большем усложнении работы, когда требуется
>получить предсказуемый результат от GCC, без вмешательства оптимизатора. Отмечается, что компилятор
>становится слишком умным, что мешает использованию Си в роли высокоуровневого ассемблера,
>так как все труднее и труднее предсказать какой результирующий код будет
>сгенерирован.
>При тестировании на машине с многоядерным CPU архитектуры Nehalem, написанная для уменьшения
>числа зависимостей кода GIT реализация алгоритма хэширования SHA1 на языке Си
>с использованием ассемблерных вставок ...Как можно использовать ассемблерные вставки если не известно куда что положит сишный код?
Как можно использовать сишный код, если неизвестно, куда что положат ассемблерные вставки?
>Как можно использовать сишный код, если неизвестно, куда что положат ассемблерные вставки?А зачем это знать? Можно пользоваться компьютером, не умея программировать. Можно программировать потоки (grep, sed и им подобные, связанные пайпами), не зная, как именно реализована работа с регексами. Можно программировать на языке высокого уровня, не зная, какой код на родном языке процессора получится.
Главное - чтобы код был корректным. А Си провоцирует на неоднозначное понимание возможности оптимизации. Например:
x=a+b;
*p=*q;
y=x+1;Компилятор может попытаться вычислить икс в регистре и не записывать его значение в память. Но это допустимо только если есть гарантия, что ни пи, ни кью не указывают на икс.
>А зачем это знать?А вы попробуйте написать что-нибудь на сях с ассемблерными вставками.Тогда поймете.
>Можно пользоваться компьютером, не умея программировать.
А еще можно жить не умея считать, читать, писать, ... :)
>именно реализована работа с регексами. Можно программировать на языке высокого уровня,
>не зная, какой код на родном языке процессора получится.Только в результате обычо получается быдлокод.Унылый.Однообразный.Неэффективный.А вот красивые, эффективные и мощные алгоритмы почему-то такие "программеры" сделать обычно не могут.Более того - иногда на совершенно детскую задачку можно услышать ответ какогонить "дотнетчика":
- А можно сделать вон то и вон это?
- А так нельзя!
- ??? WTF ???
- Для этого класса нет...Да, такой "програмер" не родит свой алгоритм, хотя-бы уровня b-tree.Он родит только унылое однообразное говно...
>Главное - чтобы код был корректным. А Си провоцирует на неоднозначное понимание
>возможности оптимизации.Да, си не строит быдляк в строй при помощи пилюлей - это тулза для системщиков и програмеров.У которых мозг на месте, что несколько отличает их в лучшую сторону.А не для дебилов, которые понимают только пилюли сдобренные истошным воплем "нельзя!!!".Для таких есть высокоуровневые явы и дотнеты, там построение при помощи пилюлей и "нельзя!!!" реализовано.Ну и возможностей меньше, соответственно.Везде ограничения, тормоза, "нельзя!!!" одним словом.Крутой кодек на яве и дотнете не напишешь, пишут в итоге только унылую как дождливый день бизнес логику да всякий оверблоатнутый шыт сделанный по принципу "на отвали".
Минус асма, для меня, в низкой портабельности кода.Сначала мучаешься под x86, а потом еще мучиться под x86_64, потом опять мучиться под ARM, а потом снова мучиться под MIPS, а потом мучиться еще под что нибудь.
А если код еще и под разные ОС должен работать, так это сразу застрелиться.
Все таки C, а в задачах где логику программы приходиться часто менять и языки высокого уровня, мое все.
код на ассемблере не портабелен вообще.
>код на ассемблере не портабелен вообще.А если это ассемблер виртуальной машины?Собссно в яве и дотнете есть промежуточный байткод, как раз примерно оно и есть :)
Сдается мне, что это какой-то юношеский максимализм! По-вашему, если программер решает задачи на джаве или дотнете то он быдлопрограммер и не имеет права на существование? А вы ту же самую задачу за то же самое время за те же самые деньги решите на си или асме?Т.е. все повара по квалификации хуже чем шеф-повар элитного ресторана должны срочно застрелиться и не портить высокое звание повара в глазах потребителей? И много ли найдется подобных мастеров? И будут ли они работать за те же деньги что и быдлоповара? И успеют ли они всех накормить?
На мой взгляд, для решения разных задач нужны наиболее подходящие инструменты. И нечего микроскопами гвозди забивать.
Да, рассуждение здравое, но пардон, работа в макдональдсе и не считается почетной, если вы не заметили.Большинство людей вполне конкретного мнения о качестве тамошней "стряпни" и ее полезности.Ну и врядли коллеги из ресторанов питают чрезмерные симпатии к школоте из соседнего макдональдса, позорящей профессию поваров как класс.В итоге - работа в макдональдсе может и популярнее чем работа шеф-поваром в приличном ресторане, но таким достижением особо не погордишься - это не сильно почетнее работы дворником.Что-то не так?Нет, наверное бывают нормальные програмеры на дотнете и яве.И крутые повара в макдональдсах.Но я честно говоря ни тех ни других не встречал.Хотя, безусловно, совсем отрицать возможность их существования - глупо, да.
>Да, рассуждение здравое, но пардон, работа в макдональдсе и не считается почетной,
>если вы не заметили.Большинство людей вполне конкретного мнения о качестве тамошней
>"стряпни" и ее полезности.Ну и врядли коллеги из ресторанов питают чрезмерные
>симпатии к школоте из соседнего макдональдса, позорящей профессию поваров как класс.В
>итоге - работа в макдональдсе может и популярнее чем работа шеф-поваром
>в приличном ресторане, но таким достижением особо не погордишься - это
>не сильно почетнее работы дворником.Что-то не так?Нет, наверное бывают нормальные програмеры
>на дотнете и яве.И крутые повара в макдональдсах.Но я честно говоря
>ни тех ни других не встречал.Хотя, безусловно, совсем отрицать возможность их
>существования - глупо, да.Вы меня немного не поняли. Я не о квалификации программеров говорил, а о том, что порой и не требуется из пушки по воробьям. И решение не слишком замысловатой и не очень интересной задачи лучше поручить "быдлокодеру" - пусть он ее решит своими "быдлоинструментами". Это будет целесообразно.
А чего бороться? Вынести алгоритм в отдельный файл и компилить с -O0. У меня тоже выходило times33 вручную оптимизировать лучше, чем с -O3, при этом включение оптимизаций на оптимизированном вручную коде заметно снижал производительность.
Аптимизаторы млин> 74 /* Output hash
> 75 */
> 76 for (i = 0; i < 5; i++)
> 77 ((unsigned int *)hashout)[i] = htonl(ctx->H[i]);
> 78 }/* Output hash */
((unsigned int *)hashout)[0] = htonl(ctx->H[0]);
((unsigned int *)hashout)[1] = htonl(ctx->H[1]);
((unsigned int *)hashout)[2] = htonl(ctx->H[2]);
((unsigned int *)hashout)[3] = htonl(ctx->H[3]);
((unsigned int *)hashout)[4] = htonl(ctx->H[4]);:)