はてなキーワード: マルチコアとは
たぶん失恋。
好きな人がいるだけでモチベーションの維持、生きる目的というか、支えられていた事に気付かされる
悪いことに好きな人のために空けておいた年末年始の連休が逆に作用し精神的にうつっぽくなって、誰とも話したくなくなっていく
元来活発な方ではあるが、しばらく社会から離れると戻ることが怖くなっていくという・・・以前の私、病弱で引きこもっていた頃のような精神状態へ傾きかけていた。
職場ではいつも元気で周囲を盛り上げていく役であったのでそれが出来るかすごく不安だった。
大人になって、病気、離婚などの困難も乗り越えてきたからであろうか・・・?
いつの間にかスイッチを切り替えることが出来るようになっていた、
職場ではいつもの私だったし、努めて演じていたわけでもない。それが自分でも驚きだった。
何十年前だろう・・・学生時に愛猫が死んでしまい学校こそ休まなかったが、授業中でもそのことで頭がいっぱいで泣き暮れていた事を思い出した。
どっちに転ぶのかね、今主流になっている、マルチコア系の技術であるマルチタスクは、スパコンやGPU並みの処理だと
スレッド技術であるLinuxより、RTOS系列のJOB・タスクであるTRON的な考え方の方が、有利であることは事実だけどね。
でもまぁ、そのJOB管理をコンパイラがやってしまおうというCILKもあるわけで、時代がどっちに転ぶかはわかんね。
ただ、スレッドのコンテキストスワップとかを理解しないで、スレッド書いている人が量産されたというバッドノウハウ的な設計がまだまだ多そうだし、
本当は学校でJOBを教えるのがいいけど、そもそも、教えられる人がいないし
時代にIFはねーなーと思う。むずかしい。
あけおめ!今年は巳年。へび。へびと言えばPython。そう今年は全てのwebエンジニアがPythonを勉強する最高の環境が整った年なのです。
必要です!必要だと思います。もはやPythonはwebエンジニアにとって必修言語となりつつあると思います。Linuxの多くの箇所でシステム言語として用いられ、可読性の高さから多くの技術系書籍のサンプルコードとして用いられ、科学技術系分野におけるエコシステムの充実っぷりはますます磨きがかかっており、様々なライブラリがどんどん出てくる現状を「Pythonわからないから自分には関係無い」と遠巻きに眺めるのはもったいないです。
あなたが既に他の言語に慣れ親しんでいるなら、特にRubyなどに精通していれば「1週間」で基本的な読み書きは出来るようになるでしょう。そのくらいPythonは敷居の低い言語です。またweb上のチュートリアルドキュメントが大変に充実していますので(もちろん和訳済み!)費用0円で勉強開始できるお手軽言語でもあります。
これは大変に悩ましい問題で、自信を持ってお薦めできるバージョンが無いのが残念な現状です。2系と3系は特に文字コード周りを中心に言語体系にそれなりの差があり、日本語を扱うエンジニアにとっては悩ましい問題です。結論としては「どちらも読み書きできる」ようにした上で「3系で書く」ですかね。2と3の違いを理解しておかないと必ずどこかで躓きます。特にweb上の情報はまだほとんどが2系ですが、ぱっと見て2と3のどちらのバージョンで書かれた情報なのかを判断できないと多くのweb上の情報を利用できずにもったいないです。
先述しましたが和訳済みのチュートリアルが充実しているのがPythonの特徴でもありますので、まずは目を通す事をお勧めします。
ぜひ超充実したドキュメント群を覗いてみてください。「チュートリアル」を読めばだいたいの言語仕様がつかめるはずです。「ライブラリリファレンス」はあなたの最高の辞書となるでしょう。
その上で、やっぱり書籍で勉強したいということでしたら以下の本がお薦めです。
・プログラミング自体が初めての人向け
・他言語を既に知っている人向け
みんなのPython 第3版(柴田 淳) ・・・2版と3版で大きく内容が異なります 2版はPython2系、3版はPython3系を中心に解説
・進んだトピックを扱う中級者以上向け
pythonはインデントの存在があるので無機能エディタで大規模なコードを書くのは案外骨が折れます。贅沢系IDEの代表格はPyCharm(有料$99)でMac,Windows,Linuxの3プラットフォームに対応しており、一つのアカウントでいくつものマシンにインストールできます(同時に使う事はできない)。30日間の無料トライアルもありますしトライアル期間が過ぎても一回あたり(たしか)5分ぐらいなら継続して使えます。無料IDEだとEclipseプラグイン、Netbeansあたりでしょうか。Netbeansは公式開発は既に終了しておりあまり安定していません。
大規模な開発ならDjangoが第一候補。歴史が長いフルスタックなフレームワークですがまだ正式版がpython3系に対応していない。最近勢いがあるPyramidは3系に対応済み。各webフレームワークについては各開発者同士が「筋が悪い」「Pythonとしておかしい」「トレンドから3年は遅れてる」などとガチンコで思いの丈をぶつけ合っている以下の記事も参考にしてください。http://www.atmarkit.co.jp/news/201209/24/pycon.html
とりあえず最低でもDjangoとPyramidは両方使ってみてから自分にあった方を選択するといいと思います。
・Numpy/Scipy
科学技術系の人が好んでpythonを使う理由の一つがNumpy。数値行列計算を内部でCを使って計算するために非常に高速。インターフェイスは書きやすいpythonだけども実行速度はCネイティブ並みというとてもありがたいライブラリです。現在のPythonの盛り上がりに間違いなく大きく影響しているライブラリ。
・nltk
言語処理で使われるライブラリ。英語がベースとなってますが工夫すれば日本語でも全然使えます。参考文献 http://nltk.googlecode.com/svn/trunk/doc/book-jp/ch12.html
・multiprocessing
並列処理ライブラリ。CPUのマルチコアを全て使い切って無駄無く高速に処理を行いたい時に重宝します。個人的に大好きなライブラリ。頑張ればちょっとした分散並列システムも作れます。このライブラリのお陰で自宅にある10台*(擬似)8コアでお手軽python並列処理クラスタを30分ぐらいで作る事ができました。
わからんけど、グラヒクスと音声は リップシンクがあるから必ずしも別じゃないし
そもそも、音声を鳴らすチップ自体が独立したコアみたいなもんだからなぁ・・・
ネットワークチップだって独立したチップのやつは 別のコアみたいなもんだぜ?
話はずれたけど、まともなマルチコア向けプログラムを書くとなると、いわゆる1スレッド1役割みたいな処理は欠かずに
タスクシステムとか、スレッドの役割分担システムみたいなものを自分で書き下ろして、いわゆるマルチファイバーというか、マルチタスク的なシステムで
組んでいくから、(マルチタスクを自前で組むことが必ずしも高速化ではなくて、いくつもノウハウがあるけど) あまり、セマフォというかミューテックスを意識することは少ないよ?
たとえば、ちょっと違うけど 通信が一万本合ったら、1万スレッド起こすのか?起こさないというのと同じかなぁ。
逆に言うと1つのタスク中に入りと出以外に何箇所もロックしたり、開放したりするシステムはコンテキストスイッチの考え方からあまりよくない。
リソースになるべく触らない、触ったらローカルメモリーに移しておく、なるべく長い時間1つのスレッドを走らせる。リソースに触るときは処理終了して次のタスクにしてしまう。
などなど、そんな感じ。 スレッドに役割を振り分ける というよりは、タスクで回していくという感じ。
もちろん、長々走るものもあるだろうけど。
先日ニコニコ動画がリニューアルされ、ビットレートや解像度などの制限が撤廃された。
http://av.watch.impress.co.jp/docs/news/20091028_324929.html
それを受けて早速「画質の限界」に挑戦する動画が上げられ始めている。たかだか1分から2分程度の動画で容量制限(100MB)ギリギリ一杯まで使った動画である。
もし見たければ、さしあたり「高画質再アップ祭り(9)」でタグ検索をしてみると良いだろう。中にはビットレートが40Mbpsという冗談みたいなものもある。これはBlu-ray映像の上限値に匹敵するものだ。そんな動画をいくつか見ていて気になるのが、動画内でのコメントだ。
「カクカクする」
「コメントを非表示にすればなんとか見られる」
「CPU使用率100%」
「重すぎて見られない」
こんなコメントをよく目にするようになった。マルチコアCPUと十分なメモリを搭載したPCであれば再生にさほどの負荷を感じないはずだが、こういったコメントが目立つあたり、古いPC(それでもOSや一般的なアプリを動作させるには十分すぎる性能だとは思うが)で見ている人の多さを実感させられる。前述の40Mbpsの動画は極端にしても、今後は数Mbps程度の動画が増える事だろう。それに伴い動画の容量も増えていくだろうから、有料会員(時間帯によっては低画質でしか再生出来ない無料会員と違って常時高画質で再生される)の付加価値も高まるだろう。少しばかり古いPCを使っている無料会員の今後の動きが気になる。
http://anond.hatelabo.jp/20091030202541
あーネットブックか。
外出先で気軽にニコ動が見たいという動機で買った人は言いたくなるかもね。
http://anond.hatelabo.jp/20090205230411
さらにメモ。
一般的なDVDビデオ(主に映画など)をPCでH.264形式のMP4ファイルに変換し、PS3のHDDにコピーして再生可能にするための作業手順である。
MP4変換だけならば、Core2Quad Q9550で約50分で完了した。ISOイメージ化も含めるとトータル一時間強か。
いろいろ間違ってるかもしれないが、力尽きた
分類 | 開発環境 | 開発言語 | メーカー | GPU | OS | API | 備考 | URL |
---|---|---|---|---|---|---|---|---|
シェーダ言語 | _ | Cg | NVIDIA | GeForce | Linux Windows Mac OS X XBOX | OpenGL DirectX 8/9 | C言語ライクな言語 グラフィック用途向け シェーダープログラムの最適化 | http://developer.nvidia.com/page/cg_main.html |
シェーダ言語 | _ | HLSL | Microsoft | GeForce RADEON | Windows | DirectX | グラフィック用途向け シェーダープログラムの最適化 | |
シェーダ言語 | _ | GLSL | OpenGL ARB | _ | _ | OpenGL | C言語ライクな言語 グラフィック用途向け シェーダープログラムの最適化 | |
GPGPU言語 | CUDA | C言語 | NVIDIA | GeForce GeForce 8100 mGPU以上 | Linux Windows XP/Vista Mac OS X | _ | 標準C言語 | http://www.nvidia.com/object/cuda_home.html |
GPGPU言語 | Stream SDK | Brook+ | AMD | RADEON R600世代以降 (=RADEON HD2400以降) | Linux Windows | OpenCL(対応予定) DirectX 11(対応予定) | C言語ライクな言語 | http://ati.amd.com/technology/streamcomputing/index.html |
GPGPU言語 | Brook for GPU | Brook | スタンフォード大学 | GeForce RADEON | Linux Windows | OpenGL DirectX 9 | C++ライクな言語 | |
GPGPU言語 | Close to Metal(CTM) | アセンブリ言語 | AMD | RADEON | _ | Stream SDKのCALに移行 | ||
GPGPU言語 | _ | Sh | _ | _ | _ | _ | C++ライクな言語 | |
GPGPU言語 | RapidMind | C++ | _ | GPU マルチコアCPU Cell | _ | _ | Shの商用化版 |
参考文献
CUDAを使う:tech.ckme.co.jp
http://tech.ckme.co.jp/cuda.shtml
【特集】超並列プロセサ - GeForceアーキテクチャとCUDAプログラミング
http://journal.mycom.co.jp/special/2008/cuda/menu.html
Windows環境は、Visual Studioを用いてmakeを行うようになっている