研究ブログ

うだうだWeblog2 Researchmap出張版

2024年研究(あくまで)計画表

2024年
(1) 第193回HPC研究発表会 2024-03: 2024-01申込〆切, 2024-02予稿〆切
 「マルチコンポーネント型多倍長精度浮動小数点演算を用いた複素LU分解の高性能化」
(2) ICCSA 2024 2024-07:2024-03-15(金) 〆切
 「Performance evaluation of accelerated complex multiple-precision LU decomposition」
(3) 静岡理工科大学紀要原稿:2024-03-26(火)提出22(金)〆切
 「指数部長の長い多倍長精度浮動小数点演算に対応した尾崎スキームの実装
 「Pythonプログラミング環境における多倍長複素線形計算の高速化」
(4) SWoPP2024: 2024-05申込〆切,2024-06予稿〆切
 「SIMD + OpenMPを用いた多倍長精度SpMVの高速化(とその応用)」
(5) 第50回数値解析シンポジウム: 講演申込2024-05-01〆切, 予稿2024-05-22〆切
 「Lanczos法とDKA法を用いた多倍長精度固有値ソルバーの性能評価」
(6) ICNAAM 2024 2024-09: 2024-06投稿〆切:5月以降の課題
 「Rebuilding ODE solver using optimized multiple precision BLAS」or
 「Accelerated real and complex LU decomposition and its application on Python environment」
(7) 環瀬戸内応用数理部会第28回シンポジウム: 2024-11申込?
 「Python環境における可変長精度数値計算モジュールの実装と性能評価」
 or 「多倍長精度ODEソルバーの高性能化」
 or 「WASMを用いたWeb上の多倍長精度線形計算の高速化」or「Pythonを用いた高速多倍長精度数値計算環境の実装と性能評価」

2025年

(1) HPC研究発表会: 2025-01申込〆切, 2025-02予稿〆切, 2025-03発表
「混合精度同時反復法のMPI並列化」
(2) ICCSA2025:2025-03〆切
「Performance evaluation of multiple-precision eigenvalue solver with Lanczos and DKA method」
(3) 静岡理工科大学紀要原稿:2025-03〆切
「多倍長精度数値計算の過去・現在・未来」
(4) SWoPP2025: 2025-05申込〆切, 2025-06予稿〆切
「未定」
(5) 第51回数値解析シンポジウム: 2025-05申込〆切, 2025-06発表
「未定」
(6) 環瀬戸内応用数理部会第29回シンポジウム: 2025-11申込〆切, 2025-12発表
「未定」

2026年, 2027年, 2028年, 2029年, 2030年, 2031年, 2032年, 2033年, 2034年

2023年 研究集会・論文〆切予定表

 文字数制限のため,あまり書き込めないこのblog機能,使い道がないかと思っていたが,研究集会参加と論文〆切の予定をチマチマ書く程度なら,制限にも引っかからずに済むと考えたので試しにやってみることにする。2022年内〆切のものはもうないので,2023年度から開始というのも切りが良い。来年度以降は院生さんも修了しているので,のんびり定常運転(査読1~2件,口頭2~3件)ペースでやっていくつもりです。

2023年
(1) IPSJ ACS論文誌 1月中旬〆切→1/20(金)投稿完了
 打桐・幸谷「Ozakiスキームを用いた多倍長精度行列乗算の高速化」
(2) HPC研究会 2023-03-15 - 17:2023-01-13(金)申込済,2023-02-13(月) 23:59原稿〆切→2/13(月)提出完了
 幸谷・打桐「最適化した多倍長精度基本線形計算ライブラリの開発」
(3) ARITH 2023:2023-03-12(日)投稿〆切→4/30(日)投稿・校正済み
 幸谷「Acceleration of complex multiple-precision matrix multiplication using Strassen algorithm and Ozaki scheme」
(4) 静岡理工科大学紀要原稿:2023-03-24(金)〆切→3/23(木)投稿完了
 幸谷「数値計算における統計的誤差推定方法の提案」
(5) ICCSA 2023 2023-07-03 - 06:2023-03-26(日)〆切→3/23(木)投稿完了
 幸谷・打桐「Optimization of multiple precision LU decomposition using Ozaki scheme」
(6) ICIAM 2023 :2023-08-20 - 25(早稲田大学早稲田キャンパス) 2023-04-20(木)アブストラクト〆切→2/1(水)投稿完了
Mini Symposium "Exploring Arithmetic and Data Representation Beyond The Standard in HPC" 参加(受理済み)
 幸谷「Implementation of highly optimized multiple precision BLAS: Strassen vs. Ozaki scheme」
(7) SWoPP2023: 2023-05申込〆切,原稿〆切 2023-06-30
 幸谷「マルチコンポーネント型多倍長精度複素行列乗算の実装と性能評価」(HPC)
 幸谷「多倍長精度演算を用いた直接法に基づく実行列の固有値計算の試み」(MEPA)・・・できるかな?(無理)
(8) 第49回数値解析シンポジウム2023-05-26申込,原稿〆切 2020-06-23
 幸谷「3M法を用いたマルチコンポーネント型多倍長精度複素BLASの実装と性能評価」(しないかも)
(9) ICNAAM 2023 2023-09-11 - 17: 2023-06-26 (月)投稿〆切
 Tomonori Kouya, "A proposal of statistical round-off error estimation and its application on TensorFlow"(間に合わず)

(10) 環瀬戸内応用数理部会第27回シンポジウム

「3M 法を用いたマルチコンポーネント型多倍長精度複素LU 分解の性能評価」

 

研究日記

このblog,文字数制限があってあまり沢山書けないので,ついつい放置状態になってしまうので,使い方を考えた結果,日々少しずつ行っている研究活動をメモ代わりに書き付けておくという手があることに気がついた。ということで,なるべくこれからは本日やったことをここに書き付けておくことにする。自分以外には全く役に立たない記事だが,読まれることを想定しないのでこれで良いのである。何より,SNS連携していないところが良い。

  1. 行列乗算,行列ベクトル乗算ベンチマーク・・・Corei9マシンとEPYCマシン。Xeonマシンはまだ別の計算中。
  2. テスト行列生成プログラムのC++実装・・・Pythonで書いてある奴が,mpmathを使っている関係上,めちゃくちゃ遅いのでMPLAPACKと自分のライブラリで実装し直し。
  3. 混合精度反復改良法ののベンチマークテスト・・・まだ構想段階。できればArithに投稿したいが間に合うかどうか。

 今日はこんなところで。

「万年助手」についての一考察

 日本の大学において,専任教員としての職位は次のように決められている。

  1. 教授・・・いわゆるfull professor
  2. 准教授
  3. 講師・・・ないところもある
  4. 助教

「助手」は助教に繋がるステップとして残してある大学もあるようだが,基本,講義を担当できないのでここでは教員としては考えない。

 大学内部のことに詳しくない人でも,一番偉いのが教授で一番下っ端が助教,准教授は教授の一つ下,というぐらいは知っているのが普通である。ただ「講師」というのが「常勤」なのか「非常勤」なのかが分かりづらいのが困ったところで,講師暦12年のワシは区別のためにあえて「常雇です」と説明する必要があったりした。だもんで,助教の次は准教授にステップアップし,准教授に階層を付けるケースもあるようだ。

 さて,大学という組織にいる以上は,教員たるもの全員「教授」を目指すべきであるし,そうでないと組織的にも困るんだけど,純粋に一個人の幸せを追求する方々におかれましては,そーゆー「上昇志向」が皆無であるというケースもあるんだなこれが。

 今や死語となったが「万年助手」という高貴なご身分がまかり通った時代が昭和にはあったのである。今で言うところの「助教どまり」のことであるが,イマドキの大学なら助手は助教は年限付きのケースが多かろうし,最近はどの職位で入ったとしても問答無用で年限付き(更新あり)だったりするケースも珍しくないので,現代の常識に鑑みて信じがたいことではあるけれど,助手という腰掛が定年まで安泰だった時代があったのである。・・・なんともはや,給料が頭打ちになることを除けば羨ましいご身分なのである。

 受け持つ講義は皆無,せいぜい実験や演習の手伝いをすればよく,空き時間は全て自学自習,研究三昧の生活を定年まで送れるとあらば,今でもそれを望む向きが結構な率で存在するのではないか。最下層から上役たる教授に物申しつつ建設的な意見書なんぞメンドクサイ,ふんぞり返ってどんな出世の圧力に対しても馬耳東風,かういふひとにわたしはなりたひ。無理だけど。

 一人でコツコツ論文を仕上げては年に1~2本投稿するというペースで仕事ができたらいいな,と夢想する向きは今でも結構いるんじゃないのかなとは思うが,科研費や企業研究費をガツガツ持ってこない限り,やりたい実験も手数も足りないという分野が多い昨今では,こういう牧歌的な態度の教員は時限付きで放り出したい,というリストラ圧力は高かろう。そういう文科行政に対する批判は多いが,さてそれは日本だけなのかなと考えると,一概に否定はできまい。そういうグローバル的に吹き荒れる圧力に左右される役職者(学長,学部長,学科主任等々)から見れば,「万年助手」的教員は,個人的信条としては憧れ的な存在ではあるけれど,組織的,というより上に忖度しなきゃいけない立場からすれば,厄介な「杭」のように思えてしまうのである。

 牧歌的な万年助手が,教育的学術的に優れた存在であれば,それはそれでいいし,かつての昭和の万年助手の中にはそーゆー人も,少数ながら存在した。しかし多数はそうではないし,基本「もちっと(学術にしろ内部事務にしろ教育にしろ)仕事してよ」と言いたくなるものであるからして,現在日本から万年助手が消え去るのはやむを得ない。ノスタルジーに浸る前に,教授目指して昇進することの意義をまじめに考えて欲しいなぁと思う,コロナウィルス騒ぎでPCR検査もままならない日本の学術研究の貧相さにため息が出る今日この頃である。

