The OpenNET Project / Index page

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



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

Оглавление

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

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


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ообщить модератору

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

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




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

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