(情報科学)技術的特異点と科学技術等 2 (ナノテク)©2ch.net

1オーバーテクナナシー 転載ダメ©2ch.net2017/03/19(日) 20:22:23.35ID:cRK6Y+kv
※ このスレは、本家スレから分かれた分家スレです。科学・技術系で『専門的な』話題を特に扱います。

スレ成立のきっかけ
・技術的特異点の関わる分野は非常に幅広く、浅い部分から深い部分までレベルも様々で、多様な人が集まっている
・上記を前提として、科学・技術系で専門的な内容に集中しやすいように、ノイズ(特に不毛な論争)を減らしたい
・これにより、興味がある者同士の意思疎通困難性、過去ログ参照の困難性などが解消される

ただし性質上、本家との区分は厳密には困難です ( むしろ同じ内容が扱われても構いません ) 。
本家は雑談寄り、ここではより専門色を強く、とご理解下さい。

■現在の本家スレと前スレ
(強いAI)技術的特異点/シンギュラリティ63
http://rio2016.2ch.net/test/read.cgi/future/1489471775/
(情報科学)技術的特異点と科学技術等 1 (ナノテク)
http://rio2016.2ch.net/test/read.cgi/future/1475986330/

■関連スレ等
関連書籍・リンク・テンプレ集[必見]
http://singularity-2ch.memo.wiki/
(AI)技術的特異点と経済社会等 9 (BI)
http://rio2016.2ch.net/test/read.cgi/future/1484578214/
人工知能
http://rio2016.2ch.net/test/read.cgi/future/1286353655/
人工知能で自我・魂が作れるか
http://rio2016.2ch.net/test/read.cgi/future/1476229483/
不老不死(不老長寿)を目指すスレ Part32
http://rio2016.2ch.net/test/read.cgi/future/1485781591/
検索
http://google.jp/?q=site:2ch.net/test/read.cgi/future/+tokuiten+cyouju
http://google.jp/search?q=singularity+saron+OR+sinpojiumu&num=20

234>>2302018/07/30(月) 06:46:14.12ID:wOzVCFyH?2BP(0)

DDR4-I/F 64 bit 2400MHz  DDR4-I/F 64 bit 2400MHz

235>>2312018/07/30(月) 06:47:10.62ID:wOzVCFyH?2BP(0)

DDR4-I/F 64 bit 2400MHz  DDR4-I/F 64 bit 2400MHz

236>>2322018/07/30(月) 06:47:55.24ID:wOzVCFyH?2BP(0)

DDR4-I/F 64 bit 2400MHz  DDR4-I/F 64 bit 2400MHz

237>>229-2362018/07/30(月) 06:51:12.91ID:wOzVCFyH?2BP(0)

ARM926
Host I/F & Inter Processor I/F
Host I/F
PCI Express Gen3 x8
Host I/F
PCI Express Gen3 x8
Host I/F
PCI Express Gen3 x8
Host I/F
PCI Express Gen3 x8
UART
SPI BUS
GPIO

238>>229-2372018/07/30(月) 06:54:34.12ID:wOzVCFyH?2BP(0)

Page 15

階層構造と同期メカニズム

? スレッドを階層管理
? 同期レベル(バリア同期)
  ? Level 0 :スレッドレベル、 PE内の0-3スレッド、または4-7スレッド
  ? Level 1 : PEレベル、PE内の8スレッド
  ? Level 2 : Villageレベル、4つのPEとL1キャッシュ
  ? Level 3 : Cityレベル、16のPEとL1/L2キャッシュまで
  ? Level 4 : Prefectureレベル、256のPEとL1/L2/L3キャッシュまで
  ? Level 5 : PEZY-SCレベル、1024のPEとL1/L2/L3キャッシュまで

Sync Level
0  Thread 0-3  Thread 4-7
1    PE  PE  PE  PE
      L1 Cache
2        Village  Village  Village  Village
          L2 Cache
3            City
              L3 Cache
4                Prefecture
5                  PEZYSC Core

239>>2382018/07/30(月) 06:55:38.03ID:wOzVCFyH?2BP(0)

Page 16

オンチップキャッシュ

  level  Size(B)  Chip Total(B)  Way  Entry  Line 長(B)  接続
データキャッシュ
  L1  2K  1M  8  4  64  2PEに1つ
  L2  64k  4M  8  32  256  Ciry毎 L1 8 個に対して
  L3  2M  8M  8  256  1k  Prefecture毎 L2 16 個に対して
命令キャッシュ
  L1  2K  2M  8  2  128  PE毎
  L2  32K  2M  4  32  256  City毎 PE 16個
  L3  128K  512K  4  32  1K  Prefecture毎 L2 16 個

複数PE間のメモリコンシステンシはソフトウェア責任、 PE毎に16KBのローカルメモリを備える


Page 17

プログラミング概要

240>>2392018/07/30(月) 06:56:30.65ID:wOzVCFyH?2BP(0)

Page 18

プログラミング対象

Xeon
  PEZY-SC
  PEZY-SC
  PEZY-SC
  PEZY-SC
    <演算リソース>
      ・1024個の演算コア(PE)
      ・1PEあたり8個のスレッド
    <メモリ>
      ・32GBのデバイスメモリ
      ・1PEあたり16KBのローカルメモリ

241>>2402018/07/30(月) 06:57:53.49ID:wOzVCFyH?2BP(0)

Page 19

作成するプログラム

? 2種類のプログラムを作成する必要がある
  ? CPU上のプログラム(C++で記述)
  ? PEZY-SC上のカーネルプログラム(PZCLで記述)
    ※PZCL=カーネルプログラムを記述するPEZY独自仕様の言語
    コンパイラはllvmを用いている。

main関数呼び出し
  CPU プログラム
    起動  終了
      カーネルプログラム1
    起動  終了
      カーネルプログラム2

上図のようにCPUプログラムからカーネルプログラムを起動する

242>>2412018/07/30(月) 06:58:54.95ID:wOzVCFyH?2BP(0)

Page 20

特殊な関数

? カーネルプログラムで利用可能な、PEZY-SC制御に必要な組み込み関数がある。

  ? sync_L1 (L1キャッシュにアクセスする単位でのスレッド同期)
  ? sync_L2 (L2キャッシュにアクセスする単位でのスレッド同期)
  ? sync_L3 (L3キャッシュにアクセスする単位でのスレッド同期)
  ? sync (sync_L3と同等)

  ? flush_L1 (L1キャッシュのフラッシュ)
  ? flush_L2 (L2キャッシュのフラッシュ)
  ? flush_L3 (L3キャッシュのフラッシュ)
  ? flush (flush_L3と同等)

  ? get_pid (PE ID取得)
  ? get_tid (PE内スレッドID取得)
  ? chgthread (PE内スレッドの表裏切り替え)

243>>2422018/07/30(月) 06:59:40.84ID:wOzVCFyH?2BP(0)

Page 21

カーネルプログラムの構造

? 基本的な構造
  void pzc_foo(…)
  {
    ? PE ID取得(get_pid)
    ? PE内スレッドID取得(get_tid)
    ? 自スレッドに割り当てられた処理の実行
    ? 出力バッファフラッシュ(flush)
  }


Page 22

pzcAddサンプル

? カーネルは起動するとユニークな tid,pid を持って、 CPUから指定されたスレッド分実行される。

tid=0,pid=0
  void pzc_Add(float* a, float* b, float* c, int count)
  {
    int tid = get_tid();
    int pid = get_pid();
    int index = pid * get_maxtid() + tid;
    if(index >= count) return;
    c[index] = a[index] + b[index];
    flush(); // cache flush
  }

244>>2432018/07/30(月) 07:00:23.57ID:wOzVCFyH?2BP(0)

tid=1,pid=0
  void pzc_Add(float* a, float* b, float* c, int count)
  {
    int tid = get_tid();
    int pid = get_pid();
    int index = pid * get_maxtid() + tid;
    if(index >= count) return;
    c[index] = a[index] + b[index];
    flush(); // cache flush
  }

tid=7,pid=N
  void pzc_Add(float* a, float* b, float* c, int count)
  {
    int tid = get_tid();
    int pid = get_pid();
    int index = pid * get_maxtid() + tid;
    if(index >= count) return;
    c[index] = a[index] + b[index];
    flush(); // cache flush
  }

? 1つのPEには8スレッドが存在する
  ? スレッド数を128で起動した場合、128/8=16個のPEが実行される
? 8192を超えるスレッド数で起動する場合、CPUから複数回に分けて起動される

245>>2442018/07/30(月) 07:01:00.85ID:wOzVCFyH?2BP(0)

Page 23

簡単な最適化の説明

? 前述のpzcAddサンプルを用いて、PEZY-SC内での簡単な最適化の説明を行う
? ここでは以下のような最適化を行っている
  ? カーネル呼び出しのオーバヘッドの削減
  ? chgthreadを用いたレイテンシーの隠蔽
  ? 同期を用いたキャッシュアクセスの効率化


Page 24

オーバヘッド削減(1/2)

? 以下のコードをスレッド数=要素数として起動する場合、
8192を超えるサイズを処理しようとした場合にカーネルが複数回起動されるため、カーネル呼び出しのオーバヘッドが増加する

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int index = pid * get_maxtid() + tid;
  if(index >= count) return;
  c[index] = a[index] + b[index];
  flush(); // cache flush
}

246>>2452018/07/30(月) 07:03:04.06ID:wOzVCFyH?2BP(0)

Page 25

オーバヘッド削減(2/2)

? 以下のようにカーネルコードを修正し、CPUからの呼び出し時のスレッド数を固定にしても、
1回のカーネル呼び出しで全要素の処理を行えることとなる。
? これによってオーバヘッドを減らすことができる。

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int offset = pid * get_maxtid() + tid;
  int step = get_maxtid() * get_maxpid();
  for(int pos = offset; pos < count; pos += step) {
    c[pos] = a[pos] + b[pos];
  }
  flush();
}

247>>2462018/07/30(月) 07:03:40.68ID:wOzVCFyH?2BP(0)

Page 26

寄り道:CPUエミュレート

? このようにカーネルの中でループさせることは別のメリットもある。
? CPUで1スレッドでの動作として、この関数を同じように動作させることができる
→ソースを共有したデバッグに有効

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int offset = pid * get_maxtid() + tid;
  int step = get_maxtid() * get_maxpid();
  for(int pos = offset; pos < count; pos += step) {
    c[pos] = a[pos] + b[pos];
  }
  flush();
}

CPUでは
  get_tid() … 常に0
  get_pid() … 常に0
  get_maxtid() … 1
  get_maxpid() … 1

248>>2472018/07/30(月) 07:04:41.29ID:wOzVCFyH?2BP(0)

Page 27

スレッドの切り替え (1/3)

? 1つのPEに8スレッド存在するが、一度には4スレッドのみが動作する。
  ? 表裏で4スレッドずつ。
? sync/flushなどの同期やchgthreadを使用しないと、表裏が切り替わらない。

249>>2482018/07/30(月) 07:05:33.12ID:wOzVCFyH?2BP(0)

Page 28

スレッドの切り替え (2/3)

? 以下の実装では、ループの中にスレッドが切り替わる命令が無いので
現在実行中の各スレッドが flushにたどり着くまで裏スレッドは処理されない。
? アクセスのアドレスが不連続になり、キャッシュ効率が悪い
? メモリアクセスのレイテンシーを隠蔽できない

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int offset = pid * get_maxtid() + tid;
  int step = get_maxtid() * get_maxpid();
  for(int pos = offset; pos < count; pos += step) {
    c[pos] = a[pos] + b[pos];
  }
  flush();
}

    memory
  ↑ request    ↓
t0    stall      flush
t4

250>>2492018/07/30(月) 07:06:07.72ID:wOzVCFyH?2BP(0)

Page 29

スレッドの切り替え (3/3)

? 以下のようにa, bの読み込み後にchgthreadを入れる事で改善される。

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int offset = pid * get_maxtid() + tid;
  int step = get_maxtid() * get_maxpid();
  for(int pos = offset; pos < count; pos += step) {
    float a_ = a[pos];
    float b_ = b[pos];
    chgthread();
    c[pos] = a_ + b_;
  }
  flush();
}

    memory
  ↑ request    ↓
t0    stall      flush
   ↓ chgthread
t4

251>>2502018/07/30(月) 07:06:50.07ID:wOzVCFyH?2BP(0)

Page 30

メモリアクセスの同期(1/2)

? 以下の実装だと、各スレッドがメモリレイテンシーの状況によって進行度がばらばらになり、
キャッシュアクセスが非効率となる場合がある。

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int offset = pid * get_maxtid() + tid;
  int step = get_maxtid() * get_maxpid();
  for(int pos = offset; pos < count; pos += step) {
    float a_ = a[pos];
    float b_ = b[pos];
    chgthread();
    c[pos] = a_ + b_;
  }
  flush();
}

  memory request
t0 ↑
t1  ↑

t7 ↑

252>>2512018/07/30(月) 07:07:24.21ID:wOzVCFyH?2BP(0)

Page 31

メモリアクセスの同期(2/2)

? 以下のようにメモリアクセス前に同期を入れることにより、メモリアクセス性能が向上する場合がある
ただし同期自体のペナルティがあるため、利用する/しない、あるいは同期レベルの選択に注意が必要

void pzc_Add(float* a, float* b, float* c, int count)
{
  int tid = get_tid(); // thread ID (0 - 7)
  int pid = get_pid(); // PE ID
  int offset = pid * get_maxtid() + tid;
  int step = get_maxtid() * get_maxpid();
  for(int pos = offset; pos < count; pos += step) {
    sync_L2();
    float a_ = a[pos];
    float b_ = b[pos];
    chgthread();
    c[pos] = a_ + b_;
  }
  flush();
}

  memory request
t0 →  ↑
t1  →  ↑
…  sync
t7 →    ↑

253>>2522018/07/30(月) 07:08:00.62ID:wOzVCFyH?2BP(0)

Page 32

PEZY-SCの効果的な利用

? スレッド、PE単位の並列性を活かす
? L1~L3キャッシュに優しいメモリ配置を行う
? CPUからカーネルの起動回数を減らす
? chgthread を用いてレイテンシーを隠蔽する
? 同期を適切に用いて、キャッシュの効率を上げる
? ローカルメモリを利用することでメモリアクセスを減らす
? その他各種設定(メモリ書き出し設定・カーネル呼び出し方法設定)→これについては今後必要に応じて情報公開します。


Page 33

ローカルメモリの利用(1/2)

? PE毎に16KBのローカルメモリをカーネルプログラムで利用できる
? デフォルトではPE内の8スレッドのスタック領域として、2KBずつを割り振られている
  0x0000
    スレッド0用スタック領域(2KB)
    スレッド1用スタック領域(2KB)
    スレッド2用スタック領域(2KB)
    スレッド3用スタック領域(2KB)
    スレッド4用スタック領域(2KB)
    スレッド5用スタック領域(2KB)
    スレッド6用スタック領域(2KB)
    スレッド7用スタック領域(2KB)
  0x3fff          16KB

254>>2532018/07/30(月) 07:08:43.24ID:wOzVCFyH?2BP(0)

Page 34

ローカルメモリの利用(2/2)

? このままではユーザが利用できないため、スレッド用のスタック領域を削減する
(下図はスレッド毎のスタックサイズを1KBとした場合)
  0x0000
    スレッド0用スタック領域(1KB)
    スレッド1用スタック領域(1KB)
    スレッド2用スタック領域(1KB)
    スレッド3用スタック領域(1KB)
    スレッド4用スタック領域(1KB)
    スレッド5用スタック領域(1KB)
    スレッド6用スタック領域(1KB)
    スレッド7用スタック領域(1KB)
0x2000            8KB
    ユーザ利用可能領域(8KB)
0x3fff            8KB


Page 35

プログラミングのパターン

? PEZY-SCのカーネルプログラムはなるべく全処理を一括で持っていきたい
  ? MIMDでプログラミングに自由度があるので、多少並列度が落ちるところもとりあえずカーネルには載せることは容易

    SC処理1 → CPU処理2 → SC処理3 → CPU処理4 → SC処理5

      ↓

    SC処理1 → SC処理2 → SC処理3 → SC処理4 → SC処理5

255>>2542018/07/30(月) 07:09:32.45ID:wOzVCFyH?2BP(0)

Page 36

プログラミングのパターン

? フロントエンドがclangであり、ほとんどのケースではSCとCPUでのソースコードの共有が容易。
? デバッグ時には細かい単位で切り替えながら不具合を特定することが非常に有効

  CPU処理1 ⇔ SC処理1
      ↓
  CPU処理2 ⇔ SC処理2
      ↓
  CPU処理3 ⇔ SC処理3
      ↓
  CPU処理4 ⇔ SC処理4
      ↓
  CPU処理5 ⇔ SC処理5


Page 37

プログラミングのパターン

? 最終的な実行はなるべくカーネル処理だけとする
  CPU処理1 SC処理1
        ↓
  CPU処理2 SC処理2
        ↓
  CPU処理3 SC処理3
        ↓
  CPU処理4 SC処理4
        ↓
  CPU処理5 SC処理5

256>>2552018/07/30(月) 07:10:04.32ID:wOzVCFyH?2BP(0)

Page 38

その他の話題


Page 39

共同開発のパターン

? そもそもPEZY-SCは利用できそうだろうか?
? 自分のところで評価するのは負荷が高い。。。


Page 40

共同開発のパターン1

? そもそもPEZY-SCは利用できそうだろうか?
? 自分のところで評価するのは負荷が高い。。。
→(可能な範囲で)実装に必要な情報をご提供頂き、PEZY側で(可能な範囲で)評価を行う(基本はNDAベース)
  A社/大学/研究所
実装に必要な情報  ↑
  ↓      評価結果
    PEZY

257>>2562018/07/30(月) 07:10:59.53ID:wOzVCFyH?2BP(0)

Page 41

共同開発のパターン2

? そもそもPEZY-SCは利用できそうだろうか?

? まずは簡単に触ってみたい。。。
? PEZY-SCを空冷環境下でご提供
  ? ただし、開発途上のものなので十分な情報やサポートを保証できるものではありません。
  (弊社側で可能な範囲でのご提供となります)

  A社/大学/研究所
    ↑    ↑
PEZY-SC空冷環境  評価結果
    PEZY

258>>2572018/07/30(月) 07:12:26.60ID:wOzVCFyH?2BP(0)

Page 42

PEZY-SC評価システム例

LIANLI ATX PC-T60A
  ASUS X99E WS
    Intel? Xeon? Processor E5-2650 v3 (25M Cache, 2.30 GHz)
    Samsung DDR4-2133 8GB×4
    Crucial 2.5” SSD CT250BX100SSD1
    PEZY-SC Dual Board x 2 株式会社 PEZY Computing 社製品
  RA-750S
  Optional
    120 mm / 140 mm Fan Cooler Model: T60-1

259>>2582018/07/30(月) 07:13:17.14ID:wOzVCFyH?2BP(0)

Page 43

共同開発のパターン3

? そもそもPEZY-SCは利用できそうだろうか?
? 液浸環境下でスパコン構成を試してみたい。 →菖蒲システムの利用公募
http://accc.riken.jp/news1/2016-07-01/
こちらも十分な情報やサポートを保証できるものではありません(可能な範囲でのご提供となります)
研究開発用途で開発情報を公開可能ならばお勧め!
個人でも応募可!!


Page 44

菖蒲システムでできること

? 複数のコンピュートノードを用いた大規模な並列計算が可能。MPIの利用が可能。
? 現状は1タンク=16ブリック=256ノードが開発者に常時提供されている。
必要に応じて全システムでの利用も可能。
? ジョブ管理システムslurmの利用が可能。
? フロントエンド、コンピュートノードともに linux(centOS7)が入っており、
一般的なlinuxのライブラリやツールが利用可能。

260>>2592018/07/30(月) 07:14:05.52ID:wOzVCFyH?2BP(0)

Page 45

菖蒲の構成

? フロントエンドとコンピュートノードから構成される。
? 4つのコンピュートノードは1つのブリックを構成する。
? また、各コンピュートノードはそれぞれ1個のXeonと4個のPEZY-SCを所持する。
? フロントエンド、コンピュートノードはInfinibandにより結合されている。
shoubu
  t1n011 t1n012 t1n013 t1n014  1ブリック
  t1n021
  ‥‥


Page 46

ジョブ管理システムの利用

? 複数の人が菖蒲システムを利用するためにジョブシステム (slurm)が導入されている。
これにより特定のコンピュートノードを意識せずに利用ができる。
  ? ssh shoubu.riken.jp のようにしてフロントエンドにログインする。
  ? フロントエンド上でプログラムの編集、ビルドを行う。
  ? sbatch ?nodes <ノード数> --ntasks-per-node <ノードあたりの MPIプロセス数> tst.sh

    #!/bin/sh
    #SBATCH ?p debug
    #SBATCH ?exclusive

    mpirun ... //MPIを用いる場合

261>>2602018/07/30(月) 07:14:44.17ID:wOzVCFyH?2BP(0)

Page 47

今後の展開


Page 48

今後の展開

? 新プロセッサ PEZY-SC2の開発
  ? 2,048コアの演算PE+MIPSプロセッサ内蔵
  ? TCIインタフェースによる、メモリ帯域の飛躍的拡大

? Brickボード、液浸冷却システムのブラッシュアップ
  ? 新ブリック構成で冷却効率を向上

? ZettaScaler-2.xシリーズ
  ? これらの新規開発要素を組み合わせた、新しいスーパーコンピュータの実現

262>>2612018/07/30(月) 07:15:27.78ID:wOzVCFyH?2BP(0)

Page 49

PEZY-SC2の特徴

? CPUがMIPSとなりSC2とメモリ空間を共有する
→従来XeonとSCの間で必要であったメモリ転送が必要なくなる。

メモリ
↑ Xeon
↓ SC SC SC SC
メモリ メモリ メモリ メモリ

  ↓

メモリ
  MIPS
  SC2


Page 50

PEZY-SC2の特徴

? CPUとSC2の協調動作の強化
? 各種命令セットの補強
? (大きな変更なく)SCのプログラムをそのままコンパイル・実行できる

263>>2622018/07/30(月) 07:16:03.73ID:wOzVCFyH?2BP(0)

Page 51

外部に公開している情報

? 若干のサンプルプログラム
? Doxygenで自動生成されたAPIリファレンス
? 簡単なアーキテクチャ説明資料
? 簡単なプログラミングマニュアル


Page 52

外部に公開している情報

? 若干のサンプルプログラム
? Doxygenで自動生成されたAPIリファレンス
? 簡単なアーキテクチャ説明資料
? 簡単なプログラミングマニュアル



? ユーザポータルを作成してここに各種情報を集約していく予定です(2017/1予定)
  ? PEZYと個別にNDAのやり取りを行い、その後に参加して頂くようになります。

264>>2632018/07/30(月) 07:17:26.14ID:wOzVCFyH?2BP(0)

Page 53

開発中/予定のソフトウェア

? 物理系シミュレーション
? 開発環境
  ? OpenACC/OpenCL/PUDA(!)・・・
? 量子計算シミュレーション
? メタゲノム解析ツール
? ニューラルネット
  ? Caffe/・・・
? 数値計算ライブラリ
  ? BLAS/FFT・・・
? ・・・


Page 54

ご興味がありましたら
ishikawaATpezy.co.jp
お気軽にご連絡ください

265>>217-2642018/07/30(月) 07:23:05.62ID:wOzVCFyH?2BP(0)

>>217-264
>4 YAMAGUTIseisei 180610 0143 OGJRAL12?
>>145 オryー 180203 1039 lpGi+Bkf
> :
>> 技術流出を防ぐためにペジー社は守る!?
>>http://m.youtube.com/watch?v=PZ-5ORv783Q
>
>
>>5 yamaguti~貸 170319 2042 cRK6Y+kv
>> 【櫻LIVE】 齊藤元章・PEZY Computing代表取締役社長 × 櫻井よしこ(プレビュー版)
>> http://m.youtube.com/watch?v=9cGdcLAbSu4
> :

266>>2652018/07/30(月) 07:23:57.02ID:wOzVCFyH?2BP(0)

>831 オryー 180706 1751 H22QHp/d
> 第51回のTop500は米国のSummitが中国から首位を奪回 | マイナビニュース
>http://news.mynavi.jp/article/20180706-659829/
:
>。もし運用 ry 、20.41PFlopsでTop500 5位 ry 、幻 ry 。ExaScalerでは、暁光を設置 ry 主体を募集 ry 、きちんと運用 ry 、国内でなくても良い

>832 オryー 0706 2235 kFCxLR3J
> 中国だな

267>>1732018/08/12(日) 20:42:35.91ID:ltAhnLdz?2BP(0)

>>184-216
http://rio2016.2ch.net/test/read.cgi/future/1481407726/105-154
>153 >>152 180812 2027 ltAhnLdz?
> >>105-152
> http://rio2016.2ch.net/test/read.cgi/future/1489922543/184-216
> >184 yamaguti 180727 0129 pBBIx/eO?2BP(0)
>> >>46 >>173 >>152-183
>> Google 翻訳
>>
>> これは、ファイル http://microsoft.com/en-us/research/wp-content/uploads/2016/02/e2-heart2010.pdf
>> の html版です。 Google
> :
>> E2ダイナミックマルチコアアーキテクチャにおける動的ベクトル化
>> 2010 HEART 2010の議事に出席する
> :


>154 >>153 180812 2033 ltAhnLdz?
>
> >>153
> http://arxiv.org/pdf/1803.06617.pdf#20180712120421
> http://mobile.twitter.com/jangray/status/1004874394957578242
> http://www.cs.utexas.edu/~cart/publications/dissertations/asmith.pdf#20150619203042
> http://www.cs.utexas.edu/users/mckinley/papers/trips-eval-asplos-2009.pdf#20151129082813
> http://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/trips-compiler-cgo4.pdf#20180619043037
> ftp%3A//ftp.cs.utexas.edu/pub/dburger/papers/IEEECOMPUTER04_trips.pdf#20170706111151
:
https://twitter.com/5chan_nel (5ch newer account)

268YAMAGUTIseisei2018/08/20(月) 01:55:24.80ID:xpTaf9mR?2BP(0)

HPKY 型 汎用 AI/AL
>>179 >>152 リンク先 > http://rio2016.2ch.net/test/read.cgi/future/1508026331/774# JinkakuSisutemu Sikumi >105-107
>774 yamaguti~貸 171020 1534 0nNF/MoU?
> >673 \> NN ベース AI というよりもいわば設計ベース AI ( AL ) + NN という事ならば説得力
>
> 従来予想 : 超強力弱い AI ( 粒度 時間方向割当度 → 強い AI 度 ) ( >5 168 )
> >371 yamaguti~貸 171011 1322 gs4iO9ie
>>+
>>粒度さえ充分に細かければ ( + データと計算機パワー 資金力 ( +
>>接地 必ずしも不要
>> http://rio2016.2ch.net/test/read.cgi/future/1505836194/217#280#284#998# EraaNaihou
>
>>+ データと
>↑ 学習済高低レイヤモジュール : 充実 ( 不足致命的ならず ) ?
>
> → 自然言語解釈動記憶システム ( 接地 ( 効果 ) 論理物理スロット シミュ ( 準 ) エミュ ) ≒ 人格システム ( 学習済モジュールベース )
>
>
>+ AutoML ( 等 ) での設計最適化 → 最早いわば設計ベース AI ( AL ) + NN ≒ 弱い強い AI ( AL ) ?
> >814 yamaguti~貸 171007 2158 ziH696dX?
>>>最適な設計を、AutoMLで探し出 ry 、AutoMLを使用した設計が、 ry 翻訳では専門家を完全に凌駕
>
> → 導かれる構造の例 ( 上記条件下 ) : 外部記憶比重 >>709 ⇔ 追加学習比重 ( 極論 : 不要 ) ( ≒ 簡易版強い AI ( AL ) )
> 但し 敢て追加学習 → 極論 : 転移学習だけで良い ( 下記文脈 )
>ry http://mobile.twitter.com/ken_demu/status/918820770456858624
>>>>DNNにMeta-Learning + ゲーム理論と転移学習( ry )と強化学習(人間の目的指向の再現)を組み合 ry AGIっぽ ry
>>>>>>>>> >482 自然言語解釈
>>>>>>>>>DeepMind : DNC のスロットベーススロットをスロットに見立てる等 \> ( → 整備済 )
> +
> http://rio2016.2ch.net/test/read.cgi/future/1506697885/814# JinkakuSisutemu Sikumi
>>814 yamaguti~貸 171007 2158 ziH696dX?
>>>> この国だけに配慮致します立場でなくなってしまいましたので申上げます
https://twitter.com/5chan_nel (5ch newer account)

269YAMAGUTIseisei2018/08/20(月) 02:36:33.99ID:xpTaf9mR?2BP(0)

>>268
>>>+ データと
>>↑ 学習済高低レイヤモジュール : 充実 ( 不足致命的ならず ) ?

必ずしも充実不要 ( 一見致命的不足状態も条件次第で可 )

270YAMAGUTIseisei2018/09/08(土) 00:07:50.66ID:sHJfJTCE?2BP(0)

>>269
> YAMAGUTIseisei wrote:
>> HPKY 型 汎用 AI/AL
>> DSL 型 汎用 AI/AL
>> 他
>>
>>
>> >179 yamaguti 180602 1505 5+vbS3Cj?
>>> >>162 >>152 >>178 辞書ベース
>>>> 23 yamaguti 180523 0850 nChEz1ni?
>>>>> 10 NN ベース辞書ベース例 ( 候補例 : テキストベース辞書ベース )
>>>>> 13 >22 >> この国だけに配慮致します立場でなくなってしまいましたので申上げます
>> :
>>
>>
>> >268 YAMAGUTIseisei 180820 0155 xpTaf9mR?
>>> HPKY 型 汎用 AI/AL
>>>>>179 >>152 リンク先 > http://rio2016.2ch.net/test/read.cgi/future/1508026331/774# JinkakuSisutemu Sikumi >105-107
>> :
>>
>>
>> >269 YAMAGUTIseisei 180820 0236 xpTaf9mR?
>>>>>268
>>>>>> + データと
>>>>> ↑ 学習済高低レイヤモジュール : 充実 ( 不足致命的ならず ) ?
>>> 必ずしも充実不要 ( 一見致命的不足状態も条件次第で可 )
>>
>> データなし + 学習機構なし ( NN 等なし ) 可 ( 禅 無 空 )
>>
>> 関連 時間方向粒度 : 疑似接地 ( 超高精度耳年増 )
:

271YAMAGUTIseisei2018/09/08(土) 00:18:18.50ID:sHJfJTCE?2BP(0)

272YAMAGUTIseisei2018/09/16(日) 18:40:23.27ID:m2szPimC?2BP(0)

>>189 >>267 >>184-216
YAMAGUTIseisei wrote:
>> E2ダイナミックマルチコアアーキテクチャにおける動的ベクトル化
>
> 訂正
>
>> スカラーモードでは、どの命令もブロック内の他の回路にオペランドを送信でき、電力を節約するためにALUのうち2つを除くすべてがオフになります。
>> ベクタモードでは、すべてのN個のALUはオンになっていますが、回路は同じベクタレーンの回路にのみオペランドを送信できます。
>
> スカラーモードでは、どの命令もブロック内の他の命令にオペランドを送信でき、電力を節約するためにALUのうち2つを除くすべてがオフになります。
> ベクタモードでは、すべてのN個のALUはオンになっていますが、命令は同じベクタレーンの命令にのみオペランドを送信できます。

273>>2702018/09/16(日) 21:30:31.65ID:m2szPimC?2BP(0)

> YAMAGUTIseisei wrote:
:
>> dahara1 氏
>> Universal Transformerを用いて翻訳を超える
>> http://webbigdata.jp/ai/post-1575
>>> 以下、ai.googleblog.comより「Moving Beyond Translation with the Universal Transformer」の意訳です。
>> 要約
>>
>>
>>
>> 目次
>>
>> * 1. ry まとめ
>> * 2. ry Transformerをより汎用的にしたUniversal Transformer
>> * 3. ry 感想
>> * 4. ry まとめ
>>
>> 1. ry まとめ
>>
>> ・機械翻訳で圧倒的な ry Transformerをより汎用的にしたUniversal Transformer ry
>> ・ry 曖昧な単語をより深く調べるように動的に動作を変更する事ができる
>> ・Transformerは翻訳以外の作業は不得意だが、Universal Transformerは様々な作業に応用できる

274>>2702018/09/16(日) 21:31:48.49ID:m2szPimC?2BP(0)

>> 2.Transformerをより汎用的にしたUniversal Transformer
>>
>> 以下、ai.googleblog.comより「Moving Beyond Translation with the Universal Transformer」の意訳です。
>>
>> 昨年、我々は既存の機械翻訳や、その他の自然言語を扱う既存 ry よりも顕著な成功 ry 機械学習モデルであるTransformer ry
>>
>> Transformer以前のニューラルネットワークに基づく機械翻訳アプローチの大半は、文章の先頭から順番に処理をしていました。
>> これはRNN ( ry ) ry 、RNNは文章を先頭から順番に ry 、ある文を翻訳した結果を続く文を翻訳する際にインプットに利用 ry
>> 、前の段落の文脈を捉え ry 、 RNNは文書のような連続する処理( ry )において非常に強力ですが、 ry
>> 、長い文章ではより多くの処理ステップと時間 ry 、またそれらの繰り返し構造は人工知能を適切に学習 ry 困難
>>
>> ry 対照的に、Transformerでは全ての単語またはシンボルを並列に処理しながら、セルフアテンションメカニズムを使用して、
>> 離れた位置の文章から文脈を組み込む ry 。並行して全ての単語を処理しつつ、
>> 複数の処理ステップにわたって各単語を文中の他の離れた単語の解釈時に入力情報とし ry 速く訓練
>>
>> ry 。しかしながら、より小さく構造化された言語を理解する作業、またはもっとシンプルな文字列のコピー( ry ) ry
>> 、トランスフォーマはあまりうまく ry 。対照的に、Neural GPUやNeural Turing Machineなどの既存 ry
>> は前述のようなシンプルなタスクでは上手く ry が、翻訳のような大規模な言語理解タスクでは上手く動作しません。
>>
>> ry Transformerを、斬新で効率的なparallel-in-time recurrenceを使用し、
>> 計算的に様々なタスクに応用できるチューリング完全なUniversal Transformersに拡張
>>

275>>2702018/09/16(日) 21:34:08.86ID:m2szPimC?2BP(0)

>> 2.Transformerをより汎用的にしたUniversal Transformer
>>
>> 以下、ai.googleblog.comより「Moving Beyond Translation with the Universal Transformer」の意訳です。
>>
>> 昨年、我々は既存の機械翻訳や、その他の自然言語を扱う既存 ry よりも顕著な成功 ry 機械学習モデルであるTransformer ry
>>
>> Transformer以前のニューラルネットワークに基づく機械翻訳アプローチの大半は、文章の先頭から順番に処理をしていました。
>> これはRNN ( ry ) ry 、RNNは文章を先頭から順番に ry 、ある文を翻訳した結果を続く文を翻訳する際にインプットに利用 ry
>> 、前の段落の文脈を捉え ry 、 RNNは文書のような連続する処理( ry )において非常に強力ですが、 ry
>> 、長い文章ではより多くの処理ステップと時間 ry 、またそれらの繰り返し構造は人工知能を適切に学習 ry 困難
>>
>> ry 対照的に、Transformerでは全ての単語またはシンボルを並列に処理しながら、セルフアテンションメカニズムを使用して、
>> 離れた位置の文章から文脈を組み込む ry 。並行して全ての単語を処理しつつ、
>> 複数の処理ステップにわたって各単語を文中の他の離れた単語の解釈時に入力情報とし ry 速く訓練
>>
>> ry 。しかしながら、より小さく構造化された言語を理解する作業、またはもっとシンプルな文字列のコピー( ry ) ry
>> 、トランスフォーマはあまりうまく ry 。対照的に、Neural GPUやNeural Turing Machineなどの既存 ry
>> は前述のようなシンプルなタスクでは上手く ry が、翻訳のような大規模な言語理解タスクでは上手く動作しません。
>>
>> ry Transformerを、斬新で効率的なparallel-in-time recurrenceを使用し、
>> 計算的に様々なタスクに応用できるチューリング完全なUniversal Transformersに拡張
>>

276>>2702018/09/16(日) 21:34:53.21ID:m2szPimC?2BP(0)

>> ry 訓練速度を維持するために並列構造を構築、Transformerの異なる変換関数を
>> 複数の parallel-in-time recurrentな変換関数に置き換えました。(下図のように同じ変換関数が、
>> 複数の処理ステップにわたって並列に、全てのシンボルに適用され、各ステップの出力が次のステップの入力に
>>
>> 重要なことは、RNNがシンボルを順次処理するケースで、Universal Transformerは全てのシンボルを
>> (Transformerのように)同時に処理します。しかし同時にUniversal Transformerはセルフアテンションを使用して
>> 平行に複数回、再帰的に反復処理を行い、 ry 解釈を改善します。このparallel- in-time recurrence ry は、
>> RNNで使用されている順次処理する再帰的メカニズムよりも高速であり、 ry 標準的なフィードフォワードTransformerより強力
>>
>> Universal Transformerは、セルフアテンションを使用して異なる位置からの情報を結合し、反復遷移関数を適用することによって、
>> シーケンスの各位置について一連のベクトル表現(h1〜hmとして示される)を繰り返して品質を向上します。矢印は操作間の依存関係
>>
>> 各ステップでは、オリジナルのTransformerと同様に、セルフアテンションを使用して、各シンボル
>> (例えば、文中の単語)から他の全てのシンボルに情報が伝達 ry 、この変換 ry (すなわち反復段階の数)は、
>> ry ( ry 、固定数または入力長に設定 ry )、またはUniversal Transformer自体によって動的に決定
>>
>> 後者の機能を実現するために、各位置に適応計算メカニズム ry
>> 、あいまいなシンボルやより多くの計算を必要とするシンボルに、より多くの処理ステップを割り当
>>
>> ry bankは、「銀行」、「土手」、「堤防」、「岸辺」、「海浜」、「塚」
>> :
>> 例えば単語「bank」 ry 厳密にするためにより多くの計算ステップ ry 追加的な文脈情報を統合
>>

277>>2702018/09/16(日) 21:36:28.00ID:m2szPimC?2BP(0)

>> ry 単一の関数を繰り返し適用する事が制限のように見えるかも ry
>> 、特に異なる機能に異なる関数を適用する標準のトランスフォーマーと比較した場合は。しかし、
>> 1つの関数を繰り返し適用する方法を学ぶことは、アプリケーションの数(処理ステップの数)が可変
>>
>> 、Universal T ry がより曖昧なシンボルに多くの計算 ry 以外に、モデルは、 ry 関数アプリケーションの数を増減するか、
>> トレーニング中に学習された他の特性に基づいて入力の任意の部分に改良を適用することがよくあります。
>> これにより、 ry 、入力のさまざまな部分に異なる変換 ry 効果的に学ぶことができ、理論的な意味でもより強力 ry
>> 。これは、標準のTransformerでは実行できない ry 。標準のTransformerでは学習済み変換ブロックが1回だけ
>>
>> ry 実証的なパフォーマンスにも気をつけています。 ry 文字列のコピーや逆順にソート、整数加算などを
>> TransformerやRNNよりはるかに上手に学ぶことができることを確認 ry 。さらに、多様な言語タスクを理解するために、
>> ry bAbI linguistic reasoning task とLAMBADA language modeling taskに挑戦し、最新のスコアを達成
>>
>> 、同じトレーニングデータで同じ方法で訓練された同じ数のパラメータを持つ従来のTransformerに対して、0.9 BLEUだけ翻訳品質を向上 ry
>> 、元のTransformerは昨年 ry 従来の機械翻訳モデルより2.0 BLEUのスコア改善 ry 、それに更に約50%の相対的な改善
>>
>> Universal T ry は、このように、「実用的なシーケンスモデル(機械翻訳などの大規模な言語理解モデル)」と
>> 「計算上ユニバーサルなモデル (Neural Turing MachineやNeural GPUなどの勾配降下法を使って
>> 任意のアルゴリズムを実行することができるモデル)」とのギャップを埋めます。
>>

278>>2702018/09/16(日) 21:37:07.19ID:m2szPimC?2BP(0)

>> 私達は、最近のparallel-in-time sequence modelsを開発して計算量と再帰処理の深さを高める事、及び、
>> ここで紹介した基本的なUniversal Transformerにさらなる改良を加えてより強力でよりデータ効率の良い学習アルゴリズムを構築する事、
>> それらが、現在の最先端技術を超えた学習アルゴリズムの一般化に繋がる事に情熱を燃やしています。
>> ここで紹介する ry さらなる改良が、より多くの学習アルゴリズムを構築するのに役立つことを願っています ry
>> 、現在の最先端技術を超えて一般化されています。
>>
>> 、Universal Transformerの学習と評価に使用されるコードは、オープンソースとしてTensor2Tensorリポジトリ
>>
>> 謝辞
>> この研究は、Mostafa Dehghani、Stephan Gouws、Oriol Vinyals、Jakob Uszkoreit、および?ukaszKaiserによって行われました。
>> 実り多いコメントとインスピレーションのため、Ashish Vaswani、Douglas Eck、David Dohanに感謝します。
>> 3. ry 感想
>>
>> やっている事自体は人間が翻訳時に無意識にやっている事の真似で「曖昧な単語について前後の文脈を見て何度も意味を推測する。
>> 曖昧でない単語は特に注目せずにさっと翻訳する」だけの話なのですが、それを実現している所が凄いですね。
>>
>>「チューリング完全」 ry 、応用範囲が一気に広が
>> 4. ry まとめ
>>
>> 1)ai.googleblog.com
>> Moving Beyond Translation with the Universal Transformer
>>
>> 2)arxiv.org
>> Universal Transformers
>>
>> 3)github.com
>> universal_transformer.py
>>
>>
>>
>>

279>>272-2762018/09/16(日) 21:39:08.85ID:m2szPimC?2BP(0)

280>>272-2762018/09/16(日) 21:39:28.50ID:m2szPimC?2BP(0)

>>> 183 名前:yamaguti E-mail:1427220599/490sage492 投稿日:2018/06/25(月) 02:58:02.57 ID:wuqwxjPG?2BP(0)
>> :
>>>>> 182 >>178-179 >>114 ( 一形態 : 物理空間融合レンダ 仮想空間融合レンダ 意味空間融合レンダ 人格システム )
>>>> DeepMind : DNC のスロットベーススロットをスロットに見立てる等 ( 下手すれば 2018 年にも目鼻 )
>>>> 目鼻 → 1 年以内 ? 一まずの変革完了 ( ≒ 曲りなり特異点 ? ) → 1 年以内 ? 接地構造手直し完了 ( ≒ 特異点 ? )
>>>>>> 178 3D ゲーム環境内疑似コマンド限定接地
>>> ↓
>>> GQN : 現実 3D 空間対応基盤 (
>> :
>>
>>
>>> 、計算的に様々なタスクに応用できるチューリング完全なUniversal Transformers
>> 汎用
>>
>>
>>

281>>272-2762018/09/16(日) 21:42:13.69ID:m2szPimC?2BP(0)

282>>272-2762018/09/16(日) 21:42:41.84ID:m2szPimC?2BP(0)

>>> 、Transformerでは全ての単語またはシンボルを並列に処理しながら、 ry 、離れた位置の文章から文脈を組み込む ry 。
>> ry 処理しつつ、複数の処理ステップにわたって各単語を文中の他の離れた単語の解釈時に入力情報とし ry 速く訓練
>> :
>>> ry Transformerを、斬新で効率的なparallel-in-time recurrenceを使用し、
>> 計算的に様々なタスクに応用できるチューリング完全なUniversal Transformersに拡張
>>
>>
>>> 145 yamaguti~貸 171005 1350 Mw10xW3l? \>482 yamaguti~貸 170923 1906 gJe8GJca? \>182 yamaguti 180617 0148 GMgC8zpV?
>>> :
>>>> 631 yamaguti~貸 170925 0009 mWACkEZG?
>> :
>>>>>> 482 自然言語解釈
>>>>>>> 479 >>241 >255
>>>>> DeepMind 又カーネギーメロン大が最近達成した
>>>>> 3D ゲーム環境内疑似コマンド限定接地の仕組を多重化すれば可能 ( 強力版弱い AI )
>>>>>
>>>>> DeepMind : DNC のスロットベーススロットをスロットに見立てる等 ( 下手すれば 2018 年にも目鼻 )
>> :
>>
>>> 178 yamaguti 180528 1227 x4HB0Rxw?
>>>>> 145 メタ
>>>>>> DeepMind 又カーネギーメロン大が最近達成した
>>>>>> 3D ゲーム環境内疑似コマンド限定接地の仕組を多重化すれば可能 ( 強力版弱い AI )
>>>>>>
>>>>>> DeepMind : DNC のスロットベーススロットをスロットに見立てる等 ( 下手すれば 2018 年にも目鼻 )
>> :
>>

283>>2822018/09/16(日) 21:44:46.87ID:m2szPimC?2BP(0)

>>280
順序間違い
>>282 >>280 の順

284>>280-2832018/09/16(日) 21:46:04.43ID:m2szPimC?2BP(0)

>>> 23 名前:yamaguti E-mail:1531923755sage330 投稿日:2018/07/29(日) 12:06:53.16 ID:xu0GwKe6?-2BP(0)
>>>> 310 yamaguti 180721 2201 1u89Awcb?
>>>>> 289 \>>Universal Transformersがタイムステップ+ポジションで位置情報変化
>>> :
>>>>> 405 オryー 180714 1249 D84wNS6G
>>>> :
>>>>> 言語の特徴量ベクトルにタイムステップとポジション(時間間隔と位置情報)を付加した上で \>> 1つ1つのシンボルではなく、全てのベクトルを再帰処理に回す手法
>>>>
>>>> 再帰効果 ( 上記文脈 ) エミュの究極 ( 完全汎用 AI/AL )
>>>>> 14
>>>>> http://rio2016.2ch.net/test/read.cgi/future/1489922543/152### HPKY gata Hannyou AI/AL \> 機械学習限定論ご遠慮下さ
>>
>>>>> 再帰効果 ( 上記文脈 ) エミュの究極 ( 完全汎用 AI/AL )
>> 補足
>> △ 言語の特徴量ベクトルにタイムステップとポジション(時間間隔と位置情報)を付加 ( 数理発想 )
>> ○ タイムステップとポジション ( 時間間隔と位置情報 ) に言語の特徴量ベクトル情報を割付け ( 非数理発想 哲学発想 )
:

新着レスの表示
レスを投稿する