「I/O」を含む日記

はてなキーワード: I/Oとは

2019-09-29

■2012年に就活で書かされたインターネットの未来って課題が出てきたので貼ってみる。

---

インターネットの未来は,電話が携帯電話により,個人の物になったように,ネット端末が個人の物になっていくだろう.この過程の上で重要な端末がスマートデバイス,つまりスマートフォンやタブレット端末だ.これらはそれ自体でネットに接続することが出来,持ち運びが可能なため個人で所有できる.また通信技術も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はホワイトボックススイッチとかいい感じですね。

動画コンテンツが流行るには回線の速度が必要になるとか、インフラスペックがコンテンツの流行りを決めるというのは今でも自分のテーマにある。セガはいつも早すぎるんだよ!

Permalink | 記事への反応(0) | 06:26

2019-07-17

■男のI/Oって尻穴？

口はI/Oになってほしくないっていう気持ちが俺にもある。

Permalink | 記事への反応(0) | 11:43

2019-06-08

■anond:20190608215207

負荷の殆どはI/Oで発生する。DBはどこにあるんだ?

Permalink | 記事への反応(0) | 22:10

2019-04-09

■vimが嫌いな理由

モードが存在すること

モードが存在するツールは究極的に言えばクソ

モードをありがたがってる人が書いたコードとか正直読みたくない

大抵外部知識に依存しすぎのマウントコードだから

もちろんI/Oのリソースとかの関係でしょうがないことはある

Linuxを使う時にコマンドを叩くのは非常に理にかなっている

でもIDEがたくさんある中でvimを推すのはやめなさい

自分で使うのは否定しないから

参考：モード　 https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%BC%E3%83%89_(%E3%83%A6%E3%83%BC%E3%82%B6%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9)

Permalink | 記事への反応(0) | 16:01

2019-04-04

■anond:20190404165512

いやいや、アセンブラを学ぶのに半加算器の知識は不要でしょw

というか、論理回路の知識すら要らない。せいぜいBooleanくらいでじゅうぶん。

知っていると便利なのは、ALUとか、レジスタとか、メモリーとか、アドレスとか、バスとか、I/Oとか、ポインターとか、スタックとか、その程度かと。

サブルーチンを呼ぶとスタックにリターンアドレスを積んで云々、、、を知っているだけでイメージがわくし。

Permalink | 記事への反応(1) | 22:36

2019-01-10

■anond:20190110153648

ryzen 1000～2000の特性は正直あんまり把握してないんだけれど、通常市民が使うようなソフトウェアはシングルコア動作に特化しているので

intelのプロセッサみたいにシングルコアでも余裕があれば確実にターボブーストされるのとは異なり、シングルコア動作では滅多にターボブーストがかからない（他のコアで動作しているものにターボブーストがかかってたりするので）から遅いと感じることはあるだろうな。

ryzen3000は更にI/OコアとCPUコアが分離したせいでCPUコアで標準入力食べるようなプログラムを動かすとメチャ遅くなるってことが言われているし、素人にゃ上手く扱えん度は大分増すだろうな。

でも藤井聡太なら多分全コア100%使い切れるだろ。

Permalink | 記事への反応(0) | 15:42

2018-12-26

■anond:20181225211030

パソコン系：テクノポリス（徳間書店から出てた）、ベーマガ、I/O

Permalink | 記事への反応(0) | 10:53

■anond:20181225211030

電子工作系なら、「子供の科学」、「模型とラジオ」、「初歩のラジオ」、「ラジオの製作」、「CQ Ham Radio」、小中高生にはちょっと難しいけど「トランジスタ技術」、マイコンが出てからは「I/O」とか。定期購読してたのもあるし。これらを読んでたのは今は50代以上かな、秋葉が電子工作の聖地だった世代。今じゃITわからずPC使えないと一括りでバカにされる世代なんだわｗ

Permalink | 記事への反応(0) | 09:57

