はてなキーワード: ARMとは
Scala や Elm と Lisp やら Haskell と OCaml に SML と関数型のプログラミング言語を勉強したけど、これらが命令型言語に劣る理由を解説しよう。
これは、SQL も同じ問題を持っているが、関数型言語は「こういうふうに動いてね」という解釈をインタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときにパフォーマンスをプログラマーが想像できない。
それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数型言語のための独自コンパイラを作る持続可能な組織が無い。確かに、LLVM を使えば x64 や arm といった最新のアーキテクチャに対応できるかもしれないけど、フロントエンドのレベルすら応対が辛い。よって、関数型言語は C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである。
例えば if と書いたら、関数型言語は else が必須ですが、命令型言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか?違うだろ。毎回、上に else のことについて聞いたら、プログラマーの生産性は下がるだろ。関数型言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから、生産性は命令型言語に劣るよ。
ソフトバンクがArmの親会社になっているときに、デザインセンターを国内に作ってエンジニア育成しておけばよかったな。
ファブレス会社はプロセス全く知らないで作れるかというと、性能をギリギリまで出すのは作れない。
IP買ってきて取り敢えず半導体作れるようになればいいのだろうか。
富士通も富嶽のCPUフルスクラッチで作ってないし、ノウハウ持っているところからの展開も難しそう。
設計ツール(EDA)を買ってきて、IP買ってきて、取り敢えずつなげれば、それっぽいのは作れるのだろうけど。
規格の仕様書、ツールの説明書、どれもこれも数百ページのドキュメントが複数あって、理解するのも大変なんだよね。
あと書籍がなさすぎる。
現状ではそう捉えてもらって構いません。
しかしながら開発環境のAndroid StudioはARMアーキテクチャー向け以外にもx86(x86_64)アーキテクチャー向けにもコンパイル&ビルドが可能です。
ゲームなど高度なグラフィックス機能を用いた場合に問題となるのはARMアーキテクチャー固有の機能へ強く依存する設計を行っているアプリですね。
ARMの機能へ強く依存しないように心がけて高度なグラフィックスを実現するとx86アーキテクチャーでも軽快なアプリは実装できます。
Chrome OSデバイスはAndroidスマートフォンと比較して大画面であることが多く、ゲームの需要も比較的高いことが予測されます。
広いプラットフォームへ配信することを考えてもアーキテクチャー固有の機能へ依存しすぎることは開発にとって技術的負債になりかねないので広範な実装をしたほうが良いでしょう。
このあたりは3Dゲームの開発環境ではデファクトスタンダード化しているUnityにも気をつけて貰いたいところです。