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 ()
Ответ на: комментарий от phasma

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

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

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

Pavval ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от question4

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

yurikoles ★★★
()
Ответ на: комментарий от 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 ★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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