성능을위한 타입 시스템

프로그램의 성능 특성을 공식화하려는 (정적) 유형 시스템이 있습니까? 그런 시도를 찾지 못하는 것 같습니다.

타입 시스템은 프로그램에 대한 진술을하기 위해 프로그래머의 무기고에서 가장 강력한 도구 중 하나이며, 성능이 중요한 경우가 많기 때문에 시도가 수행되었다고 상상하기에는 그리 멀지 않은 것 같습니다. 프로그램의 저장 및 런타임 특성에 대해 적어도 몇 가지 진술을 시도하는 형식 시스템을 만듭니다.

language-design

— 클라스 반 셰 르벤
소스

타입 시스템의 성능에 대해 무엇을 말 if condition then expensive_operation else cheap_operation하시겠습니까?

— svick

추상적 인 해석을 사용하여 최악의 경우 복잡한 코드 (및 종료)를 자동으로 추론하는 개발이있었습니다. 당신은 그것에 관심이있을 수 있습니다 ...

— Bakuriu

전적으로 관련이 없지만 여전히 : kernelnewbies.org/FAQ/LikelyUnlikely Linux에서 커널 / gcc 컴파일러는 특정 경로를 최적화하기 위해 매크로가 아닐 수도 있습니다. 예 :if (likely(operation_went_fine)) { // Do something } else if (unlikely(error_occured)) { // Do something else }

— AmazingDreams

C의 휘발성 및 레지스터 키워드가 생각납니다.

— mattnz

답변:

WCET 또는 프로그램의 복잡성 과 관련이있을 정도로 정교한 형식 시스템을 상상할 수 있습니다 . 그런 다음 문제는 사운드 유형 분석기 (또는 체커) (즉, 입력 규칙)를 만들어 가능하게하고 합리적으로 유용하게 사용할 수 있도록 효율적으로 구현하는 것입니다.

대부분의 유형 시스템은 실제로 계산하기에 충분히 간단합니다 (적어도 인간 개발자가 수동으로 작성할 수있는 합리적인 프로그램 세트에 해당).

일부 학술 프로그래밍 언어 (예 : AGDA )는 튜링이 완료된 매우 정교한 유형 시스템을 가지고 있으므로 컴파일러에서 시간이 오래 걸릴 수 있습니다.

(잘 이해하면 파리의 LIP6에서 진행중인 Jérémie Salvucci 박사 과정은 귀하의 질문과 관련이 있습니다. 나는 그에게 이메일을 보냈습니다. 지역과 유형을 찾을 수도 있습니다 ...).

그러나 쌀의 정리 와 멈춤 문제를 알고 있어야 합니다. 유형 시스템이 항상 원하는 은색 총알이 아닐 수도 있습니다 (오래된 은색 불릿 북 참조).

— 바 실레 스타 인케 비치
소스

WCET은 이러한 맥락에서 "가장 최악의 실행 시간"입니다 (나 이외의 다른 사람이 궁금한 경우)

— Klaas van Schelven

Agda, Coq, Epigram, Guru, Isabelle 등의 의존형 언어는 Turing-complete가 아닌 중단 문제, 라이스 정리 및 친구들을 "해결"합니다. 구성에 의해 (즉, 무한 루프 / 비 종료 재귀를 작성하는 것은 불가능하다) 모든 프로그램은 종료 검사기가 종료를 증명할 수있는 방식으로 작성되도록 요구하거나 프로그래머가 기계 점검 가능한 종단 증거.

— Jörg W Mittag

의 성능 특성 분류하고 유형 시스템 만들 저명 가능한 것 같다 유형(예 : "직렬 액세스의 경우 빠름 / 느린 속도, 임의 액세스의 경우 빠름 / 느린 속도", "메모리 효율적 / 비효율적") 이러한 특성은보다 구체적인 형식이 상속 된 방식으로 계층 구조에 배치되는 추상 형식 일 수 있습니다. 그러나 이러한 유형을 사용하는 모든 프로그램의 성능은 실제로 사용 / 액세스되는 방식에 따라 달라 지므로 유형 시스템이 프로그램 자체에 대한 설명을 작성하려면 해당 유형의 사용 (액세스)이 유형으로 표시되어야합니다. 이는 내장 된 제어 구조 (예 : for / while 루프)를 사용하지 않고 대신이를 구현하는 유형을 사용한다는 의미이므로 계층은 추상 직렬 액세스 유형과 하위 목록 직렬 액세스, 트리 직렬을 가질 수 있습니다. -액세스 유형 등사용 효율성은 이러한 유형을 서로 조합하여 적용함으로써 적어도 부분적으로 표현 될 수 있습니다.

제어 구조가 거의없는 Haskell과 같은 기능적 언어에서 이것은 상당히 실용 적이고 시행 가능한 것으로 보입니다 . 그러나 Java에서는 이러한 시스템을 달성하기가 훨씬 어려워 보입니다 ( 결과의 시행 가능성 / 신뢰성에서와 같이 구현 에서는 그리 많지 않습니다 ).

Haskell은 이미 우리가 얼마나 많은 프로그램이 순수한지를 명확하게 진술 할 수있게 해주 며 밀폐 된 박스 내에서 특정 활동을 제한하는 방법을 제공합니다. Haskell의 병렬 처리 / 동시성 은 유형 시스템을 통해 구현 되므로 이미 원하는 방식으로 진행되고 있다고 주장 할 수 있습니다. 대조적으로, 명령형 언어 (Java와 같이 정적으로 유형이 지정된 언어조차도)는 코더에게 이것에 대한 시도를 전복시키는 많은 방법을 제공합니다.

— 그것의 브루스
소스