アカウント名:
パスワード:
通信プログラムをつくるときには、その通信内容が、電気的にどうなっているか、までは問わないけど、イーサネットに流れるビットレベルくらいは想像がつくようになっておけ、とは言ってます。
プログラムも、概念的にどういうマシン語に落ちるかを理解しておくと、最近のマルチスレッドプログラムとかで、競合や粒度などが直感でわかるようになり、バグは減らせます。
PCIeが並行して複数のデバイス間データ転送を実行できるとしても、DMAは全部物理メモリ相手なんだから、結局メモリコントローラーの取り合いで衝突するに決まってるだろっ!!「PCIe 上に載っているデバイスは高速に応答するから大丈夫だ」って馬鹿かお前は。高速に応答するデバイスに次々とリクエスト投げたら、バスを占有しまくって、周囲のデバイスがDMA転送できなくなるだろうがっ。その、無駄にディレイさせられたデバイス上でバッファオーバーフローを起こしたら何が起こると思ってるんだっ。最高パフォーマンスを出したかったら、「速けりゃいい」っていう発想をやめろっ!!!インディ500のオーバルコースでさえ、カーブの所ではスロットルを緩めるだろうがっ!! それと一緒だっっ。コントロールを失った「高速」はクラッシュの原因でしか無いわっっ!!!
PCIeが並行して複数のデバイス間データ転送を実行できるとしても、DMAは全部物理メモリ相手なんだから、結局メモリコントローラーの取り合いで衝突するに決まってるだろっ!!
「PCIe 上に載っているデバイスは高速に応答するから大丈夫だ」って馬鹿かお前は。高速に応答するデバイスに次々とリクエスト投げたら、バスを占有しまくって、周囲のデバイスがDMA転送できなくなるだろうがっ。その、無駄にディレイさせられたデバイス上でバッファオーバーフローを起こしたら何が起こると思ってるんだっ。
最高パフォーマンスを出したかったら、「速けりゃいい」っていう発想をやめろっ!!!インディ500のオーバルコースでさえ、カーブの所ではスロットルを緩めるだろうがっ!! それと一緒だっっ。コントロールを失った「高速」はクラッシュの原因でしか無いわっっ!!!
なんか kbps の世界で痛い目にあって、 Mbps の世界で叫んだのと同じ内容を、Gbpsの世界でも叫ぶ必要があった一昨日…。
# きっと Tbps の世界でも叫ぶ必要が出るに違いない、と直感した。
地面が混雑しているなら、空を走ればいいじゃない。教祖様は保守的に過ぎます。
空を飛んでコーナーをそんなに効率よく曲がれるもんなら曲がってみなはれ。# それで効率よく曲がれるなら、グリップを失った後に壁にぶつかったりせんわい
http://www.toranoana.jp/mailorder/article/04/0000/04/91/040000049121.html [toranoana.jp]
これが時代の違いですよ、教祖様
そんなスパイダーマン [wikipedia.org]のパチモンみたいな手は通用せんっ。
オーバルコースには「天井がない」のだよ(そこっ?? 突っ込む所はそこと違うっっ)あ、もちろん、高いビルもないぞ。
だから、西新宿のせんべい屋の主だって、空を飛んだりはできんのだ。
つまり、限界までの高速化のためには限りあるバス帯域を使うのが一番のネックなので専用のメモリをオンボード実装しメモリコントローラーはボード搭載のCPU内蔵のものを使うそんなデバイスじゃないと、余所様に迷惑な実装だということですね。
そして、システムバスには「42」とだけ返答を流すと。
まずあなたが空を走ってからその走り方を伝授しなさい。
なんてか、長年やっているといろいろな所で、機能自体が隠蔽されるのと明示的に考慮が必要なのが交互に来ている気がする。まあどんな新機能でも最初は実装優先のフェーズが有り、そこから利便性の向上をめざし、更にスペックアップ…となるとそれも必然なのかも知れないとか思ったり。
それって昔のスキルというよりも下位レイヤのスキルの話だよね。
下位レイヤも知っといた方がいいよ、というのは同意。
> 今は「知っといたほうがいい」程度だけど、昔は知らなければ仕事にならなかったという意味で昔のスキル。
その通りです。昔は、周辺機器もバグが多くて、本来は自分の範囲でないところでも理解しておかないと、それを避けたり、可能であれば自分で修正したりしないと、仕事が前に進まなかったのです。
いや、未だに多いですけどね?
# x86に対応してますって、特定のOSで動いたからOKってもんじゃないぞ!# 汎用ドライバ対応のくせにforkしなきゃ他じゃ全く動かんじゃないか!
電気的にも、わかってるともっといいと思うハード不具合や故障なのにソフト不具合にされてしまうからw
いろいろ理解していることは、いいことだけどそれがすべて理解したと思って自分が知らないことがあるってことをわかってないのも困るよ外注先で、自称ネットワークに詳しい人が、そんなことできませんっていうからおかしいと思ったらPCにIPを2つ以上設定できることをしらなかったとかあった。
いろいろ理解すると知らないことがかなり増え、その知らないことを理解するとさらにさらに知らないことが増えるw
そうそう。どこまでも知って行って損はないですね。
例えば、組み込み系やってるときなんかは、ハードが疑わしい問題が発生するとオシロ繋いで電気的に信号を捕まえて、もっともシンプルなプログラムで発症させてハード担当者に調査をお願いする。なんていうのが普通の手続き。
オシロの使い方を理解していたら、次は回路の動作を理解するとさらに問題解決は早くなる。回路自体を読んだり、そのうち自分は開発中のCPUのマイクロコードを書くところまで降りて行った。そして次は・・・と、知れば知るほど、知らないことの地平がどこまでも続いていることを知る。という状態くらいが技術者にはちょうどいいと思います。
ネットワーク方面だって、安定につながったネットワーク上で動くものばかりじゃありません。遅延、欠落、輻輳などを発生させた状態で、要求仕様を満たすパフォーマンスが出るかどうか。何で試験すればいいか。何で確認すればいいか。中で何をやってるのか。エラーの原因は何か。など、学校を出たばかりの若者なんかは、スクリプトや.NETやJavaVMなどの十分にラップされたソフトウェアの上の例外でしか知らないから、エラーリカバリーなんかは教えるべきところが多々ありました。
知っている事と両手で届く範囲の安定にもたれかかっているだけでは、技術者としての成長は乏しいでしょう。若い人にも、世界の広さを探求しながら、今の業務に必要な技術を突き詰めてもらいたいですね。開拓の終わっているところは、古参者に尋ねてくれれば教えるのは厭いませんし。
お、お代官様がなんかまともに見えることを書いていらっしゃる。何かの見間違えだろうか…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
一応若いもんには (スコア:2)
通信プログラムをつくるときには、その通信内容が、電気的にどうなっているか、までは問わないけど、イーサネットに流れるビットレベルくらいは想像がつくようになっておけ、とは言ってます。
プログラムも、概念的にどういうマシン語に落ちるかを理解しておくと、最近のマルチスレッドプログラムとかで、競合や粒度などが直感でわかるようになり、バグは減らせます。
Re:一応若いもんには (スコア:3, 興味深い)
なんか kbps の世界で痛い目にあって、 Mbps の世界で叫んだのと同じ内容を、Gbpsの世界でも叫ぶ必要があった一昨日…。
# きっと Tbps の世界でも叫ぶ必要が出るに違いない、と直感した。
fjの教祖様
Re:一応若いもんには (スコア:2, 荒らし)
地面が混雑しているなら、空を走ればいいじゃない。
教祖様は保守的に過ぎます。
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:一応若いもんには (スコア:1)
空を飛んでコーナーをそんなに効率よく曲がれるもんなら曲がってみなはれ。
# それで効率よく曲がれるなら、グリップを失った後に壁にぶつかったりせんわい
fjの教祖様
Re:一応若いもんには (スコア:1, 荒らし)
http://www.toranoana.jp/mailorder/article/04/0000/04/91/040000049121.html [toranoana.jp]
これが時代の違いですよ、教祖様
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:一応若いもんには (スコア:1)
そんなスパイダーマン [wikipedia.org]のパチモンみたいな手は通用せんっ。
オーバルコースには「天井がない」のだよ(そこっ?? 突っ込む所はそこと違うっっ)
あ、もちろん、高いビルもないぞ。
だから、西新宿のせんべい屋の主だって、空を飛んだりはできんのだ。
fjの教祖様
Re:一応若いもんには (スコア:2)
つまり、限界までの高速化のためには
限りあるバス帯域を使うのが一番のネックなので
専用のメモリをオンボード実装し
メモリコントローラーはボード搭載のCPU内蔵のものを使う
そんなデバイスじゃないと、余所様に迷惑な実装だということですね。
そして、システムバスには「42」とだけ返答を流すと。
誤記 FireFox
巫女 Firefox [mozdev.org]
Re: (スコア:0)
まずあなたが空を走ってからその走り方を伝授しなさい。
Re:一応若いもんには (スコア:1, 興味深い)
なんてか、長年やっているといろいろな所で、機能自体が隠蔽されるのと明示的に考慮が必要なのが交互に来ている気がする。
まあどんな新機能でも最初は実装優先のフェーズが有り、そこから利便性の向上をめざし、更にスペックアップ…となるとそれも必然なのかも知れないとか思ったり。
Re:一応若いもんには (スコア:2, すばらしい洞察)
それって昔のスキルというよりも下位レイヤのスキルの話だよね。
下位レイヤも知っといた方がいいよ、というのは同意。
Re: (スコア:0)
Re:一応若いもんには (スコア:2)
> 今は「知っといたほうがいい」程度だけど、昔は知らなければ仕事にならなかったという意味で昔のスキル。
その通りです。昔は、周辺機器もバグが多くて、本来は自分の範囲でないところでも理解しておかないと、それを避けたり、可能であれば自分で修正したりしないと、仕事が前に進まなかったのです。
Re: (スコア:0)
いや、未だに多いですけどね?
# x86に対応してますって、特定のOSで動いたからOKってもんじゃないぞ!
# 汎用ドライバ対応のくせにforkしなきゃ他じゃ全く動かんじゃないか!
Re: (スコア:0)
電気的にも、わかってるともっといいと思う
ハード不具合や故障なのにソフト不具合にされてしまうからw
いろいろ理解していることは、いいことだけどそれがすべて理解したと思って
自分が知らないことがあるってことをわかってないのも困るよ
外注先で、自称ネットワークに詳しい人が、そんなことできませんっていうから
おかしいと思ったらPCにIPを2つ以上設定できることをしらなかったとかあった。
いろいろ理解すると知らないことがかなり増え、
その知らないことを理解するとさらにさらに知らないことが増えるw
Re:一応若いもんには (スコア:3, 参考になる)
そうそう。
どこまでも知って行って損はないですね。
例えば、組み込み系やってるときなんかは、ハードが疑わしい問題が発生するとオシロ繋いで電気的に信号を捕まえて、もっともシンプルなプログラムで発症させてハード担当者に調査をお願いする。
なんていうのが普通の手続き。
オシロの使い方を理解していたら、次は回路の動作を理解するとさらに問題解決は早くなる。
回路自体を読んだり、そのうち自分は開発中のCPUのマイクロコードを書くところまで降りて行った。
そして次は・・・
と、知れば知るほど、知らないことの地平がどこまでも続いていることを知る。という状態くらいが技術者にはちょうどいいと思います。
ネットワーク方面だって、安定につながったネットワーク上で動くものばかりじゃありません。
遅延、欠落、輻輳などを発生させた状態で、要求仕様を満たすパフォーマンスが出るかどうか。
何で試験すればいいか。何で確認すればいいか。中で何をやってるのか。エラーの原因は何か。
など、学校を出たばかりの若者なんかは、スクリプトや.NETやJavaVMなどの十分にラップされたソフトウェアの上の例外でしか知らないから、エラーリカバリーなんかは教えるべきところが多々ありました。
知っている事と両手で届く範囲の安定にもたれかかっているだけでは、技術者としての成長は乏しいでしょう。
若い人にも、世界の広さを探求しながら、今の業務に必要な技術を突き詰めてもらいたいですね。
開拓の終わっているところは、古参者に尋ねてくれれば教えるのは厭いませんし。
Re: (スコア:0)
お、お代官様がなんかまともに見えることを書いていらっしゃる。
何かの見間違えだろうか…
Re: (スコア:0)