アルミホイールや…車高調…と夢がひろがりんぐ。
…だめだ、どんどんオカシクナッテルヨwwww
という状態の納車まであと91日(暫定)の今日この頃。
正式な予定日はGW明けた頃に判明するらしいので、少しでも前倒しされていることに期待したいです…
※納車予定日は未定。7末頃との話なので、7/31と仮定して算出。
アルミホイールや…車高調…と夢がひろがりんぐ。
…だめだ、どんどんオカシクナッテルヨwwww
という状態の納車まであと91日(暫定)の今日この頃。
正式な予定日はGW明けた頃に判明するらしいので、少しでも前倒しされていることに期待したいです…
※納車予定日は未定。7末頃との話なので、7/31と仮定して算出。
日星工業から、CR-Zの電球タイプが判明!
比較的お手軽で、お財布にもやさしい(?)電球の交換から考えてみよ~♪
いやぁ、CR-Zの取扱説明書にも記載がないので、助かりますね。
ルームランプはLED!LED! 白い光が大好きdeth!
…なんだ、この逝かれたテンションは。
今や、こんな雑誌もあるんですね。つい買ってしまいそうになったwww
…べ、べつに痛車にはしないんだからねっ!
…やばいっす。このワクテカ度w
はやく、7月になって、CR-Zこないかなぁ…w
と、テンションは上がりまくりの今日この頃ですが、
冷静になって考えてみると、あと15週間…
あと105日と考えると、凹みます…。(´・ω・`)ショボーン
Blu-rayドライブを買ってみました。出た当初は10万円近かった書き込みドライブも、今では2万円台と随分手頃になりました。

ちなみに私のtx2005/CTでは、読み込み時もバスパワーで動作せず、ACアダプターが必要なようでした。

地デジレコーダーからダビングしてきたのも見られるようになりました。

いいよね、CR-Z…

と、契約してきました!

ローンの審査は通るのかっ!?

見積もりも取ってもらって、あとは自分に支払い能力があるのか、
冷静に考えたいと思います!(初めてなので。)
VC++ CriticalSectionの速度をみると、ループ速度が14倍遅くなる!?
というのを見かけたので、これから実装してみる処理を見立ててサンプリングしてみることにしました。
やりたいことは単純で、1つのメッセージキューがあり、そのキューは複数のスレッドがアクセスします。
ロックして行う作業はメッセージを入れるか、取り出すかの単純なものです。
というわけで、以下のようなコードを書いてみました。
#include <stdio.h>
#include <tchar.h>
#include <list>
#include <iostream>
#include <windows.h>
std::list<int> listValues;
CRITICAL_SECTION lock;
__int64 intCounterFreq;
void push(void)
{
listValues.push_back(0);
}
int pop(void)
{
const int value = listValues.front();
listValues.pop_front();
return value;
}
void nolock(void)
{
__int64 intStartCounter;
__int64 intEndCounter;
::QueryPerformanceCounter(reinterpret_cast<LARGE_INTEGER *>(&intStartCounter));
std::cout << "start no locking mode at " << intStartCounter << "." << std::endl;
for (int i = 0; i < 100000; i++)
{
push();
pop();
}
::QueryPerformanceCounter(reinterpret_cast<LARGE_INTEGER *>(&intEndCounter));
std::cout << "end no locking mode at " << intEndCounter << " offset " << (intEndCounter - intStartCounter) << "." << std::endl;
}
void sectionLock(void)
{
__int64 intStartCounter;
__int64 intEndCounter;
::QueryPerformanceCounter(reinterpret_cast<LARGE_INTEGER *>(&intStartCounter));
std::cout << "start section locking mode at " << intStartCounter << "." << std::endl;
for (int i = 0; i < 100000; i++)
{
::EnterCriticalSection(&lock);
push();
::LeaveCriticalSection(&lock);
::EnterCriticalSection(&lock);
pop();
::LeaveCriticalSection(&lock);
}
::QueryPerformanceCounter(reinterpret_cast<LARGE_INTEGER *>(&intEndCounter));
std::cout << "end section locking mode at " << intEndCounter << " offset " << (intEndCounter - intStartCounter) << "." << std::endl;
}
int _tmain(int argc, _TCHAR * argv[])
{
::InitializeCriticalSection(&lock);
::SetThreadAffinityMask(::GetCurrentThread(), 0x1);
::QueryPerformanceFrequency(reinterpret_cast<LARGE_INTEGER *>(&intCounterFreq));
// test functions
nolock();
sectionLock();
::DeleteCriticalSection(&lock);
return 0;
}
これを以下の環境で測定!
Model : HP Mini 2140
OS : Windows 7 Enterprise 32bit
CPU : Atom N270 1.6GHz
MEM : 2GB
環境は…Visual Studio 2010 RC(笑
コンパイラの最適化は有りで、Visual C++のデフォルト最適化のままです。
というのも、実際には最適化なしでソフトウェアをリリースするなんてことはありえませんし…。
結果は…
ロックなしが65873サンプル、ロック有りが91059サンプル(38%増加)
これを6回測定し、平均が21%遅くなるというものでした。
…と実際に処理を交えてみると、気になるほど極端には遅くならないようにみえます。
ロック処理中に何をするのか、にもよってきますので、
排他制御を適用される際には、疑似ロジックを用意して測定してみた方がよろしいようです。