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

Анализ использования ассемблерных вставок в коде открытых пр..., opennews (??), 02-Апр-13, (0) [смотреть все] интересный обзор, x0r (??), 13:28 , 02-Апр-13, (1) +4 Ни фига себе Я бы предположил, что от 12 до 120 0,06--0,6 , Аноним (-), 13:28 , 02-Апр-13, (2) –4 // так это же только количество пакетов, где порой делают вставки а не сравнение о, цирроз (ok), 16:20 , 02-Апр-13, (25) +3 Одни только кодеки и сколь-нибудь серьезные библиотеки и плееры - по жизни содер, Аноним (-), 04:41 , 03-Апр-13, (69) –1 Разве для оборудования нет Си-шных функций записи в порты , TbIK (ok), 13:32 , 02-Апр-13, (3) –2 // чего , Аноним (-), 14:33 , 02-Апр-13, (8) // си, анон (?), 14:41 , 02-Апр-13, (10) +1 Вряд ли такое возможно Это же необходимо свою индивидуальную версию Си не то, ч, dalco (ok), 14:41 , 02-Апр-13, (9) –1 // Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под терми, Аноним (-), 14:52 , 02-Апр-13, (16) +3 // include asm-generic io hstatic inline void __raw_writeb u8 b, volatile void __io, pavlinux (ok), 16:27 , 02-Апр-13, (28) +4 Посыл топика -- ответить на вопрос, как на Си писать в порты Ваш К О Зачастую о, skb7 (ok), 23:25 , 02-Апр-13, (58) +2 unsigned int 0x4ae04030 0xdeadbeef И чем это лучше ассемблера ЗыжВопро, ананим (?), 01:04 , 03-Апр-13, (65) –1 Ззыж unsigned int 0x4ae04030 0xdeadbeef Вообще йюх поймёшь что эти цифи, ананим (?), 01:06 , 03-Апр-13, (66) –1 Поэтому нормальные люди таки дают читаемые обозначения константам Или накрайняк, Аноним (-), 04:46 , 03-Апр-13, (71) –1 Большинство пакетов с ассемблерными вставками будут работать на других архитекту, ананим (?), 06:02 , 03-Апр-13, (76) Т е , другими словами, нормальные люди читают выводы А не придумывают свой хрен, ананим (?), 06:06 , 03-Апр-13, (77) –1 ЗыжДа похер чем он там знаменит, ГЛАВНОЕ 8212 он аппаратн-зависим И его хер н, ананим (?), 06:11 , 03-Апр-13, (78) –1 Было показано, что на Си можно выполнить запись в порт Приведенный код -- прост, skb7 (ok), 11:56 , 03-Апр-13, (90) +2 В таком случае - сам задал вопрос, сам и ответил Загляните в начало ветки Разв, Аноним (-), 11:12 , 03-Апр-13, (88) Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если , Аноним (-), 04:43 , 03-Апр-13, (70) ifndef PCI_IOBASE define PCI_IOBASE void __iomem 0 endif define __iomem , pavlinux (ok), 15:39 , 03-Апр-13, (94) Ок, продолжаем разгадки ребусов а что в этих определениях , Аноним (-), 13:01 , 05-Апр-13, (107) А причем тут запись в порты Если посмотришь исходники ядра, то там для этого сп, BSA (?), 15:19 , 02-Апр-13, (19) +2 // Собственно практически вся современная периферия - memory mapped в основное прос, Аноним (-), 04:47 , 03-Апр-13, (72) Именно в порты - только через функции-хелперы в которых ASM вероятно все-таки б, Аноним (-), 04:39 , 03-Апр-13, (68) Вот это просто архиважная вещь при чем первые две категории 38 и 30 - ну , Аноним (-), 13:55 , 02-Апр-13, (4) // это не бред, а печальная действительность, анон (?), 14:42 , 02-Апр-13, (11) +4 Копипаст - любимейший антипаттерн, бережно взращиваемый не одним поколением прог, Аноним (-), 14:47 , 02-Апр-13, (12) +5 // А может все это взрощенное поколение в отдельную резервацию, виртуальную чтоб б, Аноним (-), 14:51 , 02-Апр-13, (15) –2 Вполне возможно, что это и есть отдельная либа, только в виде исходников Сами р, тоже Аноним (ok), 17:13 , 02-Апр-13, (38) +2 // 100500Тонко, как английский юмор, подмечено, то что сильно похоже на копипасту, Аноним (-), 21:03 , 02-Апр-13, (53) // Ну, я, используя чужой код, кладу его в исходниках отдельно и под тем именем, по, тоже Аноним (ok), 08:33 , 03-Апр-13, (80) Одна сплошная депрессия в середине текста анализ где и для чего они используют, Аноним (-), 13:56 , 02-Апр-13, (5) –1 // И при чём тут ассемблерные вставки в исходниках портов , Аноним (-), 14:05 , 02-Апр-13, (6) // Каких портов, где прочитал , pavlinux (ok), 16:38 , 02-Апр-13, (30) // Описался по инерции Пакетов, проектов Тем не менее, вопрос - автор собрался оп, Аноним (-), 16:43 , 02-Апр-13, (31) Экак вы загнули Использование source-based дистрибутива и правильных флагов gcc , userd (ok), 14:16 , 02-Апр-13, (7) +1   // Дак как бы оптимизация компилятором по сути и делает ненужными эти дурацкие вста, Аноним (-), 14:48 , 02-Апр-13, (13) –2   // Оптимизации работают в большинстве случаев, но не всегда Если у тебя какая-то х, BSA (?), 15:23 , 02-Апр-13, (21) –1   При условии, что тот, кто это пишет, знает ассемблер не хуже тех, кто пишет комп, тоже Аноним (ok), 17:17 , 02-Апр-13, (40)   Человека, не знающего ассемблер и оправдывающего своё незнание 171 ненужностью, ананим (?), 18:49 , 02-Апр-13, (46) +2   Извините, но писать Линусу глупости вам придется самостоятельно А я слишком хоро, тоже Аноним (ok), 19:10 , 02-Апр-13, (49)   А он итак никому толком и не понадобился Только там, где необходим по моим набл, ананим (?), 23:31 , 02-Апр-13, (59)   ЗыжПиндеть, не мешки ворочать Пусть сделают коммит на си например в гстример, а , ананим (?), 23:35 , 02-Апр-13, (60)   эх, молодёжь 8230 , arisu (ok), 20:39 , 05-Апр-13, (114) +1   Ну так кто ж вам виноват что вы слили знания в унитаз Со всеми бывает, не у все, Аноним (-), 13:02 , 05-Апр-13, (108)   не обязательно, можно просто проанализировать профайлерором критичные участки ко, Карбофос (ok), 23:07 , 02-Апр-13, (57) +1   В целом можно согласиться Однако есть масса тонкостей, которые низводят пользу , Аноним (-), 17:35 , 02-Апр-13, (42) +1   Бред Нет Проверено моим студентом - прочитав по диагонали книгу по асемблеру и, Аноним (-), 19:22 , 02-Апр-13, (51) +2   Вы ведь, я надеюсь, про векторизованную обработку данных через SSE Таки да, я д, Ordu (ok), 09:04 , 03-Апр-13, (81) +2   Можно на этом и закончить Дискутировать с троллем - себя не уважать Удачи , Аноним (-), 10:12 , 03-Апр-13, (85) +1   Да-да Сидит такой программер и думает, дайка я прогу ассемблером заторможу, а т, ананим (?), 20:41 , 02-Апр-13, (52)   тише тише сейчас изя припрётся и обвинит во всех тормозах ассемблерные вставки, Карбофос (ok), 22:48 , 02-Апр-13, (56) +2   Там вон в новости и в жабе их кучу нашли то-то начиная с 6 она порезвела , ананим (?), 23:37 , 02-Апр-13, (61)   классика жанра ОЙ как неудобно получилось , Карбофос (ok), 23:41 , 02-Апр-13, (62)   Да-да Там на 2-м месте после ведра сам о ужОс компилятор гцц Щаз онанчик, ананим (?), 00:13 , 03-Апр-13, (64)   А также всякий там стартап код и прочая, все что вокруг живет , Аноним (-), 13:03 , 05-Апр-13, (109)   38 1 пакетов используют ассемблерный код для выполнения различных низкоуровнев, Аноним (-), 10:51 , 03-Апр-13, (87) –1   так продолжили бы, а не вырывали из контекста при этомПодавляющее большинство 8, ананим (?), 11:16 , 03-Апр-13, (89)   Ещё раз Я возражаю против вашего посыла, согласно которому ассемблерные вставки , Аноним (-), 12:16 , 03-Апр-13, (91)   Ок Сформулируйте, что такое низкоуровневые операции , ананим (?), 12:43 , 03-Апр-13, (92)   Ой ладно отбрехиваться Вот у меня других дел нет - разводить бестолковую диск, Аноним (-), 16:06 , 03-Апр-13, (97) –1   Учитывая насколько геморно их писать и что они непортабельны - по другим поводам, Аноним (-), 13:04 , 05-Апр-13, (110) –1   нет, это далеко не так , цирроз (ok), 16:26 , 02-Апр-13, (27)   Толку-то Кажется что сейчас соберёшь систему и будет летать на 486-м, а оно по , Аноним (-), 15:35 , 02-Апр-13, (22) –2   // Меню приложений XFCE перед первым открытием читает с диска кэш иконок, которые в, тоже Аноним (ok), 17:26 , 02-Апр-13, (41)   Нет, только не при загрузке системы, ибо при загрузке и так делов достаточно А э, Аноним (-), 21:17 , 02-Апр-13, (54)   Именно поэтому бинарные конфиги зло если они все не собраны в один сжатый архив, ананим (?), 23:45 , 02-Апр-13, (63) –1   И вставки на асме сама под ARM64 перепишет , Аноним (-), 04:49 , 03-Апр-13, (73) +1   Так целью исследования и было выяснить нужно ли делать такие же ифдэфы для этой , ананим (?), 16:09 , 02-Апр-13, (24)   Сейчас понабегут аналитеги и скажут, что ассемблерные вставки не нужны Что ж, , Аноним (-), 16:23 , 02-Апр-13, (26) –3 // Ну что ж, а вы не доросли до терпимости к другому мнению У каждого свой потолок, Аноним (-), 16:28 , 02-Апр-13, (29) +3 Самая лучшая инстукция - это NOP , pavlinux (ok), 16:50 , 02-Апр-13, (34) // Вот я её сейчас и выполняю В цикле do while tm hour 19 , Аноним (-), 16:52 , 02-Апр-13, (35) –1 // ты не одинок бро , Аноним (-), 16:54 , 02-Апр-13, (36) А вот и нифига, тут есть счётчик, а это уже перегруз NOP - это философия, NOP - , pavlinux (ok), 17:05 , 02-Апр-13, (37) +2 // С грибами , Аноним (-), 17:14 , 02-Апр-13, (39) +2 NOP выполняется за четко оговоренное количество тактов, так что созерцать его не, Аноним (-), 17:38 , 02-Апр-13, (43) Вообще то NOP суть есть MOV EAX,EAX, masakra (ok), 18:28 , 02-Апр-13, (45) –1 учитывая то, что классический однобайтный x86 NOP - это XCHG AX,AX , то это, мо, Led (ok), 22:37 , 02-Апр-13, (55) +1 Как это, AX,AX AX в квадрате , pavlinux (ok), 15:47 , 03-Апр-13, (95) Попробую объяснить смысл операции XCHG AX,AX в понятных тебе терминах шило -, Led (ok), 15:56 , 03-Апр-13, (96) Password missmatch Access denied Чё, не меняет Ну и хуй с ней , pavlinux (ok), 16:06 , 03-Апр-13, (98) –1 завязывай с ложными опятами , Карбофос (ok), 00:29 , 04-Апр-13, (101) +1 А mov ax,bx можно написать двумя способами , Forth (ok), 19:39 , 20-Май-15, (116) Или попросту - протирание штанов , Аноним (-), 04:51 , 03-Апр-13, (75) // с волками жить - по волчьи выть бро , Аноним (-), 09:13 , 03-Апр-13, (82) Ну, вам же хуже У вас был выбор , Аноним (-), 13:07 , 05-Апр-13, (111) только в закрытых продуктах, я бы скзал всякие JNZ нопами перебивать -D, цирроз (ok), 17:52 , 02-Апр-13, (44) +1 // дык по заказу хакеров и включили а то как варез то распространять потенциальным , ананим (?), 18:57 , 02-Апр-13, (48) Зато один конкретный видеокодек, который в одном случае впишется в реалтайм а в , Аноним (-), 04:17 , 03-Апр-13, (67) –1 // Тащем-то шейдеры в кодеке практичнее Да и либ с уже сделанными и оптимизированн, 123 (??), 08:29 , 03-Апр-13, (79) –1 // какое отношение шейдеры имеют к видеокодекам кроме пост-процессинга, который д, ананим (?), 10:02 , 03-Апр-13, (84) Хорошо, что пишет, если это действительно дает эффект А исследование о том, что, Аноним (-), 14:49 , 03-Апр-13, (93) людям нужны прикладные проги и игры, а они глибц и прочие в первую очередь ровня, anonymous (??), 09:30 , 03-Апр-13, (83) –1 Полное ощущение, что за ночь набежала толпа архитектурных астронавтов , Аноним (-), 10:20 , 03-Апр-13, (86) Я вообще был всегда за то, чтобы весь Линукс с приложениями был на ассемблере , X86 (ok), 18:33 , 03-Апр-13, (99) –1 // тогда получится КолибриОС, Карбофос (ok), 00:31 , 04-Апр-13, (102) // А она разве получилась , Led (ok), 01:42 , 04-Апр-13, (103) // злые языки рассказывают, что и Minix не получился, Карбофос (ok), 21:52 , 04-Апр-13, (105) КарбофОС , Аноним (-), 13:08 , 05-Апр-13, (112) Ассемблерные вставки позволяют использовать аппаратные возможности процессора, н, Аноним (-), 22:26 , 03-Апр-13, (100) –1 // как раз такие тривиальные вещи компайлер может делать по усмотрению, если действ, Карбофос (ok), 21:51 , 04-Апр-13, (104) // Ага, посмотри как GCC дуреет от армовских ld st с группами регистров Он и на , Аноним (-), 13:10 , 05-Апр-13, (113) –1 Это если компилятор в состоянии это делать, достаточно посмотреть на листинги ас, Forth (ok), 19:43 , 20-Май-15, (117) 1,2,3,4,5,26,34,67,83,86,99,100

Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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