Система типов для производительности

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

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

language-design

— Клаас ван Шельвен
источник

Что ваша система типов скажет о производительности if condition then expensive_operation else cheap_operation?

— свик

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

— Бакуриу

Не полностью связано, но все же: kernelnewbies.org/FAQ/LikelyUnlikely В ядре Linux / gcc компилятор, вероятно, / маловероятный макрос для оптимизации определенных путей. Напримерif (likely(operation_went_fine)) { // Do something } else if (unlikely(error_occured)) { // Do something else }

— AmazingDreams

В голову приходят летучие и регистрируемые ключевые слова в Си.

— Mattnz

Ответы:

Вы можете представить себе систему типов, достаточно сложную, чтобы иметь отношение к WCET или сложности программы. Затем проблема заключается в том, чтобы сделать анализатор типа звука (или средство проверки) - то есть правила набора текста - чтобы сделать это возможным, и реализовать его достаточно эффективно, чтобы сделать это достаточно полезным.

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

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

(Если я хорошо понимаю, работа доктора философии Джереми Сальвуччи на LIP6 в Париже довольно связана с вашим вопросом; я отправил ему электронное письмо об этом; вы можете искать регионы и типы ...).

Однако помните о теореме Райса и проблеме Остановки . Системы типов не всегда могут быть той «серебряной пулей», какой вы хотите их видеть (см. Старую книгу « Нет серебряных пуль» )

— Василий Старынкевич
источник

В этом контексте WCET - это «худшее время исполнения» (если кому-то, кроме меня, интересно)

— Клаас ван Шельвен,

Языки с независимой типизацией, такие как Agda, Coq, Epigram, Guru, Isabelle и т. Д., «Решают» проблему остановки, теорему Райса и друзей, не будучи полными по Тьюрингу. Либо по конструкции (т. Е. Просто невозможно написать бесконечный цикл / бесконечную рекурсию), требуя, чтобы все программы были написаны таким образом, чтобы средство проверки завершения могло доказать завершение, либо потребовав от программиста представить проверяемое машиной доказательство прекращения.

— Jörg W Mittag

Кажется, в высшей степени возможно создать систему типов, которая классифицирует характеристику производительности типов(например, «быстрый / медленный для последовательного доступа», «быстрый / медленный для произвольного доступа», «эффективная / неэффективная память»). Эти характеристики могут быть абстрактными типами, помещенными в иерархию таким образом, что более конкретные типы наследуются от них. Однако производительность любой программы, использующей эти типы, будет зависеть от того, как они на самом деле используются / к которым обращаются. Для системы типов, которая делает заявления о самой программе, использование этих типов (доступ к ним) должно быть представлено в виде типов. Это означало бы отказ от использования встроенных управляющих структур (например, для циклов for / while) и вместо этого использования типов, которые их реализуют. Следовательно, иерархия может иметь абстрактный тип последовательного доступа и наследующий список последовательный доступ, дерево последовательный типы доступа и так далее.Тогда эффективность использования может быть, по крайней мере, частично выражена сочетанием и применением этих типов друг к другу.

В функциональном языке, таком как Haskell, который в любом случае практически не имеет структур управления, это выглядит для меня довольно практичным и осуществимым. В Java, однако, такая система кажется гораздо менее достижимым (не так много от реализации , как от исполнимости / достоверности результата).

Haskell уже позволяет нам окончательно заявить, насколько чистая программа, и предоставляет способы ограничить определенные действия в запечатанных коробках. Поскольку параллелизм / параллелизм в Haskell реализуется через систему типов , можно утверждать, что это уже часть пути (к тому, что вы хотите). Напротив, императивные языки (даже статически типизированные, такие как Java) предлагают кодеру много, много способов подорвать любую попытку этого.

— itsbruce
источник