форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
Сообщение от opennews (??) on 02-Апр-13, 13:28
Стив Макинтаир (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.dev/opennews/art.shtml?num=36551
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Анализ использования ассемблерных вставок в коде открытых пр..."	+4 +/–
Сообщение от x0r (??) on 02-Апр-13, 13:28
интересный обзор
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Анализ использования ассемблерных вставок в коде открытых пр..."	–4 +/–
Сообщение от Аноним (??) on 02-Апр-13, 13:28
>около 1200 (6%) содержат ассемблерные вставки Ни фига себе! Я бы предположил, что от 12 до 120 (0,06--0,6%).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Анализ использования ассемблерных вставок в коде открытых пр..."	+3 +/–
	Сообщение от цирроз (ok) on 02-Апр-13, 16:20
	так это же только количество пакетов, где порой делают вставки. а не сравнение объёмов исходников.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	69. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:41
	> Ни фига себе! Я бы предположил, что от 12 до 120 (0,06--0,6%). Одни только кодеки и сколь-нибудь серьезные библиотеки и плееры - по жизни содержат кучу асам. А дебианщики как-то так решили спустить вопрос производительности на тормозах, походу. Вот уж от кого не ожидал подход "на отъ...сь" - так это от них. И после этого они что-то там про качество вещают :\.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Анализ использования ассемблерных вставок в коде открытых пр..."	–2 +/–
Сообщение от TbIK (ok) on 02-Апр-13, 13:32
Разве для оборудования нет Си-шных функций записи в порты??
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 14:33
	чего?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от анон on 02-Апр-13, 14:41
	си
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	9. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от dalco (ok) on 02-Апр-13, 14:41
	Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не то, что под каждую архитектуру, а, скорее, под каждый новый чип делать. Фактически, эта функция и будет ассемблерной вставкой :) Или я не прав?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	16. "Анализ использования ассемблерных вставок в коде открытых пр..."	+3 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 14:52
	> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не > то, что под каждую архитектуру, а, скорее, под каждый новый чип > делать. > Фактически, эта функция и будет ассемблерной вставкой :) > Или я не прав? Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином "порт", о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора. Но если очень грубо - да, это так :)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	28. "Анализ использования ассемблерных вставок в коде открытых пр..."	+4 +/–
	Сообщение от pavlinux (ok) on 02-Апр-13, 16:27
	>> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не >> то, что под каждую архитектуру, а, скорее, под каждый новый чип >> делать. >> Фактически, эта функция и будет ассемблерной вставкой :) >> Или я не прав? > Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином > "порт",о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора. 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); } ... и т.д.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

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

	58. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от skb7 (ok) on 02-Апр-13, 23:25
	Посыл топика -- ответить на вопрос, как на Си писать в порты. Ваш К.О. Зачастую оборудование висит прямо на шине памяти, тогда запись регистры этого оборудования производится точно также, как и запись в память. Не вижу проблемы, чтобы выполнять такую запись по адресу из Си:   *((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
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от ананим on 03-Апр-13, 01:04
	>*((unsigned int *)0x4ae04030) = 0xdeadbeef; И чем это лучше ассемблера? Зыж Вопрос не в языке и их хэйтерах. Не в ловле ведьм. А в ПЕРЕНОСИМОСТИ. Этот код будет таким же баластом на "чужой" платформе. Только а) его уже йюх отследишь (как асм в сабже) и б) где ифдифы? В связи с очередным готу-джихадом на них будет больше индусов.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	66. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от ананим on 03-Апр-13, 01:06
	Ззыж  >*((unsigned int *)0x4ae04030) = 0xdeadbeef; Вообще йюх поймёшь что эти цифири значат. Заучить?
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	71. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:46
	>  >*((unsigned int *)0x4ae04030) = 0xdeadbeef; > Вообще йюх поймёшь что эти цифири значат. Поэтому нормальные люди таки дают читаемые обозначения константам. Или накрайняк хоть комент рядом пишут. Чисто технически этот код записывает значение 0xdeadbeef по адресу 0x4ae04030. Но вот чем адрес 0x4ae04030 так примечателен на фоне остальных 4 миллиардов - из такой записи само по себе никак не видно. С другой стороны, var_4ae04030 = 0xdeadbeef можно написать на любом ЯП. Будет настолько же понятно WTF :).
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	76. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 03-Апр-13, 06:02
	Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без дополнительного портирования так как ассемблерный код используется только для оптимизации и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных возможностей, что не блокирует сборку приложения на новых архитектурах.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	77. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от ананим on 03-Апр-13, 06:06
	Т.е., другими словами, нормальные люди читают выводы: > Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без > дополнительного портирования так как ассемблерный код используется только для оптимизации > и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных > возможностей, что не блокирует сборку приложения на новых архитектурах. А не придумывают свой "хрень на плетень". Давай, запрограммируй sseX, 6 и более параметров в fast system call и т.д.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	78. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от ананим on 03-Апр-13, 06:11
	Зыж >Чисто технически этот код записывает значение 0xdeadbeef по адресу 0x4ae04030. Но вот чем адрес 0x4ae04030 так примечателен на фоне остальных 4 миллиардов - из такой записи само по себе никак не видно. Да похер чем он там знаменит, ГЛАВНОЕ — он аппаратн-зависим. И его хер найдёшь автоматом (регекспом, пока чашку кофе на кухне куришь), как ассемблерную вставку. Результат будет ещё плачевен.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	90. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от skb7 (ok) on 03-Апр-13, 11:56
	Было показано, что на Си можно выполнить запись в порт. Приведенный код -- просто пример, как это может быть сделано. Насчет именованных констант и переносимости -- сожалею, если вы хотели использовать это ПРИМЕР в продакшн-коде. Для этого есть переносимые iowrite/ioread и т.д., как выше моего поста показал pavlinux, их и используйте.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	88. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 11:12
	> Посыл топика -- ответить на вопрос, как на Си писать в порты. > Ваш К.О. В таком случае - сам задал вопрос, сам и ответил. Загляните в начало ветки. "Разве для оборудования нет Си-шных функций записи в порты??" Итак, ответ - нет. То что ваш код можно написать - кто бы спорил, на Си вообще можно написать много чего.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	70. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:43
	> static inline void outb(u8 b, unsigned long addr) { >         writeb(b, addr + PCI_IOBASE); Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если оно реально выводит в I/O порт а не memory-mapped аналог.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	94. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от pavlinux (ok) on 03-Апр-13, 15:39
	>> 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))) :)
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	107. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:01
	> # define __iomem  __attribute__((noderef, address_space(2))) Ок, продолжаем разгадки ребусов :) а что в этих определениях? :)
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	19. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от BSA on 02-Апр-13, 15:19
	А причем тут запись в порты? Если посмотришь исходники ядра, то там для этого специальные функции используются. Более того, не у всех процессоров есть "порты". Например, у ARM "порты" находятся в общем адресном пространстве - запись в порт на ассемблере ничем (кроме адреса) не отличается от записи в память.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	72. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:47
	> находятся в общем адресном пространстве - запись в порт на ассемблере > ничем (кроме адреса) не отличается от записи в память. Собственно практически вся современная периферия - memory mapped в основное пространство. Порты в том виде как у х86 - пережиток древних времен.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	68. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:39
	> Разве для оборудования нет Си-шных функций записи в порты?? Именно в порты - только через функции-хелперы (в которых ASM вероятно все-таки будет), потому что все это - в отдельном адресном пространстве. По этой причине в современных архитектурах периферия обычно memory mapped и живет в основном адресном пространстве. Так ее из сей удобнее. Но кроме портов, например DCT преобразование в кодеке выписанное на аккуратном SIMD ассемблере таки в несколько раз быстрее той галиматьи которую на этом коде сишный компилер сгенерит. А вот когда fullhd видео не укладывается в реалтайм и дропает кадры - это печально.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
