LINUX.ORG.RU

Реализация SHA1 на С от Торвальдса обогнала реализацию на ассемблере от OpenSSL

 ,


0

0

В своём блоге небезызвестный программист Линус Торвальдс сообщает, что на его рабочей станции с процессором на ядре Nehalem его реализация SHA1 для git работает быстрее SHA1 из библиотек OpenSSL. Он отмечает, что это позволило отказаться от привязки к libcrypt и на несколько секунд увеличить результаты прохождения тестов. Причём он выделяет, что он писал на «почти кросс-платформенном ассемблере» С, в отличие от разработчиков OpenSSL, писавших на ассемблере.

В своей обычной манере Торвальдс отзывается о компиляторах ("...it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever" - "...ясно, что чтобы получить хорошую реализацию SHA1, надо бороться с тенденцией компиляторов быть самыми умными"), процессорных архитектурах («On my Nehalem machine (but not Netburst or Atom - poor fragile micro-architectures that they are)...» - «На моей машине с Nehalem (ни в коем случае не с Netburst или Atom - убогие хрупкие микро-архитектуры)...») и даже бибилиотеках, к которым привязывался git ("...I get rid of two silly runtime loadable libraries that git no longer needs" - "...Я избавился от двух глупых загружаемых библиотек времени исполнения, которые больше не нужны git")

>>> Подробности



Проверено: Shaman007 ()
Ответ на: комментарий от Pavval

> Фазмочка обозвала тормозным, пусть и приводит.

совочек отобрал ? ну ты не плачь ...

phasma ★☆
()
Ответ на: комментарий от phasma

>http://code.google.com/p/support/wiki/DVCSAnalysis читай

Прочитал еще раз. И где там? Единственное что есть - это тормоза при работе через HTTP.
Это не имеет отношения к git непосредственно - это проблемы работы по ОДНОМУ ИЗ протоколов. Я, к примеру, пользуюсь git+ssh на работе - где у меня тормоза?

Лучше скоростью выполнения локальных комманд померяйся (а ведь они занимают большую часть времени).

Pavval ★★★★★
()
Ответ на: комментарий от Boy_from_Jungle

> Интересно что Торвальдс курит?!

Я тут недавно почитал Жас Фофан. Там он упивался рассказами о том, что он что-то переделывает когда ему это не нравится. Ну тут понятно, не понравилась библиотека OpenSSL. Таки он считает, что в ядре больше делать нечего? Типа там все и так пиз^Wхорошо, что он полез в чужой огород?

Походу он курит отборные вещи

valich ★★★
()
Ответ на: комментарий от Pavval

> Это не имеет отношения к git непосредственно - это проблемы работы по ОДНОМУ ИЗ протоколов. Я, к примеру, пользуюсь git+ssh на работе - где у меня тормоза?

в голове ?

> Лучше скоростью выполнения локальных комманд померяйся (а ведь они занимают большую часть времени).


начинай, теперь твоя очередь приводить пруфлинк

phasma ★☆
()
Ответ на: комментарий от Pavval

Ну я вижу, что по всем тестам git сливает. А где не сливает, автор явно что-то делал через жёпу, у меня все гораздо быстрее работает.

phasma ★☆
()
Ответ на: комментарий от phasma

>Ну я вижу, что по всем тестам git сливает. А где не сливает, автор явно что-то делал через жёпу, у меня все гораздо быстрее работает.

ЩИТО? Подробнее своб мысль, плиз.

Pavval ★★★★★
()
Ответ на: комментарий от phasma

>да там видно, что это фейк. Попробуй сам попускать.

Гг. хороший подход в троллении. Надо будет запомнить.

Когда будет не лень, повторю это все с ядром и выложу в Talks.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

>> автор явно что-то делал через жёпу, у меня все гораздо быстрее работает.

> ЩИТО? Подробнее своб мысль, плиз.

Тут 2 простых идеи: 1) кому нах нужен репозиторий ядра? 2) не использует ли Git "под капотом" inotify? Потому что единственный реальный тест - это diff, который очень хорошо ускоряется inotify (да и вообще любые операции, требующие сканирования дерева файлов). А про более быстрые коммиты Git - это прямое мошенничество. Сам знаешь, почему, или объяснить?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Тут 2 простых идеи:
>1) кому нах нужен репозиторий ядра?


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

>2) не использует ли Git "под капотом" inotify? Потому что единственный реальный тест - это diff, который очень хорошо ускоряется inotify (да и вообще любые операции, требующие сканирования дерева файлов).


Нет, не использует. Читай материалы по git.

>А про более быстрые коммиты Git - это прямое мошенничество. Сам знаешь, почему, или объяснить?


Обьясняй. Коммитит - коммитит. В чем проблема?

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Если ты про staging area - то даже вместе с git add это выходит _немногим_ быстрее, чем в hg.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

>> 1) кому нах нужен репозиторий ядра?

> Мы вроде меряем производительность, не?

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

> Дай любой другой большой проект.

Работал бы я над большим проектом - настроил бы inotify extension.

>> 2) не использует ли Git "под капотом" inotify? [...]

> Нет, не использует. Читай материалы по git.

Ссылку?

>> А про более быстрые коммиты Git - это прямое мошенничество. Сам знаешь, почему, или объяснить?

> Обьясняй. Коммитит - коммитит. В чем проблема?

И кому из нас надо читать материалы по Git? Он коммитит, но потом репозиторий надо перепаковывать. Из laserjock: "I did the packing and gc’ing after all the timing". Если этого не делать, то хваленый Git раньше замедлялся до неюзабельности; да и сейчас перепаковка - рекомендуемая процедура.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> Мы вроде меряем производительность, не?

>Нам вроде следует мерять производительность на проектах размера, который чаще встречается IRL. И не надо говорить, что это проекты размером с ядро.


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

>> Нет, не использует. Читай материалы по git.


>Ссылку?


А в гугле забанили?

>И кому из нас надо читать материалы по Git? Он коммитит, но потом репозиторий надо перепаковывать. Из laserjock: "I did the packing and gc’ing after all the timing". Если этого не делать, то хваленый Git раньше замедлялся до неюзабельности; да и сейчас перепаковка - рекомендуемая процедура.


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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

> Ты думаешь, что на более мелких проектах (но не миллипиздрических - чтобы было, что мерять) картина изменится?

Я думаю, что никто не заметит разницу между 0.1с и 0.15с

>>> Нет, не использует. Читай материалы по git.

>> Ссылку?

> А в гугле забанили?

Походу, ты и сам их не читал.

> Перепаковывать надо периодически, а не после каждого коммита. Так что не защитывается.

Перепаковывать надо? Да. Значит, затраты на перепаковку должны быть прибавлены к коммиту. Это сделано? Нет. Фанбои такие фанбои...

tailgunner ★★★★★
()

Если ему от OpenSSL больше ничего не надо кроме одной маленькой функции и выгода реальная — почему ты и нет. Только все равно ведь OpenSSL на каждой машине где есть гит тоже стоит.

svyatogor ★★★★★
()
Ответ на: комментарий от phasma

> http://code.google.com/p/support/wiki/DVCSAnalysis

Недостатки Git-а по мнению Google: больше возможностей; основная виндовая версия требует Cygwin, версия без Cygwin немного медленнее; время от времени нужно чистить хранилище командой git-gc, тогда как Mercurial просто не умеет управлять местом на диске; умеет удалять историю. Зато: Git умеет брать только необходимые куски веток, без ненужных устаревших версий; число родителей при слиянии неограничено.

В итоге выбрали Mercurial из-за лучше сделанного доступа по HTTP.

Дай-ка ещё таких ссылок про bzr и monotone.

question4 ★★★★★
()
Ответ на: комментарий от question4

> Дай-ка ещё таких ссылок про bzr и monotone.

я не пользуюсь ни bzr ни monotone

phasma ★☆
()
Ответ на: комментарий от question4

> умеет удалять историю

Это все умеют.

> Зато: Git умеет брать только необходимые куски веток, без ненужных устаревших версий

Это все умеют.

> число родителей при слиянии неограничено.

Ты так говоришь, будто это что-то хорошее.

> Дай-ка ещё таких ссылок про bzr и monotone.

Почитай лучше какую-нибудь entry-level статью по DVCS.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Это все умеют.

Список не мой, я просто перевёл статью по ссылке :) Но если так, то показывает уровень знаний человека, выбравшего Mercurial :)

