Тип системи для продуктивності

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

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

language-design

— Клаас ван Шельвен
джерело

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

— svick

Я знаю, що були розробки з використання абстрактної інтерпретації, щоб автоматично зробити висновок про найгірший складність коду (і припинення). Можливо, вас це зацікавить ...

— Бакуріу

Не повний зв’язок, але все-таки: 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 - це "найгірший час виконання" у цьому контексті (якщо хтось, крім мене, не

— замислюється

Залежно типізовані мови, такі як Агда, Кок, Епіграма, Гуру, Ізабел та ін., "Вирішують" проблему зупинки, теорему Райса та друзів, не закінчуючи Тьюрінга. Або за допомогою побудови (тобто просто неможливо записати нескінченний цикл / не припиняється рекурсія), вимагаючи, щоб усі програми були написані таким чином, щоб перевірка припинення могла довести припинення, або вимагаючи від програміста подати підтвердження машинного підтвердження закінчення.

— Йорг W Міттаг

Начебто можливо створити систему типів, яка б класифікувала продуктивність, характерну для типів(наприклад, "швидкий / повільний для послідовного доступу", "швидкий / повільний для випадкового доступу", "ефективна пам'ять / неефективний"). Ці риси можуть бути абстрактними типами, розміщеними в ієрархії таким чином, що більш конкретні типи успадковані від них. Однак ефективність будь-якої програми, що використовує ці типи, залежатиме від способу їх фактичного використання / доступу. Для того, щоб система типів робила заяви про саму програму, використання (доступ до) цих типів мало б бути представлене як типи . Це означало б відмовитися від використання вбудованих структур управління (наприклад, для циклів / час) та замість цього використовувати типи, які їх реалізують. Отже, ієрархія може мати абстрактний тип послідовного доступу та список нащадків-серійний-доступ, дерево-серійний -доступні типи тощо.Ефективність використання може бути принаймні частково виражена комбінацією та застосуванням цих типів один до одного.

У такій функціональній мові, як Haskell - яка майже не має структур управління - це здається мені досить практичним та дієвим . В Java, проте, така система здається набагато менш досяжним (Не так багато від реалізації , як від можливості виконання / достовірності результату).

Haskell вже дозволяє остаточно констатувати, яка частина програми є чистою, і пропонує способи обмеження певної діяльності в запечатаних скриньках. Оскільки паралелізм / паралельність у Haskell реалізований через систему типів , можна стверджувати, що він вже є частиною шляху (до того, що ви хочете). Навпаки, імперативні мови (навіть типові, такі як Java) пропонують кодеру багато, багато способів підривати будь-яку спробу цього.

— їїбрюс
джерело