  |
はてなキーワード: 高速化とは
クイックソートで囲うとしたが、ここは
マージソートでメモリーを使って高速化ってなんどもいってるんだけど
ようやくバケツソートができるようになった初心者だからって、甘えんなよ。
マージソートぐらい初歩だろ？
メモ取ってんのか？
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
---
インターネットの未来は,電話が携帯電話により,個人の物になったように,ネット端末が個人の物になっていくだろう.この過程の上で重要な端末がスマートデバイス,つまりスマートフォンやタブレット端末だ.これらはそれ自体でネットに接続することが出来,持ち運びが可能なため個人で所有できる.また通信技術も4Gというネットが家庭に普及したADSLと同等の速度を持つ規格が普及しつつある.この見地からもネットが個人の物になっていく傾向が伺える.
それでは,ネット端末が個人の物になった未来ではどうなっているだろうか,近い未来では,スマートフォンで動画を投稿しあうソーシャルサービスが出てくるのではないだろうか.現在は'Instagram'のような画像を投稿し共有しあうサービスが登場している.それが回線の高速化によりソレの動画版が出てもおかしくはない.その場合,大量の動画を画像のように消費する必要が出てくるので60秒以内などの制限がつくであろう.
また,個人の物になったということは,ネットは公の場という価値観も変わっていくだろう.つまり,現在でも問題になっている個人の問題発言などは更に増えていくのではないだろうか.それをシステム的に制御する必要性が出てくるだろう.必要な人には可視,そうでない人には不可視にする仕様がデフォルトになり,個人情報とともに個人のログもマスキングされていく.
それではその未来においてインフラ技術はどのように進化するだろうか.まず,要求されるデータ量や計算処理は増加していくだろう.ムーアの法則によりCPUやメモリやHDDは増加していくが,それらの間のI/O通信が処理時間のボトルネックになっていくのではないだろうか.それを解決するために,HDDはオンメモリのDBやSDDに変わっていき,HDDはそれほど速度を要求されない場所に使われることになるだろう.また,CPUも更にメニーコアになり,GPUコンピューティングもインフラ技術に組み込まれていく.
しかし,データ量や計算処理が増加して,要求されるスペックも大きくなるにつれて,消費電力も増加するという問題点も出てくる.それに対応するために,様々な対策が講じられるだろう.現在でもインテルが低電力が特徴のIvy Bridgeをリリースしたり,Facebookもサーバー運用の仕様をOpen Compute Projectとして公開している.これからはその傾向が加速し,消費電力を維持したまま,計算量は増えていくだろう.
---
Ivy Bridgeとかなつかしー。Open Compute Projectはホワイトボックススイッチとかいい感じですね。
動画コンテンツが流行るには回線の速度が必要になるとか、インフラスペックがコンテンツの流行りを決めるというのは今でも自分のテーマにある。セガはいつも早すぎるんだよ!
ISUCON 9 参加記 - kyuridenamidaのブログ
ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog
「パスワードを平文で保存すること禁止する」というレギュレーションに対して、「パスワード+#」が違反したと見なされたのが最初の見解。
ここでいう「平文」が出てくる文脈は、初期実装のbcryptからも明らかなように暗号理論の文脈だと考えられる。ここに疑念を挟む人はまずいないだろう。
そして暗号理論の文脈で言う「平文」とは明確な定義があり、今回で言えば「パスワード文字列そのもの」だ。
これは学問的には異論の余地がないので、このことを知らなかった人や、どっちもどっち論に立っていた人は、素直にごめんなさいすべきだ。
たとえば以下のツイート主が主張するような「原理的に元に戻せるのは全部平文」なんて定義は暗号理論では受け入れられていない。複合可能なら全部平文なの？
どこまでが平文って、そりゃ原理的に元に戻せるのは全部平文でしょ。Base64で保存してたパスワードが流出しました！でも平文じゃないから安全です！とでもいうのかよ(´･_･`)いやまじで。— Hideyuki Tanaka (@tanakh) September 11, 2019
もう話はここで終わってもいいのだが、まだまだ論点があるので続ける。
この立場に立っている人も結構いるように見かけたが、レギュレーションからそれが読み取れないので無理がある。
第一に、レギュレーションでは暗号強度に関して全く触れられていない。
第二に、OKな暗号強度の線引きがあるのならベンチマークでチェックすべきだ。
特に後者は今回（自分の知る限り）誰も言っていなかった気がするが、セキュリティの側面も持たせるのなら仕組みで担保しなきゃダメだろう。
運営側が想定していたレギュレーションが、平文よりも高い暗号強度での保持であったとしても、そのことが明確にわかる文章になっていないので、レギュレーション文言の実装バグとしか言いようがない。
実はこの立場で運営を擁護していた人が一番多かった気がしてしまうのだが、見事にハシゴを外されてドンマイとしか言いようがない。
たとえば有名人だとこの人とか。
平文保存がルールに抵触したかどうかは全く興味ないけど、「パスワードの末尾に#つけてから保存してたから平文じゃないです」っていうのは言い訳としては成り立たないよね。ウェブアプリケーション開発者・運用者として、仮にパスワードデータベースが流出したとして、顧客にそう言えるの？っていう— Kazuho Oku (@kazuho) September 11, 2019
残念ながらISUCON運営公式の言説として、平文とまではいかなくても暗号強度を犠牲にすることは想定内であったことがアナウンスされている。
bcryptによる負荷の対処方法として、サーバを追加、軽量なハッシュ関数での代替、あるいは平文での保持を開発チームにおいて想定しましたが、現実の問題として、パスワードなどの情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ちました。
ウェブアプリケーション開発者として、みたいなことを大上段に出されても、ISUCONは現実のウェブサービスであれば許容できないようなハックを用いてでも高速化するコンテストである、という文脈は、それこそ過去のISUCONで確立されてきたものなわけで、ISUCONを知らないのなら黙っといたほうがいい、としか言いようがない。
なお実サービスでは当然やらないことをやるのはどうよ、みたいな話を持ち出すと、今回おそらく運営の脳内レギュレーションではMD5あたりもOKだったのでは、という辺りを考え出すと、やはりどこがラインなのか明確じゃないよねって話に結局なる。（2019年にMD5を許す実サービスは流石にないよね？）
そこを明確にしたいなら文章化（脳内レギュレーションの実装）をがんばるか、ベンチマークなどで担保するしかなかったという結論は変わらない。
それが出来ないなら何でもありになるのは当然の帰結だし、それを美学だとかプライドだとか個々人の価値観が大きく異なる概念で縛ろうとするのは、こと競技に関しては真摯な姿勢ではない。
（たとえば大相撲のような競技でも、横綱が変化しちゃダメという美学に関して喧々諤々な議論が起きたりする）
王道はこれ。
脳内レギュレーションを明文化できていなかった、という反省を踏まえて次がんばるしかない。
今回は他チームから問い合わせがあったらしいが「平文」の定義をきちんと調べさえすれば、想定していた回答ではないが「パスワード+#」は平文ではないので今回のレギュレーション違反には当たらない、という結論を伝えるべきだったように思う。
現実的な落とし所はこっちだったかもしれない。おそらく該当チームも、これなら反発はしなかったんじゃないか。
ということで騒ぎは終わりにしたい、という気持ちに関しては多くの人の一致を見るはずだ。
一方で運営側の朝令暮改のような対応に不信感や疑問を持つ人が多いのも事実だと思う。
ボランティアでがんばってるんだから目を瞑ろう、という感情的な意見もまあ分かる。お疲れ様だ。
またこれは個人的な見解だが、特に今回の予選問題は過去最高傑作と言っても過言ではないくらいよく出来ていると思うし、流通額をスコアとするビジネス上の目的を意識させるというメッセージ性も素晴らしいと思うので、今回の一件を持って問題作扱いされてほしくない気持ちは正直ある。
でもきちんと総括しないで先に進んでも誰も幸せにならないのもまた事実だと思う。
ということで、運営側はレギュレーション文言がバグっていたことをちゃんと認めて、該当チームに落ち度が全く無かったことを謝罪した上で、次に進んでほしい。
競技中に質問に答えなかったこと、参戦後のブログを根拠に裁定をくだしたことも悪手だと思うが、それ以上に、「レギュレーション違反はなかった」ことをきちんと伝えて名誉回復してあげるのが一番の筋のはずだ。
builderscon前夜祭の炎上の件について思うところがあるので書く。
事の顛末はこうだ。
前夜祭最後のセッションで「CROSS MEで黒髪のメガネ女子とマッチングするデバイスをAIとIoTを駆使して作った話」が話される。
前夜祭 (4)「CROSS MEで黒髪のメガネ女子とマッチングするデバイスをAIとIoTを駆使して作った話」 - builderscon tokyo 2019
↓
それを聞いた一部の意識高い系エンジニアがTwitterで苦言。
↓
それが波及し、行ってない人まで苦言を呈しはじめる。
そしてこの件についてしんぺい氏という参加者がブログを書いている。
エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
私はこれに異を唱えたい。
チケットを発売する前にセッションは出揃っており、参加者はそれに納得してチケットを買ったのではないか。
学校の勉強のように強制的にセッションを聞かされるわけではないのだからセッションを吟味した結果不愉快になりそうなので「行かない」という選択肢が取れるはずだ。
あるいは行かないとまではならなくても、対象のセッションが始まる前に「退席する」という事はできるはず。
これだけの苦言が呈されるということは去年も行ったからという理由でタイムテーブルもろくに見ず盲目的にチケットを買った人が多いんじゃないかと思っている。
例えば家電を買うときに皆さんはきちんと機能や大きさ、色など吟味して買うのではないだろうか。
それと同じようにカンファレンスに参加するときもセッションを吟味して買わなければならないと私は思っている。
今回の件は中華料理屋で四川風麻婆豆腐を注文して「辛い！」とクレームをつけているようなものだと私は思った。
自分が「四川風」を見落としたのにクレームをつけるのはただのクレーマーに過ぎないのではないか。
運営の物だ。
CfPを募集してSNSの盛り上がりも考慮しているとは言いつつも運営がセッションを決める。
最終的には運営側が見せたいセッションを選んでどうですか？こんな話聞けますよという事だと思っている。
参加者はその提案を受けてチケットを買うか買わないか判断するだけだ。
今は多くのカンファレンスや勉強会が開催されており、参加者はそれを盲目的にあの人が主催だからとかいう理由で参加するのではなく、きちんとセッション内容を吟味して選ぶ義務がある。
すべての勉強会が型にはめたようにポリコレに配慮する必要はないと思っている。
お行儀の良いNHK教育のようなカンファレンスもあればおもしろいを追求するフジテレビのようなカンファレンスもあってよいのだ。
だから今回の件に異論があるならもっとポリコレに配慮したNHK教育のようなカンファレンスを自分で立ち上げれば良いと思う。
あなたは強制的にカンファレンスに連れてこられて椅子に縛り付けられて不愉快なセッションを聞かされているわけではない。
きちんとカンファレンスを選ぼう。
本当に何も残らなくなるのではないのか。
そういう懸念が私にはある。
この懸念はVim/Go言語で著名なエンジニアのmattn氏も表明している
万人が不快感を示さないはずと信じていたジョークに、あるとき誰かが不快感を示したら僕らは何ができるんだろう。例えばラーメンをテーマにしてたら「ラーメンがかわいそう」という人が現れたりとか。極端な例えだけど、僕が今朝言いたかった事はそういう事です。— mattn＠有益情報 (@mattn_jp) August 30, 2019
今更聞けないsystemd入門 - builderscon tokyo 2019
この内容の中で
という一文があるのだが、これに対して
「はぁ？serviceコマンドまだ叩いてますけど！不愉快だ！このセッションを中止しろ！」
というクレームが付いたらどうだろうか。
先の黒髪のメガネ女子とマッチング～のセッションのように不愉快な人が居るのだから中止にしたほうがよいと思うだろうか？
私は思わない。
そういう人はこのセッションを聞かなければいいだけだ。
私は同じように先の黒髪のメガネ女子とマッチング～も不愉快な人は聞かなければいいだけだと思う。
別の視点からの意見として事業によって参加できるできないが決まるのは技術カンファレンスとして間違っていると思うしもったいないと思っている。
例えばDMMで作られたFANZA TikはPWAの技術を使用している。
その話をするセッションをしたいと思ってもこれはセクハラになるのだろうか。
また、今回のセッションがダメだとしたら当然マッチングアプリと呼ばれる出会い系事業者のエンジニアはセッションが行えない事になるのではないか？
マッチングアプリでどのようなアルゴリズムでマッチングさせているとか、その高速化とかは聞いてみたいと私は思う。
このように技術的には価値があるのに女性が不愉快になる可能性があるからNGみたいなセッションが出てくるのはカンファレンスとして損失ではないのかと私は思う。
今まで書いたことを実践するには主催者にも義務を果たしてもらわなければならない。
なので主催者にはチケット発売前にきちんと内容を開示してほしい。
お願いします。
長々と書いたが言いたいことは
「カンファレンスに参加するかを決めるのは参加者であり、自分で選んで参加しておいてセッションに文句をつけるのは違うのではないか。」
ということ。
男女LGBTどんな属性でも自分が不愉快なのにその場に居続けなければならないという事は無いんだよと言いたい。
最初から参加しない。途中で帰るという選択肢はあなたに与えられている。
私が懸念しているのは今回のことでCfPのチェックを厳しく時間をかけてしなければいけなくなり運営の負担が大きくなってしまうこと。
builderscon運営の負担が大きくなるのも懸念だけど、buildersconはそれなりに大きいカンファレンスだし正直できると思っている。
それ以上に問題なのが手弁当でやっているような他の小さい勉強会/カンファレンスがbuildersconがやっているのだからお前らもやれよと参加者にクレームをつけられて負担が大きくなって「無理！やめる！」となったり、
新たに勉強会/カンファレンスを立ち上げようと思っている人が「buildersconであんなに炎上するなら俺が勉強会立ち上げるなんて無理そうだな。。。」となること。
小さい勉強会/カンファレンスも気軽に開催できるような雰囲気であってほしい。
なので
という風になってほしい。
そしてクレームつけられても
「知りません。事前に内容は提供してあったでしょ。参加するって決めたのはあなた。」
あとは単純にbuildersconがNHK教育のようなお行儀がいいカンファレンスになってつまらなくなる事が一参加者としては嫌だなと思っている。
YAPC::Asia Tokyoの流れを汲んだbuildersconがこれからも「おもしろいカンファレンス」として続くことを願います。
最近ではコードレビューシステムを取り入れてる会社は多いだろうが
まともに運用できているのか知りたい。
いちゃもんつけては10回、時には100回以上書き直させるというキチガイが暴れていたからだ。
1文字の変更でも数十行はコミットメッセージを書かねばならず、
ブーリアン型を2つ使っているだけでも
同じ処理をしている2行が一度でも現れたら関数化しなければならなかった。
重要なのは、別の修正でブーリアン型を2つ使っている箇所をByte型のビット演算にして
同じ処理をしている2行が一箇所でもあればそれらを全部関数化すると
正確さを追求しているのでもなく、効率化でも、高速化でも、平易化でもなく
難癖つけてやり直しを命じることが目的になっていた。
出来上がったコードはひどい出来だった。
やり直すごとにクソになっているのに書き直さなくてはいけないのが本当に苦痛だった。
ときには、嫌がらせ目的でパッチのすべての行に「is it correct?」と書いたり、
すべてのパッチを作成直後に減点してコミットできないようにしたりしていた。
変数名を決めるだけで5個ぐらい候補を上げてどれが好みですか、とキチガイにメールで聞くことすらあった。
一人でそれができてしまう、というのがとても気がかりだ。
今はまともな職場で働けているが、いつかまたそういう職場にあたってしまうかもしれない。
「人にやらせるよりも機械にやらせた方が安い」≒『シンギュラリティ』
これでもう間違いない。
「機械化を実装するのにかかる予算/実装が成功する確率」＜「機械化なんてさせずに人間にやらせたほうが安い」
の不等式が成り立った瞬間を俺たちはずっと『シンギュラリティ』と読んでいたんだ。
技術的な特異点と一口にいうが、その技術とは「安く抑える」技術だったんだよ。
「処理の高速化」なんてのは「作業単位あたりにかかるコストの削減」に向けた手段でしか無かったんだ！
エウレカ！
こんな簡単なことをみんなはもう気づいていたはずだ！
でも、言語化はしてなかった！
俺は今それを言語化した！
そこなんだよ！
エウレは言語だったんだ！
エウレカ！
日曜日が終わってしまうので、ここらで一発、何らかの生産的な行動をやっていきたいぞ、と思ったわけですけども、なぜかこうして増田に張り付いています。
前頭前野の敗北であり、辺縁系の勝利です。勝利、勝利、大勝利。長良は辺縁系ではありません。
なぜか私のPCデスクには知恵の輪が転がっています。なぜでしょう。お見舞いでもらった品です。なぜ知恵の輪。ボケ防止にとのことでしたが。
ところで、先程PCデスクと言いましたが、これは厳密に言うと、いえ別にそんな厳密とかじゃなくて普通に言ってそうなんですが、私が今パソコンを置いている場所は、PCデスクなどという大層な代物ではありません。
というかデスクですらありません。
私は椅子の上にディスプレイとキーボードとマウスを置いています。
正確には、椅子の上に、ホームセンターで買った合板を乗せて、それを机とし、周辺機器を乗っけているのです。
これは案外便利です。広い、安い、手軽、収納しやすい。見た目のアレさにさえ目をつむれば、非常に合理的な選択であると言ってよいでしょう。
あるいは、見た目などという些事に囚われていないことが、余計に合理的な選択であることを強調している、とさえ言ってもよいかもしれません。
ところで、さっきまで、やむを得ない事情により、VBAなる恐ろしい言語を使っていたのですが、これには様々な謎仕様があるようです。それらは名状しがたき恐怖で我々を戦かせます。
一般的に知られていると思われる謎仕様と致しましては、例えば、配列におけるReDimなるステートメントが上げられるでしょう。
他にも、例えばマクロの高速化のための方策として、範囲を配列に代入するというテクニックが紹介されることがありますが、この配列と範囲との間にも謎の関係性が存在しています。
この手のソフトウェアを扱うに当たり、いちいち一つずつセルに値を書き込むことはご法度、というのが定番ではありまして、私も素直にこの定石にしたがい、セル範囲を二次元配列に格納したりしております。
しかし、範囲を配列に代入した場合、その配列の要素のインデックスは、どうも1から始まるようなのです。
なぜ1スタートなのでしょうか。VBAの仕様においても、配列の添字はいちおう0から始まることになっているのですが、範囲を配列に格納した場合、0行0列の要素は空となっており、Array(1,1)にRangeの始点の値が格納されております。
まあたとえ1スタートであっても、言語内で仕様が統一されているのであれば、まだよいのです。
しかしここが彼の言語の恐怖ポイントなのでありまして、どういうことかといいますと、
すなわち、今度は逆に配列を範囲に代入、すなわち配列の各要素の値を対応する範囲のセルに書き込む場合、インデックスが0である要素から順に処理されるのです。
範囲を配列に代入するときはインデックスが1から始まるのに、配列を範囲に代入するときはインデックスが0から始まるのです。
Array = Range
Range = Array
とすると、一番上の行と一番左の列が、空白行、空白列になってしまうのです。
なんですかこれは。誰が考えたんですか。おかしいでしょう。私はおかしさのあまり死にました。
この理不尽さに比べれば、Collectionなる連想配列の添字が1から始まることなど些事に過ぎません。
昨日までJavaJavaしていた人は、どうやら配列なんぞには目もくれていなかった様子でしたので、この謎仕様に気づくこともなかったのでしょうが、悲しいことに、この謎仕様の配列を用いた高速化テクニックはほぼ必須のスキルでありますので、例の御人も、遅かれ早かれ、この罠に絡め取られていたことでしょう。
あるいは、この謎現象を回避するための方策はきちんと用意されており、無知な私はそれを知らないがゆえに、このような的はずれな不満をぶちまけているのかもしれません。
しかし、上述したような単純かつ直感的な代入が上手くいかないという仕様は、やはり、なかなかの欠陥ではないかと思うわけです。
まあそんな愚痴はどうでもいいのです。変な仕様は適当にハックしてやればよいのです。
でもクラスモジュールとやらのパワーは貧弱なのでそれも大変困難ではあります。
標準モジュールでライブラリもどきをちまちまと作っていくしかないのでしょうか。
とてもではありませんが、こんなもんを極める気にはなりませんので、そこら辺のことをいい感じにまとめてくれている知見があればよいのですけれども、しかし、まともな人間はこんなもんを相手にしたりはしない、というパラドックスがあります。
（https://sites.google.com/site/compositiosystemae/home/vbaworld/upper/interface はわりとよかったような気がします。システムハンガリアン使ってますけど）
こんなもんを扱わざるを得ないような環境に留まってしまっている私がおかしいという話もあります。
悪いことは言いません。pythonで書かせてください。お願いします。
そんな増田の切なる願いは、社会という名の抗いがたい泥沼に絡め取られ、今日も悲しみに満ち満ちたコードを生成していくのであります。
そういえば今日は休日でした。休日は普通楽しいものなのではないでしょうか。どうしてこんな悲しい気分になっているのでしょう。
答えは簡単でして、悲しいことを書いているからです。楽しい気分になるには、楽しいことを書く必要があります。
楽しいこととは何でしょうか。例えばオナニーなどが挙げられます。人生において、オナニーよりも楽しいことは、あまりありません。
よって、楽しくなるには、オナニーの話をすればよいです。
私は一時期、DLditeで同人音声を漁っておりまして、催眠に掛かるべく邁進していた時期もありました。
なぜ私は催眠に掛かれないのか。
集中力の欠如、衝動性の強さ、慢心、環境の違いなど、様々な要因が考えられますが、最も大きな原因と思われるのは、台詞がめっちゃ気になることです。
おっさんが考えた可愛い二次元の女の子みたいな台詞が、えらく癇に障るのです。
そのために、可愛らしい女性の声に没頭できないばかりか、声によって現実に引き戻されてしまう、という逆説に襲われるのです。
おっさんは蓮を咲かせる泥だという話もありますが、恐らく、真に良質な泥おっさんというのは、非常に稀な存在なのでしょう。
つまり、いいおっさんは泥ですが、悪いおっさんはゲロということです。
しかし、これもおっさんに限らず、大抵のことに言える話でありまして、良質なものはどこでも少ないものです。
生の増田を見てもそうでしょう。
ホッテントリに上がる増田しか見ないライト増田、あるいはブクマカには想像もできない世界が、生の増田には広がっています。例えばこの増田とかです。
（これは私見ですが、VIPやなんｊ、あるいは虹裏などと比べても、増田の毛色は違います）
増田のほとんどは泥であり、ホッテントリに上がった増田は花なのです。
何だかまた悲しい話になってるじゃないですか。なぜ私はいつも悲しい話をしてしまうのですか。
それは恐らく、心の通奏低音（俗用）のようなものが、悲しみに染まっているからです。
基本的に悲しんでいるので、無意識に任せて話すと、悲しい話ばかりが飛び出てくる、というわけです。
javascriptは高速化に貢献してる部分もあるのだがな。
増田ダイアリーの「▼言及先エントリを開く」もjavascriptだけど、これないとすげぇ使い辛くなると思う
勝手にジョークぶちあげて揚げ足取られたら話の筋道をそらすのは如何な論法かと思うけどね、ジョークならジョークで完結させろよと言いたいが、「それはジョークだじゃあ話を元に戻そう」、これでいいのでは？それとも子供に対してCPUのことを計算してくれる装置ですよと語りかけるが如く丁寧懇切に連立方程式の解き方からBLASの存在まで説明しろとおっしゃるのかな？
それは筋が通らない話だと思うし議論する気があるなら最低限・・そうだな大学がならう数値計算とか並列計算機の授業のレジュメをさらっと目を通すぐらいはしたらどうでしょうか？
https://www.cspp.cc.u-tokyo.ac.jp/hanawa/class/sp20180925.pdf
うーむHPCに対するアプローチは二通りあって情報工学的に計算機科学の一環（つまりスパコンを作る側）として見るか、1科学者としてのシミュレーションを行う場、仮想実験場（スパコンを使う側）としてる見る場合の2つのアプローチがあると思うのだけど・・・PEZY-SCを搭載したシステムに関しては前者、計算機科学の成果としてみるべきシステムだと思うのよ、これの成果としては「非GPUで超メニーコアシステムを実現すると共に高効率なシステムを構築することに成功した」って言う一つの事実に集約されると思う。
でここで高効率なシステムの基準はなんなのかとというと「HPL」と言うベンチマークですわな、HPL=LINPACKと言う認識で話を進行させるけど、HPLは本来連立方程式の求解を行う速度を競うベンチマークであって、これを皆が手放しで賞賛してるのはおかしいと言う批判が存在する。
これは一理あってすべての科学技術計算の性能向上に寄与する指標とは言いがたいからだ。
じゃあなんでこれが推されている居るかというと理由は何個かあるけど連立方程式の解を求める必要のある技術計算はとても多いから、昔からやっててデーターが揃ってるから
ここまででHPLが重要視されている理由がご理解いただけると幸いなんだけど・・じゃあ具体的に連立方程式を使用する場面を示せよと言われると腐るほどあってどれを示せばいいのかわあらんのですが・・
http://www.cs.kyoto-u.ac.jp/wp-content/uploads/2012/07/05hori.pdf
まああんまり人様の研究をあれこれ紹介して間違った説明しても申し訳ないので中身には触れないでおくけど実際に連立方程式は最もシェア率が高い問題であると言う認識は持ってくれると
話が早い
まあさっきのXeonでいいじゃんって話も一理あって性能が低くてもx86_64時代のコードそのまま使いまわせるし、さっきあげたユーザー側から見た時楽ちんであるのは事実だ。
なによりintel C++/Fortranコンパイラと言うクソ便利なものがあってライセンス料払うとある程度勝手に高速化してくれたりするし使いまわせるコードも多い
まあPEZY-SCよりXeonのほうが計算機を研究してるわけじゃない物理学者とかの各種研究者エンジニアからすれば魅力的な点が多いのは事実だと思う
だからと言って計算機科学としての計算機の純粋な性能向上を主とする研究・開発成果を邪険にしていいわけないしまた別の問題、確かに商業ベースで考えたとき
これらの問題をどうにかしないといけないのは事実だし改善して行かねばならないのはPEZYやエクサスケーラーの各位に残された課題であるのは間違いない。
だが少なくともまだこの世に銀の弾丸となりうる万能システムは存在しない。
もしあるなら俺にくれ あといい加減なこと言ってたらゴメン、強いひとに殴ってもらうと筋トレになる
痴漢被害では全国レベルの知名度を誇る埼京線、一時期は飲酒電車と揶揄された常磐線など、結構な強豪がひしめく中、個人的な推しは武蔵野線である。
何しろ、JR東日本の路線別顧客満足度における最下位レース常連なのだから恐れ入る。
理由は首都圏の路線の中でも、今や最も古い車両の品質に、ほぼほぼ集約されるだろう。
とにかく超うるさい上にやたら揺れるせいで不快極まりないのだ。
これは他路線のお下がりをかき集めた、まさに昭和の国鉄型通勤電車の墓場と化しているところに、モーターだけ交換して無理やり高速化した結果だろう。
しかもそんな車両のうち一部の編成は、なんとATSすら備わっていないインドネシアに譲渡しているときたもんだ。
つまり武蔵野線とインドネシアの路線が同格の扱いという時点で、JR東日本のやる気の無さがハッキリ分かんだね。
そんなクソ以下の乗り心地に心折れた筆者としては、出かけるたびどんなに遠回りになろうが、可能な限り武蔵野線を使わない経路をいちいち探す羽目になっている。
結局乗ろうが乗るまいがイライラの種は尽きない。
日本でしか流行っていない印象のあるVRは、単に海外では通信環境の縛りがあるから流行っていないというか使えないと思われるので、モバイル通信の高速化がより発展すると爆発的に普及する可能性はある
現在はまだゲーマーや一部のギークしか使っていないが、もしかしたら一般のネットユーザーにも降りてくるかも知れない
日本ではMastodonくらいしか流行っていないが、分散SNSの歴史は海外のほうが実際は長い
LINEグループやSlackのチャンネルのノリで分散SNSサーバを建てられるようになったらもしかしたら仲の良い友人たちだけの分散SNSサーバみたいなのが沢山登場するかも
デザインやファッション好きの間では最早ド定番なれど、まだまだ一般ユーザが使っているとは言えないPinterest
Instagram女子のノリでPinterest女子が登場するかも
高低差やトンネルには弱いが、Apple CarPlayやGoogle AndroidAutoが普通に自動車へ搭載されるようになったら日本国内で高い評価を受ける可能性がある
中小非IT企業につきブラックボックス化は避けたいのでExcelを使う
関数の処理量とテーブルの扱いやすさを天秤に掛けつつ高速化を図る
VBAとかいうのは極力使わない (Office2019など当然導入されない) (だいたいWindows10ですらない)
そこそこの期間の運用を想定しているのである程度の拡張性は欲しい
設定用シートを作ってグローバル変数を扱うように管理する方法などが王道だろうがあまりやりたくない
具体的な関数の使い方などの情報は腐るほどあるけどブックの構成にまで踏み込んでいるものは少ない
アメリカでは作者が出版社に著作権をまるごと譲渡しているからのようだが、
http://www.bunka.go.jp/seisaku/bunkashingikai/kondankaito/denshishoseki/10/pdf/shiryo_4_1.pdf
日本の出版社が作者に「著作権くれ」って言ったら叩かれるだろうな。
・電子化するとき、一つ一つの作品ごとに契約を結ばなくてもよくなるので、スピーディに電子化できる。（＝出版社が速やかに電子書籍を作れれば、作家も儲かるはず）
・海賊版を訴えるときに、いちいち作者に確認しなくても、出版社の判断で訴えることが出来る。（＝出版社が作家の代わりに海賊版をドンドン訴えてあげれば、作者も喜ぶはず）
という点が上げられます。
・・・しかし、１はこれまでの出版契約書方式でも十分スピーディであり、権利を与えてまで高速化する必要は無さそうな感じもしますね。
２も、今までの契約書方式で、出版社がドンドン違法なサイトや人を狩っており、作者（真の権利者）に電話一本入れる手間が省けるだけの話です。
山本一郎の言うように「クラウドフレアがカドカワの情報開示請求に応じないのは出版社に権利がないから」だとすれば、
「出版社は関係ないので海賊版については作者が自腹で対応してください」ということにならざるを得ないけど、
それはそれで叩かれそうだよな。
カドカワ詰んでるわ。
だからこれだろ？
https://lwn.net/Articles/249460/
ここで「c++はクソ効率悪いコード吐くし、c++で高速化しよう思ったらそれはCのコードと同じになる」なんて言ってない。
inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
この文章で、非効率(inefficient)って言ってるのは、「abstracted programming models」「the nice object models」であって「c++はクソ効率悪いコード吐く」なんて話じゃない
メモリが増えて、CPUが高速化して、昔のゲームがかなり快適に遊べるのかと思っていた、ころもあった
実際にはオープンワールドやら4kとかグラフィックとかその辺を優先させて、快適さは特に上がってない
ただそれが全部メモリになるからロード時間が0になるとかそういうのを求めてたんだ
敵の表示数が増えて一気に多くの敵を倒せるとかそういうのを求めてたんだ
遠くまで見えたり遠距離ビーム技が本当に端から端というくらいに遠くでもあたるとかそういうのを求めてたんだ
マイクラなんかはグラフィックは凄くシンプルにしてる分とても広いワールドを旅できるし回路みたいなのつくて同時に多くのものが処理されてたりするし良い方向だと思う
