Стив Макинтаир (Steve McIntyre), несколько лет занимавший пост лидера проекта Debian, опубликовал (http://blog.einval.com/2013/03/30) результаты исследования (https://wiki.linaro.org/LEG/Engineering/OPTIM/Assembly) интенсивности использования ассемблерного кода в открытых проектах. Исследование проведено инженерной группой консорциума Linaro, занимающегося адаптацией и оптимизацией открытых проектов и Linux для платформы ARM, совместно с разработчиками дистрибутивов Ubuntu и Fedora.
Исследование проведено с целью выявления областей, требующих доработки в процессе внедрения новой 64-разрядной архитектуры ARMv8 (AArch64) и серверных систем на базе архитеутуры ARMv7. Наличие специфичных для различных архитектур ассемблерных вставок является одним из признаков необходимости портирования кода для использовании на новой архитектуре или проведения дополнительных оптимизаций. В итоге, после изучения кода всех пакетов в репозиториях Ubuntu и Fedora, был сформирован список (https://docs.google.com/spreadsheet/ccc?key=0AlPnaP13iYU0dGJ... из 1435 пакетов, включающих ассемблерные вставки и проведён анализ где и для чего они используются и действительно ли подобные вставки необходимы.
Основные выводы:- Подавляющее большинство приложений в репозиториях не требуют отдельного портирования. Например, в из более 20 тысяч src-пакетов в репозитории Ubuntu 13.04 только около 1200 (6%) содержат ассемблерные вставки.
- Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без дополнительного портирования так как ассемблерный код используется только для оптимизации и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных возможностей, что не блокирует сборку приложения на новых архитектурах.
- Большая часть ассемблерных вставок малозначительна и не создаёт должного эффекта увеличения производительности. Часто разработчики пытаются использовать тривиальный код с надеждой увеличить скорость выполнения тех или иных действий, но при этом общий эффект подавляется другими узкими местами.
- Наименее приоритетными категориями портирования называются игры и десктоп-приложения. В первую очередь планируется портировать системные компоненты, библиотеки и базовые инструменты. Среди пакетов, требующих портирования, отмечаются: ядро, gcc, (e)glibc, klibc, libffi, binutils, gdb, device-tree-compiler, libunwind, openjdk, mpfr, llvm, gmp. Будут работать, но требуют реализации дополнительных оптимизаций grub2, TBB, openssl, libatomic-ops, libgcrypt, php, postgres, mysql, libaio. Кроме того, в первоочерёдный список портирования попали zlib, libgc, libjpeg, dlmalloc, nss и gnulib.
- В качестве основные проблем упоминается необдуманное копирование оптимизаций из одного приложения в другое, во многих пакетах они применены не к месту и не приводят к ожидаемому разработчиками эффекту. Часто подобным образом расползается по проектам код, содержащий ошибки. Другой проблемой является встраивание библиотек в программу, вместо их использования в качестве зависимости. Некоторые ассемблерные вставки нельзя трактовать иначе, как код, забытый десятилетия назад. Например, был обнаружен код для систем Vax (http://ru.wikipedia.org/wiki/VAX), образца 1970-х годов. Также во многих местах ассемблерный код присутствует в коде, но не используется.Выявленные ассемблерные компоненты были разделены на следующие категории (проценты указаны относительно числа пактов с ассемблерными вставками):
- 38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения. Многие программы используют инструкции CPUID для идентификации CPU, при этом данные чаще всего используются лишь для статистики/диагностики и напрямую не связаны с работой приложения. Популярно также использование инструкций RDTSC для взаимодействия с таймером.
- 30.4% пакетов используют ассемблерные вставки для оптимизации производительности, например, для ускорения мультимедийных операций применяются инструкции SIMD (MMX/SSE/SSE2). Многие из ассемблерных оптимизаций типовые и скопированы из других пакетов не разбираясь особо как именно работает код.
- 18.1% пакетов связны со встраиванием в состав кода различных типовых библиотек, содержащих ассемблерные вставки, например, чаще всего встраиваются libjpeg, gettext, gnulib, libgc, sqlite и zlib.- 11.1% пакетов попали в список по ошибке, например, файлы с расширением ".s" были приняты на код на ассемблере или содержали ассемблерный код в форме данных, в комментариях или в документации.
- В 10% пакетов ассемблерный код используется для реализации различных атомарных примитивов, таких как блокировки и операции инкремента/декремента.
- 9.3% пакетов включают ассемблерный код, необходимый для обеспечения работы на других операционных системах или сторонних платформах, т.е. в Linux не используется.
- В 2.9% пакетов ассемблерные вставки используются для прямого управления содержимым служебных областей исполняемых файлов или библиотек.
URL: http://blog.einval.com/2013/03/30
Новость: http://www.opennet.ru/opennews/art.shtml?num=36551
интересный обзор
>около 1200 (6%) содержат ассемблерные вставкиНи фига себе! Я бы предположил, что от 12 до 120 (0,06--0,6%).
так это же только количество пакетов, где порой делают вставки. а не сравнение объёмов исходников.
> Ни фига себе! Я бы предположил, что от 12 до 120 (0,06--0,6%).Одни только кодеки и сколь-нибудь серьезные библиотеки и плееры - по жизни содержат кучу асам. А дебианщики как-то так решили спустить вопрос производительности на тормозах, походу. Вот уж от кого не ожидал подход "на отъ...сь" - так это от них. И после этого они что-то там про качество вещают :\.
Разве для оборудования нет Си-шных функций записи в порты??
чего?
си
Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не то, что под каждую архитектуру, а, скорее, под каждый новый чип делать.Фактически, эта функция и будет ассемблерной вставкой :)
Или я не прав?
> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не
> то, что под каждую архитектуру, а, скорее, под каждый новый чип
> делать.
> Фактически, эта функция и будет ассемблерной вставкой :)
> Или я не прав?Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином "порт", о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора.
Но если очень грубо - да, это так :)
>> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не
>> то, что под каждую архитектуру, а, скорее, под каждый новый чип
>> делать.
>> Фактически, эта функция и будет ассемблерной вставкой :)
>> Или я не прав?
> Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином
> "порт",о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора.include/asm-generic/io.h
static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
{
*(volatile u8 __force *) addr = b;
}#define writeb __raw_writeb
static inline void outb(u8 b, unsigned long addr) {
writeb(b, addr + PCI_IOBASE);
}
...
и т.д.
Посыл топика -- ответить на вопрос, как на Си писать в порты. Ваш К.О.Зачастую оборудование висит прямо на шине памяти, тогда запись регистры этого оборудования производится точно также, как и запись в память. Не вижу проблемы, чтобы выполнять такую запись по адресу из Си:
*((unsigned int *)0x4ae04030) = 0xdeadbeef;
На самом деле всё немного сложнее и нужно делать ioremap(), чтобы отобразить адреса i/o в память, и потом в эту память записать нужное значение -- т.о. регистр будет содержать записанное значение.
Всё описанное должно выполняться в пространстве ядра, естественно.
Более подробно можно почитать тут:
http://rus-linux.net/MyLDP/BOOKS/drivers/linux-device-driver...
http://rus-linux.net/MyLDP/BOOKS/drivers/linux-device-driver...
http://www.makelinux.net/ldd3/chp-9-sect-4
>*((unsigned int *)0x4ae04030) = 0xdeadbeef;И чем это лучше ассемблера?
Зыж
Вопрос не в языке и их хэйтерах. Не в ловле ведьм.
А в ПЕРЕНОСИМОСТИ.
Этот код будет таким же баластом на "чужой" платформе.
Только а) его уже йюх отследишь (как асм в сабже) и б) где ифдифы? В связи с очередным готу-джихадом на них будет больше индусов.
Ззыж
>*((unsigned int *)0x4ae04030) = 0xdeadbeef;
Вообще йюх поймёшь что эти цифири значат.
Заучить?
> >*((unsigned int *)0x4ae04030) = 0xdeadbeef;
> Вообще йюх поймёшь что эти цифири значат.Поэтому нормальные люди таки дают читаемые обозначения константам. Или накрайняк хоть комент рядом пишут.
Чисто технически этот код записывает значение 0xdeadbeef по адресу 0x4ae04030. Но вот чем адрес 0x4ae04030 так примечателен на фоне остальных 4 миллиардов - из такой записи само по себе никак не видно.
С другой стороны, var_4ae04030 = 0xdeadbeef можно написать на любом ЯП. Будет настолько же понятно WTF :).
Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без дополнительного портирования так как ассемблерный код используется только для оптимизации и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных возможностей, что не блокирует сборку приложения на новых архитектурах.
Т.е., другими словами, нормальные люди читают выводы:
> Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без
> дополнительного портирования так как ассемблерный код используется только для оптимизации
> и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных
> возможностей, что не блокирует сборку приложения на новых архитектурах.А не придумывают свой "хрень на плетень".
Давай, запрограммируй sseX, 6 и более параметров в fast system call и т.д.
Зыж
>Чисто технически этот код записывает значение 0xdeadbeef по адресу 0x4ae04030. Но вот чем адрес 0x4ae04030 так примечателен на фоне остальных 4 миллиардов - из такой записи само по себе никак не видно.Да похер чем он там знаменит, ГЛАВНОЕ — он аппаратн-зависим.
И его хер найдёшь автоматом (регекспом, пока чашку кофе на кухне куришь), как ассемблерную вставку.
Результат будет ещё плачевен.
Было показано, что на Си можно выполнить запись в порт. Приведенный код -- просто пример, как это может быть сделано. Насчет именованных констант и переносимости -- сожалею, если вы хотели использовать это ПРИМЕР в продакшн-коде. Для этого есть переносимые iowrite/ioread и т.д., как выше моего поста показал pavlinux, их и используйте.
> Посыл топика -- ответить на вопрос, как на Си писать в порты.
> Ваш К.О.В таком случае - сам задал вопрос, сам и ответил. Загляните в начало ветки.
"Разве для оборудования нет Си-шных функций записи в порты??"Итак, ответ - нет. То что ваш код можно написать - кто бы спорил, на Си вообще можно написать много чего.
> static inline void outb(u8 b, unsigned long addr) {
> writeb(b, addr + PCI_IOBASE);Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если оно реально выводит в I/O порт а не memory-mapped аналог.
>> static inline void outb(u8 b, unsigned long addr) {
>> writeb(b, addr + PCI_IOBASE);
> Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если оно
> реально выводит в I/O порт а не memory-mapped аналог.#ifndef PCI_IOBASE
#define PCI_IOBASE ((void __iomem *) 0)
#endif# define __iomem __attribute__((noderef, address_space(2)))
:)
> # define __iomem __attribute__((noderef, address_space(2)))Ок, продолжаем разгадки ребусов :) а что в этих определениях? :)
А причем тут запись в порты? Если посмотришь исходники ядра, то там для этого специальные функции используются.
Более того, не у всех процессоров есть "порты". Например, у ARM "порты" находятся в общем адресном пространстве - запись в порт на ассемблере ничем (кроме адреса) не отличается от записи в память.
> находятся в общем адресном пространстве - запись в порт на ассемблере
> ничем (кроме адреса) не отличается от записи в память.Собственно практически вся современная периферия - memory mapped в основное пространство. Порты в том виде как у х86 - пережиток древних времен.
> Разве для оборудования нет Си-шных функций записи в порты??Именно в порты - только через функции-хелперы (в которых ASM вероятно все-таки будет), потому что все это - в отдельном адресном пространстве. По этой причине в современных архитектурах периферия обычно memory mapped и живет в основном адресном пространстве. Так ее из сей удобнее.
Но кроме портов, например DCT преобразование в кодеке выписанное на аккуратном SIMD ассемблере таки в несколько раз быстрее той галиматьи которую на этом коде сишный компилер сгенерит. А вот когда fullhd видео не укладывается в реалтайм и дропает кадры - это печально.
Вот это просто архиважная вещь... при чем первые две категории (38% и 30%) - ну это просто бред. Если куча копипасты, то могли все вынести в отдельную либу и ее юзать. Дак нет - давайте прямо в код.
это не бред, а печальная действительность
> Если куча копипасты, то могли все вынести в отдельную либу и ее юзать.Копипаст - любимейший антипаттерн, бережно взращиваемый не одним поколением программистов, а вы его так с ходу в либу... Жестоко :)
А может все это взрощенное поколение в отдельную резервацию, виртуальную (чтоб без доступа к рабочим частям мира). И пусть они там в Hello world сколько угодно копипасты на асме вставляют.
Вполне возможно, что это и есть отдельная либа, только в виде исходников.
Сами разработчики пакета его не писали (возможно, даже не читали). Просто нашли чужое решение, которое делает то, что нужно.
Это сильно похоже на копипасту, но реально ей не является, так как чужой код изолирован, а не перемешан с авторским. И выполняет конкретные действия, а не является частью логики самой программы. Так что возни с его выкидыванием куда меньше.
> Вполне возможно, что это и есть отдельная либа, только в виде исходников.
> Сами разработчики пакета его не писали (возможно, даже не читали). Просто нашли
> чужое решение, которое делает то, что нужно.
> Это сильно похоже на копипасту, но реально ей не является, так как
> чужой код изолирован, а не перемешан с авторским. И выполняет конкретные
> действия, а не является частью логики самой программы. Так что возни
> с его выкидыванием куда меньше.+100500
Тонко, как английский юмор, подмечено, то что "сильно похоже на копипасту, но реально ей не является".
Насколько известно непрофесионалу в области программирогравия, есть люди которые могут за выходные и копилятор LISP (или подставте свой любимый ЯП) закодить (так между делом), но невсегда на начальном этапе ясно, что есть "либа", а что основная логика программы.
Ну, я, используя чужой код, кладу его в исходниках отдельно и под тем именем, под которым нашел. С основной логикой его перепутать сложно. Насколько эта логика зависит от логики чужого кода - это другой вопрос.
Одна сплошная депрессия в середине текста. "анализ где и для чего они используются и действительно ли подобные вставки необходимы", "Большая часть ассемблерных вставок малозначительна и не создаёт должного увеличения производительности", "необдуманное копирование оптимизаций из одного приложения в другое, во многих пакетах они применены не к месту и не приводят к ожидаемому разработчиками эффекту"...То есть получается, оптимизированная имеено для твоего компьютера операционная система Linux - всего лишь мечта и не существует ни на одном компьютере мира?
> То есть получается, оптимизированная имеено для твоего компьютера операционная система
> Linux - всего лишь мечта и не существует ни на одном
> компьютере мира?И при чём тут ассемблерные вставки в исходниках портов?!
>> То есть получается, оптимизированная имеено для твоего компьютера операционная система
>> Linux - всего лишь мечта и не существует ни на одном
>> компьютере мира?
> И при чём тут ассемблерные вставки в исходниках портов?!Каких портов, где прочитал?
> Каких портов, где прочитал?Описался по инерции. Пакетов, проектов. Тем не менее, вопрос - автор собрался оптимизицию системы строить на основе ассемблерных вставок в её компоненты? Не великоват замах?
> То есть получается, оптимизированная имеено для твоего компьютера операционная система Linux - всего лишь мечта и не существует ни на одном компьютере мира?Экак вы загнули.
Использование source-based дистрибутива и правильных флагов gcc восстановит ваш покой.
Дак как бы оптимизация компилятором по сути и делает ненужными эти дурацкие вставки на asm, теперь только от них надо избавиться. Вообщем всяческих успехов ребятам.
Оптимизации работают в большинстве случаев, но не всегда. Если у тебя какая-то хитрая обработка данных, то скорее всего, код на ассемблере будет значительно быстрее любой оптимизации компилятора. Просто потому, что разработчики компиляторов не могут зашивать все возможные алгоритмы программ в оптимизатор.
> скорее всего, код на ассемблере будет значительно быстрее любой оптимизации компилятора.При условии, что тот, кто это пишет, знает ассемблер не хуже тех, кто пишет компилятор. И при условии, что процессор, на котором будет выполняться этот код, не сильно отличается от того, который у автора. И даже при соблюдении этих условий фаза луны будет определять очень многое...
Человека, не знающего ассемблер и оправдывающего своё незнание «ненужностью», видно сразу.зыж
Напиши письмо Торвальсу и скажи что он дурак, раз стал использовать **Fast System Calls** вместо тормозных **software interrupts** с помощью ассемблерных вставок — https://lkml.org/lkml/2002/12/18/218ззыж
только местные аналитеги могут связать сабжевое исследование с компиляторами С.
Ау! Это исследование ставило целью выявить необходимость переписывания этих вставок на вставки же, но под арм. Дураку понятно, что а) всё переписывать не нужно и б) индусы и в ассемблере встречаются (особенно те, кто скопипастил не зная асм, но зная что вон тот код работает и работает быстро).
Извините, но писать Линусу глупости вам придется самостоятельно.
А я слишком хорошо помню, как оптимизировал текстовый интерфейс, записывая символы в видеопамять вместо вызова int 10h. И Питера Абеля я к тому времени читывал... вот только ассемблер мне до сих пор так толком и не понадобился. Признаться, совершенно об этом не жалею.В новости недвусмысленно говорится, что большинство вставок были ненужными, и повторять эту ошибку при портировании кода под другой процессор совершенно необязательно.
>вот только ассемблер мне до сих пор так толком и не понадобился.А он итак никому толком и не понадобился.
Только там, где необходим (по моим наблюдениям) — ядро, железо, аппаратное ускорение (тут его даже мало)
Зыж
>В новости недвусмысленно говорится, что большинство вставок были ненужнымиПиндеть, не мешки ворочать.
Пусть сделают коммит на си например в гстример, а вы порадуетесь. (К слову, именно для арма в медиа больше всего вставок).
А так да, фильм на 90 минут смотрится 90 минут и с си, и с асм-вставками.
>>вот только ассемблер мне до сих пор так толком и не понадобился.
> А он итак никому толком и не понадобился.эх, молодёжь…
> вот только ассемблер мне до сих пор так толком и не понадобился.Ну так кто ж вам виноват что вы слили знания в унитаз? Со всеми бывает, не у всех проходит.
не обязательно, можно просто проанализировать профайлерором критичные участки кода и посмотреть, что происходит внутри. чтобы посмотреть, что внутри, можно сохранить временные файлы компайлера. покумекать. иногда полезно изменить структуры, перейти с булевских массивов на битовые и так далее. для этого не обязательно знать лучше пишуших компайллеры.
да и потом можно оптимизировать, в том числе и на ассебмлере. к примеру, поиск в тех же самых битовых полях.
> Оптимизации работают в большинстве случаев, но не всегда. Если у тебя какая-то
> хитрая обработка данных, то скорее всего, код на ассемблере будет значительно
> быстрее любой оптимизации компилятора. Просто потому, что разработчики компиляторов не
> могут зашивать все возможные алгоритмы программ в оптимизатор.В целом можно согласиться. Однако есть масса тонкостей, которые низводят пользу от оптимизации ассемблерными вставками до величин, близких к нулю:
1. Нужно реально иметь очень высокое мастерство работы на ассемблере.
2. Код будет скорее всего зависим от hardware.
3. Величина выигрыша будет почти наверняка зависеть от hardware.
4. Для оптимизации хитрой обработки нужно оказаться хитрее компилятора, который разрабатывали не студенты-первокурсники, надо отметить.
5. Трудозатраты на работу на ассемблере весьма велики.
6. Как показывает практика, цитата : "общий эффект подавляется другими узкими местами".ИМХО, пункт 6 наиболее убийственный из перечисленных.
Бред.> 1. Нужно реально иметь очень высокое мастерство работы на ассемблере.
Нет. Проверено моим студентом - прочитав по диагонали книгу по асемблеру (и не зная низкоуровневой кухни как-то кэши, предсказания ветвлений, конвееры и т.д.) совершенно наивный asm код примерно в половине раз получается быстрее последних gcc. Проверено на написании библиотеки графических фильтров.
> 2. Код будет скорее всего зависим от hardware.
В новости написано что почти везде это альтернативные реализации с переносимым fallback'ом.
> 3. Величина выигрыша будет почти наверняка зависеть от hardware.
Будет, и что?
> 4. Для оптимизации хитрой обработки нужно оказаться хитрее компилятора, который разрабатывали не студенты-первокурсники, надо отметить.
См п.1 - нет, ну нужно.
> 5. Трудозатраты на работу на ассемблере весьма велики.
Это никого не волнует.
> 6. Как показывает практика, цитата : "общий эффект подавляется другими узкими местами".
А вот это самый большой бред, ибо средняя температура по больнице. То, что "подавляется" в 99% случаев в 1% даст прирост производительности в десятки раз.
Итого, посыл новости должен быть в ключе: низкоуровневым оптимизациям быть, если предусмотрен
- переносимый fallback на высокоуровневом языке (заодно описывающий алгоритм)
- система сборки позволяет легко переключаться между оптимизированным и fallback вариантами
- обеспечено должное тестирование
> Нет. Проверено моим студентом - прочитав по диагонали книгу по асемблеру (и не зная
> низкоуровневой кухни как-то кэши, предсказания ветвлений, конвееры и т.д.) совершенно
> наивный asm код примерно в половине раз получается быстрее последних gcc. Проверено на
> написании библиотеки графических фильтров.Вы ведь, я надеюсь, про векторизованную обработку данных через SSE? Таки да, я думаю на этом пути возможно и несложно обогнать компилятор. Но с тех пор, как я в последний раз занимался тем, чем занимался ваш студент (то есть сравнивал ручной код на ассемблере с кодом сгенерированным компилятором) прошло лет пять-семь. С тех пор, в новостях проскакивало не раз, что у gcc всё лучше и лучше с векторизацией. Ваш студент не пробовал применять всякие опции типа -ftree-vectorize? Название опции сугубо приблизительно, я не помню точно, но в мануале всё это есть. Собственно я думаю, студент ваш (если не разгильдяй) лучше меня знает названия этих опций, и уж точно может привести список их наизусть.
В общем, если студент ваш с этими опциями поигрался как следует, то подскажите ему идею изложить результаты этих "игр" в виде статейки в интернете. Было бы интересно почитать, чтобы на таком бытовом уровне понять, что же и как gcc умеет векторизовывать. И ещё интересно было бы, если бы он рассказал о том, имеет ли смысл эти опции включать system wide, и компилировать всё без разбору с ними (ну если в этих опциях вообще есть какой-нибудь смысл).
> Бред.Можно на этом и закончить. Дискутировать с троллем - себя не уважать. Удачи.
>1. реально иметь очень высокое мастерство работы на ассемблере.
>2. Код будет скорее всего зависим от hardware.
>3. Величина выигрыша будет почти наверняка зависеть от hardware.
>4. Для оптимизации хитрой обработки нужно оказаться хитрее компилятора, который разрабатывали не студенты-первокурсники, надо отметить.Да-да. Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а то что-то быстро работает.
Зыж
Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях:
1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть, оставляют.
2. Сперли код из другого проекта вместе с асмом, в коротрый и не смотрели. Но вот с чём штука, его смотрели те, кто из пункта 1.
Про хардваре вообще эпично, а компилятор вообще нифига на целевую платформу не нацелен, не?
>Да-да. Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а то что-то быстро работает.тише! тише! сейчас изя припрётся и обвинит во всех тормозах ассемблерные вставки :)
Там вон в новости и в жабе их кучу нашли (то-то начиная с 6 она порезвела)
>Там вон в новости и в жабе их кучу нашли (то-то начиная с 6 она порезвела)классика жанра: ОЙ! как неудобно получилось!
Да-да! Там на 2-м месте (после ведра) сам (о ужОс!!!) компилятор гцц.
Щаз онанчик научит их родину любить.
> Да-да! Там на 2-м месте (после ведра) сам (о ужОс!!!) компилятор гцц.А также всякий там стартап код и прочая, все что вокруг живет.
> Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях:
> 1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть,
> оставляют.
> 2. Сперли код из другого проекта вместе с асмом, в коротрый и
> не смотрели. Но вот с чём штука, его смотрели те, кто
> из пункта 1."38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения."
С этим-то что делать, а? Вот только не надо подгонять результаты фактического исследования под теорию.
так продолжили бы, а не вырывали из контекста:
> при этом данные чаще всего используются лишь для статистики/диагностики и напрямую не связаны с работой приложения.при этом
>Основные выводы:
>Подавляющее большинство приложений в репозиториях не требуют отдельного портирования. Например, из более 20 тысяч src-пакетов в репозитории Ubuntu 13.04 только около 1200 (6%) содержат ассемблерные вставки. Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без дополнительного портирования так как ассемблерный код используется только для оптимизации и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных возможностей, что не блокирует сборку приложения на новых архитектурах.Подавляющее большинство… это сколько? 90%? 99%? если к примеру 80%, то подавляющим как бы не назовёшь, 20% — солидная цифра. таким образом:
1) выводы сделаны? да. на основании этих цифр? да. в цифрах указан объём кода, корректность обработки кода, фалбэк для этого кода? НЕТ. очевидно выводы сделаны на основании безопасности данного кода для портирования.
2) это всего-лишь 457 пакетов. очевидно в этих случаях просто не было (и нет скорее всего) совместно-используемой библиотеки из разряда LSB, где этот ассемблерный код мог бы спрятаться за API.
3) если бы цеплялись к оборудованию хакерскими средствами из С (там вон выше предлагали), то этот код вообще бы не нашли.
при этом он так бы и остался платформ-зависимым.
4) и в чём собственно криминал? можете ответить?
Ещё раз.Я возражаю против вашего посыла, согласно которому ассемблерные вставки пишутся только и исключительно для повышения производительности (либо копируются из работы людей, которые их писали для повышения производительности).
Цитирую его :
> Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях:
> 1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть,
> оставляют.
> 2. Сперли код из другого проекта вместе с асмом, в коротрый и
> не смотрели. Но вот с чём штука, его смотрели те, кто
> из пункта 1.Мой аргумент :
"38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения."Если неудачно сформулировали (слишком категорично) "только в 2-х случаях" - так и напишите, зачем плодить в оправдание наскоро написанной формулировки посты с непонятной логикой?
>"38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения."Ок. Сформулируйте, что такое низкоуровневые операции.
> Ок. Сформулируйте, что такое низкоуровневые операции.Ой ладно отбрехиваться :) Вот у меня других дел нет - разводить бестолковую дискуссию :)
Короче. Ассемблерные вставки почти в 40% случаев пишутся потому, что через них авторам почему-то лучше работается в аппаратурой.
Я, в отличие от вас, стараюсь не допускать тупых категоричных формулировок. Поэтому сразу скажу, что вполне возможно, что НЕКОТОРАЯ ЧАСТЬ этих вставок обеспечивает рост производительности. Это предположение отнюдь не приведёт к выводу о том, что все ассемблерные вставки пишутся для оптимизации производительности, что вы изволили утверждать.
> что все ассемблерные вставки пишутся для оптимизации производительности,Учитывая насколько геморно их писать и что они непортабельны - по другим поводам их на данный момент довольно редко пишут.
нет, это далеко не так.
Толку-то? Кажется что сейчас соберёшь систему и будет летать на 486-м, а оно по скорости проигрывает даже бинарным Red Hat-ам и Mandrake-ам начала 00-х! Казалось бы - свежий код, оптимизация под SSE3 - но не задействуется даже MMX. И наконец казалось бы, ассемблерные вставки делают запускаемые на моём процессоре программы реактивными - но и это оказывается неправдой, если авторы исследования правы! Судя по процитированным мной отрывкам перевода.Так что же - пользоваться бинарной CentOS 5 вместо того чтобы компилировать Gentoo или LFS с оптимизациями? Всё равно код 50% программ не оптимизирован под процессорные инструкции моего процессора? И даже если есть ассемблерные вставки - 99% из них скопировано из учебников и ничего не ускоряет?
Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые встречаются в этом меню.
Меню можно переписать на ассемблере, на джаваскрипте или на Lua, но пока с диска не будет прочитан кэш иконок, оно не откроется.
По-моему, достаточно наглядный пример случая, где оптимизация кода бессильна... А вот предусмотреть чтение кэша при загрузке системы решило бы проблему. Независимо от использованного для этого языка. И открывалось бы это меню так же моментально, как у "старых добрых" систем.
> Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые
> встречаются в этом меню.
> Меню можно переписать на ассемблере, на джаваскрипте или на Lua, но пока
> с диска не будет прочитан кэш иконок, оно не откроется.
> По-моему, достаточно наглядный пример случая, где оптимизация кода бессильна... А вот предусмотреть
> чтение кэша при загрузке системы решило бы проблему. Независимо от использованного
> для этого языка. И открывалось бы это меню так же моментально,
> как у "старых добрых" систем.Нет, только не при загрузке системы, ибо при загрузке и так делов достаточно.
А это меню может вообще ни разу не востребоватся.
>Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые встречаются в этом меню.Именно поэтому бинарные конфиги зло (если они все не собраны в один сжатый архив. Аля одт)
Зыж
Сам сижу на xfce. Грузится дольше всех (кроме г3). Но дальше работает как из пушки.
> Использование source-based дистрибутива и правильных флагов gcc восстановит ваш покой.И вставки на асме сама под ARM64 перепишет :)
>99% ассемблерных вставок ограничены всякими define.Так целью исследования и было выяснить нужно ли делать такие же ифдэфы для этой платформы или нет.
Т.к. без них возможны 2-а варинта — 1) собирается, но не работает, 2) собирается, но работает медленно/печально/криво_вплоть_до_делает_противоположенного_задумынному.Вариант "не собирается" не так интересен, т.к. диагностируется легко банальной сборкой и разбором полётов.
Сейчас понабегут аналитеги и скажут, что ассемблерные вставки не нужны. Что ж, не доросли вы просто еще до понятий.
> Сейчас понабегут аналитеги и скажут, что ассемблерные вставки не нужны. Что
> ж, не доросли вы просто еще до понятий.Ну что ж, а вы не доросли до терпимости к другому мнению. У каждого свой потолок развития.
Самая лучшая инстукция - это NOP !
> Самая лучшая инстукция - это NOP !Вот я её сейчас и выполняю. В цикле do { ... } while(tm.hour<19); :)
ты не одинок бро)
>> Самая лучшая инстукция - это NOP !
> Вот я её сейчас и выполняю. В цикле do { ... }
> while(tm.hour<19); :)А вот и нифига, тут есть счётчик, а это уже перегруз
NOP - это философия, NOP - это как квадрат Малевича,
в NOP нужно погрузиться, NOP нужно созерцать, не считая пространства и время!---
Какой-то хороший чай я заварил... Ж=)
> Какой-то хороший чай я заварил... Ж=)С грибами?!
:)
NOP выполняется за четко оговоренное количество тактов, так что созерцать его не считая времени не получится
Вообще то NOP суть есть MOV EAX,EAX
> NOP - это философия, NOP - это как квадрат Малевичаучитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то это, может и "философия", но уж никак не "квадрат Малевича".
>> NOP - это философия, NOP - это как квадрат Малевича
> учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то
> это, может и "философия", но уж никак не "квадрат Малевича".Как это, AX,AX == AX в квадрате!
>>> NOP - это философия, NOP - это как квадрат Малевича
>> учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то
>> это, может и "философия", но уж никак не "квадрат Малевича".
> Как это, AX,AX == AX в квадрате!Попробую объяснить смысл операции "XCHG AX,AX" в понятных тебе терминах: "шило - на мыло".
> И ваще, XCHG выставляет флаги,
Какие?:)
>> И ваще, XCHG выставляет флаги,
> Какие?:)Password missmatch. Access denied.
Чё, не меняет? Ну и хуй с ней.. :)
завязывай с ложными опятами ;)
А mov ax,bx можно написать двумя способами.
> Вот я её сейчас и выполняю. В цикле do { ... } while(tm.hour<19); :)Или попросту - протирание штанов :)
с волками жить - по волчьи выть бро)
> с волками жить - по волчьи выть бро)Ну, вам же хуже. У вас был выбор...
только в закрытых продуктах, я бы скзал. всякие JNZ нопами перебивать :-D
дык по заказу хакеров и включили.
а то как варез то распространять потенциальным клиентам?
> Большая часть ассемблерных вставок малозначительнаЗато один конкретный видеокодек, который в одном случае впишется в реалтайм а в другом нет - может сильно испортить настроение. И пока дебианщики лечат, гугель например, которому важнее результат - люто пилит ASM вставки в своем кодеке.
Засчитывается все-таки результат а не "ну вы же понимаете, так было проще".
Тащем-то шейдеры в кодеке практичнее. Да и либ с уже сделанными и оптимизированными алгоритмами у интела и AMD с терабайт.
>Тащем-то шейдеры в кодеке практичнее.какое отношение шейдеры имеют к видеокодекам? (кроме пост-процессинга, который дома для фильмов наюх нипёрся)
> Да и либ с уже сделанными и оптимизированными алгоритмами у интела и AMD с терабайт.в которых уже понапихано ассемблерных вставок.
зыж
http://www.opennet.ru/opennews/art.shtml?num=36563
>Google выпустил третью версию библиотеки с реализацией формата WebP
>Проведена оптимизация работы кодировщика изображений. Ускорение особенно заметно в режиме кодирования c потерей качества (увеличение скорости в 3-6 раз). Добавлена порция ассемблерных оптимизаций для процессоров ARM, поддерживающих SIMD-инструкции NEON;порция ассемблерных … для процессоров ARM … SIMD-инструкции NEON;
> ато один конкретный видеокодек, который в одном случае впишется в реалтайм а в другом нет - может сильно испортить настроение. И пока дебианщики лечат, гугель например, которому важнее результат - люто пилит ASM вставки в своем кодеке.Хорошо, что пишет, если это действительно дает эффект. А исследование о том, что в куче проектов асм-вставки иногда пихают на авось, не понимая их смысла и даже не удосужившись сравнить производительность с вариантом без асма
людям нужны прикладные проги и игры, а они глибц и прочие в первую очередь ровняют...
Полное ощущение, что за ночь набежала толпа архитектурных астронавтов.
Я вообще был всегда за то, чтобы весь Линукс с приложениями был на ассемблере)
тогда получится КолибриОС
> тогда получится КолибриОСА она разве получилась?
злые языки рассказывают, что и Minix не получился
> тогда получится КолибриОСКарбофОС :)
Ассемблерные вставки позволяют использовать аппаратные возможности процессора, например инструкция POPCNT.
Это как вместо пересчёта колва спичек в спичечной коробке взвесить её :D
как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно в этом есть необходимость.
> как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно
> в этом есть необходимость.Ага, посмотри как GCC дуреет от армовских ld*/st* с группами регистров. Он и на пятую часть таких наворотов не рассчитан изначально был :)
> как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно
> в этом есть необходимость.Это если компилятор в состоянии это делать, достаточно посмотреть на листинги ассемблерные, что там gcc нагенерил для arm, например, да и на x86 порой чушь есть на -O2.