Сообщение от Аноним (??) on 02-Апр-13, 13:55
Вот это просто архиважная вещь... при чем первые две категории (38% и 30%) - ну это просто бред. Если куча копипасты, то могли все вынести в отдельную либу и ее юзать. Дак нет - давайте прямо в код.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Анализ использования ассемблерных вставок в коде открытых пр..."	+4 +/–
	Сообщение от анон on 02-Апр-13, 14:42
	это не бред, а печальная действительность
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Анализ использования ассемблерных вставок в коде открытых пр..."	+5 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 14:47
	> Если куча копипасты, то могли все вынести в отдельную либу и ее юзать. Копипаст - любимейший антипаттерн, бережно взращиваемый не одним поколением программистов, а вы его так с ходу в либу... Жестоко :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	15. "Анализ использования ассемблерных вставок в коде открытых пр..."	–2 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 14:51
	А может все это взрощенное поколение в отдельную резервацию, виртуальную (чтоб без доступа к рабочим частям мира). И пусть они там в Hello world сколько угодно копипасты на асме вставляют.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	38. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от тоже Аноним (ok) on 02-Апр-13, 17:13
	Вполне возможно, что это и есть отдельная либа, только в виде исходников. Сами разработчики пакета его не писали (возможно, даже не читали). Просто нашли чужое решение, которое делает то, что нужно. Это сильно похоже на копипасту, но реально ей не является, так как чужой код изолирован, а не перемешан с авторским. И выполняет конкретные действия, а не является частью логики самой программы. Так что возни с его выкидыванием куда меньше.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	53. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 21:03
	> Вполне возможно, что это и есть отдельная либа, только в виде исходников. > Сами разработчики пакета его не писали (возможно, даже не читали). Просто нашли > чужое решение, которое делает то, что нужно. > Это сильно похоже на копипасту, но реально ей не является, так как > чужой код изолирован, а не перемешан с авторским. И выполняет конкретные > действия, а не является частью логики самой программы. Так что возни > с его выкидыванием куда меньше. +100500 Тонко, как английский юмор, подмечено, то что "сильно похоже на копипасту, но реально ей не является". Насколько известно непрофесионалу в области программирогравия, есть люди которые могут за выходные и копилятор LISP (или подставте свой любимый ЯП) закодить (так между делом), но невсегда на начальном этапе ясно, что есть "либа", а что основная логика программы.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	80. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от тоже Аноним (ok) on 03-Апр-13, 08:33
	Ну, я, используя чужой код, кладу его в исходниках отдельно и под тем именем, под которым нашел. С основной логикой его перепутать сложно. Насколько эта логика зависит от логики чужого кода - это другой вопрос.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

5. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
Сообщение от Аноним (??) on 02-Апр-13, 13:56
Одна сплошная депрессия в середине текста. "анализ где и для чего они используются и действительно ли подобные вставки необходимы", "Большая часть ассемблерных вставок малозначительна и не создаёт должного увеличения производительности", "необдуманное копирование оптимизаций из одного приложения в другое, во многих пакетах они применены не к месту и не приводят к ожидаемому разработчиками эффекту"... То есть получается, оптимизированная имеено для твоего компьютера операционная система Linux - всего лишь мечта и не существует ни на одном компьютере мира?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 14:05
	> То есть получается, оптимизированная имеено для твоего компьютера операционная система > Linux - всего лишь мечта и не существует ни на одном > компьютере мира? И при чём тут ассемблерные вставки в исходниках портов?!
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	30. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от pavlinux (ok) on 02-Апр-13, 16:38
	>> То есть получается, оптимизированная имеено для твоего компьютера операционная система >> Linux - всего лишь мечта и не существует ни на одном >> компьютере мира? > И при чём тут ассемблерные вставки в исходниках портов?! Каких портов, где прочитал?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	31. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 16:43
	> Каких портов, где прочитал? Описался по инерции. Пакетов, проектов. Тем не менее, вопрос - автор собрался оптимизицию системы строить на основе ассемблерных вставок в её компоненты? Не великоват замах?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	7. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от userd (ok) on 02-Апр-13, 14:16
	> То есть получается, оптимизированная имеено для твоего компьютера операционная система Linux - всего лишь мечта и не существует ни на одном компьютере мира? Экак вы загнули. Использование source-based дистрибутива и правильных флагов gcc восстановит ваш покой.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	13. "Анализ использования ассемблерных вставок в коде открытых пр..."	–2 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 14:48
	Дак как бы оптимизация компилятором по сути и делает ненужными эти дурацкие вставки на asm, теперь только  от них надо избавиться. Вообщем всяческих успехов ребятам.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	21. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от BSA on 02-Апр-13, 15:23
	Оптимизации работают в большинстве случаев, но не всегда. Если у тебя какая-то хитрая обработка данных, то скорее всего, код на ассемблере будет значительно быстрее любой оптимизации компилятора. Просто потому, что разработчики компиляторов не могут зашивать все возможные алгоритмы программ в оптимизатор.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	40. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от тоже Аноним (ok) on 02-Апр-13, 17:17
	> скорее всего, код на ассемблере будет значительно быстрее любой оптимизации компилятора. При условии, что тот, кто это пишет, знает ассемблер не хуже тех, кто пишет компилятор. И при условии, что процессор, на котором будет выполняться этот код, не сильно отличается от того, который у автора. И даже при соблюдении этих условий фаза луны будет определять очень многое...
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	46. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от ананим on 02-Апр-13, 18:49
	Человека, не знающего ассемблер и оправдывающего своё незнание «ненужностью», видно сразу. зыж Напиши письмо Торвальсу и скажи что он дурак, раз стал использовать **Fast System Calls** вместо тормозных **software interrupts** с помощью ассемблерных вставок — https://lkml.org/lkml/2002/12/18/218 ззыж только местные аналитеги могут связать сабжевое исследование с компиляторами С. Ау! Это исследование ставило целью выявить необходимость переписывания этих вставок на вставки же, но под арм. Дураку понятно, что а) всё переписывать не нужно и б) индусы и в ассемблере встречаются (особенно те, кто скопипастил не зная асм, но зная что вон тот код работает и работает быстро).
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	49. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от тоже Аноним (ok) on 02-Апр-13, 19:10
	Извините, но писать Линусу глупости вам придется самостоятельно. А я слишком хорошо помню, как оптимизировал текстовый интерфейс, записывая символы в видеопамять вместо вызова int 10h. И Питера Абеля я к тому времени читывал... вот только ассемблер мне до сих пор так толком и не понадобился. Признаться, совершенно об этом не жалею. В новости недвусмысленно говорится, что большинство вставок были ненужными, и повторять эту ошибку при портировании кода под другой процессор совершенно необязательно.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	59. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 02-Апр-13, 23:31
	>вот только ассемблер мне до сих пор так толком и не понадобился.  А он итак никому толком и не понадобился. Только там, где необходим (по моим наблюдениям) — ядро, железо, аппаратное ускорение (тут его даже мало)
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	60. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 02-Апр-13, 23:35
	Зыж >В новости недвусмысленно говорится, что большинство вставок были ненужными Пиндеть, не мешки ворочать. Пусть сделают коммит на си например в гстример, а вы порадуетесь. (К слову, именно для арма в медиа больше всего вставок). А так да, фильм на 90 минут смотрится 90 минут и с си, и с асм-вставками.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	114. "Анализ использования ассемблерных вставок в коде..."	+1 +/–
	Сообщение от arisu (ok) on 05-Апр-13, 20:39
	>>вот только ассемблер мне до сих пор так толком и не понадобился.  > А он итак никому толком и не понадобился. эх, молодёжь…
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	108. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:02
	> вот только ассемблер мне до сих пор так толком и не понадобился. Ну так кто ж вам виноват что вы слили знания в унитаз? Со всеми бывает, не у всех проходит.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	57. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от Карбофос (ok) on 02-Апр-13, 23:07
	не обязательно, можно просто проанализировать профайлерором критичные участки кода и посмотреть, что происходит внутри. чтобы посмотреть, что внутри, можно сохранить временные файлы компайлера. покумекать. иногда полезно изменить структуры, перейти с булевских массивов на битовые и так далее. для этого не обязательно знать лучше пишуших компайллеры. да и потом можно оптимизировать, в том числе и на ассебмлере. к примеру, поиск в тех же самых битовых полях.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	42. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 17:35
	> Оптимизации работают в большинстве случаев, но не всегда. Если у тебя какая-то > хитрая обработка данных, то скорее всего, код на ассемблере будет значительно > быстрее любой оптимизации компилятора. Просто потому, что разработчики компиляторов не > могут зашивать все возможные алгоритмы программ в оптимизатор. В целом можно согласиться. Однако есть масса тонкостей, которые низводят пользу от оптимизации ассемблерными вставками до величин, близких к нулю: 1. Нужно реально иметь очень высокое мастерство работы на ассемблере. 2. Код будет скорее всего зависим от hardware. 3. Величина выигрыша будет почти наверняка зависеть от hardware. 4. Для оптимизации хитрой обработки нужно оказаться хитрее компилятора, который разрабатывали не студенты-первокурсники, надо отметить. 5. Трудозатраты на работу на ассемблере весьма велики. 6. Как показывает практика, цитата : "общий эффект подавляется другими узкими местами". ИМХО, пункт 6 наиболее убийственный из перечисленных.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	51. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 19:22
	Бред. > 1. Нужно реально иметь очень высокое мастерство работы на ассемблере. Нет. Проверено моим студентом - прочитав по диагонали книгу по асемблеру (и не зная низкоуровневой кухни как-то кэши, предсказания ветвлений, конвееры и т.д.) совершенно наивный asm код примерно в половине раз получается быстрее последних gcc. Проверено на написании библиотеки графических фильтров. > 2. Код будет скорее всего зависим от hardware. В новости написано что почти везде это альтернативные реализации с переносимым fallback'ом. > 3. Величина выигрыша будет почти наверняка зависеть от hardware. Будет, и что? > 4. Для оптимизации хитрой обработки нужно оказаться хитрее компилятора, который разрабатывали не студенты-первокурсники, надо отметить. См п.1 - нет, ну нужно. > 5. Трудозатраты на работу на ассемблере весьма велики. Это никого не волнует. > 6. Как показывает практика, цитата : "общий эффект подавляется другими узкими местами". А вот это самый большой бред, ибо средняя температура по больнице. То, что "подавляется" в 99% случаев в 1% даст прирост производительности в десятки раз. Итого, посыл новости должен быть в ключе: низкоуровневым оптимизациям быть, если предусмотрен - переносимый fallback на высокоуровневом языке (заодно описывающий алгоритм) - система сборки позволяет легко переключаться между оптимизированным и fallback вариантами - обеспечено должное тестирование
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	81. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от Ordu (ok) on 03-Апр-13, 09:04
	> Нет. Проверено моим студентом - прочитав по диагонали книгу по асемблеру (и не зная > низкоуровневой кухни как-то кэши, предсказания ветвлений, конвееры и т.д.) совершенно > наивный asm код примерно в половине раз получается быстрее последних gcc. Проверено на > написании библиотеки графических фильтров. Вы ведь, я надеюсь, про векторизованную обработку данных через SSE? Таки да, я думаю на этом пути возможно и несложно обогнать компилятор. Но с тех пор, как я в последний раз занимался тем, чем занимался ваш студент (то есть сравнивал ручной код на ассемблере с кодом сгенерированным компилятором) прошло лет пять-семь. С тех пор, в новостях проскакивало не раз, что у gcc всё лучше и лучше с векторизацией. Ваш студент не пробовал применять всякие опции типа -ftree-vectorize? Название опции сугубо приблизительно, я не помню точно, но в мануале всё это есть. Собственно я думаю, студент ваш (если не разгильдяй) лучше меня знает названия этих опций, и уж точно может привести список их наизусть. В общем, если студент ваш с этими опциями поигрался как следует, то подскажите ему идею изложить результаты этих "игр" в виде статейки в интернете. Было бы интересно почитать, чтобы на таком бытовом уровне понять, что же и как gcc умеет векторизовывать. И ещё интересно было бы, если бы он рассказал о том, имеет ли смысл эти опции включать system wide, и компилировать всё без разбору с ними (ну если в этих опциях вообще есть какой-нибудь смысл).
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	85. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от Аноним (??) on 03-Апр-13, 10:12
	> Бред. Можно на этом и закончить. Дискутировать с троллем - себя не уважать. Удачи.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	52. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 02-Апр-13, 20:41
	>1. реально иметь очень высокое мастерство работы на ассемблере. >2. Код будет скорее всего зависим от hardware. >3. Величина выигрыша будет почти наверняка зависеть от hardware. >4. Для оптимизации хитрой обработки нужно оказаться хитрее компилятора, который разрабатывали не студенты-первокурсники, надо отметить. Да-да. Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а то что-то быстро работает. Зыж Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях: 1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть, оставляют. 2. Сперли код из другого проекта вместе с асмом, в коротрый и не смотрели. Но вот с чём штука, его смотрели те, кто из пункта 1. Про хардваре вообще эпично, а компилятор вообще нифига на целевую платформу не нацелен, не?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	56. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от Карбофос (ok) on 02-Апр-13, 22:48
	>Да-да. Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а то что-то быстро работает. тише! тише! сейчас изя припрётся и обвинит во всех тормозах ассемблерные вставки :)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	61. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 02-Апр-13, 23:37
	Там вон в новости и в жабе их кучу нашли (то-то начиная с 6 она порезвела)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	62. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Карбофос (ok) on 02-Апр-13, 23:41
	>Там вон в новости и в жабе их кучу нашли (то-то начиная с 6 она порезвела) классика жанра: ОЙ! как неудобно получилось!
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	64. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 03-Апр-13, 00:13
	Да-да! Там на 2-м месте (после ведра) сам (о ужОс!!!) компилятор гцц. Щаз онанчик научит их родину любить.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	109. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:03
	> Да-да! Там на 2-м месте (после ведра) сам (о ужОс!!!) компилятор гцц. А также всякий там стартап код и прочая, все что вокруг живет.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	87. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 03-Апр-13, 10:51
	> Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях: > 1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть, > оставляют. > 2. Сперли код из другого проекта вместе с асмом, в коротрый и > не смотрели. Но вот с чём штука, его смотрели те, кто > из пункта 1. "38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения." С этим-то что делать, а? Вот только не надо подгонять результаты фактического исследования под теорию.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	89. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 03-Апр-13, 11:16
	так продолжили бы, а не вырывали из контекста: > при этом данные чаще всего используются лишь для статистики/диагностики и напрямую не связаны с работой приложения. при этом >Основные выводы: >Подавляющее большинство приложений в репозиториях не требуют отдельного портирования. Например, из более 20 тысяч src-пакетов в репозитории Ubuntu 13.04 только около 1200 (6%) содержат ассемблерные вставки.     Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без дополнительного портирования так как ассемблерный код используется только для оптимизации и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных возможностей, что не блокирует сборку приложения на новых архитектурах. Подавляющее большинство… это сколько? 90%? 99%? если к примеру 80%, то подавляющим как бы не назовёшь, 20% — солидная цифра. таким образом: 1) выводы сделаны? да. на основании этих цифр? да. в цифрах указан объём кода, корректность обработки кода, фалбэк для этого кода? НЕТ. очевидно выводы сделаны на основании безопасности данного кода для портирования. 2) это всего-лишь 457 пакетов. очевидно в этих случаях просто не было (и нет скорее всего) совместно-используемой библиотеки из разряда LSB, где этот ассемблерный код мог бы спрятаться за API. 3) если бы цеплялись к оборудованию хакерскими средствами из С (там вон выше предлагали), то этот код вообще бы не нашли. при этом он так бы и остался платформ-зависимым. 4) и в чём собственно криминал? можете ответить?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	91. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 12:16
	Ещё раз. Я возражаю против вашего посыла, согласно которому ассемблерные вставки пишутся только и исключительно для повышения производительности (либо копируются из работы людей, которые их писали для повышения производительности). Цитирую его : > Асм вставляют (даже те кто его хорошо знает) только в 2-х случаях: > 1. Когда хотят увеличить скорость выполнения пишут, потом проверяют, если эффект есть, > оставляют. > 2. Сперли код из другого проекта вместе с асмом, в коротрый и > не смотрели. Но вот с чём штука, его смотрели те, кто > из пункта 1. Мой аргумент : "38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения." Если неудачно сформулировали (слишком категорично) "только в 2-х случаях" - так и напишите, зачем плодить в оправдание наскоро написанной формулировки посты с непонятной логикой?
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	92. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 03-Апр-13, 12:43
	>"38.1% пакетов используют ассемблерный код для выполнения различных низкоуровневых операций, таких как прямое взаимодействие с оборудованием и определение типа аппаратного обеспечения." Ок. Сформулируйте, что такое низкоуровневые операции.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	97. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 03-Апр-13, 16:06
	> Ок. Сформулируйте, что такое низкоуровневые операции. Ой ладно отбрехиваться :) Вот у меня других дел нет - разводить бестолковую дискуссию :) Короче. Ассемблерные вставки почти в 40% случаев пишутся потому, что через них авторам почему-то лучше работается в аппаратурой. Я, в отличие от вас, стараюсь не допускать тупых категоричных формулировок. Поэтому сразу скажу, что вполне возможно, что НЕКОТОРАЯ ЧАСТЬ этих вставок обеспечивает рост производительности. Это предположение отнюдь не приведёт к выводу о том, что все ассемблерные вставки пишутся для оптимизации производительности, что вы изволили утверждать.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	110. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:04
	> что все ассемблерные вставки пишутся для оптимизации производительности, Учитывая насколько геморно их писать и что они непортабельны - по другим поводам их на данный момент довольно редко пишут.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	27. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от цирроз (ok) on 02-Апр-13, 16:26
	нет, это далеко не так.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	22. "Анализ использования ассемблерных вставок в коде открытых пр..."	–2 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 15:35
	Толку-то? Кажется что сейчас соберёшь систему и будет летать на 486-м, а оно по скорости проигрывает даже бинарным Red Hat-ам и Mandrake-ам начала 00-х! Казалось бы - свежий код, оптимизация под SSE3 - но не задействуется даже MMX. И наконец казалось бы, ассемблерные вставки делают запускаемые на моём процессоре программы реактивными - но и это оказывается неправдой, если авторы исследования правы! Судя по процитированным мной отрывкам перевода. Так что же - пользоваться бинарной CentOS 5 вместо того чтобы компилировать Gentoo или LFS с оптимизациями? Всё равно код 50% программ не оптимизирован под процессорные инструкции моего процессора? И даже если есть ассемблерные вставки - 99% из них скопировано из учебников и ничего не ускоряет?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	41. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от тоже Аноним (ok) on 02-Апр-13, 17:26
	Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые встречаются в этом меню. Меню можно переписать на ассемблере, на джаваскрипте или на Lua, но пока с диска не будет прочитан кэш иконок, оно не откроется. По-моему, достаточно наглядный пример случая, где оптимизация кода бессильна... А вот предусмотреть чтение кэша при загрузке системы решило бы проблему. Независимо от использованного для этого языка. И открывалось бы это меню так же моментально, как у "старых добрых" систем.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	54. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 21:17
	> Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые > встречаются в этом меню. > Меню можно переписать на ассемблере, на джаваскрипте или на Lua, но пока > с диска не будет прочитан кэш иконок, оно не откроется. > По-моему, достаточно наглядный пример случая, где оптимизация кода бессильна... А вот предусмотреть > чтение кэша при загрузке системы решило бы проблему. Независимо от использованного > для этого языка. И открывалось бы это меню так же моментально, > как у "старых добрых" систем. Нет, только не при загрузке системы, ибо при загрузке и так делов достаточно. А это меню может вообще ни разу не востребоватся.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	63. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от ананим on 02-Апр-13, 23:45
	>Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые встречаются в этом меню. Именно поэтому бинарные конфиги зло (если они все не собраны в один сжатый архив. Аля одт) Зыж Сам сижу на xfce. Грузится дольше всех (кроме г3). Но дальше работает как из пушки.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	73. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:49
	> Использование source-based дистрибутива и правильных флагов gcc восстановит ваш покой. И вставки на асме сама под ARM64 перепишет :)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	24. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 02-Апр-13, 16:09
	>99% ассемблерных вставок ограничены всякими define.  Так целью исследования и было выяснить нужно ли делать такие же ифдэфы для этой платформы или нет. Т.к. без них возможны 2-а варинта — 1) собирается, но не работает, 2) собирается, но работает медленно/печально/криво_вплоть_до_делает_противоположенного_задумынному. Вариант "не собирается" не так интересен, т.к. диагностируется легко банальной сборкой и разбором полётов.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

26. "Анализ использования ассемблерных вставок в коде открытых пр..."	–3 +/–
Сообщение от Аноним (??) on 02-Апр-13, 16:23
Сейчас понабегут аналитеги и скажут, что  ассемблерные вставки не нужны. Что ж, не доросли вы просто еще до понятий.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Анализ использования ассемблерных вставок в коде открытых пр..."	+3 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 16:28
	> Сейчас понабегут аналитеги и скажут, что  ассемблерные вставки не нужны. Что > ж, не доросли вы просто еще до понятий. Ну что ж, а вы не доросли до терпимости к другому мнению. У каждого свой потолок развития.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

34. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
Сообщение от pavlinux (ok) on 02-Апр-13, 16:50
Самая лучшая инстукция - это NOP !
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 16:52
	> Самая лучшая инстукция - это NOP ! Вот я её сейчас и выполняю. В цикле do { ... } while(tm.hour<19); :)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	36. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 16:54
	ты не одинок бро)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от pavlinux (ok) on 02-Апр-13, 17:05
	>> Самая лучшая инстукция - это NOP ! > Вот я её сейчас и выполняю. В цикле do { ... } > while(tm.hour<19); :) А вот и нифига, тут есть счётчик, а это уже перегруз NOP - это философия, NOP - это как квадрат Малевича, в NOP нужно погрузиться, NOP нужно созерцать, не считая пространства и время! --- Какой-то хороший чай я заварил... Ж=)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "Анализ использования ассемблерных вставок в коде открытых пр..."	+2 +/–
	Сообщение от Аноним (??) on 02-Апр-13, 17:14
	> Какой-то хороший чай я заварил... Ж=) С грибами?! :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	43. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 02-Апр-13, 17:38
	NOP выполняется за четко оговоренное количество тактов, так что созерцать его не считая времени не получится
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	45. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от masakra (ok) on 02-Апр-13, 18:28
	Вообще то NOP суть есть MOV EAX,EAX
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	55. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от Led (ok) on 02-Апр-13, 22:37
	> NOP - это философия, NOP - это как квадрат Малевича учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то это, может и "философия", но уж никак не "квадрат Малевича".
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	95. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от pavlinux (ok) on 03-Апр-13, 15:47
	>> NOP - это философия, NOP - это как квадрат Малевича > учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то > это, может и "философия", но уж никак не "квадрат Малевича". Как это, AX,AX == AX в квадрате!
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	96. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Led (ok) on 03-Апр-13, 15:56
	>>> NOP - это философия, NOP - это как квадрат Малевича >> учитывая то, что классический однобайтный x86 NOP - это "XCHG AX,AX", то >> это, может и "философия", но уж никак не "квадрат Малевича". > Как это, AX,AX == AX в квадрате! Попробую объяснить смысл операции "XCHG AX,AX" в понятных тебе терминах: "шило - на мыло". > И ваще, XCHG выставляет флаги, Какие?:)
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	98. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от pavlinux (ok) on 03-Апр-13, 16:06
	>> И ваще, XCHG выставляет флаги, > Какие?:) Password missmatch. Access denied.   Чё, не меняет? Ну и хуй с ней.. :)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	101. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от Карбофос (ok) on 04-Апр-13, 00:29
	завязывай с ложными опятами ;)
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	116. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Forth (ok) on 20-Май-15, 19:39
	А mov ax,bx можно написать двумя способами.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	75. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 04:51
	> Вот я её сейчас и выполняю. В цикле do { ... } while(tm.hour<19); :) Или попросту - протирание штанов :)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	82. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 09:13
	с волками жить - по волчьи выть бро)
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	111. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:07
	> с волками жить - по волчьи выть бро) Ну, вам же хуже. У вас был выбор...
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	44. "Анализ использования ассемблерных вставок в коде открытых пр..."	+1 +/–
	Сообщение от цирроз (ok) on 02-Апр-13, 17:52
	только в закрытых продуктах, я бы скзал. всякие JNZ нопами перебивать :-D
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	48. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 02-Апр-13, 18:57
	дык по заказу хакеров и включили. а то как варез то распространять потенциальным клиентам?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

67. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
Сообщение от Аноним (??) on 03-Апр-13, 04:17
> Большая часть ассемблерных вставок малозначительна Зато один конкретный видеокодек, который в одном случае впишется в реалтайм а в другом нет - может сильно испортить настроение. И пока дебианщики лечат, гугель например, которому важнее результат - люто пилит ASM вставки в своем кодеке. Засчитывается все-таки результат а не "ну вы же понимаете, так было проще".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	79. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от 123 (??) on 03-Апр-13, 08:29
	Тащем-то шейдеры в кодеке практичнее. Да и либ с уже сделанными и оптимизированными алгоритмами у интела и AMD  с терабайт.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	84. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от ананим on 03-Апр-13, 10:02
	>Тащем-то шейдеры в кодеке практичнее. какое отношение шейдеры имеют к видеокодекам? (кроме пост-процессинга, который дома для фильмов наюх нипёрся) > Да и либ с уже сделанными и оптимизированными алгоритмами у интела и AMD  с терабайт. в которых уже понапихано ассемблерных вставок. зыж http://www.opennet.dev/opennews/art.shtml?num=36563 >Google выпустил третью версию библиотеки с реализацией формата WebP >Проведена оптимизация работы кодировщика изображений. Ускорение особенно заметно в режиме кодирования c потерей качества (увеличение скорости в 3-6 раз). Добавлена порция ассемблерных оптимизаций для процессоров ARM, поддерживающих SIMD-инструкции NEON; порция ассемблерных … для процессоров ARM … SIMD-инструкции NEON;
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	93. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 03-Апр-13, 14:49
	> ато один конкретный видеокодек, который в одном случае впишется в реалтайм а в другом нет - может сильно испортить настроение. И пока дебианщики лечат, гугель например, которому важнее результат - люто пилит ASM вставки в своем кодеке. Хорошо, что пишет, если это действительно дает эффект. А исследование о том, что в куче проектов асм-вставки иногда пихают на авось, не понимая их смысла и даже не удосужившись сравнить производительность с вариантом без асма
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

83. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
Сообщение от anonymous (??) on 03-Апр-13, 09:30
людям нужны прикладные проги и игры, а они глибц и прочие в первую очередь ровняют...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

86. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
Сообщение от Аноним (??) on 03-Апр-13, 10:20
Полное ощущение, что за ночь набежала толпа архитектурных астронавтов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

99. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
Сообщение от X86 (ok) on 03-Апр-13, 18:33
Я вообще был всегда за то, чтобы весь Линукс с приложениями был на ассемблере)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	102. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Карбофос (ok) on 04-Апр-13, 00:31
	тогда получится КолибриОС
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	103. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Led (ok) on 04-Апр-13, 01:42
	> тогда получится КолибриОС А она разве получилась?
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	105. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Карбофос (ok) on 04-Апр-13, 21:52
	злые языки рассказывают, что и Minix не получился
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	112. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:08
	> тогда получится КолибриОС КарбофОС :)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

100. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
Сообщение от Аноним (??) on 03-Апр-13, 22:26
Ассемблерные вставки позволяют использовать аппаратные возможности процессора, например инструкция POPCNT. Это как вместо пересчёта колва спичек в спичечной коробке взвесить её :D
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	104. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Карбофос (ok) on 04-Апр-13, 21:51
	как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно в этом есть необходимость.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	113. "Анализ использования ассемблерных вставок в коде открытых пр..."	–1 +/–
	Сообщение от Аноним (??) on 05-Апр-13, 13:10
	> как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно > в этом есть необходимость. Ага, посмотри как GCC дуреет от армовских ld*/st* с группами регистров. Он и на пятую часть таких наворотов не рассчитан изначально был :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	117. "Анализ использования ассемблерных вставок в коде открытых пр..."	+/–
	Сообщение от Forth (ok) on 20-Май-15, 19:43
	> как раз такие тривиальные вещи компайлер может делать по усмотрению, если действительно > в этом есть необходимость. Это если компилятор в состоянии это делать, достаточно посмотреть на листинги ассемблерные, что там gcc нагенерил для arm, например, да и на x86 порой чушь есть на -O2.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема