トップページ > プログラム > 2014年08月16日 > 5flrnqyZ

書き込み順位&時間帯一覧

4 位/158 ID中時間01234567891011121314151617181920212223Total
書き込み数0000001021200020000000008



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
【初心者歓迎】C/C++室 Ver.92【環境依存OK】
Win32API質問箱 Build118
【Python】スクリプト バトルロワイヤル45【pl,rb,php,js】

書き込みレス一覧

【初心者歓迎】C/C++室 Ver.92【環境依存OK】
274 :デフォルトの名無しさん[]:2014/08/16(土) 06:02:24.34 ID:5flrnqyZ
内部でUTF8(1バイト長)を使うと固定するように、
内部でUTF16(2バイト長)を使うと固定してもマルチプラットフォーム化は可能。
昔から次世代のPHP6は内部UTF16化しようとしてた。
Win32API質問箱 Build118
84 :デフォルトの名無しさん[]:2014/08/16(土) 08:30:07.63 ID:5flrnqyZ
質問です。
XPを使っているんですが。
XPより後バージョンにしかないAPIを抽出して実装するのと、
VC++2010になくて、gccやC11にある関数を抽出して実装するのはどうやればいいですか。
【初心者歓迎】C/C++室 Ver.92【環境依存OK】
278 :デフォルトの名無しさん[]:2014/08/16(土) 08:45:24.88 ID:5flrnqyZ
次期PHPは「PHP 7」になる? 2014年07月25日

いつまで経ってもリリースされないPHP 6だが、PHP 6はスキップして次期バージョンはPHP 7としてリリースするという案がPHPの開発チーム内で真剣に議論されているそうだ。
PHP 6については、当初文字列の内部処理をUTF-16で行うという方針で開発されていたが、2010年にこれを転換、開発ブランチがロールバックされるという事件があった(過去記事)。
その後4年が経ったが、未だPHP 6はリリースされていない。
PHP 6の開発は長きにわたり、かつて「PHP 6で導入される新機能」として紹介されたものが、実際には次期PHPには導入されない可能性もあるという。
そのため、新しい「PHP 7」というバージョンにすべきだ、という話のようだ。
http://developers.slashdot.jp/story/14/07/25/040238/
【Python】スクリプト バトルロワイヤル45【pl,rb,php,js】
670 :デフォルトの名無しさん[]:2014/08/16(土) 09:10:28.92 ID:5flrnqyZ
GoもPythonもユーザーが並列処理用コードに書きこまないと出来ないだろう。GoもPythonも50ポ100ポのようだ。
シングルもパラレルも同一コードであって自動並列化するのが楽。


http://game.watch.impress.co.jp/docs/20080911/epic.htm

現状でさえマルチスレッドプログラミングは開発の困難さが指摘されている分野である。
同時並列的に動作するプログラムがモデルデータやゲーム内状態などの共有情報にアクセスしようとするとき、そこには必ずデータ競合によるバグの発生や、デッドロックによるプログラムの停止というリスクがつきものである。

Sweeney氏は、これは現在主流の開発言語であるC++の手続き型言語としての特性に由来すると指摘する。
マルチスレッドにおける問題を避けるためのテクニックは各種あるが、Sweeney氏に言わせるとそれは「シングルスレッドのプログラムをアセンブラで書くようなもの」であり、生産性が悪いのである。

Sweeney氏は、この問題を解決するためには、ゲーム開発言語として純粋関数型の言語が必要になるだろうと言う。
この種の処理系では、C++のような共有メモリのアクセスや、I/O操作は基本的に行なえない。
その引き替えとして、各関数のアトミック性が構造的に保証されており、安全に並列実行できるのだ。
しかも、コンパイラが対応さえすれば、関数を自動的に多数のコアに分散処理させることができるというスケーラブルな実行バイナリを作り出せる。

Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。

もし、Sweeney氏のいう純粋関数型言語によるゲーム開発が実現したとして、それを基準とするならば、C++によるプログラム開発コストは、
マルチスレッド版で2倍、プレイステーション 3版において5倍、シェーダー言語で記述するGPGPU版において10倍かそれ以上にもなるという。
従って、6コア、8コアどころでは済まないメニーコア世代のプラットフォームに備えて、ゲーム会社は開発基盤を備える必要がある。
【Python】スクリプト バトルロワイヤル45【pl,rb,php,js】
672 :デフォルトの名無しさん[]:2014/08/16(土) 10:43:20.24 ID:5flrnqyZ
プログラミング・テクニックとしての遅延評価は別にして。
関数型の特徴は、手続き型でないこと(=上から下、左から右に計算するといった順序がない)で
遅延評価を取り入れるのが真っ当なだけでは。そうでないと手続き型になってしまう。
参照透過性と計算順序がない事はやや別概念だけど。コード全体で参照透過性あって、計算順序がなかったときは
理屈上、コンパイラや実行環境が自動並列処理化可能だろう。



参照透過性 - Wikipedia
参照透過性は、計算機言語の概念の一種で、文脈によらず式の値はその構成要素(例えば変数や関数)によってのみ定まるということを言う。
参照透過性が成り立つ言語は式の値がプログラムのテキストから定まるという特徴から宣言型言語と呼ばれたり、関数の数学的性質が保たれるという特徴から純粋関数型言語と呼ばれたりする。
一方、参照透過的でない言語を手続き型言語と呼ぶ。
【Python】スクリプト バトルロワイヤル45【pl,rb,php,js】
673 :デフォルトの名無しさん[]:2014/08/16(土) 10:49:44.07 ID:5flrnqyZ
命令型プログラミング - Wikipedia

命令型プログラミングとは、計算をプログラム状態を変化させる文の列で記述するプログラミングパラダイムの一種。
命令型プログラムはコンピュータが実行すべき命令列で構成される。
命令型プログラミングに従ったプログラミング言語を命令型(プログラミング)言語と呼ぶ。
一般に命令型プログラミングは、手続き型プログラミングと同義として扱われる。

命令型プログラミングは、宣言型プログラミング(関数型や論理型言語など)と対照的である。
Haskellなどの関数型プログラミング言語では、プログラムは文の並びではないし、命令型言語が持つような広域状態を持たない。
Prologのような論理プログラミング言語では、命令型言語のように計算の「方法」をプログラムとして記述するのではなく、計算すべき「事物」を定義する。

ほとんど全てのコンピュータのハードウェア実装は命令型である。
ほぼ全てのコンピュータハードウェアは機械語を実行するよう設計されており、機械語は命令から構成される。
高級な命令型言語は変数や他の複雑な構文を使用可能となっているが、基本的に同じパラダイムである。
命令型プログラミングの基本的考え方はハードウェアの実装に近く、概念的にもなじみ深いため、多くのコンピュータ言語が命令型のスタイルである。
【Python】スクリプト バトルロワイヤル45【pl,rb,php,js】
680 :デフォルトの名無しさん[]:2014/08/16(土) 14:16:29.70 ID:5flrnqyZ
Haskellコンパイラが不十分なだけだろ。
理屈上、純粋関数型なら、ソースコードに並列処理を明示しなくていいはずだがHaskellはそうでない。
シングルもパラレルも同一コードで、コンパイラオプションだけか、VMなど実行環境の設定だけで、並列化可能なはずだ。
【Python】スクリプト バトルロワイヤル45【pl,rb,php,js】
681 :デフォルトの名無しさん[]:2014/08/16(土) 14:35:34.09 ID:5flrnqyZ
自動並列化は、学習型・適応型でやるといいだろう。片っ端に出来るところをやると逆に遅くなる。


実行時コンパイラ - Wikipedia
適応的コンパイル
JITコンパイラの短所を補うためのJITコンパイルの一方式として適応的コンパイルという方式がある。

これは、起動当初はインタプリタとして実行し、よく呼び出されるメソッドや繰り返し実行されるコードの検出(プロファイリング)を行い、そのようなコードのみをコンパイルする、というものである。

実行時間の大半が費やされるようなボトルネックとなるコードのみをコンパイルすることで、起動時のオーバーヘッドや利用メモリ増大を抑えたうえで、効率よく実行速度を向上することができる。

この適応的コンパイルによる適応的最適化は、静的コンパイルでは得られない情報を元に最適化が行えるため、静的コンパイルより、むしろパフォーマンスが上がる場合もある。

JITコンパイル方式の利点
JITコンパイル方式と事前コンパイルの生成コードの質を比べると、前述のようにコンパイル時間に対する制約のためJIT方式の方が不利であるが、有利な点もある。
それは、実行環境を知った上でそれに応じた生成コードの選択や最適化を行うことができるということである。

JIT方式では、CPUがMMXをサポートしているならMMX命令を使ったコードを生成し、そうでなければ多少効率の悪いPentiumの命令の範囲内での実行を行う、ということができる。

また、実行環境におけるキャッシュやメモリのサイズ、速度特性なども実行時にならないと最終的にはわからない。
JITコンパイル方式では実際に走行しているCPUやメモリの情報を知ることができるため、それに応じたコードを生成することができ、事前コンパイルよりも優れたコードを生成できる可能性がある。

JavaScriptのJITコンパイラ
近年の主要なウェブブラウザはJavaScriptのエンジンにJITコンパイラを搭載し、高速に処理できるようになっている。
実行時の変数に代入された値の統計データから、変数に型を割り振ることにより、JITコンパイラが実現し、高速にJavaScriptを処理できるようになった。


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。