The OpenNET Project / Index page

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



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

Оглавление

Опубликованы тесты простейших приложений на различных языках..., opennews (??), 08-Дек-19, (0) [смотреть все]

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


126. "Опубликованы тесты простейших приложений на различных языках..."  –2 +/
Сообщение от VEGemail (ok), 08-Дек-19, 15:48 
Не увидел чтобы автор видео агитировал за написание всего кода на асме. Просто на практике показал что все удобства даются не бесплатно. Обещал ещё показать в следующих частях какие-то преимущества. Скорее всего покажет что компилеры способны генерировать оптимальный код только в простейших случаях, а толково применять SSE/AVX вообще толком не могут, и ручная оптимизация тут рулит на всю катушку. Полагаю, что основной посыл будет использовать асм там где это имеет смысл. Его и используют. Для оптимизации кодеков, например. Надо же чтобы кто-то это рассказал подрастающему поколению, вот автор видео и старается.
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

129. "Опубликованы тесты простейших приложений на различных языках..."  +3 +/
Сообщение от Аноним (90), 08-Дек-19, 16:00 
> Компилеры способны генерировать оптимальный код только в простейших случаях

Лол что? Это человек способен генерировать оптимальный код на ассемблере только в простейших случаях. Для большого куска кода у человека от писанины на ассемблере крыша поедет, а о том, чтобы превзойти по оптимальности код компилятора даже речи идти не будет. Современные компиляторы далеко ушли по сравнению с 80-ми, а вы похоже там и остались. Сейчас оптимизация кода производится на многих уровнях, особенно хорошо разработаны оптимизации AST-дерева, которое человек в принципе в голове удержать целиком не способен.

Ответить | Правка | Наверх | Cообщить модератору

199. "Опубликованы тесты простейших приложений на различных языках..."  +1 +/
Сообщение от Анонисмус (?), 08-Дек-19, 20:31 
Вот куда ушли современные компиляторы и технологии:
How new-lines affect the Linux kernel performance.

https://nadav.amit.zone/linux/2018/10/10/newline.html


Думаю, заголовок статьи говорит сам за себя.


Ответить | Правка | Наверх | Cообщить модератору

210. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (95), 08-Дек-19, 20:58 
Недавно видел историю где слово register (то самое против которого все топят) применённое к переменной-счётчику, ускоряло код в 9999 раз. Компиляторы такие умные сегодня.
Ответить | Правка | Наверх | Cообщить модератору

221. "Опубликованы тесты простейших приложений на различных языках..."  +2 +/
Сообщение от Аноним84701 (ok), 08-Дек-19, 21:44 
> Вот куда ушли современные компиляторы и технологии:
> How new-lines affect the Linux kernel performance.
> https://nadav.amit.zone/linux/2018/10/10/newline.html
> Думаю, заголовок статьи говорит сам за себя.

Думаю, читать все же желательно не только заголовки:
> New lines in inline assembly

...
> The reason turns to be the newline characters (marked as ‘\n’ above [asm volatile("1: ud2\n"]). The kernel compiler, GCC, is unaware to the code size that will be generated by the inline assembly. It therefore tries to estimate its size based on newline characters and statement separators (‘;’ on x86). In GCC, we can see the code that performs this estimation in the estimate_num_insns() function:

...
> Solving the problem is not trivial. Ideally, GCC would have used an integrated assembler, similarly to LLVM, which would give better estimation of the generated code size of inline assembly.
> Experimentally, LLVM seems to make the right inlining decisions and is not affected by new-lines or data that is set in other sections of the executable ... GCC, however, uses the GNU assembler after the code is compiled,

Разъясняю для опеннетных аналитиков современного компиляторостроения:
Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";".
Решается проблема ручками (указание размера/оверрайд и т.д.) или же включением ассемблера непосредственно в компилятор.

Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

226. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Анонисмус (?), 08-Дек-19, 22:42 
Надеюсь, что ты не много времени потратил на "онализ" статьи:

https://www.opennet.ru/opennews/art.shtml?num=49412

Ответить | Правка | Наверх | Cообщить модератору

239. "Опубликованы тесты простейших приложений на различных языках..."  +1 +/
Сообщение от Аноним84701 (ok), 09-Дек-19, 00:08 
> Надеюсь, что ты не много времени потратил на "онализ" статьи:
> https://www.opennet.ru/opennews/art.shtml?num=49412

Ну и?
> GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). Компилятор не учитывает фактический размер результирующего кода, а пытается прогнозировать его. Для ассемблерных вставок прогнозирование делается на основе числа переводов строк ("\n") и разделителей (";") в исходном тексте.

Ты считаешь, что то перевод оригинала:
ссылка из новости == предыдущая ссылка анонима
https://nadav.amit.zone/blog/linux-inline => https://nadav.amit.zone/linux/2018/10/10/newline.html

