История изменений

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

Да. Но тут понимаете ли в чем дело - я со своей позиции, т.е. с позиции человека, который под контроллеры пишет код, вижу, что язык Си не является на данный момент лучшим вариантом (если именно смотреть с позиции, на чем бы мне было удобнее и приятнее писать). Мне просто говорят «Вот у нас работа, пиши на этом и получай за это деньги.». Если я скажу «Нет, это неоптимально, хочу на этом»... в общем, никто со мной особо торговаться не будет.

И их можно понять. Допустим, согласятся они чтоб я писал на D или Rust каком-нибудь, а кто еще будет на этом писать? А если я свалю из проекта, кто это будет дальше поддерживать? Где им искать кадров? Тут речь идет не о некоторой качественности или оптимальности самого языка как такового. Да, это тоже такой локально-оптимальный путь, пусть всё остается как есть, будем пользоваться теми языками, под которых проще найти кодеров, но это не критерий оптимальности самого языка в вакууме, это критерий его оптимальности при некоторых других факторах, таких как наличие кадров, стоимость этих кадров, наличие готовых библиотек, компиляторов и так далее. Это создает сильный потенциальный барьер. И если действительно есть какой-то очень хороший язык, который на голову выше всех прочих языков для конкретной области, далеко еще не факт, что он сможет в существующей экосистеме прорваться и стать популярным. Он может просто быть не настолько лучше, чтобы все кинулись на него переучиваться и переписывать весь свой код на него.

Пардонте, откуда Вы знаете что удалось а что нет? Вы телепат?

Да я вроде сказал откуда я знаю. Я смотрел и сам отправлял багрепорты в багзиллу GCC с ключевым словом «missed-optimisation».

Если вас интересуют конкретно мои багрепорты - ну например вот один из них https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

Теоретический предел это максимально возможное число FMA операций с учетом многопоточности и векторизации (известно из доков на железо) деленный на число FMA операций в ячейке сетки за один шаг (считается на бумашке для конкретной численной схемы).

А разве все решаемые в HPC задачи всегда упирается в FMA операции? А как быть с ветвлениями? А что насчет оптимизаций методом частичных вычислений (суперкомпиляция)? Может есть способ, путем хитрых оптимизаций, радикально снизить число FMA операций, которые требутся для конкретных вычислений? И что можете сказать про полиэдральную модель для оптимизации циклов, обходящих многомерные массивы? https://iconfs.net/infocom2016/sravnenye-effektyvnosty-avtomatycheskoj-optymy... вот можете почитать, я даже могу процитировать:

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

Там по-вашему достигнут предел?

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

Вот кстати совсем недавно обсуждал с одним человеком эту тему: был кусок кода на Си который написан на интринсиках, этот человек взял асмовыхлоп компилятора для этого кода, руками там попереставлял инструкции местами - получил выигрыш в производительности. Через интринсики получилось не самое оптимальное. Ну и можно еще вспомнить Intel MKL, в которой именно не интринсики, а руками написанные куски на ассемблере. Нужны доказательства - вот https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/273636 - «MKL is hand-tuned assembly language for Intel CPUs, and also supports HyperThreading and multiprocessor systems.». Вряд ли в Intel стали бы просто так писать на асме, если бы это не давало какой-то выгоды.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

А на саму реализацию этого LRnLA где можно посмотреть? Вообще, это мне напомнило то, что сделали в FFTW3 - http://www.fftw.org/fftw-paper-ieee.pdf - у них свой метаязык (DSL) на Ocaml синтезирует сишный код. Притом там даже система символьных вычислений есть над всем этим. Цитата:

Consequently, to generate code for a trigonometric transform, genfft first reduces it to a DFT and then it generates a dag for the DFT, imposing the necessary symmetries, setting the appropriate inputs to 0, and pruning the dag to the appropriate subset of the outputs. The symbolic simplications performed by genfft are powerful enough to eliminate all redundant computations, thus producing aspecialized DCT/DST algorithm. This strategy requires noprior knowledge of trigonometric-transform algorithms and is exceptionally easy to implement.

Может и для алгоритма LRnLA такой подход будет оптимальней.

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну если мы к списку требований добавляем популярность и возможность привлечения, то это уже не о качестве языка, я об этом выше уже написал. И в таком случае я уже вполне могу согласиться, что такой выбор оптимален. А так - ну можно взять OCaml и Си (где OCaml будет синтезировать код на Си из некоего DSL). В той статье про FFTW3 http://www.fftw.org/fftw-paper-ieee.pdf пишут про компилятор специального назначения, который на выходе дает код на Си. Вот такой подход можно использовать.

Можно еще взять еще OCaml и D в BetterC режиме. Можно взять LISP который генерит код на FORTRAN и так далее, вариантов вообще масса.

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

Аналоги плюсовых шаблонов, перегрузки и ООП можно делать на уровне самого DSL, а не на уровне языка, в который этот DSL потом транслирует код.

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

Да. Но тут понимаете ли в чем дело - я со своей позиции, т.е. с позиции человека, который под контроллеры пишет код, вижу, что язык Си не является на данный момент лучшим вариантом (если именно смотреть с позиции, на чем бы мне было удобнее и приятнее писать). Мне просто говорят «Вот у нас работа, пиши на этом и получай за это деньги.». Если я скажу «Нет, это неоптимально, хочу на этом»... в общем, никто со мной особо торговаться не будет.

И их можно понять. Допустим, согласятся они чтоб я писал на D или Rust каком-нибудь, а кто еще будет на этом писать? А если я свалю из проекта, кто это будет дальше поддерживать? Где им искать кадров? Тут речь идет не о некоторой качественности или оптимальности самого языка как такового. Да, это тоже такой локально-оптимальный путь, пусть всё остается как есть, будем пользоваться теми языками, под которых проще найти кодеров, но это не критерий оптимальности самого языка в вакууме, это критерий его оптимальности при некоторых других факторах, таких как наличие кадров, стоимость этих кадров, наличие готовых библиотек, компиляторов и так далее. Это создает сильный потенциальный барьер. И если действительно есть какой-то очень хороший язык, который на голову выше всех прочих языков для конкретной области, далеко еще не факт, что он сможет в существующей экосистеме прорваться и стать популярным. Он может просто быть не настолько лучше, чтобы все кинулись на него переучиваться и переписывать весь свой код на него.

Пардонте, откуда Вы знаете что удалось а что нет? Вы телепат?

Да я вроде сказал откуда я знаю. Я смотрел и сам отправлял багрепорты в багзиллу GCC с ключевым словом «missed-optimisation».

Если вас интересуют конкретно мои багрепорты - ну например вот один из них https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

Теоретический предел это максимально возможное число FMA операций с учетом многопоточности и векторизации (известно из доков на железо) деленный на число FMA операций в ячейке сетки за один шаг (считается на бумашке для конкретной численной схемы).

А разве все решаемые в HPC задачи всегда упирается в FMA операции? А как быть с ветвлениями? А что насчет оптимизаций методом частичных вычислений (суперкомпиляция)? Может есть способ, путем хитрых оптимизаций, радикально снизить число FMA операций, которые требутся для конкретных вычислений? И что можете сказать про полиэдральную модель для оптимизации циклов, обходящих многомерные массивы? https://iconfs.net/infocom2016/sravnenye-effektyvnosty-avtomatycheskoj-optymy... вот можете почитать, я даже могу процитировать:

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

Там по-вашему достигнут предел?

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

Вот кстати совсем недавно обсуждал с одним человеком эту тему: был кусок кода на Си который написан на интринсиках, этот человек взял асмовыхлоп компилятора для этого кода, руками там попереставлял инструкции местами - получил выигрыш в производительности. Через интринсики получилось не самое оптимальное. Ну и можно еще вспомнить Intel MKL, в которой именно не интринсики, а руками написанные куски на ассемблере. Нужны доказательства - вот https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/273636 - «MKL is hand-tuned assembly language for Intel CPUs, and also supports HyperThreading and multiprocessor systems.». Вряд ли в Intel стали бы просто так писать на асме, если бы это не давало какой-то выгоды.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

А на саму реализацию этого LRnLA где можно посмотреть? Вообще, это мне напомнило то, что сделали в FFTW3 - http://www.fftw.org/fftw-paper-ieee.pdf - у них свой метаязык (DSL) на Ocaml синтезирует сишный код. Притом там даже система символьных вычислений есть над всем этим. Цитата:

Consequently, to generate code for a trigonometric transform, genfft first reduces it to a DFT and then it generates a dag for the DFT, imposing the necessary symmetries, setting the appropriate inputs to 0, and pruning the dag to the appropriate subset of the outputs. The symbolic simplications performed by genfft are powerful enough to eliminate all redundant computations, thus producing aspecialized DCT/DST algorithm. This strategy requires noprior knowledge of trigonometric-transform algorithms and is exceptionally easy to implement.

Может и для алгоритма LRnLA такой подход будет оптимальней.

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну если мы к списку требований добавляем популярность и возможность привлечения, то это уже не о качестве языка, я об этом выше уже написал. А так - ну можно взять OCaml и Си (где OCaml будет синтезировать код на Си из некоего DSL). В той статье про FFTW3 http://www.fftw.org/fftw-paper-ieee.pdf пишут про компилятор специального назначения, который на выходе дает код на Си. Вот такой подход можно использовать.

Можно еще взять еще OCaml и D в BetterC режиме. Можно взять LISP который генерит код на FORTRAN и так далее, вариантов вообще масса.

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

Аналоги плюсовых шаблонов, перегрузки и ООП можно делать на уровне самого DSL, а не на уровне языка, в который этот DSL потом транслирует код.

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

Да. Но тут понимаете ли в чем дело - я со своей позиции, т.е. с позиции человека, который под контроллеры пишет код, вижу, что язык Си не является на данный момент лучшим вариантом (если именно смотреть с позиции, на чем бы мне было удобнее и приятнее писать). Мне просто говорят «Вот у нас работа, пиши на этом и получай за это деньги.». Если я скажу «Нет, это неоптимально, хочу на этом»... в общем, никто со мной особо торговаться не будет.

И их можно понять. Допустим, согласятся они чтоб я писал на D или Rust каком-нибудь, а кто еще будет на этом писать? А если я свалю из проекта, кто это будет дальше поддерживать? Где им искать кадров? Тут речь идет не о некоторой качественности или оптимальности самого языка как такового. Да, это такой локально-оптимальный путь, пусть всё остается как есть, будем пользоваться теми языками, под которых проще найти кодеров, но это не критерий качественности самого языка. Это создает сильный потенциальный барьер. И если действительно есть какой-то очень хороший язык, который на голову выше всех прочих языков для конкретной области, далеко еще не факт, что он сможет в существующей экосистеме прорваться и стать популярным. Он может просто быть не настолько лучше, чтобы все кинулись на него переучиваться и переписывать весь свой код на него.

Пардонте, откуда Вы знаете что удалось а что нет? Вы телепат?

Да я вроде сказал откуда я знаю. Я смотрел и сам отправлял багрепорты в багзиллу GCC с ключевым словом «missed-optimisation».

Если вас интересуют конкретно мои багрепорты - ну например вот один из них https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

Теоретический предел это максимально возможное число FMA операций с учетом многопоточности и векторизации (известно из доков на железо) деленный на число FMA операций в ячейке сетки за один шаг (считается на бумашке для конкретной численной схемы).

А разве все решаемые в HPC задачи всегда упирается в FMA операции? А как быть с ветвлениями? А что насчет оптимизаций методом частичных вычислений (суперкомпиляция)? Может есть способ, путем хитрых оптимизаций, радикально снизить число FMA операций, которые требутся для конкретных вычислений? И что можете сказать про полиэдральную модель для оптимизации циклов, обходящих многомерные массивы? https://iconfs.net/infocom2016/sravnenye-effektyvnosty-avtomatycheskoj-optymy... вот можете почитать, я даже могу процитировать:

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

Там по-вашему достигнут предел?

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

Вот кстати совсем недавно обсуждал с одним человеком эту тему: был кусок кода на Си который написан на интринсиках, этот человек взял асмовыхлоп компилятора для этого кода, руками там попереставлял инструкции местами - получил выигрыш в производительности. Через интринсики получилось не самое оптимальное. Ну и можно еще вспомнить Intel MKL, в которой именно не интринсики, а руками написанные куски на ассемблере. Нужны доказательства - вот https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/273636 - «MKL is hand-tuned assembly language for Intel CPUs, and also supports HyperThreading and multiprocessor systems.». Вряд ли в Intel стали бы просто так писать на асме, если бы это не давало какой-то выгоды.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

А на саму реализацию этого LRnLA где можно посмотреть? Вообще, это мне напомнило то, что сделали в FFTW3 - http://www.fftw.org/fftw-paper-ieee.pdf - у них свой метаязык (DSL) на Ocaml синтезирует сишный код. Притом там даже система символьных вычислений есть над всем этим. Цитата:

Consequently, to generate code for a trigonometric transform, genfft first reduces it to a DFT and then it generates a dag for the DFT, imposing the necessary symmetries, setting the appropriate inputs to 0, and pruning the dag to the appropriate subset of the outputs. The symbolic simplications performed by genfft are powerful enough to eliminate all redundant computations, thus producing aspecialized DCT/DST algorithm. This strategy requires noprior knowledge of trigonometric-transform algorithms and is exceptionally easy to implement.

Может и для алгоритма LRnLA такой подход будет оптимальней.

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну если мы к списку требований добавляем популярность и возможность привлечения, то это уже не о качестве языка, я об этом выше уже написал. А так - ну можно взять OCaml и Си (где OCaml будет синтезировать код на Си из некоего DSL). В той статье про FFTW3 http://www.fftw.org/fftw-paper-ieee.pdf пишут про компилятор специального назначения, который на выходе дает код на Си. Вот такой подход можно использовать.

Можно еще взять еще OCaml и D в BetterC режиме. Можно взять LISP который генерит код на FORTRAN и так далее, вариантов вообще масса.

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

Аналоги плюсовых шаблонов, перегрузки и ООП можно делать на уровне самого DSL, а не на уровне языка, в который этот DSL потом транслирует код.

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

Да. Но тут понимаете ли в чем дело - я со своей позиции, т.е. с позиции человека, который под контроллеры пишет код, вижу, что язык Си не является на данный момент лучшим вариантом (если именно смотреть с позиции, на чем бы мне было удобнее и приятнее писать). Мне просто говорят «Вот у нас работа, пиши на этом и получай за это деньги.». Если я скажу «Нет, это неоптимально, хочу на этом»... в общем, никто со мной особо торговаться не будет.

И их можно понять. Допустим, согласятся они чтоб я писал на D или Rust каком-нибудь, а кто еще будет на этом писать? А если я свалю из проекта, кто это будет дальше поддерживать? Где им искать кадров? Тут речь идет не о некоторой качественности или оптимальности самого языка как такового. Да, это такой локально-оптимальный путь, пусть всё остается как есть, будем пользоваться теми языками, под которых проще найти кодеров, но это не критерий качественности самого языка. Это создает сильный потенциальный барьер. И если действительно есть какой-то очень хороший язык, который на голову выше всех прочих языков для конкретной области, далеко еще не факт, что он сможет в существующей экосистеме прорваться и стать популярным. Он может просто быть не настолько лучше, чтобы все кинулись на него переучиваться и переписывать весь свой код на него.

Пардонте, откуда Вы знаете что удалось а что нет? Вы телепат?

Да я вроде сказал откуда я знаю. Я смотрел и сам отправлял багрепорты в багзиллу GCC с ключевым словом «missed-optimisation».

Если вас интересуют конкретно мои багрепорты - ну например вот один из них https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

Теоретический предел это максимально возможное число FMA операций с учетом многопоточности и векторизации (известно из доков на железо) деленный на число FMA операций в ячейке сетки за один шаг (считается на бумашке для конкретной численной схемы).

А разве все решаемые в HPC задачи всегда упирается в FMA операции? А как быть с ветвлениями? А что насчет оптимизаций методом частичных вычислений (суперкомпиляция)? А что можете сказать про полиэдральную модель для оптимизации циклов, обходящих многомерные массивы? https://iconfs.net/infocom2016/sravnenye-effektyvnosty-avtomatycheskoj-optymy... вот можете почитать, я даже могу процитировать:

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

Там по-вашему достигнут предел?

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

Вот кстати совсем недавно обсуждал с одним человеком эту тему: был кусок кода на Си который написан на интринсиках, этот человек взял асмовыхлоп компилятора для этого кода, руками там попереставлял инструкции местами - получил выигрыш в производительности. Через интринсики получилось не самое оптимальное. Ну и можно еще вспомнить Intel MKL, в которой именно не интринсики, а руками написанные куски на ассемблере. Нужны доказательства - вот https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/273636 - «MKL is hand-tuned assembly language for Intel CPUs, and also supports HyperThreading and multiprocessor systems.». Вряд ли в Intel стали бы просто так писать на асме, если бы это не давало какой-то выгоды.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

А на саму реализацию этого LRnLA где можно посмотреть? Вообще, это мне напомнило то, что сделали в FFTW3 - http://www.fftw.org/fftw-paper-ieee.pdf - у них свой метаязык (DSL) на Ocaml синтезирует сишный код. Притом там даже система символьных вычислений есть над всем этим. Цитата:

Consequently, to generate code for a trigonometric transform, genfft first reduces it to a DFT and then it generates a dag for the DFT, imposing the necessary symmetries, setting the appropriate inputs to 0, and pruning the dag to the appropriate subset of the outputs. The symbolic simplications performed by genfft are powerful enough to eliminate all redundant computations, thus producing aspecialized DCT/DST algorithm. This strategy requires noprior knowledge of trigonometric-transform algorithms and is exceptionally easy to implement.

Может и для алгоритма LRnLA такой подход будет оптимальней.

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну если мы к списку требований добавляем популярность и возможность привлечения, то это уже не о качестве языка, я об этом выше уже написал. А так - ну можно взять OCaml и Си (где OCaml будет синтезировать код на Си из некоего DSL). В той статье про FFTW3 http://www.fftw.org/fftw-paper-ieee.pdf пишут про компилятор специального назначения, который на выходе дает код на Си. Вот такой подход можно использовать.

Можно еще взять еще OCaml и D в BetterC режиме. Можно взять LISP который генерит код на FORTRAN и так далее, вариантов вообще масса.

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

Аналоги плюсовых шаблонов, перегрузки и ООП можно делать на уровне самого DSL, а не на уровне языка, в который этот DSL потом транслирует код.

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

Да. Но тут понимаете ли в чем дело - я со своей позиции, т.е. с позиции человека, который под контроллеры пишет код, вижу, что язык Си не является на данный момент лучшим вариантом (если именно смотреть с позиции, на чем бы мне было удобнее и приятнее писать). Мне просто говорят «Вот у нас работа, пиши на этом и получай за это деньги.». Если я скажу «Нет, это неоптимально, хочу на этом»... в общем, никто со мной особо торговаться не будет.

И их можно понять. Допустим, согласятся они чтоб я писал на D или Rust каком-нибудь, а кто еще будет на этом писать? А если я свалю из проекта, кто это будет дальше поддерживать? Где им искать кадров? Тут речь идет не о некоторой качественности или оптимальности самого языка как такового. Да, это такой локально-оптимальный путь, пусть всё остается как есть, будем пользоваться теми языками, под которых проще найти кодеров, но это не критерий качественности самого языка. Это создает сильный потенциальный барьер. И если действительно есть какой-то очень хороший язык, который на голову выше всех прочих языков для конкретной области, далеко еще не факт, что он сможет в существующей экосистеме прорваться и стать популярным. Он может просто быть не настолько лучше, чтобы все кинулись на него переучиваться и переписывать весь свой код на него.

Пардонте, откуда Вы знаете что удалось а что нет? Вы телепат?

Да я вроде сказал откуда я знаю. Я смотрел багрепорты в багзилле GCC с ключевым словом «missed-optimisation».

Если вас интересуют конкретно мои багрепорты - ну например вот один из них https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

Теоретический предел это максимально возможное число FMA операций с учетом многопоточности и векторизации (известно из доков на железо) деленный на число FMA операций в ячейке сетки за один шаг (считается на бумашке для конкретной численной схемы).

А разве все решаемые в HPC задачи всегда упирается в FMA операции? А как быть с ветвлениями? А что насчет оптимизаций методом частичных вычислений (суперкомпиляция)? А что можете сказать про полиэдральную модель для оптимизации циклов, обходящих многомерные массивы? https://iconfs.net/infocom2016/sravnenye-effektyvnosty-avtomatycheskoj-optymy... вот можете почитать, я даже могу процитировать:

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

Там по-вашему достигнут предел?

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

Вот кстати совсем недавно обсуждал с одним человеком эту тему: был кусок кода на Си который написан на интринсиках, этот человек взял асмовыхлоп компилятора для этого кода, руками там попереставлял инструкции местами - получил выигрыш в производительности. Через интринсики получилось не самое оптимальное. Ну и можно еще вспомнить Intel MKL, в которой именно не интринсики, а руками написанные куски на ассемблере. Нужны доказательства - вот https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/273636 - «MKL is hand-tuned assembly language for Intel CPUs, and also supports HyperThreading and multiprocessor systems.». Вряд ли в Intel стали бы просто так писать на асме, если бы это не давало какой-то выгоды.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

А на саму реализацию этого LRnLA где можно посмотреть? Вообще, это мне напомнило то, что сделали в FFTW3 - http://www.fftw.org/fftw-paper-ieee.pdf - у них свой метаязык (DSL) на Ocaml синтезирует сишный код. Притом там даже система символьных вычислений есть над всем этим. Цитата:

Consequently, to generate code for a trigonometric transform, genfft first reduces it to a DFT and then it generates a dag for the DFT, imposing the necessary symmetries, setting the appropriate inputs to 0, and pruning the dag to the appropriate subset of the outputs. The symbolic simplications performed by genfft are powerful enough to eliminate all redundant computations, thus producing aspecialized DCT/DST algorithm. This strategy requires noprior knowledge of trigonometric-transform algorithms and is exceptionally easy to implement.

Может и для алгоритма LRnLA такой подход будет оптимальней.

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну если мы к списку требований добавляем популярность и возможность привлечения, то это уже не о качестве языка, я об этом выше уже написал. А так - ну можно взять OCaml и Си (где OCaml будет синтезировать код на Си из некоего DSL). В той статье про FFTW3 http://www.fftw.org/fftw-paper-ieee.pdf пишут про компилятор специального назначения, который на выходе дает код на Си. Вот такой подход можно использовать.

Можно еще взять еще OCaml и D в BetterC режиме. Можно взять LISP который генерит код на FORTRAN и так далее, вариантов вообще масса.

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

Аналоги плюсовых шаблонов, перегрузки и ООП можно делать на уровне самого DSL, а не на уровне языка, в который этот DSL потом транслирует код.