  |
はてなキーワード: オーバーヘッドとは
http://b.hatena.ne.jp/entry/wp-d.org/2014/02/26/5709/
deployでGITの是非を語るならまだ分かるが
まるで、FTPに使いどころがあるような書き方をしてるのがいて
ブコメが恐怖に満ちてたので書く。
理由
まずなによりもこれ。FTP使うのは、公開共有フォルダと同じレベル。
・FTPなんて立てなくても、SSH/SCP/SFTPが確実にあいてる。
あえてFTPサーバー立ててる時点で相当怪しい。確実にアホな理由。ユーザーが使えないからとか
・FTPSは新規に使うモノじゃない。
FTPS意識するような人なら、既にSSH/SFTPなり使ってる。
FTPSはレガシーFTPに対して、応急処置でう使うモノであり、新規採用なんてありえない。
・FTPというステートフルなプロトコルは、プログラムには本来扱いにくい
なのにあえてFTP立ててる時点で相当怪しい。その辺から離れた世界の匂いしかしない。
FTPとHTTPのオーバーヘッドとか、このブロードバンド（死語）時代に何言ってるのよ？
というかね、転送効率がそこまでシビアだったら別な方法選択するからありえない。
あとさー。いまだにデカイファイルはFTPあけてファイル配るみたいなことやってるから
勘違いする馬鹿がいっぱいいると思うの、そろそろやめていいよ。誰も困らないから。
アホなユーザーにFTP利用させる==公開共有フォルダ化したどころかウィルスばら撒く温床にまでなった。
というかGumblarのせいでこの世からFTPは駆逐されたはずだが、
なんで時と場合を考えろみたいな話になってるの？
なんなの。なにこれすごくわい。
自分はJavaからPHPに入ったので、最初はとにかくクソな言語だと思っていた。
Copy On Writeという謎仕様なのに加え、すべての配列が常に「順序付きマップ」という謎なものになっている。ただ単にマップ（連想配列）を使いたいだけの場合でも、なぜが挿入順でキーが順序付けされているという仕様で、内部でどんだけオーバーヘッドがあるんだろうと考えると、それだけでストレスが溜まったものだ。
あと、何も宣言せず、$array['key1']['key2'] = 1としただけで、要素が１の配列が２つ作られる。これも気持ち悪い。この仕様のせいで、どれだけ見つけづらいバグが誘発されているかと思うと、それだけで痒くなった。
そんな風に思いながら、2年近く仕事をして、そこそこ大規模なシステムを一人で書けるようになった。それでも、PHPをやっている引け目のようなものはなくならなかった。
ただ、そんな思いのまま「意識が高い」系のプログラマが集まる会社に移り、RubyだとかPythonだとかScalaだとかが書けるようになった上で、あらためてPHPを見ると、その仕様が優れていることを痛感させられる。同じことを書こうとしたときの行数が圧倒的に少ないのだ。配列についてもたしかに、オーバーヘッドはあるが、実際にはパフォーマンスに影響することは少なく、それを通して得られる開発効率は半端じゃない。他の言語だといくつものライブラリを介して可能になることが、単にサーバにファイルを置くだけで可能になるというのは、特に小規模なプロジェクトでは生産性の高さに直結する。
もちろん、プロセス／スレッド／データ共有の仕組みが前時代的で、パフォーマンス効率は高くない。言語仕様が、ノンブロッキングな処理に向いていないなど、用途によっては致命的な欠点もないわけではない。ただ、きちんと言語の特性を理解するレベルで使ったことがないのに、仕様的に他の言語と変わっているところを挙げて、「PHPを使うのはレベルの低いエンジニア」というのは、そろそろ終わりにした方が良いと思う。
あと、話は変わるが「意識が高い系エンジニア」は、システムを開発する上で人件費や採用コストの問題をあまり考えていないのではないかと思う。たとえば、ビジネスが急に大きくなって、取り急ぎ100人エンジニアを雇おうとなったとき、PHPならとりあえず書ける人間をかき集めやすい。RubyやPythonで同じことをやると採用にかかる時間が大幅に伸びるか、人件費が大幅にアップするかになるだろう。これは、一緒に働くエンジニアを所与の条件として見るか、お金を払って雇うべきダイナミックなものとして見るかの違うじゃないかと思う。
これ3つくらい当てはまったら無能なｗ
http://anond.hatelabo.jp/20131109185658
特定経験に依存せずに一般化するのは難しいが幾つか、実装力、問題解決力向上に絶対に外せない基本要素を追加しといたw
Xbox360はGDDR「3」ね。
あとPCI-Eに刺すGPUは元増田が書いてるように転送がむっちゃ遅くなるから、CPU・マザーボード・GPU全部で包括的な革新が起きないとPS4の構成に同じ価格帯で並ぶには5年程度じゃギリギリ無理。
GPU DirectもあくまでマルチGPU間の並列処理データ受け渡しのオーバーヘッドを無くす技術だから、普通のGPGPU処理でCPU・メインメモリ頼りの構図はnVidiaだけが頑張っても覆せない。
PS4や次世代箱に勝てる構成が近い将来に来るとしたらAMDのHSAかIntelのXeon Phi統合CPUがハイエンド向けに作られた時だけじゃないかな
http://anond.hatelabo.jp/20130223090512
三行でまとめると
PSのビジネスモデルを振り返ってみるのだが、この切り口から行くとPSはSONYの半導体戦略、そしてSONYは製造業と言う性質とと切っても切れない関係がある。
利用上の注意
なおすべて妄想となっておりますので、これを真に受けて被った損害などについては一切責任を取れません。皆様におかれましてはその旨ご了解のうえご覧いただけますよう、よろしくお願いいたします。ご協力頂けない場合につきましては、いい歳こいたアラフォーの髭ヅラ男が涙目になると言う非常にウザイ状況が発生することとなり、誰も得をしません。ご理解とご協力をお願いいたします。
SONYがゲーム機を一緒につくろうと言って任天堂に近づいたものの交渉が決裂してできあがったのがPSであったわけだがこれが大ヒット。
さらにPSでは、内部で使われている半導体を自社設計・自社かそれに近いFabで作る事によって
など副次的な効果もあり、さらに「SONYの旗艦」といったイメージを作り上げることができた。この他に、CD-ROMを手がける部門や、SONYのCDプレス工場部門等々、PS景気により、直接的なPSによって生み出される効果以外に、PSという揺るぎない需要が存在する事で、設備投資などに積極的になれたといった効果がうまれた。
初代は始めどこまで意図されいたかは不明だが2台目ではそれらの経験が生かされる事となりより強化された。まず一番は半導体工場で有り、旺盛なその需要と、それによって得られた利益を投資に回し新プロセスを開発、シュリンクすることによって最終的な黒字を目指すことで赤字で販売をスタートすることとなる。
ゲームハードは赤字でも、ソフトが売れれば黒字。こんなの当たり前だろ、と言う話であるが、総合情報機器メーカであるSONYでは少し事情が異なる。これは、ソフトウエアライセンス事業による利益によって、間接的に半導体生産の設備投資を補填すると言う形を意味する。もちろんそれ以外にもSONYの製造部門にもPS2が赤字でも販売すると言う行為によってもたらされる間接的な利益が流れた。
ご存じの通り、PSは我が愛する芸術品たる至高のゲーム機Dreamcastを完膚なきまで叩きのめし世界最高の企業セガをプラットフォーム業から引きずり卸しパチンコ屋に買われる所まで追い込む等大成功をとげた。そしてゲーム機生産により、SONYの製造業部門を引っ張っていくという当初の見込みは大成功した。
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の改良、ミドルウエアや開発ツールの向上などにゆっくりではあるが立ち上がってきたが、製造業としてのSONYがPS3に期待した効果は得られず、ハードウエア屋、製造業がみた夢はここに破れた。
さらに時代は動き、集積回路は、Intelがプロセスで1世代以上先を行き、それ以外はすべて後から追うという構図が完全に定着してしまった。SONYも、SONYの半導体と言えば、集積回路ではなく画像素子、と言う時代が来て久しい。世界中で半導体製造業者の統廃合は進み、国内半導体産業は衰退した。新プロセス開発の難易度や、集積回路の大規模化から来る開発コストの上昇はいかんともしがたくなっていた。
ゲームが必要とするスペックはもはや飽和している。少しでもリアルに、少しでも高性能にと言う方面はすでにマニアのものだけになってしまい、それら需要だけで、そのとき販売されているパソコンを上回る高性能チップを開発、載せるコストを満たすことはできなくなっていた。具体的に言えば、ウルトラハイスペックの、GeForece GTX SLIクラスにも勝ちうるGPUを、専用設計でオーバーヘッドを極力少なくすることができるとはいえ新規設計することが難しくなっていたのである。さらにはゲーム機業界ではスペック競争を離れた任天堂がWii、あるいはDSを生み出し、ケータイ、そしてスマフォとと言う存在がカジュアルゲーム市場をかっさらうようになった。特に日本では据え置きゲーム機がリビングルームに置かれ、パーソナルな空間に置いてゲーム機は携帯ゲーム機になったのである。
そして決定的だったのが、ゲームエンジンの躍進と越境であろう。従来はゲームエンジンや製作環境はゲーム会社の門外不出のものであった。しかしそれらが会社を通じて流通し始め、さらには専門業者も現れるようになったのである。
家庭用ゲーム機と言えば、ゲーム機の性能を引き出すためにソフトごとにアセンブラで最適化チューニングを施す。それを行っても常に動作が一定になることがメリットとして、パソコンに比べてゲームは常に一定の動作をすることが担保できるためにゲーム製作に専念することができた。しかし、パソコンは十分に高性能になった。家庭用ゲーム機も十分に高性能になった。その結果、チューニングを行わなくてもそこそこの画面が作れるようになってきたのである。そこで余った能力はゲームエンジンのオーバーヘッドを許容するようになり、ゲームエンジンの躍進に繋がった。さらにゲームエンジンはプラットフォーム間の差異すら吸収し始めた。あるゲームエンジンを採用すれば、あまり手間をかけること無く、パソコン版、PS版、XBOX版、Wii版と複数プラットフォームで出せるようになったのである。これは、ゲームエンジンが新たなるゲーミングプラットフォームとして君臨する可能性を示唆していた。
しかし、チューニングなどといった、ユーザとは直接関係の無い部分に手間をかける必要が無く、作ったゲームがどこでも動く。これはクリエイタとしては非常にありがたい事なのでは無いか？
ビジネス書に出てくる例えがある。ユーザはねじ回しが欲しいのでは無い。ねじを回したいのである。同じように、客はゲームがしたい、もっといえば楽しいことがしたいのであって、別にゲーム機が欲しいわけでは無いのである。クリエイタはゲームを作りたいのであって、ゲームハードウエアを使いたいわけでは無いのである。ここに合致したのがクロスプラットフォームなゲームエンジンであり、そしてこれらはクリエイタに作りやすい環境を提供し始めた。さらにゲームエンジンは新たに現れたライバルである、タブレット/スマートフォンにも対応している。
しかしゲームエンジンの躍進は、プラットフォームビジネスの崩壊を意味したし、PS3は性能を引き出すには高いレベルの専門的チューニングが必要であった。しかしゲームエンジンはそこにコストを払う事を選択せず、PS3は高い性能を持ちながらも、それ以外のあまり高性能ではないプラットフォームとほぼ同等、せいぜい高解像度のテクスチャーに入れ替えられた程度のゲームしか提供されない、と言った事が発生するようになっていた。
そしてPS4が出た。
PS4は有り体に言って、x86-64アーキテクチャのコンピュータに、OpenGL/CL対応のGPUを搭載した、本質的にはそこらのパソコンと変わらない構成である。
さらに言えば、最新のCorei7+GeForce GTX…と行かなくとも、そこらのパソコンに較べ、性能は高くない。しかし、根本的にゲーム専用機が持つ、汎用パソコンには無い特徴
を備えている。さらには、GPUを扱いにくくする要因の一つとして上げられる、GPUとCPUのメモリ転送をほぼ考えなくて良いと言う仕様を打ち出してきた。これはCellとCPUのプログラミングが分断され、非常に開発を困難にしていたPS3の反省をダイレクトに生かしてきたと考えられる。これはAMDが出していたコンセプトだ、と話題に上がるが、あくまでもパソコンの話であって、ゲーム機の分野では少なくとも、PS2がプログラミングが困難な部分を、高速なバスで繋ぐことで隠蔽するよな仕様であったように記憶している。
さらにx86-64アーキテクチャにしたことで、ゲームエンジンがPC向けエンジンの次に、素早くPSにも対応できる素地を整えた。Power向けに施す必要のあるチューニングを不要にしたのである。従来はパソコンで開発されたクロスプラットフォームのゲームは、パソコン向けと、家庭用ゲーム機向けの2種類作られた。そして家庭用ゲーム機向けは往々にして、ターゲットとなるハードウエアの中で一番性能の低いところに合わせたデータで作られた。平たく言えばPS3の方がXBOX360よりもはるかに映像表現は優れているのに（※ただし使いこなせれば） XBOX360との差異はテクスチャやムービーの解像度程度の違いだけになってしまう事を意味していた。しかしx86-64にしたことで、家庭用ゲーム機向けに統一してダウングレードされたデータからPS版を生成させるのではなく、パソコン向けのデータから生成させた方が早いと言う状況を作り出し、他の家庭用ゲーム機にくらべてアドバンテージを得ようとしているのでは無いだろうか。これはPS VitaがARMを採用したことも同じ事である。
さらに、SONYは、PSVitaから進めてきた戦略として、自社による強力にプラットフォーム感の差異を吸収するミドルウエア群…これはゲームエンジンと読んでも良いのかも知れないが…を提供してくるだろう。x86ならば従来の資産を生かすこともできるし、世の中に出ているコンピュータ向けのライブラリも利用できる。急速に開発しやすい環境を立ち上げているのではないだろうか。これはゲームエンジンにより脅かされる、プラットフォームビジネスへの対抗措置でもあるだろう。
これにより「雑事に捕らわれること無く、ゲームの楽しさ・表現そのものに専念する」と言うクリエイタの夢を叶えるハードウエア、それがPS4であろうと思う。
平たく行ってしまうと、自社の半導体商売が死んだことにより、その死絡みから解き放たれたPSは、クリエイタ主導でゲームを作ると言う根本に立ち返って作ったのがPS4だ、と言う話である。
しかしこれだとハードウエア、製造業の夢はどうなってしまうのだろうか？そしてユーザは別にクリエイタの夢などはどうでもいい。下手をすると高性能なハードウエアを所有していると言う欲を満たせなくなる分だけこちらの方がまずいかも知れない。それをどうカバーするのか？と言う話になる。
SONYは、次世代戦略として明らかにソフトウエア重視に舵を切っている。SONYは今、収支から見ると製造業では無く金融業であるが、その次に利益を生み出しているのは音楽・映像ソフト部門とゲーム部門である。
まずはここを潰してしまっては会社として立ち行かなくなる。それはまずい。ではどうするかというと、従来の「製造業としてのSONYを強くするために、PSの需要を利用する」のではなく「コンテンツ・製造複合体としてのSONYの核にPSを据え、関連商品を生み出す形で恩恵を得る」と言う形に舵を切ってくることになる。PS3でも一部行われているが、たとえばPSのリモートプレイを可能にするパソコンやタブレット、PSを再生装置としてコンテンツを供給できるメディアサーバといった具合である。
しかしこれらに対応させるために大切なPS本体の魅力を失わせては困ると言う事は強く意識されなければならないし、意識されていくだろうと思う。
ユーザの夢は、将来的には作りやすいゲームプラットフォームが生み出す新しいコンテンツという形で満たされることになるだろうが、直近では、ソーシャルへの展開という形で示されていると思う。将来的にはいかにコンテンツを集められるかと言う事にかかっている。が、ぶっちゃけていうとユーザから見たら、これほど夢の無い話は無いと言わざるをえない。
今回発表されたタイトルのデモなどは実際にはチャンピオンで有り、実際にプレイして得られるのはPS3とそれほど感覚的に、革新的に良くなったと感じる部分は薄いと思う。この点で、PS4は、PS3と実働コンテンツはそれほど変わらないと思っている。マイナーバージョンアップ程度。パソコンがWindows XPで評価が固まったようなものである。これはおそらく次に発表される新型Xboxでも同じだ。任天堂は少し別格の応えを出したが苦戦している。
かつてセガが出した芸術品とも言える至高のゲーム機、DreamcastはOSにWindows CEを搭載した。プロセッサこそ独自であったがそれは当時のWIndows CEではあたりまえであり、むしろそこにWindowsと言う汎用のソフトウエアを利用したことで非常にゲームが開発しやすく、PCゲームが移植しやすい環境を作り上げた。それらはアーケードのnaomiプラットフォームや、ワンチップで埋め込まれたパチンコなどで今でも生き続ける。
任天堂がWiiUでコントローラに画面をつけDreamcastに追いついたように、SONYは、PS4で作りやすいゲーム機という点で追いついたと言える。
またしてもセガは早すぎた。時代がセガに追いついていなかったのである。Dreamcastはその名の通り「夢を投げる」存在であったのだ。
見出しはこれ http://anond.hatelabo.jp/20121219191602
http://toro.2ch.net/test/read.cgi/unix/1288765389/232
232 ：名無しさん＠お腹いっぱい。：2012/03/25(日) 15:05:26.72 今月はじめ、職場に新しいPC(Pentium4の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSにオープン系を採用するのは 聞いていたのですが、搬入されたPCのダンホール箱に乗っかっていたのは UNIXのインストールパッケージでした。 「うへぇ～、よりによってUNIXかよ」 デバイスドライバがない、コマンドが変・オプションがない、X環境が古い、 今の奴は日本語入力大丈夫なのか(Wnn/Canna/kinput2)、将来の64bit移行はどうなのか、 今時のネットで必須のflashのプラグインは存在するのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一CADなどのエンジニアリング環境が充実していたUNIXは大学など 教育機関に浸透していて、日本のUNIX界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかなどと、 サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去10年のUNIX界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではPlamoでもDebianでもRedHatでもKondaraでも Slackwareでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1355909018/4
4 ：名無しさん＠お腹いっぱい。：2012/12/19(水) 18:44:07.79 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、複数マシンでファイルを共有するのは 聞いていたのですが、起動したマシンの/etc/fstabの項目に書かれていたのは nfsという文字でした。 「うへぇ～、よりによってNFSかよ」 ファイルロックすると刺さる、ファイルを消したのに.nfsXXXが残る、 今の奴はACL大丈夫なのか、ファイルのCapabilityに対応してるのか、 今時のLAN上で使ってもセキュリティは大丈夫なのか不安はつきませんし、 ユーザーが減ってるのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一ローカルディスクかネットワーク上かの区別なく透過的にファイルに アクセスできたNFSは大学など教育機関に浸透していて、日本のストレージ界に 多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ファイルに書き込んだら所有者がnobodyに なっちゃったよとか、タイムスタンプがずれるよとか、NFSv4にしたらマウント できなくなったよとか、TCPよりUDPの方がオーバーヘッドが無い分速いはずだよね などと、鯖管気取りの偏ったどうでもいい我侭を言いだし、 (だからNFS鯖にするんじゃねーよ)それと戦わなければならないのでしょう。 そして時代によって決着している、過去25年のNFS界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではSambaでもNetatalkでもFTPでもなんでもいいですが 安定してユーザーが多いファイル共有システムにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1351627596/3
3 ：名無しさん＠お腹いっぱい。：2012/10/31(水) 10:57:28.82 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSに*BSDを採用するのは聞いていたのですが、 搬入されたPCのダンホール箱に乗っかっていたのはFreeBSDのインストールパッケージ でした。 「うへぇ～、よりによってFreeBSDかよ」 カーネルが変、日本語環境がない、ソフトが変・揃ってない、今の奴は 日本語文字コード大丈夫なのか(utf-8)、x86_64環境は大丈夫なのか、 今時のネットに繋いでもセキュリティは大丈夫なのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一PC98環境が充実していたFreeBSDは大学など教育機関に浸透していて、 日本のFreeBSD界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ポーツ(笑)でemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかとかなどと、 鯖管気取りの偏ったどうでもいい我侭をいいだし、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去20年のFreeBSD界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではUbuntuでもdebianでもFedoraでもRHELでも OpenSUSEでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1209056071/887
887 ：名無しさん＠お腹いっぱい。：2012/10/21(日) 11:56:55.61 今月はじめ、職場に新しい組み込みマシン(ファン付きだけど結構省スペース構成)が 入りました。多分私が開発全般をまかされそうな雰囲気です。業務的にとある 構造分析やシミュレーションなど行う必要があり、プログラムにアセンブラを 使用するのは聞いていたのですが、添付のサンプルソースコードからチラッと 見えたのはsethi %hi(hoge),%o0という命令でした。 「うへぇ～、よりによってSPARCかよ」 長くなるバイナリーコード、奇数アドレスワードアクセス不可、使いにくい レジスタウィンドウ、今時の素早いコンテキストスイッチに対応できるのか不安は つきませんし、今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 おそらく導入に際して、大学など教育機関で最初にSPARCに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、32bitCPUでRISCでM68K系よりも高速で動作したSPARCは 大学など教育機関に浸透していて、日本のCPU界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、16bitイミーディエイト値すら1命令でロード できかないのかよとか、関数呼出しのたびになんで約100バイトもスタックフレームが 要るんだよとか、フラグレジスタの読み出しがなんで特権命令なんだよとか、 %g0ってレジスタ値変わらないし壊れてるよ、初期不良で交換だよとか、 アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからSPARC使うんじゃ ねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 過去25年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの でしょう。もう今からうんざりです。 だからお願いです。教育現場ではi386でもi568でもi686でも x86_64でもなんでもいいですが現行のCPUにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
ようやくRailsの開発を一人で出来るようになった彼女が、俺に突然質問を投げかけた。
「ねぇ、WebサービスのPushってどうやって実装するの？」
「クールな順にWebSocket、次にコメット、最後にポーリングだよ」
彼女は目を輝かせながら「それでそれで？！」と説明を求めてくる。
「ポーリングは、一定の時間ごと、たとえば３秒ごとにAjaxでサーバにリクエストを送って新着の情報が無いか問い合わせて、もし新着があれば処理を、なければスルーして次の問い合わせに備えるPush通知の実装だ。手軽に実装できる反面、新着がない多くの時間常にリクエストを送り続けることになるので無駄が多い。大規模なサービスで実装すれば、それだけでDDoSっぽくなっちゃう。また、リアルタイムも厳密には実現できなくて、MAXでポーリング間隔分のラグが発生してしまう。小規模なサービスで、とりあえず実装するにはオススメかな。」
なるほどなるほど、と彼女は頷く。
「コメットは？」
「コメットはポーリングを改良したもので、ブラウザからリクエストが送られてきた時点ではサーバはすぐにレスポンスを返さずに、処理中ってことでコネクションを張ったまま一定時間待つんだ。それで、なにか新着があったタイミングで、昔送られてきてたリクエストのレスポンスを返す。そうすると、新着があったタイミング＝レスポンスを返すタイミングになるので、レスポンスはほぼリアルタイムになる」
「なるほど！すごい！！！」
「頭の良い実装だよね。Facebookの通知なんかはコメットだよ。ただ、コメットも万能じゃない。まず、レスポンスはいつまでも待てるものではなく、待たせすぎちゃうとタイムアウトになっちゃうんだ。だから一定時間ごとには何もなくても"進捗はなかったよ”というレスポンスを返してあげなきゃいけない。また、サーバはコネクションを常に割り当てないといけないので、IOをブロックするようなサーバだとリソースを食い過ぎて耐えれ無くなっちゃうから大規模な運用には金がかかっちゃうんだ。所詮はHTTPを使ったごまかしでしか無い。オーバーヘッドが大きいんだよ。」
「な、なるほどー」
少し話が小難しくなったためか、一生懸命理解しようと彼女が頑張っている。かわいい。
「そこでWebSocketの登場だ。WebSocketは厳密には違うんだけど、HTML５関連の新しい技術で、ネトゲで使うTCP/IPのセッションのようなコネクションをサーバ側と張ることができる技術なんだ。しかもNATとかも超えてくれる便利な技術。これがあればリアルタイムWebの実装はすごく簡単になるんだけど、まだ新しい技術というのもあるし、対応してるサーバやライブラリの不足や、プログラミングのスタイルがイベント駆動になるという変化もあって、まだまだ一般的にはなってない。対応してるブラウザも最近まで多くはなかったしね。やっとiPhoneでも使えるようになったし、スマフォのWebでも普通に使えるようになってきた。これからが楽しみだね。」
「うーんと、うーんと、つまり」
彼女は今日得た知識のまとめに入ったようだ。一生懸命Webの技術を学ぼうとしている健気な彼女に、僕は心がキュンとなった。
「そう、つまり…」
びっくりして目を見開いている彼女。
「チュッ、チュッ、チュッ、チュッ、チュッ、」
「これがポーリング。」
「チュポッ…」
彼女の頬は少しだけ赤く染まっていた。
「これがWebSocket、そして…」
最後に僕は彼女の顔を両手でホールドし、８秒くらいの長い、とても長いキスをした。
「よし、じゃあコーディングに戻ろう。」
「私、コメットがいいな。。。////」
STLを使うことによる オーバーヘッドは 数～数百バイトオーダーだろ。どんなに見積もってもキロ単位。
いくらなんでも、キロ単位を 詰めることは稀 というのがメモリの見解。
メモリを最も使うのが、画像。画像１枚で数百Kで こっちを何とかしたほうがよほどはやい。
ここで言ってるのはあくまでも、STLを使うことによるオーバーヘッドは メモリが潤沢にあるものと想定してもいいって話で
ここで行ってるCPUは モバイルだな。 電池の持ちにも直結するし、持ってるメモリを０クリアとか、やらなくてもいいと分かり切ってる時でかつ
「人数増やすと…」について補足。
http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1
スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマがプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションのオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。
今回のケースでは、60人が1300人になったので、コミュニケーション量は約477倍になるわけだ。
文法が狂ってるプログラムなんて今日日見たことないんだけど、実際あるの？
だって、自分がかじった数少ない開発環境でさえ、たいていコンパイルで止まるし、
ものによっては打ち込むときにエラーだと言われるものまである。
まともな開発予算が組めていれば、レビューは当然予算に組み込むもの。
（項目として入れていなくてもオーバーヘッドを取るのは当たり前）
それをしないのは発注側の落ち度でしょう。ここで愚痴ってる場合じゃない。
初めて組むところに大きな物は任せないし、レベルが低ければ切る。
全然話が進まないのは話が噛み合ってないからでしょ。
「プリプロセッサ言語でオブジェクト指向を持ち出すお前が痛すぎる」に対して、横から「オブジェクト指向プログラミング言語でなくてもオブジェクト指向は使えるだろうと思ったけどたぶん話の流れと関係ない」と言ったのが当初の発言。
それに対する返答が「そういう事じゃなくて、可読性および処理速度、オーバーヘッド的な意味でオブジェクト指向は駄目」。
全く話が噛み合ってない。「そういう事」じゃないから、「話の流れとは関係ない」って言ってるのに。
そして「オブジェクト指向プログラミング言語でなくてもオブジェクト指向は使えるだろう」の否定になってない。
これではいくら実例出しても話は進まないだろう。
事情をわかっていないようなので説明すると、昔はサーバリソースというものは大変貴重だったので、元増田が言うようなオーバーヘッドが大きいテクニックは一切使えなかったの。ただそれだけ。
「この時代にはそんな考え毛頭なかったんだね」なんてこたぁない、ただ実用的ではなかったというだけで。
そういや増田が好きなPHPも比較的サーバーリソースを食わないもんだから広まったんだっけか。やっぱ速度って大事だよなぁ。
>可読性および処理速度、オーバーヘッド的な意味でオブジェクト指向は駄目って言ってるんだろ
普通はこの１文で納得できるもんだが
ひょっとしてプリプロセッサ言語では「翻訳」が行われる事とか、オブジェクト指向的な処理をするのは最初にコンストラクタが走るのでオーバーヘッドがかかる事とか、いちいち全部情報処理の専門学校に入りたてのガキに教えるように教えないと全く判らないかい？
そういう事じゃなくて、可読性および処理速度、オーバーヘッド的な意味でオブジェクト指向は駄目って言ってるんだろ
一時オブジェクト指向を広めようとしてた連中がオブジェクト指向のプログラムは可読性が高いと言ってたが、実際は低い事が知れ渡って、オブジェクト指向の仕事がガッツリ減った時期があったし
可読性はともかく、保守性の面から、フレームワークさえ保たれてればオブジェクト指向じゃなくてもいいと思う
特にwebはオブジェクト指向ガチガチでやるとフレームの外でCookieが必要になったりして、結局オブジェクト指向を崩さなきゃならないなんて事は結構あるし
５年前だとCSSもブラウザ間でかなり処理が違ってたらしいし、時代的にオブジェクト指向で出来なかったという経緯もありそうなもんだけどね
http://amg2009.blog10.fc2.com/blog-entry-281.html
「日本のサッカー場は僕らのより１００倍広いのか？と思ってた。」
「翼が歩んでいた道こそ僕らの夢そのものだったんだ。」
「いつだって僕のイメージの中には翼のゴールがあったんだ。」
「三杉のオフサイドトラップを思いうかべて練習した。」
「僕はキャプテン翼でいえば三杉君」の発言あり。
ツインシュートの練習をしていたことがある。
『一緒に戦いたいキャプテン翼のキャラクターは？』という質問に対し、
「ジノ・ヘルナンデス」をチョイス。
マンガを全巻揃えている。
岬の得意としていた
ジャンピングボレーを得意技にする。
ある時、サッカー教室を開いて、子供達に「好きな選手は？」と聞いたら、
「翼・岬・日向・若林」など知らない名前が出てきてパニックに。
「なぜ翼をうちのチームに入れてくれなかったのか？」と発言。
ちなみに翼が入団したＦＣバルセロナは、実際に翼の入団セレモニーを行った。
翼がバルセロナに所属していることは公式に認められている。
批判する前にC++の設計哲学（ http://ja.wikipedia.org/wiki/C%2B%2B#.E5.93.B2.E5.AD.A6 ）とあなたの使い方が一致しているかどうか考えてみるべきじゃないかな。というわけでその点からこの批評を批評してみる。
総評：元増田の求めるところと言語の設計哲学とのミスマッチが見られるので、使う言語を変えるほうが幸せになれると思われる。誰かいい言語を紹介してあげて。
仮に「PS3版＝無圧縮、360版＝圧縮」だとすると、圧縮されたデータを伸張するためのオーバーヘッドがどこかで発生するはず。
別枠なんて時間と手間がかかりすぎるじゃん。オブジェクト指向の弊害と同じ。
ていうか話の主旨が変わってきてる気がするけど、少なくとも実際に多くの時間を費やす恋人に対して性欲処理以外の効用を何も求めてない男ってのは存在してて、そういう人は時間の無駄してると思ったりしないのかな？ってのが最初の疑問で、君が無駄だと思ってないというのならその理由が聞きたいわけだ。
それに対して君はdivide and conquer的な考え方が有効なんだという信念を持ってるみたいだけど、俺はそれに対してわざわざdivideするオーバーヘッドコストの方が高いんじゃねーの？って言ってるわけだ。それに対する解答はまだ得られていない。
（性欲処理の欲求があまりないのというのなら話は別）
これはつまり「性欲の優先順位が一番高い」ってことだよね？
私は結構flashについて知識がある。私が始めてトレーニングコースでflashについて言及したのが何時だったのか覚えていない。それ以来、flashはトレーニングコースの一部となっている。
しかし、トレーニングコースで人にflashについて話していても、私は実際に自身のページの中には使っていなかった。フリーランサーとして明らかに、日常の仕事において、私の顧客が使っているテクノロジーが何であれ、それを使うことを余儀なくされる。私はまだ、flashを既に使っているプロジェクトの仕事を受けていない（私は数人の顧客にflashを使ってはいかがと勧めているけれども）。
私自身のページは別だ。そのページは主に私のサイトである。最近まで、それらのどれにもflashを使わなかった。flashを使った私の最初のリリースは、なんだったろうか。始めからflashを使った新しいサイトだ。しかし、結局のところ、flashが適切である場所ならどこでもflashを使うように、遡って既存のサイトをリファクタリングしたくなることが分かった。
近年Google Mapを使い、AJAXがいかに素晴らしいかを面と向かって私に語る人々の一週間に付き合わされた。そして、歯を食いしばってリファクタリングを始める時だと決心した。
私が試みた次のサイトがフォトギャラリーのためのサイトだった。2つの理由のため、これを選んだ。第一に、それが正に見た目重視の重いサイトであるから。画像の初期読込みを別にして、このレスポンスの悪さは出来るだけ見栄えのよい画像を表示するために存在する。これは非常にflashと相性がよい。事実、flashを使うようにリニューアルすることは、トラヒック削減の主なケースだった。第二に、もっと実際的なことだった。つまり、私が知っている限り、このサイトを使っている人はいないので、私が何かを壊しても、私を罵る群衆がいないであろう。
そのリニューアルのいとも簡単さに感心したので、私はメニューに移った。この部分は、私の最初のサイトより存在していた、特別な思い入れがあった。それが特別便利とは思っていない。そのデザインは非常に基本的で、私が元々これを書いた最初のサイト以外には、どのサイトにも使っていない。私は屡々新しいテクニックを試すために、それを使用している。8月9日にバージョン2.00をリリースした（その実装の変更は、メジャーバージョンナンバーを上げることに相応しいと思った）。
昨日、私はflash使用を止める要望のRTチケットを受取った。そのチケットは、いろいろな使用（そのチケットでは、テキストベースのブラウザでの使用にも言及しているが）に対して、flashによって加わった更なるオーバーヘッドが受け入れ難いパフォーマンスの打撃になっていることを明らかにしている。
私はこれをどのように克服するか分からない。一デベロッパーとして、私はflashの使用が好きである。flashは、動的なUIのページを書くことを容易にする。私は、翌年以降年々、Webデベロッパーはflashを使っていくだろうと考えている。もし、あなたが既に充分に複雑なことを HTMLで書いているなら、flashを使っているページを使用するチャンスである。時が経つにつれて、flashに依存するページの割合は増加するだろう。しかし、小さなアプリケーションに対して受け入れ難いパフォーマンスの打撃があるならば、デベロッパーが使っていないflashを強制することはいいことだろうか？
これをもう少し熟考するまで、私の作物をflashに移動させる計画を保留したいと思う。しかし、私は他の人の意見を聞きたい。あなたがサイトオーナーなら、あなたのページでflashを使用することを考えているのか。あなたがWebサーファーなら、 flashを無理強いするページを避け始めているのか。
あなたの考えを教えてほしい。
