次期OpenGLとして予告されていたVulkanがGDC2015でついに発表されました。
噂されていたようにMantle, DirectX12と似た現代のGPUにあわせたCPUオーバーヘッドの小さい薄いAPIとなるのは予想通りだったのですが、プログラミング言語環境と実行フレームワークに少し度肝を抜かれました。
その肝はVulkanと同時に発表されたSPIR-Vです。
VulkanでもGPUでのプログラム実行には従来からのシェーダー言語であるGLSLの拡張版がつかわれますが、今回からは事前コンパイルしてバイナリ中間コード化して使えます。
このバイナリ中間コードにつかわれるのがSPIR-Vです。
実態はLLVM-IRの拡張型ですが、
LLVMと同じようにフロントエンド言語に様々なものが選べます。
GLSLシェーダー言語以外にもやはり時同じくして発表されたOpenCL2.1などにも対応しています。
SPIR-VのようなGPU実行フレームワークが策定されたことで今後GPGPUの普及が促進されることに超期待しています。
世界的な家電展示会CES2015でパナソニックだ次世代Blu-rayの「Ultra HD Blu-ray」プレイヤーを参考出品しました。
解像度をこれまでの2Kから4Kまで高精細になりHDRでダイナミックレンジも広がり益々きれいになるようです。
ディスクの記憶容量を50GBから100GBに高めることでこれを実現しています。
むむっ!? 記憶容量が2倍になったって収まり切らないでしょ?だって映像は2次元だから2Kから4Kになったら帯域4倍使うでしょ! と気づいた方は鋭い。
映像コーデックにこれまでの2倍の効率のH.265 HEVCも使っているのです。
HD映像コーデックの歴史を見てみるとMPEG2に始まり2倍の効率のH.264、さらに2倍のH.265と進化を続けています。
H.264ができた当初は詰め込めるだけのアルゴリズムは詰め込んだ！もうこれ以上は無い！とまで言われていましたがそこからさらに２倍の効率を実現したとは驚きの限りです。きっとさらに複雑高度なアルゴリズムが追加されたのでしょう。(関係者曰わく単純にマクロブロックを大きくしたのが一番効いたという話はここだけの秘密です。)
ここまですごい映像技術が将来には地上波で皆さんのお宅に放送されるなんていう噂もありますが、(今の地上波はMPEG2の2Kだから、H.265使えば4K突っ込めちゃうね。おおっぅ。)
どうせなら地上波放送を画質そのままH.265にかえて使う電波帯域を4分の1に圧縮し、余った電波を携帯とかに回したほうがみんなしあわせになれるんじゃないかと...
Windows10が公式に発表されました。
色々な機能満載のようですがには下記の二つの機能に注目です。
●大型テレビからスマホまで同じOSで対応
Windows10では端末の画面サイズ、種別(PCやタブレットなど)によって異なるユーザーインターフェースを表示するようです。
これによって上は84型の超大型テレビから、下はスマホまで、一つのOSで対応ができるわけです。
世の中に1OSでここまで対応したものはまだなおので結構大変なことですね。
今までマイクロソフトはWindow for tablet, Windows Phone, Windows Media Centerなど端末毎別々のエディションを出してきて鬱陶しい上に互換性も微妙とういイケていない状況でしたが改善されそうです。
Windows7, 8からの無償アップグレードも期間限定ですが行われるようでエンドユーザーとしては最新機能を使えてメリットも大きいです。
マイクロソフトとしても古いOSのメンテナンスコストを下げて新しい機能やサービスに注力できるメリットがありそうです。
最近、開発ツールのVisual Studioも個人向けに無償提供始めてエディションを統一したり、Internet Explorerも最新版のみサポートにしたりと、ナデルCEOになってからのマイクロソフトは価値を産む新機能、新サービスに注力したい傾向がありそうです。
(AppleやGoogleなどの競合がいなければ、古い製品のサポートで大きな収益を上げていたのでしょうが。)
●3Dメガネ「HoloLens」
こういうモノはなかなかヒットしないけどドンドンやってほしいです。マイクロソフトが出した意義は大きい。業務用の特定分野ではイケるのでは。
クアルコムの次期64bit CPUであるSnapdragon 820の情報がリークされたようです。
主な仕様は64bitオクタコアTS2コア。謎だらけのCPUコアですが、
弟分Snapdragon 815のコアがTS1iとTS1のbig.LITTLE構成なのが、TS2コアはそれだけでオクタコアを構成している模様。bigコアだけの8コアなのかも。クアルコムは32bitの独自コアKraitの頃はARMのbig.LITTLEコアを設計が悪いとさんざんバカにしていたので、64bitコア2代目のTS2で低消費電力低クロックのbigオンリー構成に目処がついたのかもしれないです。
GPUもAdreno530とこれまた謎だらけのチップですが時期的には大改造が予定されているOpenGL5.0に対応してほしいところ。競合のNvidiaがTegra X1で頑張ってきているのでこっちも頑張れ。
さてベースバンドの性能ですが、LTE-Aカテゴリー10対応MAX450Mbpsともはやなんだかわからんくらい高速になっています。月々3GBの通信プランなら1分かからず使い切れますよ！（理論値はいいから実効速度を速くしてくれキャリア様。）
このチップを載せたスマホがでる来年の今頃にはみんななかよくVoLTEでお話できたらいいな。(現実的なオチはこのくらいかと。)
Googleが開発を進めている言語 Dart が気になります。
javascriptの欠点を解決したうえに、サーバーでもクライアントでも使え性能も良かったりする、いわゆるjavascript代替言語altJSの一派です。
altJSといえば Typescript, CoffeeScript などがありますが、Dartが個人的に素敵だと思うところは、
・コンパイル無しに直接VM上で実行できる
・言語だけでなく開発環境もしっかりしている
・言語仕様がモダンな感じ
javascriptのエグい言語仕様(class風に書くのも自由すぎて一苦労、thisがコロコロ変わる、変数スコープが関数、等々々)から解放される。
・性能も良さそう。Isolateでスレッド分離してるから、並列化のボトルネックになるGIL(Global Interpreter Lock)もきっと無いに違いない。
です。
気になってインストールしてちょっと使ってみた感想は
・DartEditorのコード補完の気持ち良さや型付き言語風の守られている感は、今までの動的言語とは次元が違う感じです。統合開発環境もいい感じ。
・promise(コールバック地獄回避)とかarrow function(=>)もあたりまえに使えるのでスッキリ書けそう。
・javaやjavascriptと構文が似てるので案外スルスルっと書けそう。
・サーバー/クライアントどちらでも使える書き方はヤッパリ難しそう。サーバー側からはDOM (dart:html)をなかなか触れないとか、クライアント側からファイルIO(dart:io)触れないとか、クロスドメインアクセス制限はやっぱりあるとか、当たり前と言えば当たり前の制限なんだけど思ってたんと違う感が...
・ライブラリアーカイブ(pub)の品揃えがやっぱりまだまだ。
総評としては、期待の超大型新人、仕事はこなすし、実績積んで人脈広げたら将来天下取るかもよ？ という感じです。
現時点で勝ってに比較するなら、
node.js > Dart
かと。
頑張れDart応援してるぞ！(=普及したらちゃんと使ってみようかな)
linux 3.16が7回のリリース候補を経て公開されました。(言ってる間にlinux 3.17-rc1も公開されちゃいましたが...)
前回のlinux 3.15も凄まじい量の更新がありましたが、今回の3.16の目玉はarm 64bit対応の更新でしょう。
まもなく公開されるllvm/clang 3.5ではappleが寄贈したarm64コードが取り込まれ、
今秋の次期android "L"に置いてもarm64対応が謳われています。
モバイルの64bit CPU普及の準備が整ったといえるでしょう。
ところでandroidのlinux kernelはNexusシリーズのandroid Lでも3.4.0と本流からするとかなり古いものを使っています。
android kernelは標準のlinux kernelから省電力やプロセス権限など随分変更点があるようですが、arm64対応を考えると最新のlinuxに追従しておきたいところなおではないでしょうか？
android kernelの対応版はLSIチップベンダー主導で進められることが多く、
linuxのarm対応進めているlinaroではlinux3.16-rc6ベースのandroid kernelが公開されています。
Linaro Release
http://releases.linaro.org/14.07/components/kernel/linux-linaro
とはいえ、まだ安定版とはいえない状況のようなので、今秋発表されるといわれている初の64bit arm端末Nexus9ではどうなっているかが気になります。
(Nivdiaが泣きながら64bit Denver対応を頑張っているのでしょうが...)
8/25のllvm3.5リリースといい、今秋にむけてarm64の動向は目が離せません。
fourth tier llvm(FTL)なるものが開発中らしい。
chromeブラウザのV8 みたいにjavascriptを高速化する技術なんですが、これがappleのSafariに載るらしい。
safariもnitroとかいうjavascriptエンジンで既にかなり高速化しているんですが、FTLの何がスゴいってllvmでjavascriptをコンパイルしちゃうらしいんですよ！
ここまで聞いて詳しい方なら、「ああ、あれね、 llvmとjavascriptね。ecmascriptenとかasm.jsでやってるやつね。」といわれるかもしれませんが、
違う！違うんです！
ecmascriptenはC言語からjavascriptに変換。
FTLはjavascriptからネイティブコードに変換。
なんです！
XXX言語(のllvm中間言語)からネイティブコードに変換はllvm様のバックエンドの力を持ってすれば造作もないことなのはわかりますが、javascriptのような型の無い いい加減な、否、柔軟な動的言語をllvm中間言語の変換するとは！！フロントエンドで一体どんな革命が起きたのか！
答えはこちら！
FTL: WebKit's LLVM based JIT
...難しくてわからんがな。易しく教えて偉い人。
なんにしてもllvmプロジェクトにとっても動的言語への対応は挑戦的なことみたいですね。
カリカリに高速化されている現状からさらにこんな高速化って凄まじいなぁおい。
今秋リリースのiOS8にも載るとか載らないとか。早～く来い来いiPhone6～♪
