_taras_ | |
29 янв 2022 14:09:15 |
mrt789 | |
05 фев 2022 00:18:39 |
Цитата: _taras_ от 29.01.2022 14:09:15А в Этой статье рассмотрено нюансы создания кода для Эльбрус-ов. Читается как хороший детектив.
for (int i = start_i; i domain_n + 2) + j;
double wij = src[idx];
double wipj = src[(i + 1) * (run_config-domain_n + 2) + j];
double wimj = src[(i - 1) * (run_config-domain_n + 2) + j];
double wijp = src[i * (run_config-domain_n + 2) + j + 1];
double wijm = src[i * (run_config-domain_n + 2) + j - 1];
double x = (run_config-start_i + i - 1) * run_config-h1;
double y = (run_config-start_j + j - 1) * run_config-h2;
double laplacian = (wipj + wimj - 2 * wij) * run_config-sqinv_h1 + (wijp + wijm - 2 * wij) * run_config-sqinv_h2;
dst[idx] = q(x, y) * wij - laplacian - alpha * F(x, y);
}
}
adolfus | |
08 фев 2022 11:30:37 |
Цитата: mrt789 от 05.02.2022 00:18:39Любой же реальный софт основан на вызове подпрограмм и ветвлении, то есть на переходе к тому или иному адресу. Это базовый принцип построения софта - разбиение его на повторно используемые блоки инструкций и переход на них (от функций пользовательских библиотек и до системных вызов ядра ОС - это все адреса для перехода). И да, заинлайнить системный вызов на этапе компиляции не получится, да и с библиотеками линковка обычно идет не статичная.
mrt789 | |
08 фев 2022 19:18:12 |
Цитата: adolfus от 08.02.2022 11:30:37По первому выделению:
1. В отношении ветвления....
2. С библиотеками в программах-числодробилках....
adolfus | |
08 фев 2022 22:28:43 |
Цитата: mrt789 от 08.02.2022 19:18:121. У кремния есть уникальная абсолютно недостижимая для компилятора особенность - он всегда видит текущее состояние в рантайме.
adolfus | |
08 фев 2022 22:49:28 |
Цитата: mrt789 от 08.02.2022 19:18:12Но как был сказано "программирование начинается там, где заканчивается память" - любой ввод/ввыод (сетевой, файловой, пользовательский), это системный вызовы ядра, ты мимо них не прыгнешь. И ядро статически не слинкуешь со своим софтом.
Поверонов | |
08 фев 2022 23:52:21 |
Цитата: adolfus от 08.02.2022 22:49:28Ввод/вывод – это отдельная пестня и вряд ли прикладной программист на что-то тут может влиять, даже если он работает на уровне системных вызовов. С другой стороны у нас есть неблокирующие вызовы на сей счет и даже мультипоточность.
Работа с данными, она выдвигает особые требования. Это та поляна где идет борьба между SQL и ISAM. Тот же оракле, когда подгреб BerkeleyDB, писал в руководствах, что если схема статична, то использование SQL оправдано только для макетирования – софт с использование bdb будет производительнее в разы и вести себя более предсказуемо, поскольку управление такими ограниченными ресурсами, как память и пропускная способность сетей и каналов ввода/вывода ложатся полность на программиста, который всегда знает больше и детальнее, нежели SQL-компилятор. К сожалению, их клиентура словно в последний раз живет – кроме как быстро выпустить и срубить бабки, в том числе и на распиле, не заинтересована.
adolfus | |
12 фев 2022 01:02:45 |
Цитата: Поверонов от 08.02.2022 23:52:21Извините эффективность порядка вложения циклов при SQL запросе определяется не столько схемой сколько статистикой распределения данных по находящимся в распоряжении индексам ( execution plan ) А статистика вещь сугубо динамическая изменяющаяся во времени - то что было оптимально месяц назад сегодня может стать уже по-другому в зависимости от накопленных за это время данных в базе. Программист не должен каждый месяц переделывать порядок циклов в запросе ( вообще говоря - во всех запросах ) если конечно ему больше нечем заняться
mrt789 | |
09 фев 2022 01:08:21 |
Цитата: adolfus от 08.02.2022 22:49:28Ввод/вывод – это отдельная пестня и вряд ли прикладной программист на что-то тут может влиять, даже если он работает на уровне системных вызовов.
adolfus | |
12 фев 2022 01:28:41 |
Цитата: mrt789 от 09.02.2022 01:08:21Простыми словами: если во внутренний фор из статьи добавить банальный вывод в консоль, то широкой команде и аппаратным циклам придет пушной зверек, потому что это 100% системный вызов, который еще неизвестно чего будет делать и куда выводить. Сначала да, там будет printf, который можно заинлайнить, но дальше уже будет write.
mrt789 | |
12 фев 2022 16:53:20 |
Цитата: adolfus от 12.02.2022 01:28:41Никто во внутрений ("вычислительный") for никогда не вставляет ни одной функции, которая может быть прервана сигналом, отличным от сигнала, безусловно завершающего процесс (TERM или KILL, например). Мало того, если нужно во "внутреннем" for (я так понимаю, что это, типа "реалтайм" for?) что-то попросить у системы, то это всегда асинхронное и внутри for результаты этого вызова не нужны. А если вдруг оказывется. что таки нужны, имеет смысл пересмотреть постановку задачи.
На самом деле во "внутренние" for в приложениях, которые взаимодействуют с пользователями, никто никогда даже не вставляет функций, которые не могут быть реально inline, т.е. определены в отдельно компилируемых единицах трансляции. Все, что выполняется внутри Вашего for, должно пристутствовать в Вашем исходном модуле, либо оно должно быть функцией из стандартной библиотеки с (не c++, а именно c), а библиотека должна линковаться статически.
Цитата"внутреннем" for (я так понимаю, что это, типа "реалтайм" for?)
Поверонов | |
12 фев 2022 18:05:13 |
Цитата: mrt789 от 12.02.2022 16:53:20Не спорю, просто на всем, что не укладывается в это, эльбрус с вливом будет демонстрировать производительность в десятки процентов от заявленной.
Что он и делает. Без возможности частично выправить ситуацию за счет "суперскалярности" с предсказанием и спекулятивным исполнением.Цитата"внутреннем" for (я так понимаю, что это, типа "реалтайм" for?)
это из исходной статьи, там был код с двумя вложенными циклами
mrt789 | |
12 фев 2022 18:51:25 |
Цитата: Поверонов от 12.02.2022 18:05:13Вообще-то непонятно почему поток инструкций процессору должен оптимизировать сам процессор, а не компилятор, который имеет достаточную информацию о ветвлении логики команд. Или это эффект мультизадачности где последовательность команд процессору определяется не программной логикой, а случайно переключаемым контекстом процессов ? Но хотя бы внутри отдельного процесса можно постараться оптимизировать поток инструкций на стадии компиляции
Цитатаэффект мультизадачности
DimonT | |
12 фев 2022 21:36:08 |
Цитата: mrt789 от 12.02.2022 18:51:25Это может быть неправильно, не оптимально и ваще фу-фу-фу, вот только квака 1 почему-то гораздо лучше бегала на первом пентиуме, с меньшей частотой по сравнению с 486DX100. А кваку вряд ли можно назвать неоптимально написанным ПО - Кармак и Ко всегда выжимали максимум и по коду и по структурам данных.
adolfus | |
20 фев 2022 02:06:51 |
Цитата: mrt789 от 12.02.2022 18:51:25Велком ту зе реал ворлд, Нео.
Потому что на самом деле компилятор не имеет этой информации. По нескольким причинам:
1. Компилятор видит только, что собирает. Это следствие деления на прикладное ПО и системное, в экзешнике который вы скомпилируете, не будет кусков ядра ОС, на работу с которым он рассчитан. И при этом у вас получится исполняемый файл, который будет запускаться и работать с сетью на десятке разных машин с разным железом.
Цитата2. Ну и наконец, ветвление может зависеть от какого-то условия, которое будет или не будет только рантайме - ввод/вывод, сеть, etc. Это нельзя предсказать на этапе компиляции.
udaf | |
23 фев 2022 17:40:31 |
Цитата: mrt789 от 12.02.2022 18:51:25Потому что на самом деле компилятор не имеет этой информации. По нескольким причинам:
1. Компилятор видит только, что собирает. Это следствие деления на прикладное ПО и системное, в экзешнике который вы скомпилируете, не будет кусков ядра ОС, на работу с которым он рассчитан. И при этом у вас получится исполняемый файл, который будет запускаться и работать с сетью на десятке разных машин с разным железом.
2. Ну и наконец, ветвление может зависеть от какого-то условия, которое будет или не будет только рантайме - ввод/вывод, сеть, etc. Это нельзя предсказать на этапе компиляции.
....
Вот поэтому и не взлетело, в случае с тем же итаником. Реальное ПО на уровне потока инструкций к ЦПУ представляет собой полную кашу и мешанину из всего вышеперечисленного, и именно ЦПУ (и только он) имеет возможность как-то это все оптимизировать в целом, пусть и на масштабе в десяток команд.
Поверонов | |
23 фев 2022 19:52:22 |
Цитата: udaf от 23.02.2022 17:40:31Привед, всем! А если собирать статистику run-time и использовать при повторном выполнении кода. Эдакое автоматическое профилирование онлайн в помощь планировщику, а может и компилятору…
udaf | |
23 фев 2022 20:17:52 |
Цитата: Поверонов от 23.02.2022 19:52:22L1,L2 кэши в процессоре что-то такое и делают
gvf | |
23 фев 2022 20:26:45 |
Цитата: udaf от 23.02.2022 20:17:52это про
udaf | |
24 фев 2022 07:36:38 |
Цитата: gvf от 23.02.2022 20:26:45Все давным давно придумано до вас.
Дело кончилось уязвимостями типа spectre.
Senya | |
23 фев 2022 20:30:14 |
Цитата: udaf от 23.02.2022 20:17:52это про текущее выполнение (ну и про данные, а не инструкции процессора), а я про статистику которая собирается в процессе работы программы и сохраняется по окончании, при следующем запуске процессор может получать информацию о вероятности переходов в условиях, кол-во циклов и т.д.
Процессор запускает программу каждый раз, как в первый раз...), а тут статистика как оно было ранее
udaf | |
24 фев 2022 07:58:38 |
Цитата: Senya от 23.02.2022 20:30:14Процессор, который самостоятельно собирает информацию о всех запускаемых программах и имеет низкоуровневый доступ к долговременным накопителям будет посильнееФауста Гётепроцессора, выключаемого сигналом со спутника.
А если серьёзно - не представляю подобную вещь без поддержки со стороны операционной системы и компилятора. И без вопиющего нарушения многочисленных требований по изоляции памяти и безопасности выполнения. Т.е. для специальных изолированных систем.
mse | |
24 фев 2022 10:53:25 |
Цитата: udaf от 24.02.2022 07:58:384.Ваши страхи мне понятны, система модифицируется без участия человека, может и не туда зайти..
qurvax | |
24 фев 2022 13:58:15 |
Цитата: mse от 24.02.2022 10:53:25Ну это кагбы известный закон имени известного человека: "если что-то может пойти не так, то именно так оно и пойдёт"
adolfus | |
27 фев 2022 00:37:42 |
Цитата: Поверонов от 23.02.2022 19:52:22L1,L2 кэши в процессоре что-то такое и делают
kerosene | |
13 фев 2022 19:10:51 |
Цитата: mrt789 от 12.02.2022 16:53:20Не спорю, просто на всем, что не укладывается в это, эльбрус с вливом будет демонстрировать производительность в десятки процентов от заявленной.
Что он и делает. Без возможности частично выправить ситуацию за счет "суперскалярности" с предсказанием и спекулятивным исполнением.
kerosene | |
13 фев 2022 19:07:35 |
Цитата: adolfus от 12.02.2022 01:28:41Никто во внутрений ("вычислительный") for никогда не вставляет ни одной функции, которая может быть прервана сигналом, отличным от сигнала, безусловно завершающего процесс (TERM или KILL, например). Мало того, если нужно во "внутреннем" for (я так понимаю, что это, типа "реалтайм" for?) что-то попросить у системы, то это всегда асинхронное и внутри for результаты этого вызова не нужны. А если вдруг оказывется. что таки нужны, имеет смысл пересмотреть постановку задачи.
На самом деле во "внутренние" for в приложениях, которые взаимодействуют с пользователями, никто никогда даже не вставляет функций, которые не могут быть реально inline, т.е. определены в отдельно компилируемых единицах трансляции. Все, что выполняется внутри Вашего for, должно пристутствовать в Вашем исходном модуле, либо оно должно быть функцией из стандартной библиотеки с (не c++, а именно c), а библиотека должна линковаться статически.
adolfus | |
20 фев 2022 02:51:53 |
Цитата: kerosene от 13.02.2022 19:07:35Практически весь системный софт содержит кучу системных вызовов внутри for или while. Пример - утилита печати содержимого каталогов ls и т.д.
В Линуксе любые демоны это всегда цикл с кучей системных вызовов внутри.
AndreyK-AV | |
08 фев 2022 22:51:14 |
Цитата: adolfus от 08.02.2022 11:30:37По первому выделению:
В отношении ветвления программы бывают очень разные. Где-то много циклов, как в вычислительных алгоритмах, и данные тут, в основном, с плавающей запятой, где-то циклов мало, зато куча условных переходов. И .....
adolfus | |
12 фев 2022 00:32:19 |
Цитата: AndreyK-AV от 08.02.2022 22:51:14
Дональд Кнут "Искусство программирования", на сегодня уже 4 тома....
Гениальная книга, вроде об программировании как искусстве, но в итоге ведёт программирование в категорию высокотехнологичных инженерных дисциплин....