Я не работаю ни в каких распределённых проектах, только скачиваю снапшоты. И мне важны только 2 вещи: скорость и место на диске. По соотношению время/объём git далеко всех обходит, по размеру хранилища приемлем. Но Mercurial я не пробовал.

question4 ★★★★★
()

В этом топике Линус писнул хешца.

xap4o
()
Ответ на: комментарий от question4

git УГ, ибо не умеет докачивать обновления, git-merge жрёт ппц сколько памяти, глючит разрешитель конфликтов. Последние два пункта я самолично увидел когда делал git pull для linux-next и fatfs-dualnames, которые я клонировал за пару дней до этого и ничего не менял. Процесс git-merge скушал более 700 МБ ОЗУ, пришлось жать резет, у меня всего 1 гиг рамы. Может из-за резета появились конфликты, х.з.

yurikoles ★★★
()

>>> <i>библиотек времени исполнения</i>

Та насяльника, испальнения шайтанама.

rattlesnake
()
Ответ на: комментарий от sjinks

>Те же самые три movl, один xorl и ror(l), не находите?

не нахожу, потому что это листинг в контексте printf, а не sha1

>К слову о переносимости

Вообще к слову: некоторымнеплохо было бы прочитать название и текст топика

frame ★★★
()
Ответ на: комментарий от tailgunner

>> Ты думаешь, что на более мелких проектах (но не миллипиздрических - чтобы было, что мерять) картина изменится?

>Я думаю, что никто не заметит разницу между 0.1с и 0.15с


А я про что? Потому и тестируем на большом проекте.

>> Перепаковывать надо периодически, а не после каждого коммита. Так что не защитывается.


>Перепаковывать надо? Да. Значит, затраты на перепаковку должны быть прибавлены к коммиту. Это сделано? Нет. Фанбои такие фанбои...


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

>> А в гугле забанили?


>Походу, ты и сам их не читал.


Забанили - там и скажи. По внутренностям git не так и много материалов.

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index

The index enables fast comparisons between the tree object it defines and the working tree.

It does this by storing some additional data for each entry (such as the last modified time). This data is not displayed above, and is not stored in the created tree object, but it can be used to determine quickly which files in the working directory differ from what was stored in the index, and thus save git from having to read all of the data from such files to look for changes.

Pavval ★★★★★
()
Ответ на: комментарий от tailgunner

Привет всем.

> Перепаковывать надо? Да. Значит, затраты на перепаковку должны быть прибавлены к коммиту. Это сделано? Нет. Фанбои такие фанбои...

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

Lego_12239 ★★
()

Если говнокод переписать по нормальному, ЛЮБАЯ программа только выйграет. Своим шагом трольвальдс только показал лишний раз, что в FOSS полно левых утилит, которые давно пора закопать.

matumba ★★★★★
()
Ответ на: комментарий от Lego_12239

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

Абстрактный сферический промежуток времени? ХЗ. Я могу точно сказать насчет коммита, что это вещь довольно редкая, и подождать на пару секунд никакой проблемы не составляет. Насчет использования patch queue типа mq или stgit - в единственном тесте, который я видел, mq был быстрее.

> Я не конкрето про git, а вообще :-).

А я конкретно про методику тестирования.

tailgunner ★★★★★
()
Ответ на: комментарий от Pavval

>>> Ты думаешь, что на более мелких проектах (но не миллипиздрических - чтобы было, что мерять) картина изменится?

>> Я думаю, что никто не заметит разницу между 0.1с и 0.15с

> А я про что? Потому и тестируем на большом проекте.

Я не понял, про что ты, а я - про то, что несколько секунд преимущества во времени diff на большом проекте ничего не значат для большей части реального мира. А если значат - ну так с inotify Mercurial уделает всех.

>> Перепаковывать надо? Да. Значит, затраты на перепаковку должны быть прибавлены к коммиту. Это сделано? Нет. Фанбои такие фанбои...

> Ну давай учитывать одну перепаковку на 50 коммитов

Давай ты приведешь данные, учитывающие перепаковку (если они вообще существуют).

> The index enables fast comparisons between the tree object it defines and the working tree.

Я знаю, что такое индекс в Git. И прикинь, аналогичная структура есть вообще в любой VCS.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Абстрактный сферический промежуток времени? ХЗ. Я могу точно сказать насчет коммита, что это вещь довольно редкая, и подождать на пару секунд никакой проблемы не составляет.

Не редкая. Я постоянно комичусь. Комичусь, когда хочу что-либо проверить; потом откатываюсь. При этом, мой друг делает это редко. Но он пользует svn и это понятно. Там с коммитами не разбежишься. Он, вообще, не понимаешь зачем нужны DVCS :-). Кто как привык работать.

> Насчет использования patch queue типа mq или stgit - в единственном тесте, который я видел, mq был быстрее.

Может, быть. По-большому счёту, мне всё равно, кто где быстрее. По-моему, это загон :-).

Про git-repack, я к тому, что, в общем-то, он никак не влияет и не мешает, если я его делаю в субботу утром во время проверки почты или после рабочего дня, а не в основное рабочее время.

Lego_12239 ★★
()
Ответ на: комментарий от tailgunner

>Я не понял, про что ты, а я - про то, что несколько секунд преимущества во времени diff на большом проекте ничего не значат для большей части реального мира. А если значат - ну так с inotify Mercurial уделает всех.

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

>> Ну давай учитывать одну перепаковку на 50 коммитов


>Давай ты приведешь данные, учитывающие перепаковку (если они вообще существуют).


Могу, а смысл? Перепаковка в нерабочее всемя про cron. Каким это влияет на скорость работы?

>Я знаю, что такое индекс в Git. И прикинь, аналогичная структура есть вообще в любой VCS.


А дальше читал?

Pavval ★★★★★
()
Ответ на: комментарий от sjinks

Если всё это действительно так, отправляйте свой вариант Линусу, покажите ему, кто здесь настоящий C-программер :)

Sadler ★★★
()
Ответ на: комментарий от Pavval

>>Давай ты приведешь данные, учитывающие перепаковку (если они вообще существуют).

>Могу, а смысл?

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

>> Я знаю, что такое индекс в Git. И прикинь, аналогичная структура есть вообще в любой VCS.

> А дальше читал?

Ага, причем первый раз - еще в 2005, в git@gelato

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ну ты типа сказал, что "изначально разговор был про производительность". А сейчас ты говоришь, что умеешь пользоваться cron.

И каким образом задача в cron влияет на производительность?

>Ага, причем первый раз - еще в 2005, в git@gelato


Ну там и почему ты у меня спрашиваешь про работу git-diff-tree? и сам должен знать.

Pavval ★★★★★
()
Ответ на: комментарий от Lego_12239

> Я постоянно комичусь.

"Постоянно" - это каждую минуту? 5? 10?

> По-большому счёту, мне всё равно, кто где быстрее. По-моему, это загон :-).

В общем, да - начиная с некоторой величины, разница перестает ощущуаться. Но фанбои git постоянно размахиваю транспарантом "Git сцуко быстрый!!11".

tailgunner ★★★★★
()
Ответ на: комментарий от frame

> не нахожу, потому что это листинг в контексте printf, а не sha1

Вы действительно тупи^Wне понимаете или просто притворяетесь? Неужели непонятно, что return (x >> n) | (x << (32 - n)) транслируется в одну инструкцию вне зависимости от контекста?

* http://blog.sjinks.org.ua/test/sha/test.c - исходный текст (я совместил .c и .h в один файл);
* http://blog.sjinks.org.ua/test/sha/test_linus.S - ассемблерный вариант кода Линуса;
* http://blog.sjinks.org.ua/test/sha/test_my.S - ассемблерный вариант кода с моими rol32()/ror32();
* http://blog.sjinks.org.ua/test/sha/test.diff - unified diff двух вариантов.

Если внимательно посмотреть в дифф, разница там в именах локальных меток, регистрах и порядке инструкций (отсутствие ассемблерных вставок даёт больше простора оптимизатору). В остальном всё похоже. И rol32()/ror32() разворачиваются в одну ассемблерную инструкцию.

> Вообще к слову


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

sjinks ★★★
()
Ответ на: комментарий от Sadler

> Если всё это действительно так, отправляйте свой вариант Линусу

Линус это и сам знает. Если прочитать статью из блога внимательно: реализация SHA в OpenSSL была на асме, Линус переписал её на C. Компилятор в большинстве случаев лучше человека рассчитает оптимальный (или близкий к оптимальному) порядок инструкций, уменьшит число AGI и т.п. Что мы и видим на примере кода Линуса. Мой пример лишь подтверждает это.

А отсутствие инструкций типа rol/ror/bswap/shld/shrd нисколько не мешает компилятору их генерировать, если он может определить, что реализация через сдвиги делает то же самое. Я полгода назад интересовался данным вопросом, и знаю, как поступает gcc в подобных случаях.

sjinks ★★★
()
Ответ на: комментарий от tailgunner

> "Постоянно" - это каждую минуту? 5? 10?

В среднем меньше, конечно. Но говорю ж, бывают моменты, когда и каждые 10 минут приходится комититься. Но, не суть.

Lego_12239 ★★
()
Ответ на: комментарий от sjinks

>разница там в именах локальных меток, регистрах и порядке инструкций (отсутствие ассемблерных вставок даёт больше простора оптимизатору). В остальном всё похоже. И rol32()/ror32() разворачиваются в одну ассемблерную инструкцию.

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

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


Как там насчёт производительности, тов. моралист? :)

frame ★★★
()
Ответ на: комментарий от frame

> то-то я смотрю, что в _my листинге этих инструкций как грязи, да ещё с неявными параметрами :)

Японские боги, да раскрой же ты глаза и посмотри на дифф.

-#APP
-# 147 "test.c" 1
- rol $5,%ecx
-# 0 "" 2
-#NO_APP
+ rorl $5, %eax

$ cat test.diff | grep -v "^-#" | grep "^-" | wc -l
1058
$ cat test.diff | grep -v "^+#" | grep "^+" | wc -l
1057

Ничего не говорит?

Может, временами стоит думать головой?

sjinks ★★★
()
Ответ на: комментарий от sjinks

>Ничего не говорит?

Зачем мне дифф с кодом, который генерирует неверную SHA1?

>Может, временами стоит думать головой?


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

frame ★★★
()
Ответ на: комментарий от frame

> Зачем мне дифф с кодом, который генерирует неверную SHA1?

Ну ты упрямый...

http://ru.wikipedia.org/wiki/SHA1

> SHA-1("The quick brown fox jumps over the lazy dog") 
>  = 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

$ ./test_linus ; ./test_my
2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12
2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12

Enough? Или будем упорствовать?

> Ну ты размеры бинарников сравни - тогда и подумай, следствием чего оно так получается

$ ls -la test_{linus,my}
-rwxr-xr-x 1 vladimir vladimir 10512 2009-08-13 16:48 test_linus
-rwxr-xr-x 1 vladimir vladimir 10512 2009-08-13 16:48 test_my

Размер совпадает, странно, правда? Теперь подумай, следствием чего это является.

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

Пруфкод (чтобы не было заявлений, что это всё один и тот же файл, просто переименованный): http://blog.sjinks.org.ua/test/sha.zip

sjinks ★★★
()
Ответ на: комментарий от sjinks

>Размер совпадает, странно, правда?

У меня с GCC 4.1.2 размер бинарника linus'а меньше и мне этого достаточно.

>Подсказка: в моём случае у компилятора больше свобода выбора относительно планирования инструкций.


GCC это тормозное и глючное поделие, которому нельзя доверять. Поэтому только с твоим компилятором и только в твоём случае тебе повезло. Поэтому Линус написал так, как оно есть. Поэтому все жалобы на asm-вставки в его коде - отправлять лично ему.

frame ★★★
()
Ответ на: комментарий от frame

> У меня с GCC 4.1.2 размер бинарника linus'а меньше и мне этого достаточно.

Неубедительно. Я специально поставил gcc-4.1.

