「x86」を含む日記 RSS

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

2018-09-10

anond:20170827112731

android-9.0.0_r8

repo sync

ローカルミラーからsync。同一HDD

Fetching projects: 100% (668/668), done.  
Checking out files: 100% (7881/7881), done.
Checking out files: 100% (15939/15939), done. files:  12% (2013/15939)   
Checking out files: 100% (8013/8013), done.
Checking out files: 100% (6701/6701), done.
Checking out files: 100% (9166/9166), done.out files:   2% (236/9166)   
Checking out files: 100% (15547/15547), done.t files:  29% (4600/15547)   
Checking out files: 100% (12/12), done.
Checking out files: 100% (2500/2500), done.out files:  35% (884/2500)   
Checking out files: 100% (9195/9195), done.out files:  16% (1502/9195)   
Checking out files: 100% (1055/1055), done.out files:  22% (240/1055)   
Checking out files: 100% (12663/12663), done.t files:   9% (1141/12663)   
Checking out files: 100% (3965/3965), done.out files:  20% (824/3965)   
Checking out files: 100% (9487/9487), done. out files:  16% (1529/9487)   
Checking out files: 100% (94/94), done.king out files:  34% (32/94)   
Checking out files: 100% (6246/6246), done. out files:   2% (171/6246)   
Checking out files: 100% (1461/1461), done. out files:  46% (677/1461)   
Checking out files: 100% (118/118), done.
Checking out files: 100% (761/761), done.ng out files:   8% (64/761)   
Checking out files: 100% (266/266), done.
Checking out files: 100% (21720/21720), done.
Checking out files: 100% (5502/5502), done. out files:  23% (1281/5502)   
Checking out files: 100% (259/259), done.ng out files:  35% (92/259)   
Checking out files: 100% (679/679), done.ng out files:  20% (139/679)   
Checking out files: 100% (828/828), done.ng out files:  17% (141/828)   
Checking out files: 100% (4534/4534), done. out files:  42% (1948/4534)   
Checking out files: 100% (4112/4112), done.
Checking out files: 100% (198/198), done.ng out files:   1% (2/198)   
Checking out files: 100% (4584/4584), done.
Checking out files: 100% (5661/5661), done. out files:  29% (1694/5661)   
Checking out files: 100% (400/400), done.
Checking out files: 100% (9937/9937), done. out files:  12% (1254/9937)   
Checking out files: 100% (488/488), done.ng out files:   4% (23/488)   
Checking out files: 100% (2818/2818), done. out files:   8% (228/2818)   
Checking out files: 100% (2842/2842), done.
Checking out files: 100% (4195/4195), done. out files:   7% (319/4195)   
Checking out files: 100% (30060/30060), done.ut files:   2% (782/30060)   
Checking out files: 100% (1478/1478), done. out files:   7% (114/1478)   
Checking out files: 100% (8122/8122), done. out files:  24% (2010/8122)   
Checking out files: 100% (43/43), done.king out files:   4% (2/43)   
Checking out files: 100% (2040/2040), done. out files:  30% (615/2040)   
Checking out files: 100% (6259/6259), done. out files:  46% (2894/6259)   
Checking out files: 100% (4276/4276), done. out files:  28% (1238/4276)   
Checking out files: 100% (417/417), done.ng out files:  49% (206/417)   
Checking out files: 100% (3226/3226), done.
Checking out files: 100% (323/323), done.ng out files:   4% (14/323)   
Checking out files: 100% (16/16), done.king out files:  43% (7/16)   
Checking out files: 100% (15073/15073), done.
Checking out files: 100% (16166/16166), done.
Checking out files: 100% (189/189), done.ng out files:   1% (3/189)   
Checking out files: 100% (220/220), done.
Checking out files: 100% (191/191), done.ng out files:  33% (64/191)   
Checking out files: 100% (4427/4427), done.
Checking out files: 100% (7584/7584), done. out files:  12% (974/7584)   
Checking out files: 100% (7584/7584), done.
Checking out files: 100% (33748/33748), done.
Checking out files: 100% (683/683), done.
Checking out files: 100% (763/763), done.
Checking out files: 100% (12188/12188), done.ut files:  14% (1779/12188)   
Checking out files: 100% (2218/2218), done.
Checking out files: 100% (8081/8081), done.
Checking out files: 100% (73/73), done.king out files:  43% (32/73)   
Checking out files: 100% (4084/4084), done.
Checking out files: 100% (10157/10157), done.
Checking out files: 100% (1150/1150), done.
Checking out files: 100% (891/891), done.ng out files:  12% (111/891)   
Checking out files: 100% (67/67), done.king out files:  49% (33/67)   
Checking out files: 100% (18572/18572), done.
Checking out files: 100% (17/17), done.king out files:  35% (6/17)   
Syncing work tree: 100% (668/668), done.  

real	124m38.905s
user	178m3.356s
sys	15m38.860s

いねえ・・

ls

Android.bp      build          device      libnativehelper   system
Makefile        compatibility  external    packages          test
art             cts            frameworks  pdk               toolchain
bionic          dalvik         hardware    platform_testing  tools
bootable        developers     kernel      prebuilts         zip
bootstrap.bash  development    libcore     sdk

du -hs

66G	android-9.0.0_r8/
30G	android-9.0.0_r8/.repo/

ソースだけで30GB超w

build

$ source buile/envsetup.sh
including device/generic/car/vendorsetup.sh
including device/generic/mini-emulator-arm64/vendorsetup.sh
including device/generic/mini-emulator-armv7-a-neon/vendorsetup.sh
including device/generic/mini-emulator-mips/vendorsetup.sh
including device/generic/mini-emulator-mips64/vendorsetup.sh
including device/generic/mini-emulator-x86/vendorsetup.sh
including device/generic/mini-emulator-x86_64/vendorsetup.sh
including device/generic/uml/vendorsetup.sh
including device/google/cuttlefish/vendorsetup.sh
including device/google/marlin/vendorsetup.sh
including device/google/muskie/vendorsetup.sh
including device/google/taimen/vendorsetup.sh
including device/linaro/hikey/vendorsetup.sh
including sdk/bash_completion/adb.bash

$ lunch

You're building on Linux

Lunch menu... pick a combo:
     1. aosp_arm-eng
     2. aosp_arm64-eng
     3. aosp_mips-eng
     4. aosp_mips64-eng
     5. aosp_x86-eng
     6. aosp_x86_64-eng
     7. aosp_car_arm-userdebug
     8. aosp_car_arm64-userdebug
     9. aosp_car_x86-userdebug
     10. aosp_car_x86_64-userdebug
     11. mini_emulator_arm64-userdebug
     12. m_e_arm-userdebug
     13. m_e_mips-userdebug
     14. m_e_mips64-eng
     15. mini_emulator_x86-userdebug
     16. mini_emulator_x86_64-userdebug
     17. uml-userdebug
     18. aosp_cf_x86_auto-userdebug
     19. aosp_cf_x86_phone-userdebug
     20. aosp_cf_x86_tablet-userdebug
     21. aosp_cf_x86_tablet_3g-userdebug
     22. aosp_cf_x86_tv-userdebug
     23. aosp_cf_x86_wear-userdebug
     24. aosp_cf_x86_64_auto-userdebug
     25. aosp_cf_x86_64_phone-userdebug
     26. aosp_cf_x86_64_tablet-userdebug
     27. aosp_cf_x86_64_tablet_3g-userdebug
     28. aosp_cf_x86_64_tv-userdebug
     29. aosp_cf_x86_64_wear-userdebug
     30. cf_x86_auto-userdebug
     31. cf_x86_phone-userdebug
     32. cf_x86_tablet-userdebug
     33. cf_x86_tablet_3g-userdebug
     34. cf_x86_tv-userdebug
     35. cf_x86_wear-userdebug
     36. cf_x86_64_auto-userdebug
     37. cf_x86_64_phone-userdebug
     38. cf_x86_64_tablet-userdebug
     39. cf_x86_64_tablet_3g-userdebug
     40. cf_x86_64_tv-userdebug
     41. cf_x86_64_wear-userdebug
     42. aosp_marlin-userdebug
     43. aosp_marlin_svelte-userdebug
     44. aosp_sailfish-userdebug
     45. aosp_walleye-userdebug
     46. aosp_walleye_test-userdebug
     47. aosp_taimen-userdebug
     48. hikey-userdebug
     49. hikey64_only-userdebug
     50. hikey960-userdebug

Which would you like? [aosp_arm-eng] 42

make -j4

PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=9
TARGET_PRODUCT=aosp_marlin
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=kryo
TARGET_2ND_ARCH=arm
TARGET_2ND_ARCH_VARIANT=armv8-a
TARGET_2ND_CPU_VARIANT=kryo
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-4.8.0-36-generic-x86_64-Ubuntu-16.04.2-LTS
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=PPR2.180905.006.A1
OUT_DIR=out

============================================
[1/1] out/soong/.minibootstrap/minibp out/soong/.bootstrap/build.ninja
[55/56] glob prebuilts/ndk/cpufeatures.bp
[77/77] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja
out/build-aosp_marlin-cleanspec.ninja is missing, regenerating...
out/build-aosp_marlin.ninja is missing, regenerating...
[564/934] including system/sepolicy/Android.mk ...
system/sepolicy/Android.mk:79: warning: BOARD_SEPOLICY_VERS not specified, assuming current platform version
[934/934] including tools/tradefederation/core/Android.mk ...
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/marlin/system/lib/libclcore_neon.bc'
build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/marlin/system/lib/libclcore_neon.bc'
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/marlin/system/lib64/libminui.so'
build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/marlin/system/lib64/libminui.so'
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/marlin/system/lib64/libbcc.so'
build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/marlin/system/lib64/libbcc.so'
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/marlin/system/lib/libion.so'
build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/marlin/system/lib/libion.so'
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/marlin/system/lib64/libLLVM_android.so'
build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/marlin/system/lib64/libLLVM_android.so'
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/marlin/system/lib/libminui.so'
build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/marlin/system/lib/libminui.so'
[ 99% 722/723] glob tools/tradefederation/core/atest/**/*.py

Android.mkファイルを900以上読み込み完了

[  0% 113/89294] host C++: libadb <= system/core/adb/client/usb_linux.cpp

どこまで行くかな〜〜

追記

時間で20%進んだ。単純計算で100%まで5時間

やむを得ず今日はこのまま出るか。

会社からリモートできりゃいいんだけどな

やったー!

#### build completed successfully (08:56:47 (hh:mm:ss)) ####

real	536m47.886s
user	2057m24.280s
sys	55m15.296s

ビルド成功〜〜。約9時間

 

朝仕掛けておけば、定時帰宅前には終わってるなw

AOSPロムビルド

$ time make otapackage

============================================
ninja: no work to do.
ninja: no work to do.
wildcard(out/target/product/marlin/clean_steps.mk) was changed, regenerating...
No need to regenerate ninja file
[ 99% 250/251] Package target files: o...sp_marlin-target_files-eng.unko.zip
Warning: could not read VENDOR/build.prop

#### build completed successfully (14:58 (mm:ss)) ####

real	14m58.814s
user	41m56.244s
sys	1m7.420s

du -hs

66G	android-9.0.0_r8/
30G	android-9.0.0_r8/.repo/
94G	out/

おまwww ビルドバイナリ100GBいきそうww

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       1.8T  1.7T   43G  98% /home

ああああああああああああ

2018-03-28

NVIDIAのDGX-1とDGX-2の比較とNVSwitchについてのメモ

公開用Blogもってないのでここにメモしとく

DGX-1とDGX-2の比較

 DGX-1DGX-2DGX-1比 参考DGX-1*3
価格$149K$399K268% $447K
消費電力3.2kw10kw313% 9.6kw
CPUXeon E5-2698(20core)*2XeonPlatinum(28core?)*2140%? Xeon(20core)*6
Memory512GB1.5TB300% 1.5TB
GPUVolta*8Volta*16200% Volta*24
GPU-Memory128GB(16GB*8)512GB(32GB*16)400% 384GB(16GB*24)
SSD1.92T*430TB375% 23TB(1.92*12)

所感

値段2.5倍、消費電力3倍をどうみるか。

用途によってはDGX-2(Volta*16)よりDGX-1を3台(Volta*24)とかのほうが・・・

NVSwitch

消費電力高そう。

上記比較CPU数同じ、GPU倍、で多分増えてるPCIeスイッチ増加分にSSDメモリ増量を含めても消費電力3倍以上というのは・・・

上記の表から単純に考えて NVSwitch12個の消費電力+(PCIeスイッチ*X) = Xeon*4 + Volta*8 - HBM2 128GB分 - SSD7TB分。NVSwitch1つで数十Wはありそう、100w超えるかも。

18Portある。

DGX-2での接続不明

GPU-Switch間は各GPUから6Switchに1Portづつ接続Switchの8Portを使用。ここまでは確実だと思う、これ以外の接続思いつかない。図みたらそうっぽい。

問題Switch間がどうつながるか、6基づつで1クラスタクラスタ内はSwitch接続不要クラスタ間は別クラスタの1SwitchGPU接続数と同じ8Port使用とか?(合計16Port使用)

全然違った。クラスタ間は別クラスタ6Switchに1Portづつだった。

消費電力は1つ100w12Switchで1.2Kwだと。GPU間そんなつかわないならSwitch減らしてGPU増やしたいところ。

https://news.mynavi.jp/article/20180404-611133/

いや、クラスタ間は予想通りだった。そしてSwitch減らしたいというのは同意

https://news.mynavi.jp/article/20180418-617343/

所感

X86系ではGPU接続優先でCPU-GPU間は重視しない方向性にし、

Power系でCPU-GPU間を重視する方向性に行くように見える。

2018-01-29

俺の人生足枷となっているもの

PCおよびWindowsというクソ製品調子の悪さに、公私問わず何する時も足を引っ張られ時間と労力を奪われている

前者はIntelx86を無理矢理発展させてきたグチャグチャのアーキテクチャIBM-PCをこれまた無理矢理拡張してきた無駄だらけのハードウェア後者はただひたすらマイクロソフトのクソさが原因でありこいつらが人類の敵である

ちなみにMacという製品もあったが賢者キチガイには近寄らないかスルー

2017-10-13

汎用機シュミレータまたは1チップ汎用機

汎用機からの移行失敗とかの記事を見て思ったのだがx86上で汎用機をシミュレーとするとか1チップ汎用機を作るとかいう方向はないのだろうか。つまりハードウェアは置き換えて、ソフトはそのまま使うという方法

それなりの開発規模になるので、IBMはともかく富士通日立には無理な気もするけど。

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-08-27

[]Android 8のソース、27GB

追記

ローカルaospミラーからのcheck out(repo sync)に3時間かかった

(Core2Duo w)

 

追記

tar.gzに40分かかった

追記

 

追記

解凍に1時間40分w

 

追記

にんにん中now。途中でディスク容量が足りなくなる予定

 

追記

80分後にエラー終了