2018-08-31

■

仕事の一環でスパコン向けのプログラミングとかやってるけど、このスキル F1カー並みに潰し効かないよなあ、とふと思うことはある。

MPI/OpenMPのハイブリッド並列とかSIMD化とかミジミジ計算機様に人間が合わせるの普通にしんどすぎひん？Web屋とかSIerとかだともっとずっと楽なんだろうなあ。

Permalink | 記事への反応(0) | 21:53

2018-08-21

■anond:20180820183639

一般人はI/Oが猛烈に遅いから3時間かけて小説1ページ読んだりしてるよ

Permalink | 記事への反応(0) | 10:36

2018-08-07

■ホワイト企業ってどれぐらいホワイト ナノ？

始業時間の３０分前に来たら「１時間前に来い。実質３０分の遅刻だぞ」って言われたりしないの？

もしそうならそれは凄いな。

同じ日本だとは思えない。

社内規定でインターネットを制限されまくってググることすら禁止されている環境で先輩に質問したら「自分で調べろ。共有フォルダに今までやってきた連中の過去データが入ってるからそこからパターン見つけてけ」と自社の書類相手にI/Oでリバースエンジニアリングする羽目になるのが日常化してないの？

もしそうならそれはもう２３世紀の世界だな。

２０１８年に存在していい人間社会じゃないだろオーパーツだろ。

会社の飲み会に出ないと「お前、空気読めねーな」と怒られて、かといって飲み会に参加すると「お前仕事遅れてるのに飲み会に参加するとはいい度胸だな？」と脅されて、それなら次はと参加しないとやっぱり「何で休むんだ？定年退職した大先輩が来る飲み会に参加しないのは人として駄目だろ」と謎ルールをいきなり聞かされたりしないのか？

そりゃもう地球じゃねえな。

同じ星に生まれ育ってDNAの９９％が同じでそんなことになるはずがないからな。

Permalink | 記事への反応(4) | 20:07

2018-06-01

■anond:20180601143400

同じボリュームを複数インスタンスでマウントできるってこと？

といってもAWSって特別ディスク I/Oが速いってイメージはないから

ネットワーク越しのボリュームになったらEBSよりパフォーマンス下がるんちゃうかなあ。

Permalink | 記事への反応(0) | 14:39

2018-04-26

■anond:20180426102121

触ってちょっと新しいと感じたもの（steam）

Magicka

キーに8+2属性が割り当てられて、それを使って魔法を詠唱する見下ろしアクション

2はレベルデザインに失敗してる

Factorio

工場ライン構築ゲーム

Kerbal Space Program

自由にロケットを作って飛ばす、物理がちょっとリアルな宇宙開発シム

Human Resource Machine

取っつきやすいプログラミングパズル

Shenzhen I/O

取っつきにくいプログラミングパズル

Silicon Zeroes

プログラミングが回路設計になったプログラミングパズル

Scribblenauts

言葉を実体化させて問題を解決していくアドベンチャー

Viscera Cleanup Detail

凄惨に汚れた現場をひたすら掃除していく掃除ゲー

やってると意外に時間が経ってる

Permalink | 記事への反応(0) | 20:34

2018-03-16

■世界四大プログラミングが理解出来るっぽいPCゲーム

・Factorio

・Human Resource Machine

・SHENZHEN I/O

あと一つは？？

Permalink | 記事への反応(1) | 23:36

2017-05-19

■http://anond.hatelabo.jp/20170519083045

呼ばれたようで。

https://japan.zdnet.com/article/35081029/

影響力の大きさ
　フラッシュメモリを用いたSSDは、磁気ディスクを用いたハードディスクよりも高速なストレージだが、I/O スタックは同じだ。このため、デバイスにデータを書き込む際に生じる問題（遅延、エラー、複数のバッファ間の調整）はそのまま残っている。つまり、SSDは単なる高速なディスクにすぎないと言える。
　しかしNVMは単に高速なだけではない。NVMには永続性があり、ストレージとしても使用できるメモリである、ストレージクラスメモリ（SCM）に利用できる。
　純粋なSCMは、DRAMとストレージデバイスの違いをなくしてしまう。メモリとストレージを別に持つのではなく、永続的にデータを保持できる単一レイヤのメモリを持つことができるわけだ。

昔からのことナリよ。

Permalink | 記事への反応(1) | 18:04

2017-01-22

■ownership とシステムプログラミングその他に関する怪文書

この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。

坂木
わろた
Rust vs. Go に対する @tanakh さんの発言まとめ
https://togetter.com/li/1072495

坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原
NTPsec が，ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした（こなみかん

宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森
……が、理解できないものに対して、理解を試みず～すべきだ～と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原
いや，私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います． ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です．

宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている（思い込んでいる）人たちですんで……こわちかは同意。

安原
いや，私は C で開発してきた人たちの多くは，そもそも ownership の概念を獲得していないのではないかと危惧しています．元々，私はもっと楽観的で，多くの C プログラマは ownership の概念を獲得していると思っていました．

宮森
あ、それはそうだと思います＞概念を獲得していない
リソースは人間が管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原
OpenSSL の騒動の時，関数の途中で return したことによるリソース漏れを揶揄したことがあります． OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ， ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました．

安原
ああ，はい．人間を信頼しすぎているというのはいかにもありそうですね．

藤堂
C++er の方がその辺もっときちんとしているように見える

安原
むしろ C++ によって ownership という概念が明確になり，その重要性が認知されるようになったのではないでしょうか？これについては，私は歴史的なことが分からないので真偽のほどは何とも言えませんが．

宮森
シニアな開発者にしか C++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象（[検閲削除]社時経験）。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井
自分が知っている C 「しか」書けない職業プログラマ、基本的に地雷だなぁ...。

今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原
うーん，数値計算系のチームやコミュニティも ownership の概念の獲得，重要性の理解，その管理を自動化することへの理解，これらを期待するのは難しいだろうなあ……．そもそも高度なリソース管理が必要になる場面少ないし……．

坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原
OS 実装とかシステムプログラミングって，クライアントに直接接しないだけで，その上にクライアントサイドソフトウェアが載るわけで，コードの品質が強く求められると思うのですがそれは……．まあ， API とかで切り離されているので，そこだけしっかりしていれば，という話はあるか．

宮森
そこはコードレビューやテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木
品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井
あとは、デモが作れればいい、的なのも同じかなぁ。

宮森
メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森
メモリ管理、コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原
OS が GC してくれる論， TPO をわきまえているならば普通にありですよね（TPO をわきまえているならば！）．

今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木
私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井
あれ、そうなんです？私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。
(つまり、ここから坂木さんのハードルがめっちゃ高いという帰結が...)

宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます（プログラムと顧客の大事なデータが）

安原
しかし，システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの，何か構造的な原因があったりするのかなあ？

宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森
実際、Linux カーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれる気持ちも分かる。

宮森
他の言語でOS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議

安原
Linux カーネルのアレは，属人性に依拠しすぎていて全然スケールしないのでは……．

坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな

宮森
属人性に依拠しさえすればできるので十分な数の開発者がいれば問題になりません（ｷﾘｯ

安原
私も [検閲削除] のコミュニティを見てましたから，各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが，本当にただの奇跡でしかないと思っています．

宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森
なおその対極がみずh（省略されました

安原
Linux カーネルにおけるスケール云々は， Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて，（システム）プログラミングコミュニティ全体（他のプロジェクト）へスケールするかどうかを言ったつもりでした．

坂木
まあ人外を集めるという手法は一般にはスケールしないですからね……

宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原
＞システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると，やはり Rust だ……Rust しかない……．ツール周りとか，まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば……．