vladimir@sjinks:~/test/sha$ make clean all
rm -f test_linus test_my test_linus.S test_my.S test.diff
gcc-4.1 -O2 -fomit-frame-pointer -Wl,-s -DLINUS_HERE test.c -o test_linus
gcc-4.1 -O2 -fomit-frame-pointer -Wl,-s test.c -o test_my
gcc-4.1 -O2 -fomit-frame-pointer -S test.c -o test_my.S
gcc-4.1 -O2 -fomit-frame-pointer -S -DLINUS_HERE test.c -o test_linus.S
diff -uwd test_linus.S test_my.S > test.diff
make: [test.diff] Ошибка 1 (игнорирована)
vladimir@sjinks:~/test/sha$ ls -la test_{linus,my}
-rwxr-xr-x 1 vladimir vladimir 10992 2009-08-15 18:58 test_linus
-rwxr-xr-x 1 vladimir vladimir 10992 2009-08-15 18:58 test_my
vladimir@sjinks:~/test/sha$

Если размер бинарника меньше, то ссылки на асм в студию. И использованные опции компилятора. Я подкрепляю свои слова делом, ты — нет. Так что talk is cheap. Don't sing it, just bring it.

А в случае gcc 3.4 и того лучше:

vladimir@sjinks:~/test/sha$ make clean all
rm -f test_linus test_my test_linus.S test_my.S test.diff
gcc-3.4 -O2 -fomit-frame-pointer -Wl,-s -DLINUS_HERE test.c -o test_linus
gcc-3.4 -O2 -fomit-frame-pointer -Wl,-s test.c -o test_my
gcc-3.4 -O2 -fomit-frame-pointer -S test.c -o test_my.S
gcc-3.4 -O2 -fomit-frame-pointer -S -DLINUS_HERE test.c -o test_linus.S
diff -uwd test_linus.S test_my.S > test.diff
make: [test.diff] Ошибка 1 (игнорирована)
vladimir@sjinks:~/test/sha$ ls -la test_{linus,my}
-rwxr-xr-x 1 vladimir vladimir 9904 2009-08-15 19:06 test_linus
-rwxr-xr-x 1 vladimir vladimir 9776 2009-08-15 19:06 test_my

> GCC это тормозное и глючное поделие, которому нельзя доверять.

О да, о да. И поэтому практически во всех версиях Linux gcc стоит компилятором по умолчанию.

Тогда вопрос: какой компилятор для тебя эталон качества?

И даже если это «тормозное и глючное поделие» в состоянии свернуть сдвиги в rol/ror, то что говорить тогда о «летающих и безглючных продуктах». Они тоже смогут. И тогда тем более нет смысла использовать непереносимую асмовскую вставку.

> Поэтому только с твоим компилятором и только в твоём случае тебе повезло.

К слову сказать, extended asm (то, что использовал Линус в коде) — расширение *GCC*. Прочитай: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm Так что повезло или нет — вопрос весьма спорный.

sjinks ★★★
()
Ответ на: комментарий от sjinks

>Я специально поставил gcc-4.1.

Я тестировал 4.1.2 (самый последний снимок), компилировал только с -02

>Если размер бинарника меньше, то ссылки на асм в студию.


ok
http://pastebin.com/m3bf105d1 - Линуса
http://pastebin.com/mf7c0785 - твое

>И тогда тем более нет смысла использовать непереносимую асмовскую вставку.


Поздравляю, ты не нашёл смысла в исходниках от самого Линуса Торвальдса! Рекомендую обозвать его некомпетентным идиотом и выдвинуть себя на его место :D

>И даже если это «тормозное и глючное поделие» в состоянии свернуть сдвиги в rol/ror


А твоя функция работает корректно работать лишь в случае 32-х битных переменных

>К слову сказать, extended asm (то, что использовал Линус в коде) — расширение *GCC*


Ядто (активно) использует расширения GCC, и некоторый софт тоже.

frame ★★★
()
Ответ на: комментарий от sjinks

>О да, о да. И поэтому практически во всех версиях Linux gcc стоит компилятором по умолчанию.

Бгггггг, "по умолчанию" - это типа намек, что есть типа еще из чего можно выбрать? Спасибо, давно так не смеялся по умолчанию! :-D

frame ★★★
()
Ответ на: комментарий от frame

> Бгггггг, "по умолчанию" - это типа намек, что есть типа еще из чего можно выбрать?

У желания — тысяча возможностей, у нежелания — тысяча причин.

При желании можно поставить icc, pcc, компиляторы Sun Studio, Tiny C Compiler, LCC (:-)), Cyclone, TenDRA, cilk и т.п. Как говорится, было бы желание.

sjinks ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.