[  4% 2919/61548] yacc out/soong/.intermediates/frameworks...cc/frameworks/compile/mclinker/lib/Script/ScriptParser.cpp
FAILED: out/soong/.intermediates/frameworks/compile/mclinker/lib/Script/libmcldScript/android_arm_armv7-a_static_core/gen/yacc/frameworks/compile/mclinker/lib/Script/ScriptParser.cpp out/soong/.intermediates/frameworks/compile/mclinker/lib/Script/libmcldScript/android_arm_armv7-a_static_core/gen/yacc/frameworks/compile/mclinker/lib/Script/ScriptParser.h
BISON_PKGDATADIR=external/bison/data prebuilts/misc/linux-x86/bison/bison -d  --defines=out/soong/.intermediates/frameworks/compile/mclinker/lib/Script/libmcldScript/android_arm_armv7-a_static_core/gen/yacc/frameworks/compile/mclinker/lib/Script/ScriptParser.h -o out/soong/.intermediates/frameworks/compile/mclinker/lib/Script/libmcldScript/android_arm_armv7-a_static_core/gen/yacc/frameworks/compile/mclinker/lib/Script/ScriptParser.cpp frameworks/compile/mclinker/lib/Script/ScriptParser.yy
prebuilts/misc/linux-x86/bison/bison: 1: prebuilts/misc/linux-x86/bison/bison: Syntax error: "(" unexpected
ninja: build stopped: subcommand failed.
15:45:20 ninja failed with: exit status 1
make: *** [run_soong_ui] Error 1

 

 

今日はここまで

ちょっとアレしないと

 

 

追記

WSL(Windows Subsystem for Linux

bisonネットでひろったバイナリへ変更 → エラー対処できた可能性あり。時間切れで中断。ただ、ビルド継続するとディスクの空き容量が・・・

https://github.com/Microsoft/BashOnWindows/issues/1771

https://github.com/kxzxxx/android_build

 

UM(Ubuntu on Mac

make -j4でjavaメモリ不足?エラー。j4なしで → エラー対処できた可能性あり。時間切れで中断。こっちはディスク空きは大丈夫なはず

にしても、ネイティブメモリ16GBで厳しいのか・・ → 追記 8GBって認識されてる。

$ ldhw -c memory
     *-bank:0
          詳細: SODIMM DDR3 同期 1333 MHz (0.8 ns)
          ベンダー: 0x0383
          物理ID: 0
          シリアル: 0x00000000
          スロット: DIMM0
          サイズ: 8GiB
          クロック: 1333MHz (0.8ns)
     *-bank:1
          詳細: SODIMMProject-Id-Version: lshwReport-Msgid-Bugs-To: FULL NAME <EMAIL@ADDRESS>POT-Creation-Date: 2009-10-08 14:02+0200PO-Revision-Date: 2014-10-12 06:22+0000Last-Translator: Shushi Kurose <md81bird@hitaki.net>Language-Team: Japanese <ja@li.org>MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bitX-Launchpad-Export-Date: 2016-06-27 17:08+0000X-Generator: Launchpad (build 18115) [空]
          物理ID: 1
          スロット: DIMM0

壊れたか!!!???

 

 

 

予断は許さないが、WSLでAndroidロムのビルドができる可能性あり

っていうか、AOSPじゃなくて、カスロムだとビルド成功報告があるしな

ただし、ディスク容量がたんまり必要

たぶんビルドで30GB以上でてくるはず

 

ソース 約30GB

.repo 約20GB

ビルド 約30GB

雑に計 約80GB

 

追記

WSL(Windows Subsystem for Linux

進捗10%でディスク空きが3GBwになったので、泣く泣く中断

UMでの出力ファイルサイズを見て、やるやらないきめましょう

 

UM(Ubuntu on Mac

時間で30%ぐらい。ってことは、10時間ってことか??

寝て起きても終わってないな。

 → さらに、前回中断してるので、それを加味すると10時間じゃきかないな。

追記

UM(Ubuntu on Mac

[ 57% 30322/52868] Building with Jack:...k_intermediates/with-local/classes.dex
FAILED: out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex 
/bin/bash out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex.rsp
Out of memory error (version 1.3-rc6 'Douarn' (441800 22a11d4b264ae70e366aed3025ef47362d1522bb by android-jack-team@google.com)).
GC overhead limit exceeded.
Try increasing heap size with java option '-Xmx<size>'.
Warning: This may have produced partial or corrupted output.
ninja: build stopped: subcommand failed.
01:27:14 ninja failed with: exit status 1
build/core/main.mk:21: ターゲット 'run_soong_ui' のレシピで失敗しました
make: *** [run_soong_ui] エラー 1

#### make failed to build some targets (07:31:51 (hh:mm:ss)) ####


real	451m51.293s
user	418m48.588s
sys	13m8.276s

 

おおぅ・・

再起動してみるか

 

 

追記

mac再起動したけど、片方のメモリ認識せず

蓋開けて、刺し込み位置取り換えして、再起動・・・、16GB認識OK

よかった・・・

Galaxy S3が壊れて泣きそうなので、ほんとうによかった・・

 

 

追記

UM(Ubuntu on Mac

ビルド成功トータルで何時間だろう?10時間未満だとは思うけど・・

んで、outが44GB

ふざけんなwww

$ du -hs android-8.0.0_r4/
93G	android-8.0.0_r4/

これってなんかおかしくね?

WSL(Windows Subsystem for Linux)でもやりたかったけど、無理だな

外付けもあまってないしな〜〜

SSD調達しようかねえ?

 

追記

SSD500GB 20,000円付近か~~

KKOだからな~~~

どうしようかな~~~~

しぃなぁ~~~~~

 

外付けデータディスクとして使う予定だから、3.5HDDでもいいか???

いっつも悩むんだよなあああああ

 

内蔵の確かSSD128GBだったような気がするけど、この際に交換か???

 

追記

Core2Duo・メモリGBの廃スペックノートPCUbuntu)でビルド

[  3% 2191/61548] Building with Jack: ...l_intermediates/with-local/classes.dex
FAILED: out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/with-local/classes.dex 
/bin/bash out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/with-local/classes.dex.rsp
Out of memory error (version 1.3-rc6 'Douarn' (441800 22a11d4b264ae70e366aed3025ef47362d1522bb by android-jack-team@google.com)).
GC overhead limit exceeded.
Try increasing heap size with java option '-Xmx<size>'.
Warning: This may have produced partial or corrupted output.
ninja: build stopped: subcommand failed.
11:39:11 ninja failed with: exit status 1
make: *** [run_soong_ui] エラー 1

#### make failed to build some targets (49:35 (mm:ss)) ####


real	49m34.775s

予想通りではあるが、メモリ不足で終了。オプションで調整できる?調整したところで無理か?

どうも、HDDの肥やしをみると、Android 6はビルドできたっぽいんだが。7でもメモリ不足で失敗してたか

 

追記

WSL(Windows Subsystem for Linux

USB2.0wの外付けHDDでやりなおし。なんか出てるな~~

[ 27% 17003/61548] Generating TOC: out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc
FAILED: out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc
/bin/bash -c "(prebuilts/build-tools/linux-x86/bin/ijar out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc.tmp ) && (if cmp -s out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc.tmp out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc ; then rm out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc.tmp ; else mv out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc.tmp out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc ; fi )"
ftruncate(fd_out, GetSize()): Invalid argument
/bin/bash: line 1: 30384 Aborted                 (core dumped) ( prebuilts/build-tools/linux-x86/bin/ijar out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar out/target/common/obj/JAVA_LIBRARIES/core-all_intermediates/classes.jar.toc.tmp )
ninja: build stopped: subcommand failed.
10:26:21 ninja failed with: exit status 1
make: *** [run_soong_ui] Error 1

#### make failed to build some targets (08:44:50 (hh:mm:ss)) ####


real    524m50.540s
user    332m5.844s
sys     170m18.359s

https://forum.xda-developers.com/android/general/guide-build-rom-source-windows-10-t3469420/page2

 

追記

あの~~、ninja差分ビルド?部分ビルドってどうやんの・・・

 

まとめ

Core2Duo・メモリGBの廃スペックノートPCUbuntu) → メモリ不足

Ubuntu on Mac mini・メモリ16GB → 10時間ぐらい?でビルド完了

WSL(Windows Subsystem for Linux)・メモリ16GB・USB2.0外付けHDD → 検証なう・・

 bisonの入れ替えが必要

 ijarでエラーが出ている

2018/06/30

android-8.1.0_r29

[ 99% 68782/68882] target Java: Dialer...obj/APPS/Dialer_intermediates/classes)
注意:一部の入力ファイルは非推奨のAPI使用またはオーバーライドしています。
注意:詳細は、-Xlint:deprecationオプション指定して再コンパイルしてください。
注意:入力ファイル操作のうち、未チェックまたは安全ではないものがあります。
注意:詳細は、-Xlint:uncheckedオプション指定して再コンパイルしてください。
[ 99% 68870/68882] build out/target/product/generic/obj/NOTICE.xml
Combining NOTICE files into text
Combining NOTICE files into XML
[ 99% 68873/68882] build out/target/product/generic/obj/NOTICE_VENDOR.xml
Combining NOTICE files into text
Combining NOTICE files into XML
[ 99% 68877/68882] Target vendor fs im... out/target/product/generic/vendor.img
Running:  mkuserimg.sh out/target/product/generic/vendor out/target/product/generic/vendor.img ext4 vendor 100000000 -D out/target/product/generic/system -L vendor out/target/product/generic/obj/ETC/file_contexts.bin_intermediates/file_contexts.bin
make_ext4fs -T -1 -S out/target/product/generic/obj/ETC/file_contexts.bin_intermediates/file_contexts.bin -L vendor -l 100000000 -a vendor out/target/product/generic/vendor.img out/target/product/generic/vendor out/target/product/generic/system
Creating filesystem with parameters:
    Size: 99999744
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 6112
    Inode size: 256
    Journal blocks: 1024
    Label: vendor
    Blocks: 24414
    Block groups: 1
    Reserved block group size: 7
Created filesystem with 303/6112 inodes and 3283/24414 blocks
out/target/product/generic/vendor.img maxsize=102091968 blocksize=2112 total=99999744 reserve=1032768
[ 99% 68878/68882] Create vendor-qemu.img
1+0 レコード入力
2048+0 レコード出力
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00426194 s, 246 MB/s
95+1 レコード入力
96+0 レコード出力
100663296 bytes (101 MB, 96 MiB) copied, 0.108146 s, 931 MB/s
1048576+0 レコード入力
1048576+0 レコード出力
1048576 bytes (1.0 MB, 1.0 MiB) copied, 1.73453 s, 605 kB/s
Creating new GPT entries.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Setting name!
partNum is 0
REALLY setting name!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
[ 99% 68880/68882] Target system fs im...G/systemimage_intermediates/system.img
Running:  mkuserimg.sh out/target/product/generic/system out/target/product/generic/obj/PACKAGING/systemimage_intermediates/system.img ext4 system 2147483648 -D out/target/product/generic/system -L system out/target/product/generic/obj/ETC/file_contexts.bin_intermediates/file_contexts.bin
make_ext4fs -T -1 -S out/target/product/generic/obj/ETC/file_contexts.bin_intermediates/file_contexts.bin -L system -l 2147483648 -a system out/target/product/generic/obj/PACKAGING/systemimage_intermediates/system.img out/target/product/generic/system out/target/product/generic/system
Creating filesystem with parameters:
    Size: 2147483648
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 8192
    Inode size: 256
    Journal blocks: 8192
    Label: system
    Blocks: 524288
    Block groups: 16
    Reserved block group size: 127
Created filesystem with 2205/131072 inodes and 183709/524288 blocks
[ 99% 68881/68882] Install system fs i... out/target/product/generic/system.img
out/target/product/generic/system.img+ maxsize=2192446080 blocksize=2112 total=2147483648 reserve=22146432
[100% 68882/68882] Create system-qemu.img
1+0 レコード入力
2048+0 レコード出力
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0105637 s, 99.3 MB/s
2048+0 レコード入力
2048+0 レコード出力
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 23.051 s, 93.2 MB/s
1048576+0 レコード入力
1048576+0 レコード出力
1048576 bytes (1.0 MB, 1.0 MiB) copied, 3.284 s, 319 kB/s
Creating new GPT entries.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Setting name!
partNum is 0
REALLY setting name!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.

#### build completed successfully (03:51:05 (hh:mm:ss)) ####


real	231m5.412s
user	1252m36.548s
sys	39m3.308s

約4時間

なお、

$ du -hs android-8.1.0_r29/
113G	android-8.1.0_r29/

$ du -hs android-8.1.0_r29/out/
56G	android-8.1.0_r29/out/

$ du -hs android-8.1.0_r29/.repo/
27G	このエントリーをはてなブックマークに追加

ツイートシェア

  
  
  

2017-08-19

host C++: validatekeymaps <= frameworks/base/tools/validatekeymaps/Main.cpp

prebuilts/tools/gcc-sdk/g++: line 40: prebuilts/tools/gcc-sdk/../../gcc/linux-x86/host/i686-linux-glibc2.7-4.6/bin/i686-linux-g++: cannot execute binary file: Exec format error

make: *** [out/host/linux-x86/obj/EXECUTABLES/validatekeymaps_intermediates/Main.o] Error 126

2017-07-08

https://anond.hatelabo.jp/20170708163132

体脂肪率の低い人間コンピュータを作っていれば今みたいに規格が林立したり無駄の多いX86が幅を効かせる事は無かった

常識だね

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2016-10-21

サード虐殺任天堂スイッチ

根拠1: PCPS4Xbox oneとのマルチにはほとんど期待できない

スイッチにはarmプロセッサが搭載される。これはPCPS4, xbox oneで使われてるx86系とは大きく異なり、

移植にはコストがかかるのでサードは乗り気にはならないだろう

一応unity対応するらしいが、そもそもスイッチの性能はPS3世代なので、クオリティを下げてまで移植作業をするだろうか?

根拠2: スマホゲーのマルチも期待できない

同じarm系統なので、スマホゲーの移植比較簡単そうである

しかし、多くのスマホゲーで使われている課金体系を、任天堂プラットフォームでも展開できるかは疑問である

そもそもスマホゲーに課金する層と、任天堂ハードを利用する層にどの程度オーバーラップがあるのか?

また、スマホゲーはタッチパネル最適化されているが、スイッチ移植するにはパッド操作対応させる必要がある。

結論

WiiWii U世代と同様、任天堂面白いゲームは出るだろうが、サードのゲームは期待できない

2016-09-09

http://anond.hatelabo.jp/20160909101558

そして「PS4までのゲームPS Nowで遊べるぞ!」ってか?

何のためにx86アーキテクチャに移行したかからなくなるなw


でも、基盤技術だって今のままってわけはないんだからDirectXが移り変わってきたのと同じように

ゲーム専用機だってその基盤技術が変わっていくことは避けられない。

そうなったときはやっぱり互換性切るんだろうか。

それともDirectXみたいに過去技術そのままで新しい技術を積み上げていくんだろうか。

Windows 10 Mobile

Insider Preview 初期からBTキーボードでほぼ毎日つかってる人の感想

IMEが糞

 モニタつないで大きな画面でOffice動いたとしてもそれを無に返すレベルIMEが糞ほんとツライ

 ユーザー辞書機能も無いし長文書くのにつらみしかない

アプリが少なすぎ

 あってもAndroidiOS向けと比べるとしょぼいのが多い

 ニワトリタマゴだとは思うけどKKのやる気がなさげなので何ともはや

・端末の出来が安っぽいのが多い

 HPのは期待してる。けど、端末の出来以外の所がアレすぎるのでそれに7万出せるかと言われると結構悩む

 OSとしてはETWS対応してるのに、端末メーカー有効にしてないので使えない物がそこそこあるのでその端末一台運用お勧めできない。

continuum 機能自体はまぁどうでも

 ローカル作業する気ないから外部モニタでFullScreen表示できる何かとしか思ってない

 でかい画面でRDP動くのが重要

・入手方法が限られすぎ

 キャリア経由のがないとガジェオタ端末からの脱却はムリじゃね?

ビジネス向けだからこまけー事はいいんだよという人いるけど

多分そこでメインになるであろうcontinuumIMEが糞過ぎてストレスマッハですよ?

ATOMがどんどん改良されてスマホサイズx86版動けばと結構期待してたけど残念な結果になりそう…

合うかどうかは、人というかライフスタイルにだいぶ左右されると思われる

Office Applicationだけで仕事が完結してドキュメント参照の方が多い人なら悪くないかも?

2015-06-26

http://anond.hatelabo.jp/20150626104025

ちくしょう、なんでハンドヘルドPC無くなってもうたんや。

macbookより小さくて持ち歩きながらでも使える端末って、(一定の)需要はあるはずなんやけどなあ。

今や世界中探しても作ってるメーカーすら無いって有様よ。

技術は発展してx86CPU積んだマシンでもまともにバッテリー持つようになったっていうのによぉ…

2015-02-11

SpringBootアプリjavafxを使って配布しやすくしよう

概要

Javaで開発されたアプリケーションにはインストールにまつわる難点がある。

それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである

また、サーバーサイドアプリケーションJavaである場合デプロイ監視の際の難点が多く運用者を悩ませてきた。

javafxで導入されたパッケージャを用いることで各OSネイティブインストーラーの作成が可能になり、この問題を解消・緩和できる。

SpringBoot などを用いた ExecutableJar作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるものパッケージングできる。

問題点の整理

Javaで開発されたアプリケーションの配布には以下の問題点がある。

解決方法として

javafx-maven-pluginを使うとよい。javafxと冠しているが実態パッケージングツール

javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。

Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OSディストリビューション固有のパッケージングが行える。

公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。

実際にどのようにすればパッケージングできるか

まずアプリケーションmaven アプリとして開発する。

pom.xml に以下を追加する。

mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。

vendor適当組織や個人の名前を入れておきましょう。

※ 以下の XML が化けるのは増田不具合仕様っぽい。 http://anond.hatelabo.jp/20100205210805

<plugin>
  <groupId>com.zenjava</groupId>
  <artifactId>javafx-maven-plugin</artifactId>
  <version>8.1.2</version>
  <configuration>
    <mainClass>[main method class]</mainClass>
    <vendor>[Vendor Name]</vendor>
  </configuration>
</plugin>

あとはそのままビルドすればよい。

maven clean jfx:native

ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります

本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。

これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。

/opt/app-name/ の下には app と runtime の2つのディレクトリがあります

app の下にはビルドした jar ファイル依存ライブラリが置かれています

runtime の下には実行用の jre が配備されています

実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です)

課題

OS毎の注意点

2014-09-18

http://anond.hatelabo.jp/20140918122923

ごめん、数年というのはどこからの話してる?

OS X以前以後の話か?x86化以前以後の話か?

2014-06-18

Program Files (x86) 先輩のウザさは異常

Program Files ですらパスに半角スペース先輩が入っててムズムズするのにProgram Files (x86) ってなんなんだよ(笑)分ける必要ねえよ(笑)

おまけにUAC先輩で読み取り専用先輩になるというので、Program Files (ext) まで作ってる先輩なんなの?(笑)普通にProgramData先輩とか使えばいいだろ(笑)

2013-07-12

x86solaris6万円出して購入し、コマンド必死で覚えていたあの頃から

十数年でなんでも無料時代常時接続時代か…。

2013-06-29

7インチタブレットの今後(今年後半)

Kindle

現在3000円引きで在庫処分中。秋ごろアンドロイド4.3のアプデと合わせて新型の可能性大

・Nexsus

アンドロイド4.3のアプデに合わせて新型投入の可能性大

ipad mini

発売1年なので新型は難しい。9月低価格iphone、iwatchの方に注力。

Windows8

8.1のバージョンアップ、7インチ許可、オフィス付き、OSライセンスの条件暖和で年末時期に攻勢。x86CPUで優位性をアピール。

2013-05-09

http://www.nikkei.com/article/DGXNASGG08015_Y3A500C1EA1000/

新たなアーキテクチャーを創設するくらいならオープンソース分散並列(OpenMP-MPI)のハイブリッド(CPU-GPU)数値処理ソフトウェア開発に力を入れたほうがいい。

少なくともオープンソースで動くOpenMP-MPI CPU-GPUの基本的な数値計算ソフト(特に行列計算)は世界最先端研究内容。こういったソフトを毎回アーキテクチャーごとに作るのは金の無駄だし、x86-x64環境で動くようにすればいい。

現状の数値シミュレーションなんてKrylov methodなどの行列処理が主な作業なんだから、それを汎用アーキテクチャで使えるようにしたほうがいい。CPU-GPUOpenMP-MPIで動く行列処理のソフトがあればそれが汎用の処理として使えるんだからくそみたいにコンパイルがめんどくさいアーキテクチャを作るくらいなら、汎用で使えるオープンソースソフトを作れよ。



そんなコードがTrilinosなんだけどね。

2013-02-25

結局ソニーハードウェアしか見ていないということ

ぶっちゃけ言うとハードウェアよりもどんどんソフトウェアの作りやすさが重要になっている

x86に移行したという事はソフトウェアの開発を行い易くするという事だろうが

ますますマイクロソフトと強みに差がなくなっていく。

ただマイクロソフトDirectX互換は最強で

PC版を作り、一部機能オフにして360用にコンパイルすれば終わりに近いマイクロソフトには遠く及ばない

まぁコンソール自体がオワコンだがな

http://anond.hatelabo.jp/20130223090512

2013-02-24

http://anond.hatelabo.jp/20130223144152

ぶっちゃけ言うとそれはない

x86で今の構成でも同じ事ができない道理はない

しろPS2とかPS3とか結構トリッキーなことをしてたか

性能が高くて使いづらかったが

一般PCと同じ構成をとってしまった現在、激的にPCを上回ることはできないよ。

2013-02-23

ぼくのかんがえたPS4分析 - SONY製造業としての業から解き放たれたPS4

http://anond.hatelabo.jp/20130223090512

に触発されて俺なりのPS4分析をしてみた。

ハードウエア製造業の夢より、ソフトウエアクリエイタの夢 - ハードからソフトへと言う現実

一言で言うと↑これがPS4だと思う。

三行でまとめると

PSのビジネスモデルを振り返ってみるのだが、この切り口から行くとPSはSONY半導体戦略、そしてSONY製造業と言う性質とと切っても切れない関係がある。

利用上の注意

なおすべて妄想となっておりますので、これを真に受けて被った損害などについては一切責任を取れません。皆様におかれましてはその旨ご了解のうえご覧いただけますよう、よろしくお願いいたします。ご協力頂けない場合につきましては、いい歳こいたアラフォーの髭ヅラ男が涙目になると言う非常にウザイ状況が発生することとなり、誰も得をしません。ご理解とご協力をお願いいたします。

PSの歴史SONY戦略について

初代PSとそれがもたらしたもの

SONYゲーム機を一緒につくろうと言って任天堂に近づいたものの交渉が決裂してできあがったのがPSであったわけだがこれが大ヒット。

さらにPSでは、内部で使われている半導体を自社設計・自社かそれに近いFabで作る事によって

など副次的な効果もあり、さらに「SONYの旗艦」といったイメージを作り上げることができた。この他に、CD-ROMを手がける部門や、SONYのCDプレス工場部門等々、PS景気により、直接的なPSによって生み出される効果以外に、PSという揺るぎない需要存在する事で、設備投資などに積極的になれたといった効果がうまれた。

PS2では完璧芸術品であったDreamcastを殺すほど大成功

初代は始めどこまで意図されいたかは不明だが2台目ではそれらの経験が生かされる事となりより強化された。まず一番は半導体工場で有り、旺盛なその需要と、それによって得られた利益投資に回し新プロセスを開発、シュリンクすることによって最終的な黒字を目指すことで赤字で販売をスタートすることとなる。

ゲームハード赤字でも、ソフトが売れれば黒字。こんなの当たり前だろ、と言う話であるが、総合情報機器メーカであるSONYでは少し事情が異なる。これは、ソフトウエアライセンス事業による利益によって、間接的に半導体生産設備投資を補填すると言う形を意味する。もちろんそれ以外にもSONYの製造部門にもPS2赤字でも販売すると言う行為によってもたらされる間接的な利益が流れた。

ご存じの通り、PSは我が愛する芸術品たる至高のゲーム機Dreamcastを完膚なきまで叩きのめし世界最高の企業セガプラットフォームから引きずり卸しパチンコ屋に買われる所まで追い込む等大成功をとげた。そしてゲーム機生産により、SONY製造業部門を引っ張っていくという当初の見込みは大成功した。

それをさらに強化したのがPS3、そしてCellであった。

PS3Cell BE が見た夢

PS3時代になると、パソコンの旺盛な需要の元、急速に進化した集積回路は、プロセッサの新規開発コストさら半導体プロセス開発に必要な資金が膨大に膨らむという現実に、様々な企業が立ち向かうよう時代が来ていた。世界の巨人たるIntelと、それ以外という構図が生まれ、世界中でFabの統廃合が進んでいた。

その中で目をつけられたのがゲーム機という存在であるパソコンに対抗できるほどの膨大な需要を生むゲーム機は、薄利という性質を持ちながらも数が出るため、生産設備を拡大しやすプロセス開発の資金を捻出する事に有利であった。さらSONYは、ゲームハードウエアが、当時のパソコンなどに比べて圧倒的に高い性能を持っていなければ存在価値が無い、と言う観念を持っていた。これはかつて任天堂がもっていた思想であった。

さらIBMなどの思惑とも一致、開発がされたのがCell B.E.であり、この存在PS3を生んだ。そう、ここまで来てSONYは、半導体のためにゲーム機デザインしたのである

もちろんこの説にはいろいろな異論はある。しかし俺は順序としては、ソニーグループ全体の長期的な戦略にPSが生む半導体工場の増設という戦略が大規模に組み込まれていたのは間違いないのでは無いかとみている。そこで完成したマシンは、化け物であった。現在まで続く潮流であるGPGPU的な動作もこなCell B.Eがもたらす高性能と、高い拡張性を備え、既にゲーム機では無いとまで言わしめるものができた。この性能は当時の最新鋭コンピュータを大幅に上回るものであった。

しかし……。GPGPU概念は早すぎた。性能を引き出すことが、当人であるSONYでも難しかったのである。そしてこれはミドルウエアや開発ツールの乏しさにも繋がる。そのためスタートアップに失敗した。この失敗は、PSがゲーム機として優れていなかった、あるいは、他者装置に負けた、と言う意味で失敗では無い。製造業としてのSONYが、自社の思惑通りに事を運べなかったと言う事での失敗である

ハードウエアの夢、ソフトウエアの夢

結果SONYは、PS3需要を当て込んだ生産設備リストラ・売却するなどの対処をを迫られる。さら韓国勢などの追い上げ、AV市場の急速な変化、SONY本体の体力の低下、パソコン高速化などにも影響を受けることになる。

PS3のものは、OSの改良、ミドルウエアや開発ツールの向上などにゆっくりではあるが立ち上がってきたが、製造業としてのSONYPS3に期待した効果は得られず、ハードウエア屋、製造業がみた夢はここに破れた。

さら時代は動き、集積回路は、Intelプロセスで1世代以上先を行き、それ以外はすべて後から追うという構図が完全に定着してしまった。SONYも、SONY半導体と言えば、集積回路ではなく画像素子、と言う時代が来て久しい。世界中半導体製造業者の統廃合は進み、国内半導体産業は衰退した。新プロセス開発の難易度や、集積回路の大規模化から来る開発コストの上昇はいかんともしがたくなっていた。

ゲーム必要とするスペックはもはや飽和している。少しでもリアルに、少しでも高性能にと言う方面はすでにマニアのものだけになってしまい、それら需要だけで、そのとき販売されているパソコンを上回る高性能チップを開発、載せるコストを満たすことはできなくなっていた。具体的に言えば、ウルトラハイスペックの、GeForece GTX SLIクラスにも勝ちうるGPUを、専用設計オーバーヘッドを極力少なくすることができるとはいえ新規設計することが難しくなっていたのであるさらにはゲーム機業界ではスペック競争を離れた任天堂Wii、あるいはDSを生み出し、ケータイ、そしてスマフォとと言う存在カジュアルゲーム市場をかっさらうようになった。特に日本では据え置きゲーム機リビングルームに置かれ、パーソナルな空間に置いてゲーム機携帯ゲーム機になったのである

そして決定的だったのが、ゲームエンジンの躍進と越境であろう。従来はゲームエンジン製作環境ゲーム会社門外不出のものであった。しかしそれらが会社を通じて流通し始め、さらには専門業者も現れるようになったのである

家庭用ゲーム機と言えば、ゲーム機の性能を引き出すためにソフトごとにアセンブラ最適化チューニングを施す。それを行っても常に動作が一定になることがメリットとして、パソコンに比べてゲームは常に一定の動作をすることが担保できるためにゲーム製作に専念することができた。しかし、パソコンは十分に高性能になった。家庭用ゲーム機も十分に高性能になった。その結果、チューニングを行わなくてもそこそこの画面が作れるようになってきたのである。そこで余った能力ゲームエンジンオーバーヘッドを許容するようになり、ゲームエンジンの躍進に繋がった。さらゲームエンジンプラットフォーム間の差異すら吸収し始めた。あるゲームエンジン採用すれば、あまり手間をかけること無く、パソコン版、PS版、XBOX版、Wii版と複数プラットフォームで出せるようになったのである。これは、ゲームエンジンが新たなるゲーミングプラットフォームとして君臨する可能性を示唆していた。

しかし、チューニングなどといった、ユーザとは直接関係の無い部分に手間をかける必要が無く、作ったゲームがどこでも動く。これはクリエイタとしては非常にありがたい事なのでは無いか

ビジネス書に出てくる例えがある。ユーザねじ回しが欲しいのでは無い。ねじを回したいのである。同じように、客はゲームがしたい、もっといえば楽しいことがしたいのであって、別にゲーム機が欲しいわけでは無いのであるクリエイタはゲームを作りたいのであって、ゲームハードウエアを使いたいわけでは無いのである。ここに合致したのがクロスプラットフォームゲームエンジンであり、そしてこれらはクリエイタに作りやす環境提供し始めた。さらゲームエンジンは新たに現れたライバルであるタブレット/スマートフォンにも対応している。

しかゲームエンジンの躍進は、プラットフォームビジネス崩壊意味したし、PS3は性能を引き出すには高いレベルの専門的チューニング必要であった。しかゲームエンジンはそこにコストを払う事を選択せず、PS3は高い性能を持ちながらも、それ以外のあまり高性能ではないプラットフォームとほぼ同等、せいぜい高解像度テクスチャーに入れ替えられた程度のゲームしか提供されない、と言った事が発生するようになっていた。

ソフトウエアの夢が花開くのがPS4,PSVita

そしてPS4が出た。

PS4は有り体に言って、x86-64アーキテクチャコンピュータに、OpenGL/CL対応GPUを搭載した、本質的にはそこらのパソコンと変わらない構成である

さらに言えば、最新のCorei7+GeForce GTX…と行かなくとも、そこらのパソコンに較べ、性能は高くない。しかし、根本的にゲーム専用機が持つ、汎用パソコンには無い特徴

を備えている。さらには、GPUを扱いにくくする要因の一つとして上げられる、GPUCPUメモリ転送をほぼ考えなくて良いと言う仕様を打ち出してきた。これはCellCPUプログラミングが分断され、非常に開発を困難にしていたPS3反省ダイレクトに生かしてきたと考えられる。これはAMDが出していたコンセプトだ、と話題に上がるが、あくまでもパソコンの話であって、ゲーム機の分野では少なくとも、PS2プログラミングが困難な部分を、高速なバスで繋ぐことで隠蔽するよな仕様であったように記憶している。

さらx86-64アーキテクチャにしたことで、ゲームエンジンがPC向けエンジンの次に、素早くPSにも対応できる素地を整えた。Power向けに施す必要のあるチューニング不要にしたのである。従来はパソコンで開発されたクロスプラットフォームゲームは、パソコン向けと、家庭用ゲーム機向けの2種類作られた。そして家庭用ゲーム機向けは往々にして、ターゲットとなるハードウエアの中で一番性能の低いところに合わせたデータで作られた。平たく言えばPS3の方がXBOX360よりもはるか映像表現は優れているのに(※ただし使いこなせれば) XBOX360との差異はテクスチャムービー解像度程度の違いだけになってしまう事を意味していた。しかx86-64にしたことで、家庭用ゲーム機向けに統一してダウングレードされたデータからPS版を生成させるのではなく、パソコン向けのデータから生成させた方が早いと言う状況を作り出し、他の家庭用ゲーム機にくらべてアドバンテージを得ようとしているのでは無いだろうか。これはPS VitaARM採用したことも同じ事である

さらに、SONYは、PSVitaから進めてきた戦略として、自社による強力にプラットフォーム感の差異を吸収するミドルウエア群…これはゲームエンジンと読んでも良いのかも知れないが…を提供してくるだろう。x86ならば従来の資産を生かすこともできるし、世の中に出ているコンピュータ向けのライブラリも利用できる。急速に開発しやす環境を立ち上げているのではないだろうか。これはゲームエンジンにより脅かされる、プラットフォームビジネスへの対抗措置でもあるだろう。

これにより「雑事に捕らわれること無く、ゲームの楽しさ・表現のものに専念する」と言うクリエイタの夢を叶えるハードウエア、それがPS4であろうと思う。

平たく行ってしまうと、自社の半導体商売が死んだことにより、その死絡みから解き放たれたPSは、クリエイタ主導でゲームを作ると言う根本に立ち返って作ったのがPS4だ、と言う話である

しかしこれだとハードウエア製造業の夢はどうなってしまうのだろうか?そしてユーザ別にクリエイタの夢などはどうでもいい。下手をすると高性能なハードウエアを所有していると言う欲を満たせなくなる分だけこちらの方がまずいかも知れない。それをどうカバーするのか?と言う話になる。

「夢」PS4

ハードウエア/製造業の夢はどうなるのか

SONYは、次世代戦略として明らかにソフトウエア重視に舵を切っている。SONYは今、収支から見ると製造業では無く金融業であるが、その次に利益を生み出しているのは音楽映像ソフト部門とゲーム部門である

まずはここを潰してしまっては会社として立ち行かなくなる。それはまずい。ではどうするかというと、従来の「製造業としてのSONYを強くするために、PSの需要を利用する」のではなく「コンテンツ・製造複合体としてのSONYの核にPSを据え、関連商品を生み出す形で恩恵を得る」と言う形に舵を切ってくることになる。PS3でも一部行われているが、たとえばPSのリモートプレイを可能にするパソコンタブレット、PSを再生装置としてコンテンツ供給できるメディアサーバといった具合である

しかしこれらに対応させるために大切なPS本体の魅力を失わせては困ると言う事は強く意識されなければならないし、意識されていくだろうと思う。

ユーザの夢はどうなるのか

ユーザの夢は、将来的には作りやすゲームプラットフォームが生み出す新しいコンテンツという形で満たされることになるだろうが、直近では、ソーシャルへの展開という形で示されていると思う。将来的にはいかにコンテンツを集められるかと言う事にかかっている。が、ぶっちゃけていうとユーザから見たら、これほど夢の無い話は無いと言わざるをえない。

今回発表されたタイトルデモなどは実際にはチャンピオンで有り、実際にプレイして得られるのはPS3とそれほど感覚的に、革新的に良くなったと感じる部分は薄いと思う。この点で、PS4は、PS3と実働コンテンツはそれほど変わらないと思っている。マイナーバージョンアップ程度。パソコンWindows XPで評価が固まったようなものである。これはおそらく次に発表される新型Xboxでも同じだ。任天堂は少し別格の応えを出したが苦戦している。

結論 またしてもセガは早すぎた

かつてセガが出した芸術品とも言える至高のゲーム機DreamcastOSWindows CEを搭載した。プロセッサこそ独自であったがそれは当時のWIndows CEではあたりまえであり、むしろそこにWindowsと言う汎用のソフトウエアを利用したことで非常にゲームが開発しやすく、PCゲーム移植やす環境を作り上げた。それらはアーケードのnaomiプラットフォームや、ワンチップで埋め込まれたパチンコなどで今でも生き続ける。

任天堂WiiUコントローラに画面をつけDreamcastに追いついたように、SONYは、PS4で作りやすゲーム機という点で追いついたと言える。

またしてもセガは早すぎた。時代セガに追いついていなかったのであるDreamcastはその名の通り「夢を投げる」存在であったのだ。

PlayStation4は夢が無い」という幻想をぶち壊す

最初に言っておくと、増田SCEが嫌いな方でPS3Vitaも持っていない。

PSPスパロボの新作が出るまで持っていなかったほどだ。

そんな増田だが、PlayStation4発表でのハードウェアに対する誤解の数々を見てちょっとばかり怒りを覚えたので少し書いておく

x86」ではなく「AMD64

いきなり「何が違うんだ?」と思う人や「何も違わないだろ?」と言う人も居るかも知れない。

だが後半を語る上でもこれは重要な話なので省略しないでおく。

最近PCは当たり前のように64bitのメモリ空間を扱えるようになった。

この増田を読んでる人でも64bit OSを使っている人は少なくないはずだ。

これをもたらしたのは、x86 CPUを作ったIntelではなくx86互換CPUを作っていたAMDである

じゃあIntelは何をしていたのかと言うと、64bit CPUを作っていた。x86を完全に捨てて。

Intelは「IA-64」という64bit CPUを開発して商品も出していたが、これは現在ではほぼ完全に消えている。

何故かと言うと、x86が動かなかったからだ。

確かにIA-64は64bitをネイティブで扱えて「x86の古臭い負債」が全く無かった。しかし、現実世界x86で作られた既存ソフトウェアを求めたのだ。ゲーム業界でも似たような話を聞いた気もする。

それに対して、AMDは「64bitを扱えるx86」を作ってしまった。これが「AMD64」であり、現在業界標準としてx86-64と呼ばれているものである

知っての通り、x86-64現在Intel CPUでも対応している。AMDが作った命令を使わされる事になったIntelは何を思っただろうか。逆に、これまでIntelの命令を使ってきたAMDは何を思っていたのだろう。

Cellが目指した「理想的」なヘテロジニアスコンピューティングGPUが実現した「現実的」なヘテロジニアスコンピューティング

PS3に搭載されていたCellは、非x86スカラプロセッサPowerPC CPU(PPE)と、複数のベクトルプロセッサSPEを組み合わせたヘテロジニアス(非対称)プロセッサだった。(スカラベクトルについてはググろう)

スカラプロセッサが得意な処理、ベクトルプロセッサが得意な処理を両方とも高速に実行できる。それがCellの目指した「夢」だった。

しかし、知っての通りCellが目指した夢は破れた。

スカラプロセッサベクトルプロセッサプログラム最適化は全く別の概念で、プログラマーにとっては野球サッカーを同時にやらされるような物である

しかも、スカラプロセッサベクトルプロセッサの間でデータの交換もある。野球サッカーキャッチボールて。

スーパーコンピュータ「京」スカラベクトルの合わせ業で池田某氏に何度も叩かれるほどの超絶難産だった事は記憶に新し…いっけ?

それが原因でPS3の性能を最大限に引き出したソフトほとんど存在せず、こともあろうにXbox360とのマルチソフトが溢れる結果となった。(ちなみに増田360も持ってないのでエルシャダイプレイ出来ていない、問題だ)

それに対し、PC世界ではPS3360が発売してしばらく後に新たなヘテロジニアスコンピューティングが生まれていた。

CPUに比べて進化が止まらないGPUベクトルプロセッサの代わりとして使う試みだ。

GPUスパコン用のベクトルプロセッサCellSPEと違い、最近のどのPCにも搭載されているので量産効果で割安というメリットがある。

DirectXバージョンも2桁に突入機能が増えるにつれて、「もうこれで計算すれば良いんじゃね?」となったわけだ。

結論から言うとこの試みは無茶苦茶ヒットした。近年開発されたTOP500スパコンGPUが使われていないものを探すのが難しくなってきたし、

最近Photoshopなんかの比較的身近なツールもGPUコンピューティング対応してきてヌルヌル動くようになっている。

しかし、そんなGPUにも欠点はある。「CPUメモリから絶望的に遠い」のだ。

IBM発明MS-DOSWindowsが動くことで爆発的に普及した今のPCは、GPUを外付けにすること前提で設計されていた。

DirectXOpenGLのような例外を除いて、基本的に現代OSCPUとメインメモリソフトを動かすように出来ている。

GPUも、一旦メインメモリ上でGPURAMに載せるためのデータを生成し、CPUからGPU動かすよー」という命令を出さなければ動かせないのだ。

これはGPUにとって致命的すぎる欠点だった。これが原因で、遅さを跳ね返せる最新のミドルレンジハイエンドGPUでなければ逆にCPUより遅くなってしまうケースばかりだ。

現実的な理由で始まったGPUコンピューティングがぶち当たった現実的な壁である

CPUGPUAPU(加速するプロセッサ)の夢

このGPU欠点を克服する方法について、AMDはかなり前(少なくともGPUコンピューティング流行るより前の2007年以前)から取り組んでいた。

GPUコンピューティングが遅いのはCPUから物理的に遠いため命令を送る時間が掛かり、メモリの扱いも異なるせいである。

なら同じ場所に載せてしまえば良いのだ。

CPUからGPUに命令を送る遅延を無くし、CPUメモリGPUメモリを交換する時間も減らせばGPUコンピューティングデメリットは消え失せる。

夢のある話だ。

しかし、AMDには発想と設計技術はあったがカネと製造技術Intelと比べて絶望的に劣っていたため、

初めてのCPUGPU統合したプロセッサIntelに先を越されてしまった。(IntelGPU絶望的に遅いからって実質出てないなんて言っちゃダメだ)

これにはAMDもかなり堪えただろう。けれどもAMD戦略を曲げなかった。

IntelGPU絶望的に遅いのでほとんど意味は無かったが、少なくとも前世代のIntel GPUに比べると格段に実効性能が上がっていたのだ。CPUGPUを近付ける統合には間違いなく意味があったということである

AMDCPUGPUを同じチップにするだけでは無く、メモリアドレス空間」も一緒にする道を目指した。

こうなるとCPUの使っているメモリGPUから直接扱え、GPUの使っているメモリCPUから直接扱えるようになる。

これが実現するとCPUGPUが完全なヘテロジニアスコンピュータに一歩近付くのだ。

しかし、そんな夢のあるCPU+GPUの開発は当然難航した。

半導体工場部門を分社化して売り払ってもまだ開発は遅れた。

2011年にやっとAMD初めてのCPUGPUであるAPUを出せたが、メモリアドレス空間はまだ別々だった。

2012年になってもメモリ空間は別々のままだったが、AMDARMiPhoneAndroidWindows Phoneに載っているARMである)と合同でHSA(ヘテロジニアスシステムアーキテクチャ)を推進すると発表した。

世の中の現実的な人々は笑った。「アーキテクチャだけを作ってもハードソフトが出てこないんじゃ話になりませんよ」と。

同じ2012年AMD2013年中にHSAの第1世代製品を出すとだけ発表し2012年は終わった。

ぼくのかんがえたヘテロジニアスコンピューティングマシン

そして2013年2月21日米国時間20日)、Sony Computer EntertainmentPlayStation 4を発表した。

Cellコケしまったので載らない事は誰もが知っていたが、載っているハードウェア一部の人が驚いた。

―HSAであるPC用のHSA対応APUがまだ正式発表されていない中で、なんとHSAを載せてきた。(2013年末発売だから当たり前だというツッコミは止めろ!)

CPUx86-64Jaguar 8コア(ちなみにPC向けJaguarは4コアまでだ)、GPURadeon HD 7800相当でPS3と違いガチで1.8TFLOPS(理論上1秒間に計1.8兆個の小数点を含む計算を実行可能)のスペックを持つ代物だ。

このCPUGPUは8GBのGDDR5メモリを共有して動作する。8GBと聞くと最近PCから考えると少なく聞こえるかも知れないが、(わたしのメモリは16GBです)

GDDR5とはGPUの描画計算を速く済ませるために作られた超高速メモリであり、ご家庭のDDR3メモリとは比べ物にならない速さが出せる。

実際の所PS4がHSA対応かは正式発表されていないのだが、PC向けJaguarはHSA対応と発表されており、SCEPS4APUCPUGPU)と呼んでいてこの変態メモリ構成とすると、発売までにクッタリスペックダウンしない限りHSA確定と見て良いはずだ。

また、PlayStationはこれまで一度もx86CPU採用した事が無く、これが最初(で最g)のx86採用機となる。

Intelが初代XboxCeleron搭載)であっさり諦めたx86ゲーム機市場制圧の夢を、AMDが思いもよらぬ形で果たしたのだ。

これまでPCしか発売されてこなかったDiabloが、x86-64PS4向けに初めてコンシューマ版を発表した事もx86-64採用が決してつまらない事ではなかった証だろう。(Diabloと戦うハメになるサードの方々にとっては非常につまらないが)

CPUGPUの”フュージョン”…(HSAは以前はFusionと呼ばれていた。そういえばドラゴンボール映画も今年やな…)

AMDが長年の間見てきた夢が、PS4で初めて現実世界に現れることになる。(※ただし次世代XboxもHSA採用PS4より先に発売したりしない世界線に限る)

こんな馬鹿らしいほど夢が詰まったマシンを「x86搭載だからPCみたいで夢が無い」という一言で切り捨ててしまう人に増田絶望した。

なおこの増田Core i7GeForceで書かれた模様


追記

予想以上に反響が大きくてビビったので

でも、それってユーザーの夢にどう繋がるの?

という趣旨感想についてだけ補足。

性能の引き出し易さがPS3と比べて格段に良くなるのでPS3ラストレムナント人喰いの大鷲トリコのような非情現実が減る。以上。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん