The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Анализ использования ассемблерных вставок в коде открытых проектов

02.04.2013 11:02

Стив Макинтаир (Steve McIntyre), несколько лет занимавший пост лидера проекта Debian, опубликовал результаты исследования интенсивности использования ассемблерного кода в открытых проектах. Исследование проведено инженерной группой консорциума Linaro, занимающегося адаптацией и оптимизацией открытых проектов и Linux для платформы ARM, совместно с разработчиками дистрибутивов Ubuntu и Fedora.

Исследование нацелено на выявление областей, требующих доработки в процессе внедрения новой 64-разрядной архитектуры ARMv8 (AArch64) и серверных систем на базе архитектуры ARMv7. Наличие специфичных для различных архитектур ассемблерных вставок является одним из признаков необходимости портирования кода для использования на новой архитектуре или проведения дополнительных оптимизаций. В итоге, после изучения кода всех пакетов в репозиториях Ubuntu и Fedora, был сформирован список из 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, образца 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% пакетов ассемблерные вставки используются для прямого управления содержимым служебных областей исполняемых файлов или библиотек.


  1. Главная ссылка к новости (http://blog.einval.com/2013/03...)
Лицензия: CC-BY
Тип: Обобщение
Ключевые слова: assembler, code
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (105) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, x0r (??), 13:28, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    интересный обзор
     
  • 1.2, Аноним (-), 13:28, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >около 1200 (6%) содержат ассемблерные вставки

    Ни фига себе! Я бы предположил, что от 12 до 120 (0,06--0,6%).

     
     
  • 2.25, цирроз (ok), 16:20, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    так это же только количество пакетов, где порой делают вставки. а не сравнение объёмов исходников.
     
  • 2.69, Аноним (-), 04:41, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ни фига себе! Я бы предположил, что от 12 до 120 (0,06--0,6%).

    Одни только кодеки и сколь-нибудь серьезные библиотеки и плееры - по жизни содержат кучу асам. А дебианщики как-то так решили спустить вопрос производительности на тормозах, походу. Вот уж от кого не ожидал подход "на отъ...сь" - так это от них. И после этого они что-то там про качество вещают :\.

     

  • 1.3, TbIK (ok), 13:32, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Разве для оборудования нет Си-шных функций записи в порты??
     
     
  • 2.8, Аноним (-), 14:33, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    чего?
     
     
  • 3.10, анон (?), 14:41, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    си
     
  • 2.9, dalco (ok), 14:41, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не то, что под каждую архитектуру, а, скорее, под каждый новый чип делать.

    Фактически, эта функция и будет ассемблерной вставкой :)

    Или я не прав?

     
     
  • 3.16, Аноним (-), 14:52, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не
    > то, что под каждую архитектуру, а, скорее, под каждый новый чип
    > делать.
    > Фактически, эта функция и будет ассемблерной вставкой :)
    > Или я не прав?

    Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином "порт", о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора.
    Но если очень грубо - да, это так :)

     
     
  • 4.28, pavlinux (ok), 16:27, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не
    >> то, что под каждую архитектуру, а, скорее, под каждый новый чип
    >> делать.
    >> Фактически, эта функция и будет ассемблерной вставкой :)
    >> Или я не прав?
    > Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином
    > "порт",о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора.

    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);
    }
    ...
    и т.д.

     
     
     
    Часть нити удалена модератором

  • 6.58, skb7 (ok), 23:25, 02/04/2013 [ответить]  
  • +2 +/
    Посыл топика -- ответить на вопрос, как на Си писать в порты Ваш К О Зачастую ... текст свёрнут, показать
     
     
  • 7.65, ананим (?), 01:04, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
     >*((unsigned int *)0x4ae04030) = 0xdeadbeef;

    И чем это лучше ассемблера?

    Зыж
    Вопрос не в языке и их хэйтерах. Не в ловле ведьм.
    А в ПЕРЕНОСИМОСТИ.
    Этот код будет таким же баластом на "чужой" платформе.
    Только а) его уже йюх отследишь (как асм в сабже) и б) где ифдифы? В связи с очередным готу-джихадом на них будет больше индусов.

     
     
  • 8.66, ананим (?), 01:06, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ззыж unsigned int 0x4ae04030 0xdeadbeef Вообще йюх поймёшь что эти ци... текст свёрнут, показать
     
     
  • 9.71, Аноним (-), 04:46, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поэтому нормальные люди таки дают читаемые обозначения константам Или накрайняк... текст свёрнут, показать
     
     
  • 10.76, ананим (?), 06:02, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Большинство пакетов с ассемблерными вставками будут работать на других архитекту... текст свёрнут, показать
     
     
  • 11.77, ананим (?), 06:06, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Т е , другими словами, нормальные люди читают выводы А не придумывают свой хре... текст свёрнут, показать
     
  • 10.78, ананим (?), 06:11, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зыж Да похер чем он там знаменит, ГЛАВНОЕ 8212 он аппаратн-зависим И его хер... текст свёрнут, показать
     
  • 10.90, skb7 (ok), 11:56, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Было показано, что на Си можно выполнить запись в порт Приведенный код -- прост... текст свёрнут, показать
     
  • 7.88, Аноним (-), 11:12, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Посыл топика -- ответить на вопрос, как на Си писать в порты.
    > Ваш К.О.

    В таком случае - сам задал вопрос, сам и ответил. Загляните в начало ветки.
    "Разве для оборудования нет Си-шных функций записи в порты??"

    Итак, ответ - нет. То что ваш код можно написать - кто бы спорил, на Си вообще можно написать много чего.

     
  • 5.70, Аноним (-), 04:43, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > static inline void outb(u8 b, unsigned long addr) {
    >         writeb(b, addr + PCI_IOBASE);

    Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если оно реально выводит в I/O порт а не memory-mapped аналог.

     
     
  • 6.94, pavlinux (ok), 15:39, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> 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)))

    :)

     
     
  • 7.107, Аноним (-), 13:01, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > # define __iomem  __attribute__((noderef, address_space(2)))

    Ок, продолжаем разгадки ребусов :) а что в этих определениях? :)


     
  • 2.19, BSA (?), 15:19, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А причем тут запись в порты? Если посмотришь исходники ядра, то там для этого специальные функции используются.
    Более того, не у всех процессоров есть "порты". Например, у ARM "порты" находятся в общем адресном пространстве - запись в порт на ассемблере ничем (кроме адреса) не отличается от записи в память.
     
     
  • 3.72, Аноним (-), 04:47, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > находятся в общем адресном пространстве - запись в порт на ассемблере
    > ничем (кроме адреса) не отличается от записи в память.

    Собственно практически вся современная периферия - memory mapped в основное пространство. Порты в том виде как у х86 - пережиток древних времен.

     
  • 2.68, Аноним (-), 04:39, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Разве для оборудования нет Си-шных функций записи в порты??

    Именно в порты - только через функции-хелперы (в которых ASM вероятно все-таки будет), потому что все это - в отдельном адресном пространстве. По этой причине в современных архитектурах периферия обычно memory mapped и живет в основном адресном пространстве. Так ее из сей удобнее.

    Но кроме портов, например DCT преобразование в кодеке выписанное на аккуратном SIMD ассемблере таки в несколько раз быстрее той галиматьи которую на этом коде сишный компилер сгенерит. А вот когда fullhd видео не укладывается в реалтайм и дропает кадры - это печально.

     

  • 1.4, Аноним (-), 13:55, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот это просто архиважная вещь... при чем первые две категории (38% и 30%) - ну это просто бред. Если куча копипасты, то могли все вынести в отдельную либу и ее юзать. Дак нет - давайте прямо в код.
     
     
  • 2.11, анон (?), 14:42, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    это не бред, а печальная действительность
     
  • 2.12, Аноним (-), 14:47, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Если куча копипасты, то могли все вынести в отдельную либу и ее юзать.

    Копипаст - любимейший антипаттерн, бережно взращиваемый не одним поколением программистов, а вы его так с ходу в либу... Жестоко :)

     
     
  • 3.15, Аноним (-), 14:51, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А может все это взрощенное поколение в отдельную резервацию, виртуальную (чтоб без доступа к рабочим частям мира). И пусть они там в Hello world сколько угодно копипасты на асме вставляют.
     
  • 2.38, тоже Аноним (ok), 17:13, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вполне возможно, что это и есть отдельная либа, только в виде исходников.
    Сами разработчики пакета его не писали (возможно, даже не читали). Просто нашли чужое решение, которое делает то, что нужно.
    Это сильно похоже на копипасту, но реально ей не является, так как чужой код изолирован, а не перемешан с авторским. И выполняет конкретные действия, а не является частью логики самой программы. Так что возни с его выкидыванием куда меньше.
     
     
  • 3.53, Аноним (-), 21:03, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    100500 Тонко, как английский юмор, подмечено, то что сильно похоже на копипаст... текст свёрнут, показать
     
     
  • 4.80, тоже Аноним (ok), 08:33, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, я, используя чужой код, кладу его в исходниках отдельно и под тем именем, под которым нашел. С основной логикой его перепутать сложно. Насколько эта логика зависит от логики чужого кода - это другой вопрос.
     

  • 1.5, Аноним (-), 13:56, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Одна сплошная депрессия в середине текста. "анализ где и для чего они используются и действительно ли подобные вставки необходимы", "Большая часть ассемблерных вставок малозначительна и не создаёт должного увеличения производительности", "необдуманное копирование оптимизаций из одного приложения в другое, во многих пакетах они применены не к месту и не приводят к ожидаемому разработчиками эффекту"...

    То есть получается, оптимизированная имеено для твоего компьютера операционная система Linux - всего лишь мечта и не существует ни на одном компьютере мира?

     
     
  • 2.6, Аноним (-), 14:05, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть получается, оптимизированная имеено для твоего компьютера операционная система
    > Linux - всего лишь мечта и не существует ни на одном
    > компьютере мира?

    И при чём тут ассемблерные вставки в исходниках портов?!

     
     
  • 3.30, pavlinux (ok), 16:38, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> То есть получается, оптимизированная имеено для твоего компьютера операционная система
    >> Linux - всего лишь мечта и не существует ни на одном
    >> компьютере мира?
    > И при чём тут ассемблерные вставки в исходниках портов?!

    Каких портов, где прочитал?

     
     
  • 4.31, Аноним (-), 16:43, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Каких портов, где прочитал?

    Описался по инерции. Пакетов, проектов. Тем не менее, вопрос - автор собрался оптимизицию системы строить на основе ассемблерных вставок в её компоненты? Не великоват замах?


     
  • 2.7, userd (ok), 14:16, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть получается, оптимизированная имеено для твоего компьютера операционная система Linux - всего лишь мечта и не существует ни на одном компьютере мира?

    Экак вы загнули.
    Использование source-based дистрибутива и правильных флагов gcc восстановит ваш покой.

     
     
  • 3.13, Аноним (-), 14:48, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Дак как бы оптимизация компилятором по сути и делает ненужными эти дурацкие вставки на asm, теперь только  от них надо избавиться. Вообщем всяческих успехов ребятам.
     
     
  • 4.21, BSA (?), 15:23, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оптимизации работают в большинстве случаев, но не всегда. Если у тебя какая-то хитрая обработка данных, то скорее всего, код на ассемблере будет значительно быстрее любой оптимизации компилятора. Просто потому, что разработчики компиляторов не могут зашивать все возможные алгоритмы программ в оптимизатор.
     
     
  • 5.40, тоже Аноним (ok), 17:17, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > скорее всего, код на ассемблере будет значительно быстрее любой оптимизации компилятора.

    При условии, что тот, кто это пишет, знает ассемблер не хуже тех, кто пишет компилятор. И при условии, что процессор, на котором будет выполняться этот код, не сильно отличается от того, который у автора. И даже при соблюдении этих условий фаза луны будет определять очень многое...

     
     
  • 6.46, ананим (?), 18:49, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Человека, не знающего ассемблер и оправдывающего своё незнание «ненужностью», видно сразу.

    зыж
    Напиши письмо Торвальсу и скажи что он дурак, раз стал использовать **Fast System Calls** вместо тормозных **software interrupts** с помощью ассемблерных вставок — https://lkml.org/lkml/2002/12/18/218

    ззыж
    только местные аналитеги могут связать сабжевое исследование с компиляторами С.
    Ау! Это исследование ставило целью выявить необходимость переписывания этих вставок на вставки же, но под арм. Дураку понятно, что а) всё переписывать не нужно и б) индусы и в ассемблере встречаются (особенно те, кто скопипастил не зная асм, но зная что вон тот код работает и работает быстро).

     
     
  • 7.49, тоже Аноним (ok), 19:10, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Извините, но писать Линусу глупости вам придется самостоятельно.
    А я слишком хорошо помню, как оптимизировал текстовый интерфейс, записывая символы в видеопамять вместо вызова int 10h. И Питера Абеля я к тому времени читывал... вот только ассемблер мне до сих пор так толком и не понадобился. Признаться, совершенно об этом не жалею.

    В новости недвусмысленно говорится, что большинство вставок были ненужными, и повторять эту ошибку при портировании кода под другой процессор совершенно необязательно.

     
     
  • 8.59, ананим (?), 23:31, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А он итак никому толком и не понадобился Только там, где необходим по моим наб... текст свёрнут, показать
     
     
  • 9.60, ананим (?), 23:35, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Зыж Пиндеть, не мешки ворочать Пусть сделают коммит на си например в гстример, ... текст свёрнут, показать
     
  • 9.114, arisu (ok), 20:39, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    эх, молодёжь 8230 ... текст свёрнут, показать
     
  • 8.108, Аноним (-), 13:02, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так кто ж вам виноват что вы слили знания в унитаз Со всеми бывает, не у все... текст свёрнут, показать
     
  • 6.57, Карбофос (ok), 23:07, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не обязательно, можно просто проанализировать профайлерором критичные участки кода и посмотреть, что происходит внутри. чтобы посмотреть, что внутри, можно сохранить временные файлы компайлера. покумекать. иногда полезно изменить структуры, перейти с булевских массивов на битовые и так далее. для этого не обязательно знать лучше пишуших компайллеры.
    да и потом можно оптимизировать, в том числе и на ассебмлере. к примеру, поиск в тех же самых битовых полях.
     
  • 5.42, Аноним (-), 17:35, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В целом можно согласиться Однако есть масса тонкостей, которые низводят пользу ... текст свёрнут, показать
     
     
  • 6.51, Аноним (-), 19:22, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Бред Нет Проверено моим студентом - прочитав по диагонали книгу по асемблеру ... текст свёрнут, показать
     
     
  • 7.81, Ordu (ok), 09:04, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы ведь, я надеюсь, про векторизованную обработку данных через SSE Таки да, я д... текст свёрнут, показать
     
  • 7.85, Аноним (-), 10:12, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Бред.

    Можно на этом и закончить. Дискутировать с троллем - себя не уважать. Удачи.

     
  • 6.52, ананим (?), 20:41, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а т... текст свёрнут, показать
     
     
  • 7.56, Карбофос (ok), 22:48, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Да-да. Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а то что-то быстро работает.

    тише! тише! сейчас изя припрётся и обвинит во всех тормозах ассемблерные вставки :)

     
     
  • 8.61, ананим (?), 23:37, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Там вон в новости и в жабе их кучу нашли то-то начиная с 6 она порезвела ... текст свёрнут, показать
     
     
  • 9.62, Карбофос (ok), 23:41, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    классика жанра ОЙ как неудобно получилось ... текст свёрнут, показать
     
     
  • 10.64, ананим (?), 00:13, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да Там на 2-м месте после ведра сам о ужОс компилятор гцц Щаз онанчи... текст свёрнут, показать
     
     
  • 11.109, Аноним (-), 13:03, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А также всякий там стартап код и прочая, все что вокруг живет ... текст свёрнут, показать
     
  • 7.87, Аноним (-), 10:51, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях:
    > 1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть,
    > оставляют.
    > 2. Сперли код из другого проекта вместе с асмом, в коротрый и
    > не смотрели. Но вот с чём штука, его смотрели те, кто
    > из пункта 1.

    "38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения."
    С этим-то что делать, а? Вот только не надо подгонять результаты фактического исследования под теорию.

     
     
  • 8.89, ананим (?), 11:16, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    так продолжили бы, а не вырывали из контекста при этом Подавляющее большинство ... текст свёрнут, показать
     
     
  • 9.91, Аноним (-), 12:16, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз Я возражаю против вашего посыла, согласно которому ассемблерные вставки... текст свёрнут, показать
     
     
  • 10.92, ананим (?), 12:43, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ок Сформулируйте, что такое низкоуровневые операции ... текст свёрнут, показать
     
     
  • 11.97, Аноним (-), 16:06, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой ладно отбрехиваться Вот у меня других дел нет - разводить бестолковую диск... текст свёрнут, показать
     
     
  • 12.110, Аноним (-), 13:04, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Учитывая насколько геморно их писать и что они непортабельны - по другим поводам... текст свёрнут, показать
     
  • 4.27, цирроз (ok), 16:26, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    нет, это далеко не так.
     
  • 3.22, Аноним (-), 15:35, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Толку-то? Кажется что сейчас соберёшь систему и будет летать на 486-м, а оно по скорости проигрывает даже бинарным Red Hat-ам и Mandrake-ам начала 00-х! Казалось бы - свежий код, оптимизация под SSE3 - но не задействуется даже MMX. И наконец казалось бы, ассемблерные вставки делают запускаемые на моём процессоре программы реактивными - но и это оказывается неправдой, если авторы исследования правы! Судя по процитированным мной отрывкам перевода.

    Так что же - пользоваться бинарной CentOS 5 вместо того чтобы компилировать Gentoo или LFS с оптимизациями? Всё равно код 50% программ не оптимизирован под процессорные инструкции моего процессора? И даже если есть ассемблерные вставки - 99% из них скопировано из учебников и ничего не ускоряет?

     
     
  • 4.41, тоже Аноним (ok), 17:26, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые встречаются в этом меню.
    Меню можно переписать на ассемблере, на джаваскрипте или на Lua, но пока с диска не будет прочитан кэш иконок, оно не откроется.
    По-моему, достаточно наглядный пример случая, где оптимизация кода бессильна... А вот предусмотреть чтение кэша при загрузке системы решило бы проблему. Независимо от использованного для этого языка. И открывалось бы это меню так же моментально, как у "старых добрых" систем.
     
     
  • 5.54, Аноним (-), 21:17, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые
    > встречаются в этом меню.
    > Меню можно переписать на ассемблере, на джаваскрипте или на Lua, но пока
    > с диска не будет прочитан кэш иконок, оно не откроется.
    > По-моему, достаточно наглядный пример случая, где оптимизация кода бессильна... А вот предусмотреть
    > чтение кэша при загрузке системы решило бы проблему. Независимо от использованного
    > для этого языка. И открывалось бы это меню так же моментально,
    > как у "старых добрых" систем.

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

     
  • 5.63, ананим (?), 23:45, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые встречаются в этом меню.

    Именно поэтому бинарные конфиги зло (если они все не собраны в один сжатый архив. Аля одт)

    Зыж
    Сам сижу на xfce. Грузится дольше всех (кроме г3). Но дальше работает как из пушки.

     
  • 3.73, Аноним (-), 04:49, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Использование source-based дистрибутива и правильных флагов gcc восстановит ваш покой.

    И вставки на асме сама под ARM64 перепишет :)


     
  • 3.24, ананим (?), 16:09, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >99% ассемблерных вставок ограничены всякими define. 

    Так целью исследования и было выяснить нужно ли делать такие же ифдэфы для этой платформы или нет.
    Т.к. без них возможны 2-а варинта — 1) собирается, но не работает, 2) собирается, но работает медленно/печально/криво_вплоть_до_делает_противоположенного_задумынному.

    Вариант "не собирается" не так интересен, т.к. диагностируется легко банальной сборкой и разбором полётов.

     

  • 1.26, Аноним (-), 16:23, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Сейчас понабегут аналитеги и скажут, что  ассемблерные вставки не нужны. Что ж, не доросли вы просто еще до понятий.
     
     
  • 2.29, Аноним (-), 16:28, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Сейчас понабегут аналитеги и скажут, что  ассемблерные вставки не нужны. Что
    > ж, не доросли вы просто еще до понятий.

    Ну что ж, а вы не доросли до терпимости к другому мнению. У каждого свой потолок развития.

     

  • 1.34, pavlinux (ok), 16:50, 02/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Самая лучшая инстукция - это NOP !
     
     
  • 2.35, Аноним (-), 16:52, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Самая лучшая инстукция - это NOP !

    Вот я её сейчас и выполняю. В цикле do { ... } while(tm.hour<19); :)

     
     
  • 3.36, Аноним (-), 16:54, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ты не одинок бро)
     
  • 3.37, pavlinux (ok), 17:05, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Самая лучшая инстукция - это NOP !
    > Вот я её сейчас и выполняю. В цикле do { ... }
    > while(tm.hour<19); :)

    А вот и нифига, тут есть счётчик, а это уже перегруз
    NOP - это философия, NOP - это как квадрат Малевича,
    в NOP нужно погрузиться, NOP нужно созерцать, не считая пространства и время!

    ---
    Какой-то хороший чай я заварил... Ж=)

     
     
  • 4.39, Аноним (-), 17:14, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Какой-то хороший чай я заварил... Ж=)

    С грибами?!
    :)

     
  • 4.43, Аноним (-), 17:38, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    NOP выполняется за четко оговоренное количество тактов, так что созерцать его не считая времени не получится
     
  • 4.45, masakra (ok), 18:28, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вообще то NOP суть есть MOV EAX,EAX
     
  • 4.55, Led (ok), 22:37, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > NOP - это философия, NOP - это как квадрат Малевича

    учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то это, может и "философия", но уж никак не "квадрат Малевича".

     
     
  • 5.95, pavlinux (ok), 15:47, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> NOP - это философия, NOP - это как квадрат Малевича
    > учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то
    > это, может и "философия", но уж никак не "квадрат Малевича".

    Как это, AX,AX == AX в квадрате!

     
     
  • 6.96, Led (ok), 15:56, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> NOP - это философия, NOP - это как квадрат Малевича
    >> учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то
    >> это, может и "философия", но уж никак не "квадрат Малевича".
    > Как это, AX,AX == AX в квадрате!

    Попробую объяснить смысл операции "XCHG AX,AX" в понятных тебе терминах: "шило - на мыло".

    > И ваще, XCHG выставляет флаги,

    Какие?:)


     
     
  • 7.98, pavlinux (ok), 16:06, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> И ваще, XCHG выставляет флаги,
    > Какие?:)

    Password missmatch. Access denied.  
    Чё, не меняет? Ну и хуй с ней.. :)

     
     
  • 8.101, Карбофос (ok), 00:29, 04/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    завязывай с ложными опятами ... текст свёрнут, показать
     
  • 5.116, Forth (ok), 19:39, 20/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А mov ax,bx можно написать двумя способами.
     
  • 3.75, Аноним (-), 04:51, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот я её сейчас и выполняю. В цикле do { ... } while(tm.hour<19); :)

    Или попросту - протирание штанов :)

     
     
  • 4.82, Аноним (-), 09:13, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    с волками жить - по волчьи выть бро)
     
     
  • 5.111, Аноним (-), 13:07, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > с волками жить - по волчьи выть бро)

    Ну, вам же хуже. У вас был выбор...

     
  • 2.44, цирроз (ok), 17:52, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    только в закрытых продуктах, я бы скзал. всякие JNZ нопами перебивать :-D
     
     
  • 3.48, ананим (?), 18:57, 02/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    дык по заказу хакеров и включили.
    а то как варез то распространять потенциальным клиентам?
     

  • 1.67, Аноним (-), 04:17, 03/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Большая часть ассемблерных вставок малозначительна

    Зато один конкретный видеокодек, который в одном случае впишется в реалтайм а в другом нет - может сильно испортить настроение. И пока дебианщики лечат, гугель например, которому важнее результат - люто пилит ASM вставки в своем кодеке.

    Засчитывается все-таки результат а не "ну вы же понимаете, так было проще".

     
     
  • 2.79, 123 (??), 08:29, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тащем-то шейдеры в кодеке практичнее. Да и либ с уже сделанными и оптимизированными алгоритмами у интела и AMD  с терабайт.
     
     
  • 3.84, ананим (?), 10:02, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Тащем-то шейдеры в кодеке практичнее.

    какое отношение шейдеры имеют к видеокодекам? (кроме пост-процессинга, который дома для фильмов наюх нипёрся)
    > Да и либ с уже сделанными и оптимизированными алгоритмами у интела и AMD  с терабайт.

    в которых уже понапихано ассемблерных вставок.

    зыж
    https://www.opennet.ru/opennews/art.shtml?num=36563
    >Google выпустил третью версию библиотеки с реализацией формата WebP
    >Проведена оптимизация работы кодировщика изображений. Ускорение особенно заметно в режиме кодирования c потерей качества (увеличение скорости в 3-6 раз). Добавлена порция ассемблерных оптимизаций для процессоров ARM, поддерживающих SIMD-инструкции NEON;

    порция ассемблерных … для процессоров ARM … SIMD-инструкции NEON;

     
  • 2.93, Аноним (-), 14:49, 03/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ато один конкретный видеокодек, который в одном случае впишется в реалтайм а в другом нет - может сильно испортить настроение. И пока дебианщики лечат, гугель например, которому важнее результат - люто пилит ASM вставки в своем кодеке.

    Хорошо, что пишет, если это действительно дает эффект. А исследование о том, что в куче проектов асм-вставки иногда пихают на авось, не понимая их смысла и даже не удосужившись сравнить производительность с вариантом без асма

     

  • 1.83, anonymous (??), 09:30, 03/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    людям нужны прикладные проги и игры, а они глибц и прочие в первую очередь ровняют...
     
  • 1.86, Аноним (-), 10:20, 03/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Полное ощущение, что за ночь набежала толпа архитектурных астронавтов.
     
  • 1.99, X86 (ok), 18:33, 03/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я вообще был всегда за то, чтобы весь Линукс с приложениями был на ассемблере)
     
     
  • 2.102, Карбофос (ok), 00:31, 04/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    тогда получится КолибриОС
     
     
  • 3.103, Led (ok), 01:42, 04/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > тогда получится КолибриОС

    А она разве получилась?

     
     
  • 4.105, Карбофос (ok), 21:52, 04/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    злые языки рассказывают, что и Minix не получился
     
  • 3.112, Аноним (-), 13:08, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > тогда получится КолибриОС

    КарбофОС :)

     

  • 1.100, Аноним (-), 22:26, 03/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ассемблерные вставки позволяют использовать аппаратные возможности процессора, например инструкция POPCNT.
    Это как вместо пересчёта колва спичек в спичечной коробке взвесить её :D
     
     
  • 2.104, Карбофос (ok), 21:51, 04/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно в этом есть необходимость.
     
     
  • 3.113, Аноним (-), 13:10, 05/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно
    > в этом есть необходимость.

    Ага, посмотри как GCC дуреет от армовских ld*/st* с группами регистров. Он и на пятую часть таких наворотов не рассчитан изначально был :)

     
  • 3.117, Forth (ok), 19:43, 20/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно
    > в этом есть необходимость.

    Это если компилятор в состоянии это делать, достаточно посмотреть на листинги ассемблерные, что там gcc нагенерил для arm, например, да и на x86 порой чушь есть на -O2.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру