「x86」を含む日記 RSS

はてなキーワード: x86とは

2021-05-22

anond:20210522215910

現状ではそう捉えてもらって構いません。

しかしながら開発環境Android StudioARMアーキテクチャー向け以外にもx86(x86_64)アーキテクチャー向けにもコンパイルビルド可能です。

ゲームなど高度なグラフィックス機能を用いた場合問題となるのはARMアーキテクチャー固有の機能へ強く依存する設計を行っているアプリですね。
ARM機能へ強く依存しないように心がけて高度なグラフィックスを実現するとx86アーキテクチャーでも軽快なアプリ実装できます

Chrome OSデバイスAndroidスマートフォン比較して大画面であることが多く、ゲーム需要比較的高いことが予測されます
広いプラットフォーム配信することを考えてもアーキテクチャー固有の機能依存しすぎることは開発にとって技術負債になりかねないので広範な実装をしたほうが良いでしょう。

このあたりは3Dゲームの開発環境ではデファクトスタンダード化しているUnityにも気をつけて貰いたいところです。

突然、解説されるChromeOS環境構築

はじめに

エントリはある程度の情報技術リテラシー必須であり、一部の情報PC初心者および初級者に推奨できるものではない。
しかPC初心者および初級者はシステムを壊す、大事データを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報活用する場合システムを壊す、大事データを失うことを覚悟して実行するように

教訓「大事データバックアップ重要である

初期セットアップ

チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。

開発者向けの注意点

Chrome OSは初期状態デフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています
ノーマルモードChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。

しかノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムユーザー領域へ追加された情報はすべて削除されます
もしデベロッパーモード必要場合デベロッパーモードの詳細を調べ、現在情報は削除されてしまうことを念頭に実行しましょう。

ちなみにProject CrostiniのLinuxレイヤーDebianリポジトリからパッケージを導入するなどにはデベロッパーモード必要ありませんので多くの場合ノーマルモードのままの運用で十分でしょう。
Android OSアプリChrome OSアプリを開発したい場合最初からデベロッパーモードにしたほうが後悔が少ないです。

キーボードショートカットの一覧を表示する

Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカット確認できることだけは覚えておきましょう。

Google Play Store

多くの場合アプリ開発者意図していない

多くのChrome OSデバイスGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OS最適化しているのか?と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトChrome OSでの実行を許可していることもあり開発者意図せずChrome OSインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリ動作へ何らかの不具合があったとしても脊髄反射酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者情報共有することをオススメします。

CPUアーキテクチャーの違い

多くのAndroidスマートフォンタブレットARMアーキテクチャーと呼ばれるもの採用していますが、現在Chrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります
本来コンピューターアプリケーションというものアーキテクチャーが異なると実行起動動作不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリx86アーキテクチャーなデバイスで実行するとアプリ動作パフォーマンスが著しく落ることが多いです。

これは高度なグラフィックス機能必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。

高性能なChrome OSデバイスしかインストール許可していないアプリ存在する

コロナ禍によって多くのChrome OSデバイス販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリ自身Chrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者デバイス性能によってインストール許可許可を決めているために起こることで解決方法基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。

ただし、Google提供するアプリなどは基本的にそのようなことは無いようです。

Project Crostini Linuxレイヤー

Linuxを利用する

設定からLinuxベータ版)」で「オンにする」とLinuxインストールが開始されます

Crostini GPU Support

現在Chrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力アクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作不具合確認した際は設定を元に戻してください。

GUIパッケージマネージャーを導入する

LinuxにもGoogle Play Storeのような簡単Linuxアプリを導入できる環境存在します。
GUIパッケージマネージャーを導入する場合「ターミナル」を起動し下記を実行してください。

sudo apt install synaptic gnome-software

パッケージダウンロードを速くする

Chrome OSLinuxレイヤーではパッケージの導入先がデフォルト海外サーバーになっており少々遅いです。
日本国内サーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。

  1. sudo apt edit-sources
  2. 下記を最上段へ追記
    deb http://ftp.jp.debian.org/debian/ stretch main contrib non-free
    deb http://ftp.jp.debian.org/debian/ stretch-updates main contrib
    deb http://ftp.jp.debian.org/debian/ stretch-backports main contrib non-free
    deb-src http://ftp.jp.debian.org/debian/ stretch main contrib non-free
    deb-src http://ftp.jp.debian.org/debian/ stretch-updates main contrib
    deb-src http://ftp.jp.debian.org/debian/ stretch-backports main contrib non-free
  3. sudo apt-get update && sudo apt-get dist-upgrade
日本語入力Chrome OSLinuxレイヤーで共有できない

現在Chrome OS v90ではChrome OSLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッド日本語フォント必要です。
日本語インプットメソッド日本語フォントを導入する場合「ターミナル」を起動し下記を実行してください。

  1. sudo apt install fonts-ipafont fonts-ipaexfont fonts-takao fonts-takao-gothic fonts-takao-mincho fonts-noto-cjk fonts-noto-cjk-extra
  2. sudo apt install fcitx-mozc
  3. export XMODIFIERS=@im=fcitx
  4. fcitx-autostart
  5. fcitx-configtool
    1. 左下+をクリック
    2. Only Show Input Languageのチェックを外す
    3. Search Input Methodからmozc検索
    4. mozc選択してOK
    5. 下部の∧でmozcを上位にする
      1. sudo nano /etc/systemd/user/cros-garcon.service.d/cros-garcon-override.conf
      2. 下記を追記
        Environment="GTK_IM_MODULE=fcitx"
        Environment="QT_IM_MODULE=fcitx"
        Environment="XMODIFIERS=@im=fcitx"
        Environment="GDK_BACKEND=x11"
  6. 再起動

Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージDebian公式リポジトリ存在しない可能性があるのでご注意ください。

Chrome OSLinuxレイヤーディスクを共有する/マイクを共有する

設定→デベロッパーLinux開発環境

Linuxレイヤー仮想環境構築は推奨できない

KVMLXCDockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤー再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています
Project CrostiniのLinuxレイヤー自体仮想環境のため、Chrome OSシステム破壊されるわけではないですが業務利用時にLinuxレイヤーシステム破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。

ただし、Chrome OSデバイス実質的Android OSデバイスタッチスクリーンデバイスキーボード付きデバイスタブレットデバイスノートPCデバイスコンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイスウィンドウ可変デバイスタッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグデバイスとしては非常に価値があります
昨今はアスペクト比16:9でないどころかリアルタイムに可変してしまデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます
さらに言えばティーン層はGIGAスクール構想によりChrome OSプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます

長くなってしまいましたが、質問があれば気付いたときに随時回答したいと思います

2021-01-10

Business Journalの「サクラ革命記事が酷すぎるので俺がレビュー書く

セガサクラ革命』爆死&大炎上の“納得の理由”?開発費30億円超、売上7千万円か

https://biz-journal.jp/2021/01/post_200847.html

いやはやまったく、はてブにあがってたので読んでしまったが、久々にあまりにも酷いレビューを読んでしまった。あぁそうそ引用している記事にはアクセスしなくても良い。時間トラフィックリソース無駄だ。

記名は編集部となっているが、Business Journal編集部員の質はこの程度なのか?まるで私たち編集部Web検索すらしないで又聞きした情報記事にしています宣言したいがために記事を公開したのかと邪推したくなる。

1つの記事へ膨大な時間を掛けて執筆することは生産性考慮すると悪手であるのは間違いない。しかし、いくらなんでも"ほど"があるだろうと言わざる得ないのだ。

当該記事の質が低い点の指摘

下記の理由からBusiness Journal編集部は当該記事編集部員へ二度とゲーム記事は書かせないほうが良いと"ご意見"をよせさせて頂く。

太正100年への非難と新主要エネルギーへの非難整合性の無さ

当該記事では太正100年が既存サクラ大戦シリーズとの歴史的連続性の無さを指摘しつつ、蒸気エネルギー排除され主要エネルギー採用されたことへ対して非難の声がよせられていると書いている。

しかし、太正100年は西暦で言えば2011年である。半世紀以上の時間が経過していながらサクラ大戦シリーズはいまだ蒸気エネルギー依存し続けなければならないと本気で思っているのだろうか?

そして、歴史的連続性の無さを指摘しているが現在公開されているサクラ革命シナリオは、チュートリアル九州編と中国編(そして九州舞台としたサイドシナリオ特別イベント)のみだ。

サクラ革命47都道府県舞台としようとしているのは現状で明確にわかる。つまり素直に受け止めれば45シナリオが残されている。全体のシナリオ進捗は約4.25%であり、この状況ではサクラ革命サクラ大戦シリーズでどういう立ち位置なのかほぼわかっていないとWeb検索するまでもなく察することが出来るので、なぜこれを"爆死&大炎上"の理由としたのか本気で謎である

サクラ革命を現状で物凄くやり込んでいるプレイヤーすら何もわかっていないのに、何をわかったつもりで居るのか。

サクラ大戦シリーズスチームパンク世界観が支持されていたという誤解

サクラ大戦シリーズにおいて蒸気エネルギーは主要エネルギーとして確かに重要であり、サクラ大戦シリーズを彩るスパイスとして無くてはならない存在であるのは間違いない。

しかし、サクラ大戦シリーズにおいてスチームパンクスパイスであってメインの素材ではなく、あたかサクラ大戦シリーズスチームパンクからこそ支持されていたかのように描くのは誤解である

サクラ大戦シリーズファンへはわざわざ説明するまでも無い話だが、申し訳ないけれども知らない読者のためにも付き合って頂きたい。

端的にかつ簡潔に述べるならば、サクラ大戦シリーズは「アイドルマスターシリーズのご先祖である

サクラ大戦シリーズ宝塚歌劇団パロディした作品であり、その痕跡キャラクター名や帝国華撃団など各名称に現れており、歌って踊り、企画段階で強くメディアミックス意識され、当時の声業界すら巻き込んで現在にもその影響を残しているターニングポイントだった作品だ。

霊子甲冑デザインを著名なメカデザイナーが手がけているなど日本SFとして決して軽視できるものではないが、宝塚歌劇団パロディとしてゲームに落とし込んだという要素に比べればスチームパンク要素は些細と言って過言ではない。

から「戦うアイマスアイドルマスター XENOGLOSSIAかよ」と一部のユーザがそう感じてしまうのも仕方ない。ご先祖なのだから

ついでに誤解なきよう言及しておくと、蒸気エネルギー要素はディスコンされていない。当該記事の書き方では蒸気エネルギーディスコンされてしまったものと誤解する読者が出てきそうなので。

主題コンテンツ貶めるため他のコンテンツを持ってくるという禁じ手

これにはサクラ革命プレイヤープロジェクトセカイプレイヤーの双方が怒って良い。というか既に怒っているだろう。

どういう神経でプロジェクトセカイを持ってきたのか呆れて果ててしまう。

現代サブカルシーンでは主題コンテンツ貶めるため他のコンテンツを持ってくるのは禁じ手とする傾向が強くなってきているのを読み取れていないのか。

作品Aはカワイイ作品Bもカワイイ。どっちもカワイイ。どちらがカワイイのではないどちらもカワイイ

これが現代サブカルシーンであり、当該記事の書き方はまるで10年前のゲームハード戦争真っ直中の素人レビューのようだ。

他のコンテンツ貶める暇が在るなら推しコンテンツ布教しろ

サクラ革命非難される真の理由

Business Journalとかいう質が低すぎる文字同人サイトの誤りを指摘したので、次は実際にサクラ革命プレイヤーである筆者がサクラ革命非難される理由を書こう。

繰り返されるお涙頂戴シナリオ

ネタバレになるので詳細は控えるが、サクラ革命現在配信されている3つのメインシナリオであるチュートリアル九州編、中国編すべてでお涙頂戴が展開される。

しかもお涙頂戴の起因が3つとも同じだと言って良い。どれだけライターはこのシチュエーションが好きなのか。流石に3連続、というか配信されているすべてのメインシナリオがコレなのはおかしいだろう。

この繰り返される同じお涙頂戴シチュエーションについてはTwitterちょっと検索するだけで出てくるので当該記事を書いたBusiness Journal編集部員はおそらくWeb検索すらしてないと思われる。

Twitterユーザーの100文字に満たないツイート、例えば「お涙頂戴繰り返すからサクラ革命シナリオ微妙」みたいなレビューよりも質が低い上に、あれだけの文字なのだから執筆時間Twitterユーザーのツイートより掛けているだろうから生産性まで低い。圧倒的な質の低さである。お前Twitterユーザー以下だぞと。

ほぼ確定で決まる執拗な弱体化補正

サクラ革命戦闘シーンで敵ユニットが毎ターンほぼ確定で自ユニットへ弱体化補正(いわゆるデバフ)を決めてくる。

まり、敵ユニットが自ユニットへ対して攻撃力や防御力、必殺技ゲージの低下を(自ユニットが弱体化耐性を持っていない限り)毎ターンほぼ確定で決めてくるのだ。

ディライトワークスが開発するスマートデバイス向けの別ゲームタイトルFate/Grand Order」のプレイヤーならば慣れているゲーム設計と言えるが、ディライトワークス製ゲームを初プレイするプレイヤーに取っては不快ゲーム設計だろう。

サクラ革命スマートデバイス向けRPGありがちな、いわゆる「育成周回」が必須ゲーム設計となっている。

そしてサクラ革命には攻略ステージ毎へ親切にも自ユニットの適正レベル記載されているのだが、どうやらこれは自ユニット攻略ステージ開始時の初期ステータス基準にしているらしく、適正レベルへ至っていてもターンが進む毎に敵ユニットから弱体化補正をかけられ続けると攻略が困難になってくるのだ。

当然、非常に高度な立ち回りをすると苦戦しつつも結果的勝利を収められるが、忘れてはならないのがサクラ革命は「育成周回」が必須ゲーム設計なのである

「育成周回」しなければならないのにターンを膨大に重ねるのは非効率なので、ここに矛盾が生じて慣れていないプレイヤーストレスを感じてしまう。

Fate/Grand Orderプレイヤーはこのゲーム設計に慣れているので即座に「最短ターンで編成を組むのがサクラ革命の最適解」と察して行動を取れたが、ディライトワークス製ゲームを初プレイしたプレイヤーはより一層のストレスを抱えているだろう。

"お家芸"バグ

これは完全にディライトワークス製ゲームプレイヤー間の内輪ネタだが、ディライトワークス製ゲームにとってバグは"お家芸"である。何も笑えないが、ネタにして笑い飛ばすくらいの胆力がないとディライトワークスには付き合っていられない。

Fate/Grand Order」でもローンチ直後から様々なバグがあり、その伝統は本作にも引き継がれ、大いにプレイヤーを笑わせてくれている。・・・その笑いは失笑かも知れないが。

筆者が笑ってしまったのはローンチ初日サクラ革命アプリ初回起動後に追加データダウンロードというゲームアプリにはありがちな仕様(初回起動時に追加データダウンロードが発生するのは各アプリストアの仕様上の制限である)で、ダウンロードプログレスバーが表示されている間に、登場キャラクターの簡易プロフィールが読めるという演出になっていた。ダウンロード中にプレイヤーが飽きてしまわないよう配慮された仕様だ。

しかし、この簡易プロフィールデータがどうやら初回起動後の追加データに含まれていたらしく、1人目以降まったく簡易プロフィールが読めないというバグがあった(現在修正済み)。ゲームプレイする前からわかりやすバグ発見できる。これがディライトワークス。

サクラ革命を実際にコーディングしている開発者からすると変な汗が出る初歩的なバグであるのは筆者も情報技術者の末席に連ねる者としてお察し出来るので心身痛み入る、まぁそういうこともあるさという言葉を送りたい。

こうやってディライトワークス製ゲームプレイヤーが開発元ディライトワークスをイジるのが内輪ネタというわけである

ちょっと戦略性上げましたというバトルシステム

Fate/Grand Order」のバトルシステムは登場当初スマートデバイスでもバトルっぽいことができると示した素敵なエコシステムだが、サクラ革命のバトルシステムはそのエコシステムエコさ加減を最大限に活かしつつ、ちょっと戦略性を上げましたというバトルシステムである

サクラ革命という新しいゲーム開発へ関わったのだから「もうちょっとなんかあったやろ」というツッコミが方々から聞こえてくるが筆者としては1周回って「ディライトワークスだしコレで良いんじゃね?」と思えてきている。

詳細なバトルシステムが気になる人はYoutubeか何かで観たほうが早いだろうし割愛する。所詮ポチポチゲーですよ。

期待させておいて観せない歌劇シーン

筆者としては歌劇シーンを観ることができると思ってサクラ革命インストール事前予約してまで期待して待っていた(ディライトワークスなのでバトルシステムは鼻から期待してない)のだが・・・観れないんだなぁ・・・(遠い目)。

いやコチラが勝手に期待したのが悪いっちゃ悪いんだが、3DCGでやるって言うんだもんアイドルマスターみたいな歌劇シーンを期待しちゃうじゃないですか。もしかしたら初代サクラ大戦のメンバーとかもスペシャルゲストとして動いてる様子が観られるとか思っちゃうじゃないですか。

このあたりが怨嗟を生んでる気がするんですけど、ディライトワークスさん1周年イベントで良いんで歌劇シーンやりましょうや。

サクラ革命評価できる点

悪いところばかり挙げるのもアレですし、とりあえずプレイせず様子見している"司令"も居るでしょうから良い点も挙げておく。

何だかんだで立ち絵が動くって良いよね

初代サクラ大戦のイメージを引っ張っている司令からすると違和感が物凄いけれども、慣れてくるとこれはこれで良いものなのではないかと思えてくる。

ただモーションは固定なので高く期待するほどでも無い。

ガチャで思いのほか当たる☆5キャラ

サクラ革命ではガチャゲーで、アイテムや装備も一緒に排出されるいわゆる"闇鍋ガチャ"であるが、☆5キャラ排出率が恒常ピックアップ☆5キャラが0.375%で「Fate/Grand Order」と比較すると悪くはない(FGOの恒常ピックアップ☆5キャラは0.029%)。

筆者もそうであるが、コレクター的な性質を持つプレイヤーならば出費少なく結構簡単に現行でガチャ実装されているキャラが揃ってしまうので、その辺は気持ちよさがある。

ちなみにガチャで所有キャラが被ると必殺技の性能が向上するという仕様。最大でLV20。

ガチャだけでなくアイテムでも上げられる必殺技性能

前述したとおり、ガチャで所有キャラが被ると必殺技の性能が向上するという仕様だが、ガチャでなくとも必殺技の性能を挙げるためのアイテム存在する。

いわゆる"箱推し"でなく"嫁"を愛でる性質を持っているプレイヤーであるのならば自由意志で集中してアイテムリソースを注ぎ込むことが可能だ。

いやキャラデザ悪くないやろっ!

ボブ・太眉やぞ!!!?????

Chrome OSAndroidエミュレータ動作可能

一部の読者からすると途端にマニアックな話になって申し訳ないが、サクラ革命Chrome OSAndroidエミュレータ動作可能で、Chrome OS上のGoogle Play Storeで普通に配信されている。

これはおそらくAndroidアプリ開発の統合環境Android Studioの仕様で、デフォルト設定だとChrome OSでの動作許可されているためだ(ちなみに「Fate/Grand Order」も動作する)。

筆者は細かな検証をしていないが、どうやら新しいApple Sillicon M1採用したMacでは動作しないようなので、この点だけはほんの少し新しいMacbook Airよりも一歩、いや半歩だけ進んでいると言って良い。

ただ、どうやら配信されるバイナリARMアーキテクチャ向きのものであり、x86(x86_64)アーキテクチャ向きのものではないようで、そのためかレンダリングへ一部不具合を抱えている上に動作が重い。これが半歩の理由

Chrome OS上でサクラ革命動作検証した筆者のChrome OS環境で最大スペックのものCPUCore i7-10510U(第10世代)でワーキングメモリ16GB、M.2 SSD 512GB(PCI Express 3.0)であり、それでも「軽快さはないがプレイに全く支障はない」くらいの重さを感じるので、現状でサクラ革命Chrome OSプレイするならこの程度のスペック必要になると思われる。

情報技術者としては今後デスクトップおよびラップトップコンピュータスマートデバイス向きアプリケーションが動作するのが一般的なのは目に見えているので、アプリ開発者デスクトップおよびラップトップ向きのハードウェアサポート検討する時代突入し始めていると多少の意識を向けたほうが良いのかも知れない。

例えば、各アーキテクチャ最適化されたバイナリや、スマートデバイスではあまり意識されてこなかったハードウェアキーボードサポートシングルタップ時とマルチタップ時のトラックパッドの振る舞いの違い、変動するアスペクト比など挙げればキリはないので頭が痛い話だ。

<

2020-12-09

Apple M1が高性能な本当の理由解説する

Apple M1の高性能の理由について、ネットはクソみたいな解説記事に溢れている。

技術に明るいはずのはてなーですら某AVライターの間違いだらけの記事に釣られて、300ブクマ超が集まっていて嘆かわしい。

それもこれも後藤センセーがいつまでたっても解説記事を書いてくれないせいではあるが、公開情報が少なすぎるせいでまともなライターほど記事を書けないのも理解できる。

なので素人の俺が解説する。

M1メモリまでSoC化/ワンチップ化したから速い

違います

そもそもM1DRAMSoC化/ワンチップ化していません。M1がやっているのはSiP(System in Package複数チップをワンパッケージに組み込む)であって、eDRAMによるSoCとは全く異なるものです。

SiPSoCJavaJavascriptくらいには違います

SiPだとしてもメモリが近くなるから速い

違います

HBM系のメモリ採用していたらメモリ帯域は大幅に向上しますが、M1は標準DDRメモリをワンパッケージ化しているだけなので、帯域もレイテンシも変わりません。

帯域はM1 MBPとIntel MBP(Ice Lake)でチャネル数同じ、前者はLPDDR4X-4266、後者はLPDDR4X-3733なのでメモリ帯域は14%しか向上していません。また、x86x64新世代のTiger Lake/ReniorはLPDDR4X-4266に対応していますレイテンシM1が96.8ns、Tiger Lakeが98.4nsでほぼ同等です。

Apple M1の実力を最新世代のIntel/AMD CPUと比較。M1が両者を大きく上回る結果ににあるように、SiP化によって消費電力の削減は期待できます

DRAMとの物理距離が縮まって、レイテンシが短くなって速い

違います

SoC-DRAM間がマザーボード上で30cmあったとしても、電気信号の伝送にかかる時間は片道1nsです。仮にSiP化で物理距離が1/100になったとしてもレイテンシ100usが98.02usになるだけで、CPUにとってDRAM絶望的に遠いことに変わりありません。

M1UMA(Unified Memory Architecture)でCPUGPUその他でメモリを共有しているから速い

違います

まず、同一チップ上のCPUGPUが同一のメモリコントローラDRAMを共有するという意味では、Intel2011年Sandy BridgeAMD2011年のLlanoからUMAです。一歩進んだメモリ空間の共有、コヒーレンシの確保という意味でも、AMD2014年Kaveriから対応していて、この点においてM1革新性はありません。

M1CPUGPUメモリコントローラI/Oがワンチップになっているから速い

違います

上記Sandy Bridge、Llanoの世代からかつてのノースブリッジCPUに取り込まれたため、2011年以降のモバイルPC向け”CPU”のほぼ全てにはGPUメモリコントローラが含まれています

かつてのサウスブリッジIntelは今でもワンチップ化こそしていませんが、2013年HaswellからMCMでワンパッケージ内には収められていますAMD2014年のCarrizoからサウスブリッジ機能CPUに取り込まれています

この意味で、x86x64モバイルPC向け”CPU”は、かなり以前からSoCです。

M1はNPUがあるから速い

違います

NPUを活かせるアプリケーション2020年現在では未だ限定的です。もしNPUの有無によってUXが決定的に改善されるなら、NPUありのSnapdargon 8cxを積むSurface Pro Xは同世代Surface Pro 7よりずっと快適でなければなりませんが、そのような事実はありません。

M1が速いのは単にM1CPUGPUが速いからです。

M1CPUコアが採用するArm ISARISCから速い

違います

CISCRISCの論争は20年以上前に終わった話です。その後CISCRISCの美点、RISCCISCの美点を取り入れたので、現代CPUISAがCISCか/RISCかだけで性能が決定されることはありません

歴史的経緯からx86x64デコーダが複雑になりがちなのは事実ですが、5W以下のローパワープロセッサの開発へ向かうIntelにあるように、ISAの差による消費電力増は1020%のレンジで、さらに性能増によって相殺される分、電力効率の差としてはわずかです。

じゃあ結局、なんでM1は速いの?

頑張って最適化してIPC上げたのと、スマホ由来の積極的なDVFS・クロックゲーティング・パワーゲーティングで浮いた消費電力を回しているからです。

気が向いたら書きます

2020-11-11

anond:20201111224746

いや、アーキテクチャ見るよ。

x86なりx64の奴はダメ

なんだったらhello-worldもダメ

でも、多くのパッケージがARM64向けのパッケージを用意してる。

2020-08-02

プログラムというものが分からない

以下、プログラミングは出来ない俺の認識が間違っている場所があったら教えて下さい。あと、疑問2つを教えて下さい。

【俺の認識

1. コンピューター(というかCPU)が実行する命令は【機械語】で書かれている。たとえばx86CPU場合、0x04ならば『imm8をALに加算する』命令、0x90ならば『何もしない』などである

2. 流石に機械語のままでは人間プログラムするには不便なので、機械語をそのまま人間にも意味が分かるように1対1対応で書き直した【アセンブラ言語】というのがある。0x04ならば『ADD AL, imm8 』、0x90ならば『NOP』と表記される。

3. アセンブラ言語のように機械語と1対1対応している言語を【低級言語/低水準言語】と言う(この呼び方、4で書く高級言語が出来てからまれレトロニムか?)

4. アセンブラのままでプログラムするのも困難である場合が多いので、機械語と1対1対応していないプログラミング言語もある。このような言語を【高級言語/高水言語】と言う。

5. 高級言語で書かれたものそのままでコンピューターには実行できないので、【コンパイラ】というソフトによって機械語に変換している。

6. 高級言語で書かれた状態を【ソースコード】と言う。このソースコードx86用のコンパイラコンパイルすればx86で動くソフトになり、SPARC向けにコンパイルすればSPARCで、PowerPC向けにコンパイルすればPowerPCで動くソフトになる。

【疑問】

a. 認識6が正しいのであれば、(サポートするファイル形式問題などを置いておけば)windowsmacは現時点では同じCPUを使っているのだから、同じコンパイラコンパイルしたソフトwindowsでもmacでも動くのではないか

b. たまに『コンパイラを書いて』と言っている人がいるが、そんなに簡単に書けるものなのか?

2020-07-18

CPUアーキテクチャに自信ニキおる?

x86の改良をインテルがめちゃくちゃ頑張ってもARMデバイスのキレのある動きができないのはなんでやろ。

以前のワイはそれをCPUアーキテクチャのせいじゃなくて、「WindowsMacは本当のマルチタスクOSから、もろもろの割り込み処理に常に備えていて遅い」、「スマホタブレットゲーム機実質的シングルタスクからキレがあるように見える」せいやろなあ、と思っていたんだけど、最近MacARMニュース見てると違う気がしてきた。

ホントARMの方が優れてるんやろか。そしてそれはなんでや?

2020-06-18

anond:20200618203048

かにWindows10は変わったことしなきゃそれでいいってなるもんな。

Macはたしかレガシー切り捨てがやばすぎる。

しかもこの頃は脱x86すら噂されてるし、その度に新しく環境を整えようってほどの魅力が出せるのかって話もあるし…

2020-06-06

ハード技術者からみた米中日

米中の技術競争日本はおいていかれているように、いち技術からは見える。

どうして今のような状況になったのか、考えてみたい。

原因は1つではなく、複合的だろう。



設計ソフトが持てなかった日本

日本半導体を開発しようとすると設計ソフト(Cadence, Synopsysなど)が必要だが、国産はもうないに等しい。

Webで働いている人からするとオープンソースで開発すれば、と思われるかもしれないが、あるにはあるが、実際の製造には使えない。

機能全然足りていないのもそうだが、全部の設計工程用のソフトはない。


設計ソフトライセンス料金が億単位でかかる。

製造原価やウェーハ代や人件費がかかるでしょと言われるが、ライセンス金も開発費の中でかなりの割合を占めている。

Web業界だとOracleの値上げに苦しんでいたと思うが、あれと同じような状況だ。


中国はどうかというと、日本と同様に設計ソフトは作れていない。

というよりGithubそもそもないのでフォークするなど簡単には作れない。



設計ソフト書籍販売

Webプログラミング関係だと書店にいけばあるが、半導体設計用のソフトに関しての和書はない。

洋書はあるが日本からすると数万もすると買えないだろう。

中国はどうかというと、毎月数冊くらいで出版されている。

最近プログラミング関係和書だと入門編で終わるのが多いが、中国では実際の設計の一連作業まで使い方を解説した書籍存在する。

また海賊版が出回っているので自習もできる。


勉強しようにも勉強できない日本と、勉強しようとすればなんとかなる中国の差ではないだろうか。

簡単CPUが作れるだけの書籍がある日本と、x86クローンを作りかけの中国書との違いといえばいいだろうか。



計測機器が作れなかった

国内であるレベルまでの計測機器しか作れなかった。

最初からアメリカ製品を買ってきて作ることが当たり前になっていたので、国内計測機器メーカーお金が流れが作れなかった。

書籍なども使い方までしかなく、計測機器を分解して中に入っている設計ノウハウについての解説はない。

アメリカではちゃん解説している人はいるし、中国でもある。




周りに物がない日本

アメリカだと設備投資している。土地があるからというのもあるのだろうが設備が充実している。

また型落ちの設備流通していることもあって、個人で所有している人もいる。


日本場合会社にも設備はない。

削れるところから削っていった結果なのだろうが。


中国はというと、深センでわかるように、分解した部品が売られていたりする。

組み合わせて新しいものを作る環境が充実している。



権限がない

個々人ではなんとか改善したいと思っていても権限がない。

取りあえず作ってみないと承認されないが、その取りあえず作ってみる環境もなくなったというのが、今の日本ではないだろうか

2020-05-22

YES,New generation Optimizer STL/C++ Level Code Optimizer.I think too. you can!

X86以前のコードレベル自動的コード最適化をかけた後にX86最適化を行う。このさいに文法的最適化ではなくX86が最速になるようにCのコードを並び替える。

これはたしか新時代オプティマイザーなんだろう。だれが発案したの?

 

みんなx86で最適化を考えるがCのレベル等価コードであれば並び替えたほうが、さらX86最適化されるケースはあり得る。

たとえば、ライナーサーチだと判定できたら、さらに最速なアルゴリズムにCを置き換えることは不可能ではない。

 

コンパイラアルゴリズム最適化まで許可された場合 Pythonなどで培われた技術を使ってアルゴリズムコード最適化をしてCのコードアルゴリズムごと改変してもよく、その後X86最適化を行うことは、次の時代にはふさわしいと私は思う。

例:ライナーサーチをもっとはやいサーチアゴリズムに、このC言語コードライナーサーチだと判別して、コンパイラ自分関数化した後に、もっとはやいサーチに関数ごと置換する。

その考え方はすごい。

さすが。これは日本も負けてられない。(結構前の技術らしいです)

anond:20200521225730

プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。

JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScript改名されたり、規格を話すときECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。

Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。

Javaは初期のころオートボクシング / アンボクシングもなく、ストイックオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコード簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である

PHPWebネイティブ言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能初期化していない変数最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列数字臨機応変に切り替える機能もあり(今もそうかは知らん)、数字文字比較比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。

C#Hello Worldくらいしかいたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。

C++黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーション腱鞘炎になることもない。PC Unixにも最初から環境インストールされているか簡単インストールできるので毛嫌いせず使うとよいと思う。

Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。

CSS...はプログラミング言語なのか?そうか。

TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。

Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるからカーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。

これ以下のランキングのもその気になったら書こうかな。

2020-04-05

Win10へのアップグレードがやる気しない

Win7サポート切れだから本当はアップグレードしなきゃならないんだけど、やる気がしない。面倒だ。数年前の自動アップグレード騒ぎの時は強制停止させて止めさせた。というかあまりネットワーク接続しなかったから、気配すらなかったんだっけ?忘れた。

😪

サポート切れOSネット接続すると少しやましい。罪悪感がある。といってアップグレードして不具合が起きたら、光学ディスクドライブのないラップトップから、元に戻れない。HDリカバリー用の領域が呼び出せるとは、Win7が入っている場合だけらしく、Win10だとダメだというネット情報をいくつか見た。

😣

このためだけに外付け光学ディスクドライブを購入するのもなあ・・・だし・・HDMI端子のついてるタブレットを購入しておけばよかった。それならば、何のためらいもなくWin7ラップトップはメルカれたのに( ^ω^)・・・なんだかなぁラップトップってクソだ。

😣

DEX/PCモードのあるスマホに買い替えようかな?っていうか現機種は買い替えてからまだ半年のような( ^ω^)・・・

😫

まり関係ないが最近reveal.jsスライド作れるようになり脱マイクロソフトオフィス(といってもパワポだけ)成功

😄

Ubuntu換装する勇気はないヘタレプリンター接続できなくなったらどっしよかなぁ?とか心配なっちゃう。

Windows7で稼働しているときは、Cドライブ直下に、隠しフォルダとして、Recoveryフォルダ その中に、英数字の長いフォルダ名が、WinRE.wimとBoot.sdiというファイルが保管、F11で、所定のバッチプログラム類が起動されて、再インストールの処理が開始

ところが、Win10に自動アップグレードされると、WindowsREやC直下のRecovery中WinRE.wimやBoot.sdiが別物に置き換わ。


HDD を交換

Windows 7 を試用版としてインストールWindows 7インストールDVD必要

EaseUS Partition Master を使って、旧 HDD から NEC-RESTORE と Windows RE 領域コピーしてドライブレターを削除(C:ドライブ領域の後ろにコピーしても OK

HDD の \Program Files(x86)\mkrcvcd フォルダを C:\Program Files(x86) にコピー

HDD の \APSETUP フォルダを C:\ にコピー

WindowsRE partitionも書き換えるようなことが書いてあるが誤解?誤記?購入時リカバーしたあとに、C:ドライブのいくつかのフォルダーをDドライブコピーするでOKでしょ?これでいざというときWin7プレゼンマシンにはなる。

【参考トラバ

そのWin7プリンタサーバー代わりにしたらよかろ UbuntuWin7プリンタってやればWin7プリンタドライバ使えるしな

2020-03-30

押し入れを掃除してたらWindows2000が出てきたのでVWwareにインストールしてみたら起動しなかった

古いOSは非対応なのね

単純にx86エミュレーションしてるだけたと思ってたけど違うみたい

2019-10-09

PS5でPS4ゲームが遊べるのは半年前に公表されてたんだが

知らない奴多過ぎて笑えなさすぎる

お前らどんだけゲームに興味ないんだよ

https://game.watch.impress.co.jp/docs/kikaku/1181063.html

マーク・サーニー氏のインタビューから分かることは、大きくわけて次の3つだ。ひとつ目は、PS5のリリース2019年ではなく、2020年以降になるということだ。2019年内の発売を思わせる情報も飛び交っていたが、どうやらその線はなくなったようだ。

3つ目は、PS4に対する互換性が保たれるということだ。アーキテクチャの大幅な変更が行われたPS2PS3の間での世代交代では、互換性維持のため、初期のPS3ではPS2を内蔵しているも同然の状態コスト高になってしまった。また、同様に大幅なアーキテクチャ変更でPS3PS4間でも互換性が失われることになってしまったが、ほとんどx86互換PCアーキテクチャ的な違いがなくなったPS4の延長線上にあるPS5では、互換性が保たれるようだ。

これ昨日じゃないぞ

半年前の記事だぞ

次世代機ディスクレス化すると本気で予想してたらしいバカもいるし、マジでどうなってんの

2019-05-08

anond:20190508202735

マザボ壊れたからついでにIDESATAとかHDDSSDとかx86x64とか1コア→2コア→4コアとか買ってしまうんや

2019-03-25

Stadiaの開発者インタビュー その2

やっぱり途中で切れたので続きから


サービス提供を開始します。

するとシステムの準備は万端で、必要ソフトウェアの開発が必要ということでしょうか。Microsoftを見ますと、彼等はXBox OneのHWをサーバラックに積んでいるようです。あなたがたの手法とは異なりますか?

違います

するとGoogleインフラバックエンドのみでなくソフトウェアにも投資を考えていますか?

そうです。

自身の開発スタジオも考えていますか?

はい。Stadia Games and Entertainment組織を発表しました。これは我々の1stパーティスタジオです。

それが今起こっている?

はい

Google開発者に対し全てのツール支援しています。Stadia向けの開発は彼らにとって別のターゲットしか過ぎません。Visual Studioを用いる既存ツールや彼らが用いるツールの全てと共に、彼らのワークフロー統合されます。従ってStadia向けの開発はPlayStationXbox向けの開発と同じくらい簡単です。

我々はUnrealサポートします。UnityがStadiaサポートします。予想される多種多用な業界標準ツールミドルウェアが準備されます

意地悪な質問します。Googleコントロールを超えたものがありますよね。特にユーザサイド、クライアントサイドのインフラ家庭内安価ルータです。このような問題をどのように解決しますか?

とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能情報に対し投資を行うだけでなく、我々自身技術を用いて最良のパフォーマンスを実現するつもりです。Google技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCから情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。

デベロッパパブリッシャは既存ゲームをStadia移植できるのですね。しかし同時にGoogleは新しい選択肢も数多く提供できると

その通りです。それこそが我々のプラットフォーム根本的な差別化ポイントです。既存ゲームカタログを持つデベロッパにとってStadia簡単で親しみ易いものです。我々はできる限り摩擦なくゲーム移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクターストーリー世界を楽しみたいのです。しかし我々はまた開発者未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術提供します。


これまでのクラウドシステムクライアントサイドの限界基本的に画質やレイテンシに起こりました。明らかにこれらの問題インパクトはここ数年で新たにより良い技術を得ることとインフラ改善されることで緩和されてきました。しかローカル品質ストリーミング品質との間には今でも根本的なギャップ存在します。私はidソフトウェアZenimax特許を見たのですが彼らはh.264のモーションベクター効果的に用いてクライアントサイドのある程度の予測を立てレイテンシの知覚を減らしていました。Project Streamにも測定可能レイテンシ存在します。ギャップを閉じるために何をしていますか? これらの問題解決されたでしょうか。それとも少なくとも緩和はされましたか

解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Google圧縮アルゴリズム標準仕様先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となりますしかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられますGoogleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出していますさらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。

それは素晴しい。それらの改善は全て圧縮に関連するものですか?

圧縮ネットワークです。我々はGoogleインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimax使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲーム最適化を行うことができるでしょう。我々はフレーム毎のレイテンシ予測可能で彼らにそれに合わせて調整を行わせることができます


入力を受け取って、ゲームロジックを処理して描画を行うと、60Hzのゲームでは50ms程になります。続いてエンコード転送デコード、表示を行うとストリームではPC上のゲームに比べさらに60ms程かかります。これを改善することはできますか?

我々は改善を続けますStream最初バージョンです。我々は性能向上のために調査を行っており、レイテンシ適応していきますリリース時にはより良くなっているでしょう。

クラウドシステム接続可能性に従って成否が決まります。例えばRed Dead Redemption 2を数万、数十万、場合によっては数百万のプレーヤーオンラインにて同時に立ち上げるとします。システムの成否はアクセスによります。もしゲームプレイできないなら重大な障害となります

かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話しません。しかGMailMapYoutubeが同時に利用可能であるためと同じ基本的技術のいくつかが我々が依るものです。


我々は現在、現行世代が終了する移行の時を迎えています。これまではコンソールベースラインを定めてきました。Stadia次世代XboxPlayStationに対抗できると考えますか?

我々は競合他社が何をしているかは存じておりません。

でもGoogleには良い予測を立てられる優れた人々がいますよね?

我々の第一世代システムに導入されるGPU10Tflops以上の性能があり、さらスケールアップしま

GPUユーザ間で共有されますか? それとも1人のユーザが独占しますか?

単一インスタンスです。

NVIDIAGPUですか?

AMDです。

カスタムGPUだと思います

カスタムGPUです。

Google要件のために作られた訳ですね。他にも公開できる情報はありますか? Vegaですか? それともNavi、もしくはさら新世代ですか?

情報を公開したくない訳ではないのですが、このプラットフォーム進化することのほうがより重要です。そしてこの進化ユーザ開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます

クラウド確約する点ですね。ユーザはHWをアップグレードする必要がないと。

開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲーム開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。

AMDGPUを使うことでStadiaと他のコンソールの間に共通な点ができました。開発者にとって利益となるでしょうか?

シェーダコンパイラツールをいくつか開発しました。これらは開発を楽にするでしょう。しか現在GPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存ゲームをStadia移植するのはとても簡単です。Doom Eternal4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要証明ポイントです。FPSグラフィックプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます

CPUについては何か公開できる話はありますか?

x86で2.7GHzで動作しています開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトル動作するに十分なCPU提供します。

コア数、スレッド数は?

沢山です。

8コア、16スレッド? それより多い? 少い?

公開できない情報です。ハイパースレッド使用しています

しかサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策問題も異なりますコンソールとはサイズパッケージング動機が異なりますデータセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリ使用可能で、とても高速なペタバイト級のローカルストレージ使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。

するとそれが開発者が全く異なる体験のために利用可能な要因となる訳ですね。得られる機会はとても大きいことでしょう。しかし我々はマルチプラットフォーム時代生活していますGoogle先進的な機能は1stパーティのみが利用できるものですか?

パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲーム開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaビジョン説明すると、開発者リアクションは「これは私が期待したもののものだ。これはまさに我々の次のゲームのためのビジョンのものだ。elastic computingの考え、次世代レベルマルチプレーヤー環境ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます

イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケット複数プレーヤーリダイレクすることから原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計イノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています


多くの問題解決し、規準を上げる可能性がある訳ですね。

これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤー開発者に対しより大きな機会を作ってきました。エコシステム進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。

あなたは先程、スケーラビティとStadiaがどのようにしてより多くのリソースを立ち上げ増大する要求対応するかについて話して下さいました。しかし、同時に10TflopsのGPUサーバクラスCPU存在するとも仰いました。リソース拡張をどのように行うのですか?

3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者プレーヤー要求に従い、成長し、進化するプラットフォームです。なぜならStadiaデータセンタの中に構築されています進化させるのは我々にとって簡単なことです。

ここまで第一世代について多くのことを教えて頂きました。すると第二世代やその後の世代もあるでしょう。現状でもスケールアップできるわけですが、3台のGPU連携次世代でも可能ですか?

CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。

先程、エッジ上のインフラについて触れられましたが、例えばNetflixISPキャッシュインストールしている状況があると思います。これがGoogleが行っていることですか? それとも既にYoutubeで行われていますか?

それは我々も既に行っていますGoogleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。


Project Streamではユーザに対し最低で25Mbpsの帯域幅要件しました。これはストリーミングのみのためですか? それとも他のユーザが同時に同じインスタンス接続する場合を含みますか?

我々はStreamさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます

4K60には相当の帯域幅がいるのでしょうね?

4K60はもちろんより要求が高くなります

1080p60は低くなる・・・

私は具体的な数値についてはコメントしません。しかし当然低くなります

インターネット接続環境はStadiaリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性ますます多くのユーザが利用可能になります

さらに繰り返しになりますが、BBRを初めとする我々の技術がありますさらに覚えておいて頂きたいのは我々のネットワークに対する理解そのままではありません。それらもまた時と共に改善されていきますYoutubeマクロ

Stadiaの開発者インタビュー

Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事

https://www.eurogamer.net/articles/digitalfoundry-2019-google-stadia-phil-harrison-majd-bakar-interview

やっつけなので可能なら原文を読むことをお勧めします。

---

なぜ今なのでしょうか?

タイミング問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部から技術観点から技術統合を行ってきました。他社でもその視点存在していますGoogleにはその点に固有のアドバンテージ存在します。

これまでの箱をTVの下に置いておいたパラダイムに比べ、無限演算リソースによる可能性が現れます。これまで存在しなかったことをできる可能性があります

その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています開発者制限の無い計算資源が利用でき、何よりもマルチプレーヤーサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化必要でした。我々のプラットフォームではクライアントサーバも同じアーキテクチャの下にあります。これまではクライアントサーバの間のping支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一インスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞ヘッドラインを飾ることが可能技術です。

クライアントサーバの双方でこの利益を得られるのでしょうか

両方です。

すると開発者に対しStadiaホリデーシーズンにぴったりの最高の製品だと言えると。理に適った範囲無限計算資源が得られると。

ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中データセンタ間を接続しています米国西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシ予測可能でそれに従い設計を行うことができます


Youtbeとの統合について教えて下さい。

StadiaYoutube技術と深く結びついていますが、実際には一歩引いています今日ゲーム業界を考えてみて下さい。2つの世界共存しています。1つはゲームプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeゲーム毎日見ています2018年には述べで500億時間ゲームを視聴するのに費されています時間人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。

まり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザ他人を楽しませる場所です。

から我々のブランドはStadiaといいます。これはスタジアム複数形です。スタジアムスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したか意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。

まりリアルタイムシミュレーションゲームで全ての駒が人々であるようなものですか?

その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fpsHDRサラウンドサポートしました。さら開発者必要インフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDR画像送信することが可能です。だからあなたゲーム体験の思い出は常に最高の状態になります

Googleは全てを記録するでしょうか?

プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogle4Kストリームしま

共有が友達だけか、世界中に公開かも自由選択可能です。Googleユーザ制御を明け渡します。もしユーザYoutubeで公開すれば誰でもリンククリックすることでそのゲームを遊ぶことができます

するとユーザshareするだけで誰でもがその特定ゲームに参加することができる訳ですね。

そう。そしてこれはマルチプレーヤーゲームロビーの新しい形となりますYoutubeクリエイターなら誰でもがファンチャンネルのsubscriberを自分ゲームへと誘うことができます生主として、Youtubeクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。

アカウントシステムベースYoutubeですか?

Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初サービス立ち上げから全ての画面への対応を行いますTVPCラップトップタブレット携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。

我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りから解放したいのです。パフォーマンスに優れ、リンククリックすればゲームは5秒以内に開始されますダウンロードもなく、パッチもなく、インストール必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップChromeブラウザ使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラ動作します。そして、もちろん、我々自身コントローラも開発中です。

なぜ独自コントローラを作るのですか? USBコントローラはどこにでもあるじゃないですか

コントローラ自作する理由はいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続DC内のゲームに直接接続することです。ローカルデバイスとは接続しません。

それは面白い。するとほとんどそれ自体が端末な訳ですね。

その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。

そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術マイクを用いますユーザ選択により、ユーザプラットフォームゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaマルチプレーヤーゲーム指定した友人と共に直ぐに開始します。

するとGoogle伝統的なUI回避するのですね?

我々はゲーマー可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーゲームを起動したら直ぐに友人とゲームを開始したいと考えていますゲーマーUI時間を費したくは無いのです。

誰かが言ったことですが、現在コンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム自体更新や、ゲーム更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeシェアできます

端末は何でも良いのですね? スマホスマートTVも?

Youtubeが観られるならどこでもStadiaは動きます

TVへの接続にはChromecastが使用されると。では実際にはどのように動きますか?Chromecastがスマホラップトップからストリーミングを受け取るのでしょうか?

Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます画像NetflixYoutubeから直接受け取ります。Stadia場合、StadiaコントローラからChromecastへとこのゲームインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画ストリームを受け取りますクライアントはとてもシンプルです。行うのはネットワーク接続ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力コントローラが扱いますビデオと音声とネットワーク接続Chromecastの基本動作で全て既に組込まれています

Stadiaの起動はどうするのですか? コントローラで?

そうです。とても良く出来ていますWiFiに繋ぐだけです。コントローラにはWiFiIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手Chromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができますデジタルパッドでUI操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができますChromecastは5W位下です。Micro-USBで給電可能です。典型的コンソール100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画再生だけです。従ってAssassin's CreedDoomや他の重いゲームあなたスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホ10時間でも遊べます

スマートTVではStadiaYoutubeクライアントに組込まれるのでしょうか。それともStadia独立して起動させますか?

今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。

コントローラに話が戻りますが、モバイル端末にはやはり物理的なアタッチメント必要に思われます。例えばスマホコントローラ接続するような。MicrosoftのXCloudを見ていると操作には実際に問題があるようです。

Googleには解決手段があります

そうでしょう。スマホコントローラ取り付け以外にも、明らかな解決手段としてSwitchのようなクライアント端末を作るのでしょうか?

サービス開始時から提供されるサードパーティによる解決手段サポートしています。他にもアイデアがありますしかし今は話せません。

なるほど。GoogleUbisoftデモを行いましたが、これまでにDoom 2016でもデモを行いました。他にも開発企業はありますか?

良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術提供していました。StadiaLinuxベースです。グラフィックAPIはVulkanです。開発企業クラウドインスタンス作成しますので、開発キットも今ではクラウドにありますしかクラウドだけでなく、開発社のプライベートDCでも、机上のPCでも可能です。

すると開発者物理的なHWを持つことが可能ですか?

もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブゲーム開発での標準となるでしょう。

どの企業自身クラウドシステムを開発しているように見えます。例えばOriginクラウドがあるでしょう。しか必要とされるインフラ要件は、我々がここで話しているような内容を達成するには、3rdパーティには荷が重いように思えます。彼らは自身クラウド継続しながら、Googleシステムを導入するでしょうか。

デベロッパーパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要ツール技術について考えていると思いますしかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています

それはとても巨額ですね。しかしそれでも依然としてシステムを構築しインストールするのは根本的な問題です。多分野に渡る段階的なロールアウトになるのでしょうか?

米国では全ての必要場所に展開が終わっています。Project Stream試験必要環境2018年末には整いました。我々はGoogle社内で、Google社員対象2017年の始めから2年間の間、プライベートテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10

2018-12-27

anond:20181227091727

Green500と経済性は何の関係もないし、なんでそこで経済性を持ち出すのが訳がわからない。

ケーザイセーなるものは今のどの指標でも測ることはできないし、それを問題視するならケーザイセーとやらを評価するランキングを作れ。

アーキテクチャを変更したらソフトウェア更新コストがかかるなんてのは当たり前のことだし、そもそもお前の大好きなx86ですら世代を経るごとにコードを書き換えないと性能が出ない。

いい加減見苦しいぞ乞食。そろそろ黙れ。

anond:20181227011730

そもそもパソコン世界x86による統一が図られたあとだから、ほぼすべての端末で艦これが動くのであって、HPC世界にあっては、なにかを動かすためにはアーキテクチャごとに書き換える必要があるというのは、少し考えれば分かることだろうに…

おっと、いちいち書き換えるなんてコストが高すぎるとかその手の批判過去数十年繰り返されてきたし、今更そんなものに答えたくないからやめてくれ。

ログイン ユーザー登録
ようこそ ゲスト さん