投稿

4月, 2014の投稿を表示しています

やはりアクセス解析はするべきだという話。

イメージ
先日、Google Analyticsのアクセス人数が倍になって驚いた。 何故でしょうかねぇ。 ちょっとGoogle Analytics使って調査したところ、 以前書いた Qualcommの新技術に関しての記事にアクセスが集中していることがわかりました。 いろいろ個人的に調査してて面白かったのでブログ記事書いたわけですよ。 Qualcomm iZatのモバイル位置推定技術が凄い件 iZatのWiFi位置測位技術って、国内では本当に情報が少なくて、 業界の人からすれば常識かもしれないけど、門外漢の人はよく知らん話かと思ったので、 ユースケースを中心にして記事を書いた。 で、このページのリファラー見たところ、某ドメインの某ページから流入してることがわかった。 で、流入元のページ見てみたところ、ものすごくギークなページに到着しまして、 ここで解説されています。 国内ではここ以外でろくにIZatに関して触れている所は有りませんでした。 Qualcomm iZatのモバイル位置推定技術が凄い件 ~ 白いバナナ こんなふうに引用していただけていた!これはすごいことです。 なんか嬉しくなってコメントしてしまいました。 Google AnalyticsのおかげでWebでの生活が楽しくなった。 ありがとうGoogle。

Pthreadsプログラミング::なぜマルチスレッドなのか?

イメージ
- マルチスレッドプログラミングを体系的に学びたい - 予備知識はほぼゼロ といった状況なので、まずはライブラリを触ってみておおまかな実装を抑えてみることにする。 Pthreadプログラミングというまさにジャストな本があったので読みはじめました。 今日は第一章で学んだことをアウトプットします。 1章 なぜマルチスレッドなのか? 性能を向上させる一つの方法が、マルチタスク処理。 プログラムを複数のタスクに分配する方法としてはプロセスとスレッドがある。 プロセスとスレッドの違いについては、「メモリ空間がどのように使われるか」を把握すればスッキリ理解できる。 プロセスの仮想アドレス空間では以下の4つの領域が使われる。  [スタック]  実行時の関数の自動変数が置かれるスタック領域  [テキスト] プログラム命令用の読み込み専用のテキスト領域  [データ]   グローバルデータ用読み書き領域  [ヒープ]   mallocシステムコールによる動的割り当てがなされるヒープメモリ領域 システムリソースとしては、SP・PC・その他といった分類ができる。  [SP]   スタックフレームへのポインタ(SP)  [PC]   実行中の命令を指すプログラムカウンタ  [etc]   システムが提供するリソース(オープンされたファイル、ソケット、ロック、シグナル) プロセスの複製は上記の登場人物全部をまるっと複製する一方で、スレッドの複製はSPとPCだけを複製する。 どちらも独自のPC, SPを持つので、プログラムのテキスト中の異なる位置の命令を実行できるという理屈。 以下の図からもわかるように 「スレッドはメモリ空間を共有する というのはものすごく重要なので抑えておく。 プロセスリソースの共有は、パフォーマンス上の主要な利点の一つ。 各スレッドが共有リソースにアクセスできることはスレッド間の通信を容易にする反面、 スレッド同士の干渉が起きる可能性があるためプログラミングを困難にする。 マルチスレッドのコンテキスト切り替えに伴うコスト@ id:naoya  より引用 並列化により高速化できるケース - ブロッキングI/Oが...

Learning critical section with pthread

I've just started to learn how to implement multi-threaded programming. It's very easy because we just need to call two APIs, such as - pthread_create : Create a new thread - pthread_join : Join with a terminated thread In the following program, global variable "gNum" is incremented by several threads. The number of threads are defined as "THREAD_NUM". The fourth argument "loop" means the number of incrementation per one thread. In the for-loop inside addFunc function, gNum is read and updated. If at least two thread try to read gNum at the same time, gNum variable won't be updated correctly. Finally, this program can't achieve that gNum is equal to ( THREAD_NUM * loop ).

フィボナッチ数列を動的計画法で高速化する頭の体操をしてみた

入社試験の季節。プログラムの実技試験で撃沈したのは今は昔。 とってもボロボロだったけどなんでか採用してもらえたのを思い出します。 入社してから苦労してますが、なんとかやっていけています。 てか、新卒採用でプログラム試験やる会社ってなかなかないだろうなぁ。。 いまはgithub採用なんてあるらしいね。選別しやすいんだろうなぁ。 とりあえず、入社時はオブジェクト指向なにそれおいしいの?っていう人でもプログラムに興味ある人なら普通に生きていればそれなりにプログラマとしてやっていけます。 個人的に思う会社に入るメリットは、先人たちが実装した秘伝のタレを覗けることです。 スーパープログラマの実装をトラッキングして、真似して、自分のものにすることが若手エンジニアに求められていることな気がする。 なんか初々しい気持ちになったので、 今日は入社試験に出ると面白いかもな問題を自分で設定してサクッと解いてみる。 ====================================================================== 問題: 「フィボナッチ数列を、なるべく早く、安定して動作するプログラムを実装せよ」 ====================================================================== アルゴリズム的な話:  プログラムの経験のある人だったら再帰で数行書いて終わりやんって人ばっかりかも。  数学屋さんなら一般項を導出してO(1)なプログラム書いちゃうかも。 高速化の話:  動的計画法打ち込めるかどうか程度しか差異がでないのでただの暗記問題になってしまうかも 安定して:  再帰呼び出しのスタックオーバーフローとか気にしてくれると嬉しいかも  (まぁFibonacciくらいじゃスタックオーバーフローしないけど)