(с некоторыми домыслами, т.к. "inline" по стандарту c99 - только хинт
> A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared
> only once. Making a function an inline function suggests that calls to the function be as fast as possible.
> The extent to which such suggestions are effective is implementation-defined.

и компилятор си не может учитывать фактический размер вставок "foreign" кода:
> Разъясняю для опеннетных аналитиков современного компиляторостроения:
> Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";".

более "убедителен" или опять "онализировал" только заголовки?

Ответить | Правка | Наверх | Cообщить модератору

217. "Опубликованы тесты простейших приложений на различных языках..."  +2 +/
Сообщение от VEGemail (ok), 08-Дек-19, 21:27 
Мечтать не вредно, конечно, но компилеры далеки от того, чтобы самостоятельно задействовать SSE/AVX так, как это мог бы сделать человек.

Возьмём в качестве примера libjpeg-turbo. Этот проект - оптимизация обычного libjpeg. Проект проспонсирован кучей видных компаний (https://libjpeg-turbo.org/About/Sponsors), результат используется во всех браузерах и Android. А если заглянете в исходный код, чтобы посмотреть как оптимизировали, то найдёте пачки *.asm файлов (https://github.com/libjpeg-turbo/libjpeg-turbo/tree/master/s...).

Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus. Но это, по сути, ассемблер с синтаксисом C.

Что касается качества генерируемого кода C компилеров для обычного кода (который не оптимизируешь с использованием SSE/AVX), то он был весьма посредственного качества не только в 80-х, но и в 90-х (я провёл много времени дизассемблируя игры того времени, знаю о чём говорю). Современные компилеры - да, достаточно умны, чтобы в общем случае генерировать достаточно оптимальный код.

Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

252. "Опубликованы тесты простейших приложений на различных языках..."  +4 +/
Сообщение от Урри (?), 09-Дек-19, 01:48 
Я делал часть работы по оптимизации libjpeg-turbo.

Могу объяснить в чем вы правы и в чем не правы. Если вы взглянете внимательнее на асм код, то заметите что 99% его - это векторные инструкции. Причем зачастую сам алгоритм приходилось переделывать, чтобы он хорошо векторизовался; простых циклов без внутренних зависимостей в коде очень мало.
А это работа уже не компилятора, но ИИ; который в компиляторы пока еще не завезли. Вот и приходилось оплачивать работу человеков.

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

Последний процессор, для которого человек еще хорошо справлялся, был pentium2, с его U и V каналами, которые могли работать одновременно (но не для умножения - умножение работало параллельно c с другой арифметикой только если уходило в U канал). Да и то, есличестно, занятие это было дико муторным и в основном не оправдывало вложенных усилий.

Сейчас оптимизация в основном выглядит так: запускаем профайлер, ищем очень редкие узкие места и задрачиваем их в полуслепом режиме. И так для каждой(!) архитектуры.

Ответить | Правка | Наверх | Cообщить модератору

253. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Урри (?), 09-Дек-19, 01:49 
Ох, промахнулся немного комментом.
Ответить | Правка | Наверх | Cообщить модератору

262. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (260), 09-Дек-19, 02:25 
"Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п."

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

Именно этот прискорбный факт и стал основной причиной безвременной кончины интеловского итаниума.

Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

271. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Урри (?), 09-Дек-19, 04:19 
Ну здрасьте, приехали. Как это нет - у компилятора есть множество того, что мы не сможем сделать; например, возможность построить граф зависимостей по коду и данным; по использованию регистров и самому "попереименовывая" их разбросать в наилучшем порядке.

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

Да много чего есть, чего вам, как человеку, уже недоступно ввиду слишком низкой скорости обработки данных и ограниченности по объему их же.

Ответить | Правка | Наверх | Cообщить модератору

303. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (260), 09-Дек-19, 11:32 
И поэтому сплошь и рядом компиляторы устраивают в коде какой-то бл..cкий цирк с жонглированием регистрами, выкинув при этом действительно важные переменный на стек.


И кстати куда же делось вот это все: "микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги" ? Дошло что написали глупость ?

Ответить | Правка | Наверх | Cообщить модератору

272. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Урри (?), 09-Дек-19, 04:22 
Да, кстати. Итаниум умер не поэтому.
Умер он потому, что его время новых инструкций без сохранения обратной совместимости еще не пришло.

Через десять лет время пришло, но повезло в этот раз арму. Итаниум - это же современный арм, разве что с увеличенной адресной шиной.

Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

301. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (260), 09-Дек-19, 11:20 
Именно поэтому, как и многие другие VLIW процессоры.

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

Ответить | Правка | Наверх | Cообщить модератору

302. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Anonymoustus (ok), 09-Дек-19, 11:27 
> Да, кстати. Итаниум умер не поэтому.
> Умер он потому, что его время новых инструкций без сохранения обратной совместимости
> еще не пришло.
> Через десять лет время пришло, но повезло в этот раз арму. Итаниум
> - это же современный арм, разве что с увеличенной адресной шиной.

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

А ещё жаль, что ХаПэ отправила в музей Альфу.

Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

306. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (260), 09-Дек-19, 11:36 
Бабушка-с-членом-и-усами.jpg
Ответить | Правка | Наверх | Cообщить модератору

304. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (260), 09-Дек-19, 11:34 
> Итаниум - это же современный арм, разве что с увеличенной адресной шиной.

Блин, слона-то я и не приметил. Больше вопросов не имею.

Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

401. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Anonymoustus (ok), 11-Дек-19, 08:51 
>> Итаниум - это же современный арм, разве что с увеличенной адресной шиной.
> Блин, слона-то я и не приметил. Больше вопросов не имею.

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

Ответить | Правка | Наверх | Cообщить модератору

285. "Опубликованы тесты простейших приложений на различных языках..."  –1 +/
Сообщение от VEGemail (ok), 09-Дек-19, 09:49 
Так я как бы о том же о чём и вы говорил в предыдущем комментарии. Хочешь по максимуму задействовать возможности SSE/AVX - переписывай код ручками. На асме или интринсиками в C - уже дело вкуса. А полагаться на то что компилер сам догадается - не приходится. Хотя иногда он таки догадывается как какие-то простые циклы можно векторизовать, но это не точно =)
Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

327. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (327), 09-Дек-19, 14:16 
>Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus.

Это все следствие того, что поддержку векторных типов и операций над ними в стандарт С не завезли.

>Но это, по сути, ассемблер с синтаксисом C.

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

Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

421. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (-), 14-Дек-19, 04:11 
> Нет, по сути это не ассемблер. Не нужно вручную распределять регистры,  
> есть проверка типов.

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

Ответить | Правка | Наверх | Cообщить модератору

131. "Опубликованы тесты простейших приложений на различных языках..."  +3 +/
Сообщение от Forthemail (ok), 08-Дек-19, 16:06 
Тут бы лучше взять пример какой-нибудь прикладной задачи, причем не обязательно с плавающей точкой и векторными операциями.
Полно алгоритмов, где важны DMIPS-ы. Тот же поиск короткого пути в графе или например всякие алгоритмы на строках, типа наибольшей общей подпоследовательности.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

254. "Опубликованы тесты простейших приложений на различных языках..."  +1 +/
Сообщение от Урри (?), 09-Дек-19, 01:51 
Поиск на карте (с частым построением графов), кстати, одна из тех задач, где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы в виде реализации сборки мусора не в счет, естественно.
Ответить | Правка | Наверх | Cообщить модератору

419. "Опубликованы тесты простейших приложений на различных языках..."  –1 +/
Сообщение от Аноним (-), 14-Дек-19, 04:08 
> Поиск на карте (с частым построением графов), кстати, одна из тех задач,
> где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы
> в виде реализации сборки мусора не в счет, естественно.

Фича сей и тому подобных в том что если тебе надо GC - его можно сделать. Поэтому кому было надо - у них и си стал довольно высокоуровневым. А вот если в каком-нибудь Go этот самый GC мешается - уже упс.

Ответить | Правка | Наверх | Cообщить модератору

153. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (31), 08-Дек-19, 17:28 
>а толково применять SSE/AVX вообще толком не могут

OpenCL-компиляторы -- могут.

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

420. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Аноним (-), 14-Дек-19, 04:09 
> OpenCL-компиляторы -- могут.

У них даже и не SSE/AVX. У типичного GPU алушек и регистров больше чем у дурака фантиков.

Ответить | Правка | Наверх | Cообщить модератору

234. "Опубликованы тесты простейших приложений на различных языках..."  +/
Сообщение от Michael Shigorinemail (ok), 08-Дек-19, 23:18 
> Скорее всего покажет что компилеры способны генерировать оптимальный
> код только в простейших случаях, а толково применять SSE/AVX вообще
> толком не могут, и ручная оптимизация тут рулит на всю катушку.

Вы представляете себе хотя бы количество регистров в нынешних камнях (плюс-минус лапоть)?  А таблицы длительности команд под рукой держите?..

Рассказать-то рассказать, да не сказочку, а быль.

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

255. "Опубликованы тесты простейших приложений на различных языках..."  +1 +/
Сообщение от Урри (?), 09-Дек-19, 01:52 
Таблицы, коих на самом деле уже давно нет. Так как конвеер длинный и микрооперации сильно зависят друг от друга и окружающей среды (например, предсказания переходов или кеширования памяти).
Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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