プログラミング・モデル

ウィキペディア

プログラミングパラダイム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/09/29 13:14 UTC 版)

プログラミングパラダイム（英: programming paradigm）とは、プログラミングにおける模範である。

概要

プログラミングパラダイムは、プログラマにプログラムの見方を与えるものと言える。例えばオブジェクト指向プログラミングでは、プログラムとはオブジェクトを作りそれを管理するもの。関数型言語では、状態を持たない関数の評価の連続。

プログラミング言語が違えば、対応できるパラダイムも違ってくる。SmalltalkやJavaは、手続き型やオブジェクト指向、Haskellは、関数プログラミング、というように、比較的少数のパラダイムに対応している。一方、多数のパラダイムに対応した言語（マルチパラダイムプログラミング言語）もある。

多くのプログラミングパラダイムには禁じ手がある。純粋な関数型プログラミングでは、副作用があってはならない。構造化プログラミングでは、gotoの無制限な利用が戒められる。特にこの理由により、古いスタイルに慣れた者からは、よく非現実的または過剰に厳密なものと見なされる。しかし、こうした特定のテクニックを避けることで、プログラミング言語の一般の法則に制約されず、プログラムの正確さ（または単にその動作の理解）についての法則を証明しやすくする。

マルチパラダイムプログラミング言語が登場してから、プログラミングパラダイムとプログラミング言語との関連は複雑になっている。たとえば、C++は手続き型プログラミング、ジェネリックプログラミング、オブジェクト指向プログラミングに対応するよう設計されているが、設計時には個々の部分毎にどのパラダイムを使うか選ぶ必要に迫られる。あるプログラムは全て手続き型プログラミングで作り、またあるプログラムは全てオブジェクト指向で作り、また別のプログラムは両方を混在して作るという具合である。

例

比較されるものは横に並べてある。括弧内はそれを用いている例である。

• 構造化プログラミング - 非構造化プログラミング
• 命令型プログラミング - 宣言型プログラミング
• メッセージ送信プログラミング（アクターモデル）
• 手続き型プログラミング - 非手続き型言語
• イベント駆動型プログラミング
• シグナルプログラミング
• スタック指向プログラミング
• クラスベースプログラミング - プロトタイプベースプログラミング ※オブジェクト指向プログラミングの中での分類
• 並行論理プログラミング
• 制約プログラミング
• 論理プログラミング
• 解集合プログラミング（en: Answer Set Programming）
• 制約論理プログラミング
• 並行プログラミング
• 並行制約プログラミング
• 関数型プログラミング
• コンポーネント指向プログラミング (OLE)
• アスペクト指向プログラミング (AspectJ)
• 契約プログラミング
• リフレクティブプログラミング
• データフロープログラミング
• リアクティブプログラミング (スプレッドシート)

関連項目

• 抽象化 (計算機科学)
• Expression problem

ウィキペディア小見出し辞書

プログラミングモデル

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/09/05 05:56 UTC 版)

「OpenCL」の記事における「プログラミングモデル」の解説

OpenCLのプログラム（アプリケーションソフトウェア）は、GLSLを利用したOpenGLプログラムとほぼ同じ要領で開発することができ、OpenCL C/C++を利用したデバイスコード（カーネルコード）と、OpenCL APIを利用したホストコードを別々に記述する。カーネルコードのコンパイルは、clCreateProgramWithSource()関数経由でデバイスドライバーが実行する。CUDAプログラムのような専用オフライン コンパイラ（nvcc）を必要としないため、様々なプラットフォームへの展開が容易となることが利点である。ただしカーネルコードの初回の実行時コンパイル（オンライン コンパイル）に時間がかかるなどのデメリットも存在する。この点に関しては、実運用時にはclCreateProgramWithSource()関数によるオンライン コンパイルは行なわず、clGetProgramInfo()関数とclCreateProgramWithBinary()関数を用いてコンパイル済みバイナリからプログラムオブジェクトを生成する方法もある が、ベンダーごとのOpenCLバイナリ間における互換性は保証されない。デバイスドライバーにカーネル記述言語のオンラインコンパイラの役割を持たせることで、ベンダー独自の拡張を実装しやすくなるが、コンパイラ品質はデバイスドライバーの品質に左右される。 なお、OpenCL 1.2、2.0、2.1、2.2では、SPIR（英語版）およびSPIR-Vと呼ばれる中間表現（中間言語、バイトコード）をサポートすることにより、事前コンパイルしたベンダーに依存しないカーネルコードを実行することができるようになる。ただし、SPIR 1.2およびSPIR 2.0はOpenCL 1.2およびOpenCL 2.0の拡張機能（cl_khr_spir）となっており、サポート必須の機能ではない。一方、SPIR-VはOpenCL 2.1/2.2のコア機能となる。OpenCL 2.1ではSPIR-V 1.0を、OpenCL 2.2ではSPIR-V 1.0/1.1/1.2をサポートするが、OpenCL 3.0ではSPIR-Vはコア機能から外れ、サポート状況に関しては実行時の問い合わせが必要となった。