Author:nothingcosmos(坂頂佑樹) IT系、特にVMに関して 周辺技術の紹介等をしています。 コメント・質問はお気軽にどうぞ。 LLVM wiki twitter:nothingcosmos
Free Software Foundation（FSF）のGNU ProjectとGCC開発チームは6月27日、オープンソースのコンパイラスイート「GNU Compiler Collection（GCC）4.6.1」を公開した。バグ修正およびドキュメントのアップデート中心のリリースとなる。 GCC 4.6.1は、3月末に公開された4.6の最初のバグ修正リリースとなる。バージョン4.6ではC、C++、Java、Ada、Fortranなどに加え、Googleが2009年11月に発表したGo言語の対応が加わっていた。 4.6.1はバグ修正、リグレッション修正、ドキュメンテーションのアップデートが中心で、新機能の追加はない。重要度の高い「P1」に分類されたリグレッションはなく、次に重要度の高い「P2」は107件、最も低い「P3」は8件、合計で115件が修正された。 このほか、Go言語の対応がデフ
Objective-Cというプログラミング言語があります。 C言語をベースにオブジェクト指向言語のSmallTalkの拡張を施した言語です。 オブジェクト指向を取り入れたC言語にC++がありますが 根本から拡張されているC++と違い Objective-Cは素のままのC言語にSmallTalkを融合させたような形を取ります。 Objective-Cは世界で2番目に美しいGUIを生み出した現AppleComputer社CEOである Steve Jobs氏がNeXTコンピュータのOSであるNeXTSTEPで採用した言語です。 NeXTSTEP自体はPC/AT互換機やHewlett Packard社のHP9000、 Sun Microsystems社のSparcStationにも移植されたようですが、残念ながら私は触れた事がありません。 現在では希にYahoo Auctionに出品されますが、
GCC 4.4ぐらいから見たいなのですが、-Qオプションを使うと、 最適化等でどのオプションが有効になるかがわかるみたいです。 具体的には以下のようなコマンドです。 % gcc -O2 -Q --help=optimize # 個々のオプションについて 'enabled' or 'disabled'が確認できるそれで各レベルでの違いを見てみた。 まとめるのが面倒なので以下のようなスクリプトを走らせる #!/usr/bin/env perl use strict; use warnings; my @levels = qw(-O0 -O1 -O2 -O3 -Os); my @base = qw(gcc -- -Q --help=optimize); my %optimize; for my $level (@levels) { my @cmd = @base; $cmd[1] = $leve
3アドレスコード（英: three-address code）とは、コンピュータ・プログラミング言語処理系などにおける中間表現などにおける形式の1パターンである。処理系においては、コンパイラ最適化などの処理を掛けるのに適している。2つの入力と1つの出力のアドレス（メモリまたはレジスタ）を指定する形式であるため、3アドレスコードと呼ばれる。命令セットアーキテクチャにおける「3オペランド」形式の類推とも言える。 この形式における各命令は、形式的に4ツ組で表現すると (オペコード, ソース1, ソース2, デスティネーション) である。より直感的にプログラミング言語における代入と2項演算子による数式っぽく書くと、 あるいは、 といったようになる（ただし は、なんらかの演算の2項演算子とする）。「左辺」「右辺」という用語の都合から、ここでは以後、後者の記法を使う。 ここで、a と b は、比較的に
LLVM（エルエルヴィーエム、 またはエルエルブイエム）とは、コンパイル時、リンク時、実行時などあらゆる時点でプログラムを最適化するよう設計された、任意のプログラミング言語に対応可能なコンパイラ基盤である。当初は、LLVMの名称の由来は、Low Level Virtual Machine (低水準仮想機械) の略であるとしていたが[3]、現在は、何の頭文字でもないとしている[4]。 LLVMは、プラットフォームに依存しない中間表現であるLLVM-IRを生成し、LLVM-IRを特定のマシンの機械語などに変換する。LLVM-IRの段階で、言語やプラットフォームとは独立した最適化を行う。この方法によってLLVMは言語からもアーキテクチャからも独立しており、それぞれに特化した、プログラミング言語固有のモジュールと、マシン向けコード生成部を用意することにより様々な言語アーキテクチャーに対応する。LL
前回の文字列操作編では適当に文字列操作のパフォーマンスを測定しようとしたらGC様とJITコンパイラ様に阻まれた、という話だった。モヒカン族*1が「てめえの計測はなっちゃいねー！ひゃっはー！」と殴りかかったらケンシロウみたいなのが出てきて「あべしっ」となった、ぐらいのつまらない話だったが、反省してこれらと向かい合ってみたい。 JITコンパイラについての情報 JITコンパイラ（Just In Time compiler）とはインタープリタ方式のプログラム言語のランタイムが実行時に必要に応じて部分的にネイティブコード（CPUが直接実行できるマシン語）に変換することで高速化するというコンパイラである。もともとはもっと狭義のニュアンスだったが、今ではJITコンパイルとHotSpot動的コンパイルを併せて広義にJITコンパイル、それを実施する実態をJITコンパイラと呼んでいる感じだ。*2 ただ、やみく
コンパイラ開発（id:n7shi:20090310）を通して物の見方がどう変わったかについて書いてみます。一般的な見解（と私が認識しているもの）、私の見解（過去・現在）などの視点が入り乱れるため、箇条書きを中心に記述します。何かを主張しようとしているわけではないので、特に結論のようなものはないことを、あらかじめ断っておきます。 【追記】私が作成したコンパイラはSilverlight上で動作確認できます。 ⇒ id:n7shi:20090727 アセンブラ アセンブラをいじることに対する一般的な見解（と私が認識しているもの） コンピュータの動作についてよりよく理解するため。 カリカリにチューニングするため。 これらに対して以下のような意見があります。 CPU内部で更にマイクロコードに分解されるのだから、アセンブリだけ見ていてもパイプラインの動作などは分からないし、不十分 これはその通りなので
インテルが開発している「インテルコンパイラー」は、インテルCPUに最適化された高速なバイナリを生成するということで知られている。そのため、大量の数値計算が必要とされるシミュレーションの分野や3D CGなどの画像処理、科学技術分野などのソフトウェアで多く採用されている。 しかし、「インテルコンパイラーはパフォーマンスが高い」とだけ言われても、なかなかピンと来ない人も多いのではないだろうか。また、一般的なソフトウェアでも性能向上の恩恵に預かれるのかも興味深いところだろう。 そこで本特集では、このインテル コンパイラーでコンパイルされたソフトウェアについてそのパフォーマンスを調査するとともに、インテル コンパイラーでのコンパイルテクニックや、性能解析ツール「インテル VTune パフォーマンス・アナライザー」を使ってパフォーマンスチューニングを行う方法なども解説する。 なお、本特集で紹介している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
