[ /tv/ /rf/ /vg/ /a/ /b/ /u/ /bo/ /fur/ /to/ /dt/ /cp/ /oe/ /bg/ /ve/ /r/ /mad/ /d/ /mu/ /cr/ /di/ /sw/ /hr/ /wh/ /lor/ /s/ /hau/ /slow/ /gf/ /vn/ /w/ /ma/ /azu/ /wn/ ] [ Main | Settings | Bookmarks | Music Player ]

No.18675 Reply
File: Безымянный.png
Png, 21.66 KB, 660×315
edit Find source with google Find source with iqdb
Безымянный.png
File: рука_рука_рука.jpeg
Jpeg, 5.44 KB, 275×183
edit Find source with google Find source with iqdb
рука_рука_рука.jpeg

А знаете ли вы, что если получить статистику присутствия опкодов в исполняемых файлах, то окажется, что более половины из этих инструкций составляет инструкция mov?

Когда-то давно кто-то собирал подобную статистику до меня, но я не запомнил ссылки, поэтому пересобрал статистику скриптом на питоне. http://paste.org.ru/?fzw1yk

На пикрилейтеде результат обследования папочки /usr/bin на моем линуксе, горестно сообщающий нам, что примерно половину своего рабочего времени компьютер занят таким дзенским и бесполезным занятием как перекладывание байтов. Результат очевидно неточный, вследствие того, что при таком анализе не учитывается структура потока управления в анализируемых файлах. Но примерно так, никогда не замечал, что инструкции mov используются только-только вне циклов, а плюсование и минусование наоборот, яростно циклируется (или наоборот).
>> No.18676 Reply
К слову сказать, не так уж и плохо. Вон автомобильчики и вовсе имеют кпд в районе 25%, так что компьютеры даже у них выигрывают.
>> No.18677 Reply
>>18675
Ну, такой вот он gcc. Сделай свой компилятор Си, который будет делать упор на арифметику, вместо мувов.
Я почти уверен что в проприетарных шиндузячьих поделках будут лидировать джампы и коллы, что еще хуже мувов. :3
>> No.18678 Reply
File: Безымянный.png
Png, 33.93 KB, 709×333 - Click the image to expand
edit Find source with google Find source with iqdb
Безымянный.png
Проанализарованно ядро ОС Колибри. Суровым ассемблерщикам удалось достичь двухкратного снижения объема перекладывания байт. Вот она - цена отказа от кросплатформенности.
> Сделай свой компилятор Си, который будет делать упор на арифметику, вместо мувов.
Не хочу. Получится некрасиво и все меня будут ругать.
>> No.18682 Reply
>>18678
Сделайте то же самое для ядра Linux. Не для "/usr/bin", а для ядра.
>> No.18684 Reply
File: Безымянный.png
Png, 25.94 KB, 777×316 - Click the image to expand
edit Find source with google Find source with iqdb
Безымянный.png
>>18682
Сделал для ntoskrnl.exe. Хотя он тоже не кроссплатформенный вроде бы. А как получить несжатый образ линукс-ядра, который читался бы objdump -d?
>> No.18685 Reply
>>18684
> nop 6.75%
ёбаный-стыд.жпг
>> No.18686 Reply
File: Безымянный-system...
Png, 25.92 KB, 749×321
edit Find source with google Find source with iqdb
Безымянный-system32.png
File: Безымянный-охфиз.png
Png, 29.53 KB, 733×359
edit Find source with google Find source with iqdb
Безымянный-охфиз.png

В виндовсе вообще почти всегда что-то около 20-25 процентов выходит. Причем таки да, это наверное из-за компилятора, потому что анализ ls.exe из комплекта mingw выдал те же 41%, что и в линуксе. (system32 - это С:\Windows\system32\<звездочка>.dll, а охфиз - С:\Program Files\Microsoft Office\Office14\<звездочка>.dll)
>> No.18687 Reply
>>18686
> С:\Windows\system32\<звездочка>32.dll
фикс
>> No.18688 Reply
File: сырно.jpg
Jpg, 123.81 KB, 450×443 - Click the image to expand
edit Find source with google Find source with iqdb
сырно.jpg
Но вообще налицо противоречие: виндовс и линукс же тормозят примерно одинаково, только в разных местах, а разница в перекладывании байт почти 50%. Наверное выбранный метод анализа глупый, и не позволяет ничего понять относительно каких-либо реальных характеристик.

Похоже, что это выступление на симпозиуме закончилось бесславным провалом.
>> No.18689 Reply
>>18684
> А как получить несжатый образ линукс-ядра, который читался бы objdump -d?
Получить несжатый бинарник ядра можно вот так: http://blog.harrylau.com/2009/12/convert-vmlinuz-to-vmlinux.html. Если ты сам пересобирал ядро, тогда проблем вообще не должно возникнуть - несжатый образ должен лежать в директории с исходниками.
>> No.18690 Reply
File: Безымянный.png
Png, 23.64 KB, 681×325 - Click the image to expand
edit Find source with google Find source with iqdb
Безымянный.png
>> No.18692 Reply
>>18688
> виндовс и линукс же тормозят примерно одинаково
Омич-полуёбок, скажи, ты норкоман? У меня на нетбуке ШИНДОВС тормозит как эстонская шлюха на галоперидоле, а пингвин летает.
>> No.18694 Reply
>>18692
> Омич-полуёбок, скажи, ты норкоман? У меня на нетбуке ЛИНАКС тормозит как эстонская шлюха на галоперидоле, а боллмер летает.
>> No.18706 Reply
>>18692
Удваиваю. Венда куда как прожорливей. Даже со всеми своими свистелками линукс у меня везде работает ощутимо живее, чем венда. Одна разница в производительности ФФ чего стоит. Не коворя уж про ядро.
>>18675
Я не разбираюсь в ассемблере, но мне не кажется, что это адекватная оценка полезности действий. Компьютер, в конечном счёте, это машина тьюринга. Ну, типа того. А машина тьюринга как раз и занята тем, что бегает туда-обратно по ленте, совершая, в микро-перспективе, бесполезные и дзенские действия. Зато в макро-перспективе внезапно оказывается, что этим самым она вычисляет интерграл, игарет Продиджи или декодирует пнг с эротическими изображениями.
>> No.18708 Reply
>>18706
> бесполезные и дзенские действия
> ruwiki://Машина_Тьюринга
> Управляющее устройство работает согласно правилам перехода, которые представляют алгоритм, реализуемый данной машиной Тьюринга
Боюсь, что про
> Я не разбираюсь
это ты точно сказал.
>> No.18710 Reply
Вообще я уже говорил, что существуют архитектуры, процессор только перекладывает байты ( google://transport+triggered+architecture ). Чем-то похожим является режим DMA, где контроллер прерываний "ловит" запись в буфер по определенному адресу и дергает софт для обработки. Ну и все контрольные регистры - это тоже оно. Однако надо понимать, что сколько байты в однородной неспециализированной памяти не перекладывай, ни один пиксел jpeg-картинки этим не декодировать - это будет делать или компьютерная программа или железный блок прибитый гвоздями к определенным ячейкам памяти (пусть даже через маппер).
>> No.18711 Reply
>>18708
В ассемблере. А что такое машина тьюринга я, спасибо, знаю. А вот ты, похоже, слабо представляешь себе процесс, если думаешь, что отдельный переход на микро-уровне будет выглядеть чем-то осмысленным. Каретка может бегать по ленте туда-обратно на весьма значительные расстояния, что-нибудь запоминая и перекладывая (и не совершая ничего, с твоей точки зрения, "полезного"), пока, наконец, символы не выстроятся так, что "сыграют" вместе что-то осмысленное, "вызывая" тем самым умножение чисел или ещё что-то. Но "умножением" это станет только когда этот отрезок действий завершится, а до тех пор это будет просто невнятным метанием туда-обратно.
>> No.18712 Reply
>>18711
> Каретка может бегать по ленте туда-обратно на весьма значительные расстояния, что-нибудь запоминая и перекладывая
Согласно ПРАВИЛАМ ПЕРЕХОДА.
>> No.18715 Reply
>>18712
Да хоть согласно правилу левой руки. mov мы тоже не просто так выполняем, а согласно правилам.
>> No.18716 Reply
>>18715
> mov мы тоже не просто так выполняем, а согласно правилам
Безусловно. Только jpeg-то от этого не раскодируется и косинусное преобразование не преобразуется.
>> No.18718 Reply
>>18716
Писечка моя, x86-процессор может умножать-делить-вычитать, сравнивать только то, что есть у него в регистрах. Так что MOV главнее.
>> No.18719 Reply
File: 1330900690864[1].png
Png, 0.97 KB, 300×20 - Click the image to expand
edit Find source with google Find source with iqdb
1330900690864[1].png
Поцоны, а давайте я запилю эксперементальный процессор со стеками вместо регистров? (В виде эмулятора с счетчиком таков)
>> No.18720 Reply
>>18719
Довай!
>> No.18725 Reply
>>18718
Ограничение конкретной архитектуры. В случае бесконечного количества однородной памяти, удовлетворяющей всем свойствам, которые нам нужны (скорость, презистентность, отсутствие ограничений на число записей в ячейки) в мувах потребности бы не существовало.

Память же большинства производительных ЭВМ --- гетерогенна и неоднородна, мы вынуждены копировать данные из ее одного вида в другой и обратно, а машину производительные ЭВМ представляют из себя регистровую, с ограниченным числом регистров. Поэтому мув -- необходимое зло в мире под луной. Что не отменяет того, что он -- чистое воплощение накладных расходов и никаких новых результатов вычислений мы с его использованием не получаем.
>>18719
Так есть же реализации, даже на VHDL тоже где-то там живут. Лучше запили экспериментальную версию qemu, которая бы считала статистику использования инструкций. Вот тогда бы померяли, так померяли.
>> No.18740 Reply
>>18725
Не умею в системное программирование.
Post was modified last time at 2012-12-02 12:39:48
>> No.27570 Reply
>>18678
Не удивительно. Макроассемблер заменяет половину всех mov на адресную арифметику.
>> No.27572 Reply
>>18725
> презистентность
Что это?
>> No.27573 Reply
>>27572
Неправильная транскрипция http://slovari.yandex.ru/persistent/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/
>>27570
Примерищев бы.
>> No.27574 Reply
>>18719
вычисление факториала
http://pastebin.com/CxZkqWb2
1 'Мусорная' операция, которой в x86 нет
Всего в цикле 3 операции

Если вы мне предложите алгоритм не на работу с памятью (сортировка), но все же довольно простой, могу описать его в подобном стиле
>> No.27628 Reply
Вы не подумайте, я во всём этом не разбираюсь, я только пописать зашёл, но разве ж valgrind не умеет считать использованные инструкции?
>> No.27647 Reply
>>27628
Такие длинные извинения ни к чему, ведь ты всегда сможешь запустить его сам и попробовать посчитать инструкции.
>> No.27667 Reply
>>27647
Запустил — он успешно посчитал мне общее количество инструкций. Поскольку, насколько я понимаю, valgrind — прослойка между процессором и софтом («синтетический процессор», как его назвала вики), думаю, можно (в крайнем случае патчами) его заставить считать и типы инструкций.
>> No.27669 Reply
>>27667
С какими ключами ты его запускал? Мне он ничего не сообщал о количестве выполненных инструкций.

Еще, судя по википедийной статье, валгринд работает сугубо в юзерспейсе, а, стало быть, исследования ядер ОСов будут затруднены. И весит он неслабо, чем неслабее весит - тем труднее патч писать будет. Ну это в теории. На практике-то этот итт тред создавался для того, чтобы пожаловаться на несовершенство бытия, а для таких целей написание патчей излишне.
>> No.27672 Reply
>>27669
--tool=callgrind


Password:

[ /tv/ /rf/ /vg/ /a/ /b/ /u/ /bo/ /fur/ /to/ /dt/ /cp/ /oe/ /bg/ /ve/ /r/ /mad/ /d/ /mu/ /cr/ /di/ /sw/ /hr/ /wh/ /lor/ /s/ /hau/ /slow/ /gf/ /vn/ /w/ /ma/ /azu/ /wn/ ] [ Main | Settings | Bookmarks | Music Player ]