社会システムは「崩壊」しない

 書店を覗くのが趣味であるが,ビジネス書の類はあまり読まないようにしている。人生論や組織論には基本興味がない。生身の人間がぶつかり合った記録,特に政治に関するルポルタージュ物は大好きで,さいとうたかをが漫画化した「小説吉田学校」は全巻コンプリート,読売新聞から単行本が出る毎に買って読んでいた。常に権力の中枢を担ってきた与党の権力争いは非常に興味深い人間ドラマに満ちていて,示唆に富んだ出来事が次々に起きる。何より,日本という国が続いている限り,日本政府は存続し,その機能を担っている官僚組織も,変わることはあっても消え去ることはない。総理大臣は嫌になったら「いち抜ぅけた!」などと気楽に辞められるが,それは政府を束ねる要の顔が変わるだけのこと。内閣は崩壊なんかしやしないのである。存続を前提とした権力機構を巡る人間臭いドラマは誠に面白い読物であり,故に野党のお利口さん的批判は,権力を担っていない分,正しいが故につまらない空疎なアピールに終わってしまうのであろう。
 翻って,社会組織が「崩壊」するだのという言説が昨今はやっているが,人間がそこにいる限りは組織や制度は変わることはあっても崩壊なんかしないのである。「崩壊して欲しい」,「崩壊させたい」という願望はあるのだろうが,その社会組織を担っている当事者にしてみれば「So what?」である。人が消え去れば,組織や制度は消える,そうでなければそのまま存続するか変わるだけだ。故に私は「崩壊」を言いたがる輩を一切信用しないことにしている。変化のためにする有用な提言以外は聞く耳を持つ必要はないと,この先が見えている残り少ない現役生活を有効活用すべく,馬耳東風的態度を身に付けようと目下努力しているのである。

役職者から見た大学教員の活動

Work Flow in Univ.
 役職者になったので,ちょいとその立場から,大学教員の仕事がどのようなものなのか,どのように見えているのかを書いておく。あくまで本学,つまり,田舎の小規模な理工系私立大学の話なので,大規模大学や国公立大学とは違っている点も多々あろう。ま,一事例として読んで頂ければ幸いである。
 大学教員は基本,学識のある研究者として位置付けられている。最近はそうではないケースもあるようだがここでは扱わない。あくまで学術研究のできる,適宜,まとまった成果を論文等で公表できる能力を持つ人物を専任教員(助教,講師,准教授,教授)として雇うのが基本である。
 では論文だけ書いていればいいかというとそうもいかない。大学は教育機関なので,業務量の半分は教育に割いてもらわないと組織として成立しない。講義や卒業研究,大学院があればゼミ等も適宜行う必要がある。その他,税金を受け入れている以上は,地域貢献,広報活動の一環として,模擬講義や出張講義,公開講座も担ってもらわねば困る。
 ただ,これらの教育活動や広報活動の土台は各教員の学術研究活動にある,という大原則が存在していることはしっかり認識しておく必要がある。人によっては書籍を執筆したり,旧来のTVメディアに出演したりすることもあろうが,これらも例外ではない。かくして,上記のような学術研究活動が中心に据えられた図が展開されることになる。もちろん,各教員が築いた独自の学術研究ネットワークが組織を超えて存在している訳だが,ジャンルの異なる一組織の役職者から見えるのはこの図に書いた活動だけである。
 どの組織でも年度ごとに業績評価というのは行われている訳だが,その内訳もこの図に書いたものにとどまる。大体,中核の学術研究活動が活発な教員は,教育にしろ広報活動にしろ積極的に行っていただけるので,誠にありがたい存在である。多分,矢印に示すような,各活動によって得られるノウハウ(スタッフの募集や的確な指示,教材開発等)が他の活動に活かせるということも大きいのだろう。かくしてこの活動の図は,それぞれのサービスの受益者から支持されて引っ張られ,どんどん広がっていくわけである。
 問題はその逆のケース。個々人の事情があるのは重々承知しているが,何せ大学教員というのは学術研究の徒であると同時に,屁理屈の塊みたいな御仁が多いので,あれこれブツクサ言ってろくすっぽ動いてくれないケースがあるのである。役職者としては働かない教員の分を働いてくれている教員に報いれば済むだけだし,ええ歳こいた教員の人生観に嘴はさむつもりは無いのだけれど,動かないと上記の図の輪がどんどん狭くなって益々活動エリアが狭まるだけなので,なるべく若いうちは面倒臭がらず,あれこれやっておく事をオススメしたい。まぁそのおかげで役職者になっても公開講座を担当させられたりするのは,流石にヤリ過ぎたという気がしないでもないが。

新入生へのあいさつ

 ご入学おめでとうございます。静岡理工科大学情報学部へようこそ。これからの学部4年間,大学院に進まれる方は2年間,頑張って人生を切り開く第一歩を踏み出して行かれることを願っています。

 もう散々私より偉い人たちのご高説を聞いてきたので,飽きていると思います。私からは簡潔に一つの言葉と,それに対する若干の解説をして早じまいしますので,もう少し我慢して下さい。

 皆さんは「耳がいい」という言葉を聞いたことがありますか? 私は落語が好きで,よく東京の寄席や静岡県内の落語会にでかけるのですが,その落語家さんたちが使う符丁(用語)です。「耳がいい」・・・答えを言います。「物まねがうまい」「声色がうまい」という意味で使います。
 「耳がいい」=「人の話をよく聞く」というだけではないところがポイントです。「物まねがうまい」と人様から認めてもらうためには,話をよく聞くだけではダメですね。特徴を掴んで理解した上で,それを自分で表現できなくてはいけない。表現したものが一定レベルに達していなければ「似ているねぇ」とは言われませんので,鍛錬も必要になります。友達に試してみて「似てる?」「似てない」→やりなおし・・・たいていこの繰り返しを経て,旨い物まねが完成します。それができる人を「耳がいい」と言っているわけです。

 近頃,「コミュ力」という言葉が良く使われます。「耳がいい」人はコミュ力のある人,つまり,人の話をよく聞ける上に,その内容を別の人にきちんと伝えられる人であることになります。

 皆さんには,この学部時代の4年間,いや,就職活動は実質的には3年生後半から始まりますから3年間で「耳のいい」人になって頂きたいと願っています。大学にはいろんな人がいます。同学年の仲間たち,サークルの仲間や先輩たち,研究室の仲間や先輩たち,先生方,職員の方・・・多様な人たちとのやり取りを繰り返して「耳をよく」して頂きたい。これで私のあいさつを終わります。頑張って下さい。

ICTの浸透と拡散に伴うキーパンチャー養成教育の終焉(2/2)

 日々の生活やビジネスにICTがこれだけ浸透した時代,少なくとも科学技術系の仕事をしていてプログラミングと全く無縁であるような開発事例は少ないであろう。制御系の仕事をしていてプログラミンができないでは話にならないし,Web関係の仕事をしていてHTMLもJavaScriptもPHPもJavaもC#を見たことも聞いたこともないという人は皆無であろう。ちょろっとググってみればプログラミング入門教材なぞ山ほどあるし,勉強する気になればいくらでも情報は手に入る。仕事に関連するプログラミング知識を仕入れようともしない,というのはさすがに自己責任と言わざるを得ない。頭が悪いからプログラミングができない,というのは言い訳,というより愚痴としても聞くに値しない意見である。
 スタートアップのための教材が山ほど手に入る時代にも関わらず,学生のプログラミングスキルがちっともアップしない,という話は良く聞く。しかし,ICTの広がりが飽和状態に達している昨今,全体として,プログラミング人口は結構増えたような気がする。問題は,真にプログラミングを必要としている仕事に対する,大規模プロジェクト運営のノウハウという辺りにありそうな気がする。自分の関連する狭い分野に限っても,書かねばならないコード量は増加の一方だし,他人の書いた良質なライブラリを利用しなければ効率の良いコードにはならない。膨れ上がるコード量の整理や,様々なライブラリ(ソフトウェア)との接続のためのノウハウってのは,一応の常識的なものはあるにせよ,組織や個人によって千差万別にならざるを得ない。以前に比べて「プログラミングスキル」というものに求められる内実が変わっている,そしてコード管理はドキュメント執筆などのソーシャルなスキルも求められるようになっている,という事情も,「プログラミングスキル不足への嘆き」に含まれているように思われる。

 ICT飽和時代におけるプログラミングスキルというのは,Webから組み込みシステムまで,多様化しまくった環境への対応能力を多く含んでいる,ということを認識しなければならんなぁと思っているのである。

ICTの浸透と拡散に伴うキーパンチャー養成教育の終焉(1/2)

 プログラミング教育というのはある意味楽だ。手抜きをしようと思えばいくらでもできる。サンプルプログラムを配布→実行結果を見せつつ解説→プログラム打ち込み&コンパイル実習→サンプルをちょろっと手直しする程度でできる演習問題,といったぐあいに,「考える」という部分を抜けばいくらでも先に進めるし脱落者も少ない。
 しかしこれはプログラマーを養成する教育とは言えない。せいぜいキーパンチャー養成教育というべきものでしかなく,まず使い物にならない「自分はプログラマーだと思い込んでいるキーパンチャーもしくはコピペのスペシャリスト」を送り出しているだけである。

 「じゃぁ教育レベルをぐっとあげて,できない学生はどんどん落第させればいい」という意見は,ある意味正しい。しかしこれをやりすぎると,学生の意欲もそぐ結果になりかねず,塩梅が難しいところ。よく聞くのは大体90%以上の単位修得率を確保すればいい,つまりせいぜい1割程度の落第生しか出しちゃいけないよ,というのが私立大学の常識であるようだ。ま,選択科目か必修科目かというこうことによっても「さじ加減の調整」があるようだが,さすがに3割落第となると「ちょっと多すぎないか?」という感覚になる。
 ただ,今までの経験上,プログラミング教育に関しては,例えばC/C++言語の場合,変数,ループ,配列,ポインタ,関数,構造体,クラス・・・という一通りの機能を学ぶとすると,全部咀嚼して自家薬篭中のものとして使いこなせる学生が1割程度,まぁ何とかサンプルプログラムを見ながら頭の中でアルゴリズムを考えられて課題はこなせるという学生が2~3割,できる学生にくっついて教えてもらいながら課題はこなせるという学生が3~4割という感じ。合計すると,単位を取らせていいよと思える学生は4~8割というのが正直な実感である。で,ワシ個人としては5割はまぁいいとして,8割は多すぎる,大体6割ぐらいが納得できる範囲で,7割ぐらい合格させておかないと途中放棄者が大量発生しかねないよなぁ・・・という実感を持っている。つまり3割ぐらいは落とさせろ,ということである。
 合格ラインとして3割不合格,というのが妥当かどうかは学生と教員のレベルによるので,いつもこれが適切とは言えないことは当然であるが,それはさておき,この3割不合格→7割合格のうち,「キーパンチャーでないレベル」というのはせいぜい5割,プログラマーとして適正があると言える学生は2割いればいい方かなぁ,ということである。一般教養としての講義・実習ならまぁこんなもんでもいいのだろうが,専門教育として考えた場合,この歩留まり率の悪さはちとまずいのではないか?・・・と悩んだ時期もあったが,すっかりすれっからしの中年になったワシは開き直って「まぁこんなもん」と割り切っている。

 割り切った分,ワシの学生に対する視線はシビアにならざるを得ない。企業の方々にもこの「見積もり」は正直にお話しているし,実際,ICT系の企業で立派に戦力として入社していく学生数の割合も似たり寄ったりである。リーマンショック前は大卒新卒というだけで楽に就職ができていたが,昨今は大学の偏差値や出身高校までチェックされるという話も出てきて,少なくとも「情報系の勉強をしてきました」と口頭で言うだけでは誤魔化しきれない時代になっている。キーパンチャーやコピペのスペシャリストになって「プログラミングができます」と抜け抜けと主張できる図太い人間にだけはならないでほしい,という切なる望みが愚痴とか説教となって噴出してくるワシの講義は,それ故に大変評判悪いのであるw。ま,事実だし。

河野太郎の質問に答える

 とりあえずざっと下書き。だんだん手直ししていくつもり。元の質問はこちら。>http://www.taro.org/2011/11/post-1118.php

1. スパコン京の利用については、選定機関が認めたものに限るようだが、既に科研費の審査を通ったものについて、再度、スパコンを利用するための申請書を書き、それを審査するのは無駄ではないか。負担金額に応じたリソースが使えるようなルールにすべきではないか。(科学振興予算の純粋科学と技術開発の割り振りを適正化する必要がある)
ワシ意見:科研費の審査は研究の内容を見るものである。対して、京のようなスパコンを利用する必要がある研究かどうかのチェックはコンピューターの専門家の知見が必要であり、研究内容の判断とは全く別物である。

2. 成果目標の明確化を求めると、純粋な研究の可能性を狭めないか。
ワシ意見:成果目標が明確でない研究に、多額の税金を投じて作られたマシンのリソースの使用が適切とは思えない。

3. 来年6月の引き渡しから半年近く経った11月からしか供用されないのはなぜか。
ワシ意見:普通のPCクラスタでも、規模が大きくなるとチェック項目が増える。ことに、ネットワーク網が複雑なマシンの配線のチェックは時間がかかる。京のように膨大なCPUを搭載し、密結合したマシンは、なおさら動作チェックに時間がかかる。

4. 京を中核とするネットワークで接続されたHPCIとこれまでのネットワークに接続されているスパコンの環境はどこがちがうのか。
ワシ意見:HPCIを知らないので回答不能。

5. 「次世代スパコンと全国の主要スパコンをネットワークで結ぶことにより、研究の内容、性質に応じて最適なスパコンを選んで計算することが可能になる」というが、計算機を使い分けることが実際にあるのか。
ワシ意見:パソコンレベルでも、キャッシュサイズやGPU有り無しで計算スピードや適切なライブラリは異なる。複数のアーキテクチャで性能効率を比較検討することはベンチマークテストの常識。

6. ソフトウェアのデバッグを考えると、京一台というのは効率が悪くないか。
ワシ意見:京の利用形態は不明なれど、CPUを多数搭載しているので、1Nodeごとにユーザを割り当てて同時並行的にプログラム開発してもらうことは可能なはずである。全部のCPUをつぎ込む計算でない限り、京1台でも開発環境としては充分と言える。

7. 東大の次世代スパコンは、富士通の1ペタ以上のものになるが、これまでの日立のスパコンからのソフトウェアの移行という作業が加わることをどう考えるか。
ワシ意見:東大の人に聞いてほしいが、コンピューターのアーキテクチャ、ことに世界の頂上を目指すスパコンのトレンドはベクトル型CPUからコモディティCPU(アーキテクチャ)を多数利用したものに変化した。その辺かに対応することはごく当たり前のことで、逆に、トレンドに乗らない旧アーキテクチャにしがみついたソフトウェア開発を続ける方がおかしい。

8. また、京大の次世代はCLAYになるが、同じような問題が発生するのだろうか。
ワシ意見:同上。そもそもそれは「問題」ではない。

9. 民間で京クラスのスパコンを必要とするところがあるか。ソフトウェアをかける研究者がいるのか。これまでのスパコンの民間の利用はどうだったのか。
ワシ意見:詳細は知らないが、製薬開発、自動車開発での利用例があると聞いたことがある。ゼロではないはず。また産学連携的な研究もあるんじゃないかと思われる。

10. 本当に「スパコンを利用した研究が飛躍的に進展し、推定利用者が1000人から2万人になる」か。
ワシ意見:誰がそんなことを公言したかは知らないが、そんなわけないだろうと言いたくなる。

11. 開発加速の経費110億円が削減されたのにほぼ当初のスケジュールできているのはなぜか。企業努力なのか。
ワシ意見:富士通の驚異的な粘りがあった、ということは伝え聞いた。

12. NECや日立に支払われた開発経費はどうするのか。
ワシ意見:NECと日立に聞いてほしい。

13. メンテナンス経費は適正か。
ワシ意見:金額を知らないので回答不能。

14. ストレージの単価の低減が急激に起こることを考えると、ストレージの導入計画は適正か。
ワシ意見:どういう接続形態かは知らないが、安くなったストレージが、現在の京に接続できるものなのかは予測不可能では?

15. スパコンの利用率は導入年度には低く、後年度に高くなることを考えると、性能はレベルアップ方式で調達すべきではないのか。
ワシ意見:性能差のあるCPUを少しずつ継ぎ足していったスパコンの利用効率をあげることは難しい。そういう研究を推進すべきという意見は分かるし、かつてもそういう環境でのアルゴリズム研究を見たことはあるが、あまりうまくいってないように見受けられる。レベルアップは少なくとも数年単位、グロスで行うべき。

16. 10ペタという開発目標は適正だったのか。
ワシ意見:結果として達成できたのだから適正といえる。Top500の性能予測でも裏付けられている。

17. 10ペタフロップスの性能に対して、1ペタバイトのメモリーは適正か。
ワシ意見:適正かどうかは利用者が判断すべき。

18. 文科省は、かつてLinpackで一位になった中国のスパコン「天河」に関して、「多くのアプリケーションで必要とされる主記憶との間のデータ転送性能が十分とは言えず、応用範囲は限定的。性能を引き出すためには専用の言語でのプログラミングが必要となるため、ソフトウェア試算の継承や流通が難しい」と指摘したが、なぜ、京では10ペタフロップスだけが強調されるのか。
ワシ意見:その指摘自体が既に時代遅れになっている。10 PFlopsだけを強調しているという指摘自体が理解できない。

19. スカラー型とベクター型の混合型が適正とした当初の計画から、スカラー型のみの計画に転換したのはなぜか。
ワシ意見:時代の流れ。コストや今後の技術トレンドを考えると、頑張ってベクトル型を維持するメリットが開発途中で失われたと自分は解釈している。関係者の口が重いので、詳細は不明なれど、政治的・経済的な駆け引きがあってのドタバタ劇だったのだろうと考えている。

20. 文科省は、自民党の事業仕分け、民主党政権の事業仕分けで指摘されたことに対して、きっちりと答えていないではないか。
ワシ意見:文科省にこの「トレンドの変化」を説明できる人材がいないのでは。情報処理学会HPC研究会・ARC研究会あたりに参加している重鎮の研究者に直接聞いた方が早い(もっとも意見は結構まちまちのような・・・)。

21. 一部の学者のためのスパコンになっていないか。
ワシ意見:スパコンを使いこなす研究や人材が育っていない、という理屈は昔からあった。今もたぶんその状況は変わっていない。すべての研究者がスパコンを必要しているわけでもないので、裾野を広げる必要があるのは認めるが、「一部」は結構多数になると認識している。

22. なぜ、スパコン京の利用を一部の機関、一部のプログラムに優先的に割り当てる必要があるのか。
ワシ意見:「一部の機関」を知らないので想像で答えると、「過去の実績」や「利用ニーズ」に応じて京のリソースを割り当てることはごく当然のことと考える。

23. 今後のスパコン開発は何を目標とするのか。なんのためのスパコン開発をするのか。
ワシ意見:上記の意見と重複するところもあるがかいつまんで整理すると
 ・アプリケーション(ソフト)が主、スパコン(ハード)は従、とすべき。
 ・アプリが受け持つ社会的要求に対応するためにスパコンを開発する。
となる。

---
(参考)河野太郎のまとめ と 牧野先生の解答(上記と比較すると面白い)