  |
はてなキーワード: ARMとは
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
1か月ほど前まで初代第1世代Core iのPCをほぼノーマルで使っていたが、Windowsの肥大化（*1（本増田の最後に参考webページを記載。以下同様））のせいかweb閲覧やExcel操作程度の作業でも引っかかりを覚えるようになったり、Windows11ブームに煽られてセキュリティ関連の記事を読み古いCPUには脆弱性が付き物だと知った（*2・3・4）り、あれこれあったためPCを新しくすることにした。
その際に色々な知見を得て情報の更新ができたため、日記帳兼リンク集として増田に残しておくことにした。極少数の人にしか役に立たないであろう文章だが、体験談の類として暇つぶしに読んでもらえれば幸い。ただ、過去のPC事情を懐古したりするのが目的なら、数年前にホッテントリ入りした別の記事（*5・6）を読む方が有意義かもしれない。
まず、パーツの買い方を3種類に大別して検討した。
この前段階で格安の中華製ミニPC（*7）も候補に挙げていたが、拡張の厄介さや商品到着までの時間の長さを難に感じて選択肢から外した。
今新しく自作PCを組むなら鉄板の構成だと思う。現在の相場では、M/B 13k円、Celeron 7k円、DIMM2枚組 6k円、SSD 200GB 4k円で約3万円くらいになるだろう（*8・9・10）。構成品のどれかを中古にすれば2万円台前半で抑えることもできそうだ。
しかしながら、最近まで骨董品で我慢できた身には過剰スペックになりそうだという懸念と逆張り志向のせいでRyzen APUに惹かれたためとで、この組合せは除外した。
時機を見極めて個々のパーツを買えれば、安く挙げることができる方法だろう。
だが、動作不良品・リマーク品（*11）・その他の不動品（*12）等を掴むリスクやピン折れ曲り（*13）他機器不良への対処を避けるため、この組合せも選ばなかった。
M/B・CPU・ビープスピーカー・電源があれば動作検証は可能だ（*14）。そのことは前提知識として通用してるだろうと期待し、ジャンクな出品物・者を弾けば少なくとも直ぐに判明するような不良品を掴むことは避けられるだろうと考えて、セット品を軸にパーツ調達することにした。
ただ、個別のパーツだけ欲しいと思う人が多いせいか、希望に叶う出品は少なかった。値段や特定のパーツへのこだわりは捨てて条件をだいぶ緩くしたが、それでも購入作業を終えるには結構な時間がかかった。
作業の結果以下のパーツが手に入った。これら以外にも試用して直ぐ売却したものがあるが、その分は少々の損失で済んだため、実質合計費用は25k円+10k円。
元の電源が10年以上持ったので、5年前の製品なら後5年は使えるだろうと考え、中古で済ませることにした。
参考になるまとめ記事を元に、経年による劣化が小さいと思われる、電圧と電流の波形が綺麗な製品（*15）を候補にした。5年以上前に発売された商品を1年少々しか使っていない状態良好品だと嘯く詐欺師がフリマには跋扈しているが、そういう輩を除外しても選択肢が十分にあるのは幸いだった。プラグイン電源という危険そうな製品（*16）以外に無難な選択肢が無かったのは、老害な増田には難だったが。
余談だが、電動ブロワーは電源の清掃にとても役立った（*17）。騒音が問題にならない環境の人には是非お勧めしたい。
大型のファンを備えた電源ユニットをケース下部に置く組み方が主流になって久しいようだ（*18）が、冷却や静音にこだわる必要が無いのでケースは流用することにした。ただ、電源LEDがそのままでは機能しないので、オス-メスのジャンパワイヤー（デュポンケーブル）をフリマで買ってピンとコネクタをつないだ（*19）。
マザーボードについては色々調べたが、8ピンのATX 12V電源コネクタ（*20）が一般化して久しいことや、フェーズ数の増加（余談だが、I/O電圧とコア電圧が異なるデュアルボルテージは、30年近く前にモバイル版P54Cで初めて採用された）（*21・22）といった電源回りのことで特に知ることが多かった。光物（*23）はあまり興味が無いのでほぼスルーした。
RyzenもIntel Coreもどちらも魅力的だと思った（*24・25）が、結局はAMDで組むことにした。そこそこのGPUを省電力で使えることが大きかった。
メモリは多少勉強した（*26）つもりでパーツ選定に着手したが、チップセットの16Gbitチップ対応事情（*27）を全く把握していなかったため、相性問題にぶつかって最初に購入したパーツセットを買換えることになった。容量について言うと、16GBだとたまに心許なくなるが32GBだと過剰という感がある。Intelなら24GB（8+16の2枚）載せて16GB分をデュアルチャネルモードで使える（*28）ので、その点は良いなとも思う。
SATA SSDでも体感速度は悪くない（*29）という言説を見て、安く手に入ったSSDで十分と判断した。記録方式がTLCかどうかといった商品選択の時に普通ポイントになる点（*30）は、次に買換えたくなった時に気にかけようと思う。
光学ドライブも電源ユニットと同様、本来は5年程度で買換えるべき製品とされている（*31）が、それはそれとして、電源と同様の理由で5年くらい前の中古品を探そうかと思って調べてみたら、M-DISCという規格（*32）があると知った。対応するドライブやメディアを購入すると割高だ、余計に金をかけてまで保存すべきデータはどれだけあるか、そもそも光学メディアの読み書きをする機会はどれだけあるか（*33）等、あれこれ考えた結果光学ドライブは買わないことにした。
最近は無音でPCに向かうことが専らなので、USB-DACを排除してHDMIモニタのイヤホン出力で済ませることにした。気まぐれに音楽を聴きたくなったらヘッドフォンアンプをライン出力につないで使おうと思う。
ケースと一緒に死蔵品を引っ張り出した。文字入力を業としない立場なのでキーボードは何でもどうでも良い。
マウスはクリックが利き辛くなったので放置してたが、分解修理可能（*34・35・36）だと知ったので実例（*37）を参考に簡単に清掃して使えるようにした。マウスホイールは部品交換が必要な状態（ホイールのゴム部分が、加水分解して汚れてたので重曹で洗った（*38）ら、完全に溶けてなくなってしまった）なので、そのうちAliExpressで補修品（MX300適合品ではないが、サイズが同じもの）（*39）を購入しようと思う。
初めは旧システムの入ったHDDを新しいM/Bにつないで使っていた。後で中身をSSDにクローンしようと考えたが、安物のSSDゆえガンガン書き込むことを必要以上に避けなくても良いなと思い直したので、結局新規インストールすることにした。
Raven RidgeではWindows11にアップグレードできない（*40）。だが、Windows11ではGPUが重くなりその対策が未だ無いよう（*41）なので、Windows10のままで良いということにした。
Windows7の頃はUEFIで起動しないPCがまだ一般的（*42）だった。このHDDもそういうPCに接続されてたのでフォーマットはMBRだった。CSMを有効にすればそのままで起動できるが、そうできるのは古いGPUを使っている時で現行のiGPUではたいてい無効にされる（*43・44）。CSMは頼りにせずGPTに変換して使うのが無難だ。
変換の際はWindows10のUSB起動メディアでmbr2gptを使ったが、ReAgent.xmlの更新に失敗したというエラーメッセージが出たので、回復パーテーションを弄って（「コンピュータの管理」ではドライブレターを付与できないのでdiskpartを使った）修正した（*45・46）。
Microsoftアカウントで常用していたためかライセンスの再認証を求められることも無く、上記の問題を除けばほぼすんなりと使用できた。セクターにアライメントのずれが無いかどうか（*47）も調べたが、問題無かった。
VMWare上で予行した分も含めて何回もした。セットアップを繰り返した理由は、Administratorを有効にしパスワードを設定しないままメインアカウントを標準ユーザーにしたらAdministratorにログインできなくなって（*48）詰んだり、OneDriveの動作選択画面で「このPCにのみファイルを保存する」を選択せず「次へ」移動したら戻れなくなった（ドキュメントやピクチャ等のフォルダパスをOneDriveに指定した後で、再度ローカルストレージに変更するのは割と手間になる）（*49・50）り、システムファイルを移動させようとして次節で説明するようにシステムを破壊したりしたためだ。
SSDの容量節約と書込み抑制のため、ページ、スワップ、ハイバネーションの各ファイル・OneDriveフォルダ（ただし、空フォルダにマウントしたドライブは移動先に指定できない）・ユーザプロファイルフォルダ下のドキュメント等のフォルダ・AppDataフォルダ下のRoamingフォルダとLocalフォルダの一部・テンポラリフォルダ・ストアアプリフォルダを移動（*51・52・53・54）した。Superfetchはデフォルトで良しとした（*55）。
かつては別アカウントでログインしてプロファイルフォルダを全部移動しジャンクションを貼って使うこともできたが、Windows10のあるバージョン以降でそれをするとスタートメニュー他ショートカットやストアアプリが即死する（*56）。一部のシステムファイルが変化するとメニューやアプリ全体が損壊判定されるようだ（十分な検証はしてないが、container.datやハッシュ値が名前になってるファイルを弄ると不味いように感じた）（*57）。こうなるとアカウントを消して再作成する他無くなる。ちなみにCドライブ直下のProgramDataフォルダ等を壊すともっと悲惨で、新規インストールくらいしか回復の手立てが無かった。
https://b.hatena.ne.jp/entry/1 または https://b.hatena.ne.jp/entry?eid=2（それぞれ、数字部分がeid）のような形式のurlを入力すれば、当該ブックマークエントリーにアクセスできる。
| *1 | Windows 10はバージョンアップを重ねるたびに本当に遅くなっているのか？検証結果はこんな感じ - GIGAZINE | https://gigazine.net/news/20210622-windows-10-version-slow-down/ | 4704430589992224258 |
| *2 | Googleが発見した「CPUの脆弱性」とは何なのか。ゲーマーに捧ぐ「正しく恐れる」その方法まとめ | https://www.4gamer.net/games/999/G999902/20180105085/ | 373991174 |
| *3 | AMDのプロセッサに脆弱性、セキュリティ企業が情報公開--懐疑的な見方も - CNET Japan | https://japan.cnet.com/article/35116106/ | 360332677 |
| *4 | インテルとARMのCPUに脆弱性「Spectre-v2」の悪夢再び、新たな攻撃手法 | TECH+ | https://news.mynavi.jp/techplus/article/20220312-2290634/ | 4716634065497432514 |
| *5 | 「Sandy Bridgeおじさん」とは何か？ : 因画応報 | http://ingaoho.ldblog.jp/archives/4916067.html | 362560793 |
| *6 | ありがとう鼻毛鯖 8年使った鼻毛鯖をついに買い替えました | 日本霜降社 | https://nihonsoukou.com/20181123/1827 | 4665750545042615426 |
| *7 | 2万円の超格安パソコン「GREEN G2」値下げ、高性能CPUに大容量メモリやSSD採用で仕事でもプライベートでも大活躍 | Buzzap！ | https://buzzap.jp/news/20220318-trigkey-green-g2-ultra-low-price-pc-happy-price-down-3/ | 4716943171239004674 |
| *8 | 第12世代インテル Core プロセッサー 特集 | パソコンSHOPアーク（ark） | https://www.ark-pc.co.jp/special/intel-12th-gen-core-series/ | - |
| *9 | 8GBモジュール | 2枚組 | DDR4 DIMM (288pin) | デスクトップ用 | 通販・価格/性能比較一覧 | 価格の安い順 | パソコンSHOPアーク（ark） | https://www.ark-pc.co.jp/search/?col=3&order=&p1=b21010&p2=c21050&p5=s21010&p6=w11726 | - |
| *10 | 〜256GB | M.2 | SSD | 通販・価格/性能比較一覧 | 価格の安い順 | パソコンSHOPアーク（ark） | https://www.ark-pc.co.jp/search/?col=3&order=&p1=b32020&p2=c32024&p5=s32220 | - |
| *11 | 【やじうまPC Watch】中国でIntel CPUの偽造品出回る。公式が注意を呼びかけ - PC Watch | https://pc.watch.impress.co.jp/docs/news/yajiuma/1248215.html | 4684567815854719490 |
| *12 | Lenovoに搭載されているAMD CPUにベンダーロックが設定されているせいで中古市場が混乱している - GIGAZINE | https://gigazine.net/news/20220118-lenovo-vendor-lock-amd-cpu/ | 4714151541045747810 |
| *13 | ASCII.jp：冗談ではなく目の前が真っ暗になる恐怖……ピンを曲げてしまったRyzen 9 5950Xの修復を試みる (1/3) | https://ascii.jp/elem/000/004/053/4053723/ | 4703873313928579106 |
| *14 | パソコンが起動しない場合の確認方法｜テックウインド株式会社 | https://www.tekwind.co.jp/ASU/faq/entry_31.php | 4666842797243724258 |
| *15 | 【自作PC】電源ユニットの選び方を自作経験者がガチ解説する | ちもろぐ | https://chimolog.co/bto-choose-psu/ | 367187040 |
| *16 | 何故プラグイン式PC電源ユニットのコネクタは規格統一されていないのか？ - Togetter | https://togetter.com/li/1564076 | 4688976497965880706 |
| *17 | ブロワーの選び方 | DIY工具紹介部 | https://diytool.biz/blois | 170335990 |
| *18 | “冷却の常識”を徹底検証 - AKIBA PC Hotline! | https://akiba-pc.watch.impress.co.jp/docs/dosv/662237.html | 364049132 |
| *19 | PCケースのPower LEDケーブルを3ピンから2ピンに変換した | TeraDas | https://www.teradas.net/archives/16603/ | 4705898232067265346 |
| *20 | 20ピン ATX 電源は 24ピンのマザーボードに使えるのか – 分かりにくい ASUS マニュアルと ATX 電源の規格 | Nire.Com | https://www.nire.com/2009/10/atx-24pin-motherboard-vs-20pin-power/ | 75424033 |
容量超過のため、anond:20220419200228 に続く。追記もあり。
alder lakeは見た目凄いけど実際は中途半端じゃね
省電力コアのワッパってM1超えてるんだっけ？
超えてなかったら結局ラップトップはM1が良いよね、ってなるしクアルコムとマイクロソフトがM1みたいな良い感じのWindows用ARM CPU作っちゃったらalder lakeの省電力コアの優位性ゼロになるし
高負荷のとき性能は現状Ryzenに勝ってるけど相変わらずの爆熱
Ryzenに現状勝ってるけど次どうなるかわからないし、ワッパじゃ勝てないだろうからデスクトップではどうでもいい低負荷時の効率がRyzenより良いだけのCPUになる可能性がある
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にも気をつけて貰いたいところです。
