Index / Reload

Latest Comments 50

* soda 2017-01-30 13:12:09 [/~nminoru/postgresql/pg-coding-style.html, BBS]

2箇所typoがありました。
誤 STATIC_IF_INLNIE
正 STATIC_IF_INLINE

6.2 SQ に Send Work Request を投入する

次に送信側が Send WR を SQ に投入する。 これには ibv_post_send() を使う。 ibv_post_send() も 1 回の呼び出しで、を数珠繋ぎにした複数の Receive WR を登録できるが、この例では 1 個だけを登録している。

ーーーーーーー
"複数の Receive WR”じゃなくて、”複数の Send WR" ではないでしょうか?

* 管理人 2016-05-08 14:31:08 [/~nminoru/teiid/teiid-introduction.html, BBS]

ご指摘ありがとうございます。確かに BEA は関係ありませんでいsた。

* 管理者 2016-05-06 09:41:09 [/~nminoru/memo/barcode/index.html, BBS]

御指摘ありがとうございます。
近日中に修正します。

* 名無しさん 2016-05-03 10:41:10 [/~nminoru/teiid/teiid-introduction.html, BBS]

「2. Teiid とは」に、「BEA 社の JBoss Enterprise Application Server (EAP) 上」とありますが、BEAではなくJBoss Inc.ですよね。

* まえ 2016-04-26 08:00:49 [/~nminoru/memo/barcode/index.html, BBS]

いつも重宝させて頂いております。恐れ入りますが、ここ2週間くらい、うまく動作していないようです。
(結果が返ってきません)
お手数ですが、ご確認頂ければ幸甚です。

初めまして、情報処理の勉強をしております。

メモリ保護について、学ばせていただきました。

ありがとうございます!

* nminoru 2015-06-01 01:08:36 [/~nminoru/diary/2011/12.html#2011-12-12, BBS]

ご指摘ありがとうございます。
日記の内容を修正しました。

* 名無しさん 2015-04-17 02:26:57 [/~nminoru/diary/2011/12.html#2011-12-12, BBS]

例の
if (-1 >= v && v >= 200)

if (v >= -1 && v >= 200)
ですよね?

googleで「sigaction linux SEGV_MAPERR」の検索をしてずいぶん前の記事をみつけたのですが、あまりに面白いのでここまで読んできて上記間違いを見つけました。

linux mmap SEGV

* hir0 2014-09-21 07:49:08 [/~nminoru/programming/bitcount.html, BBS]

下位ビットの影響を受けてしまうので、消してあげないといけないですね。

int
nlz(int x)
{
int c = 0;
if (x == 0) return 32;
if (x & 0xffff0000) { x &= 0xffff0000; c |= 0x10; }
if (x & 0xff00ff00) { x &= 0xff00ff00; c |= 0x08; }
if (x & 0xf0f0f0f0) { x &= 0xf0f0f0f0; c |= 0x04; }
if (x & 0xcccccccc) { x &= 0xcccccccc; c |= 0x02; }
if (x & 0xaaaaaaaa) { c |= 0x01; }
return c ^ 31;
}

* くに 2013-05-08 17:42:14 [/~nminoru/programming/bitcount.html, BBS]

さささんのnlz5は正しく動かないようです。
入力値bを2のべき乗に切り下げて(ハッカーのたのしみで言うところのflip2)
最後のreturnを下記のように変更すれば意図通り動くと思います。

return 31-((b&0xFFFF0000)?c|0x10:c);

はじめまして。とても勉強になります。
有難うございました!

* @TO 2012-10-20 22:11:28 [/~nminoru/diary/2012/09.html#2012-09-17, BBS]

音楽が多い結婚式でした。

* cola 2012-10-10 22:04:07 [/~nminoru/diary/2012/09.html#2012-09-17, BBS]

非常に良い結婚式だったね!

さささんコメントありがとうございます。
Core i5-2400 での測定では POPCNT や浮動小数点のトリックを使わないやり方では、さささんのアルゴリズムが一番高速でした。
記事を書き直しました。

* ささ 2012-08-31 23:28:02 [/~nminoru/programming/bitcount.html, BBS]

中村さん初めまして、色々参考にさせてもらってます。
numofbits5 を見て思いついたんですけど
int int nlz5(int b)
{
if(b==0)return 32;
int c = (b&0xAAAAAAAA)?0x01:0;
if(b&0xCCCCCCCC)c|=0x02;
if(b&0xF0F0F0F0)c|=0x04;
if(b&0xFF00FF00)c|=0x08;
return (b&0xFFFF0000)?c|0x10:c;
}
とかしてみるとちょっと早くなるかなとか
numofbits5のマスクそのまま使うと左から何番目とかも
できたりとかいかがでしょうか

* 名無しさん 2012-04-13 11:22:40 [/~nminoru/java/class_unloading.html, BBS]

非常にわかりやすく、理解できました。ありがとうございました!

>>NTZ は比較的簡単である。 x&(-x) を行うと左側から最初に 1 が立っているアドレスのみを残して
>「右側」では?
左側は私のミスです。ページを修正しておきます。

>NTZ は比較的簡単である。 x&(-x) を行うと左側から最初に 1 が立っているアドレスのみを残して
「右側」では?

* hiro 2011-05-07 11:49:08 [/~nminoru/diary/2008/02.html#2008-02-06, BBS]

proxy_arp の設定や ip alias を用いてNWを構築しているなかで妙な現象が現れて困惑していたところ、こちらのページにたどり着き、一発で解決しました!

助かりました〜

* nminoru 2011-03-18 22:58:58 [/~nminoru/diary/2002/10.html#2002-10-30, BBS]

> @koieさん
確かに例題のプログラムだとmemory orderingは関係ないですね。
実際に問題を起こしたコードはアセンブラレベルで確認して確かにmemory orderingが原因だった記憶があるのですが、簡略化したサンプルを作るうちに変わってしまったのだと思います。
ただどういう問題だったかすでに記憶があやふやで思い出せません。

* @koie 2011-03-18 20:59:12 [/~nminoru/diary/2002/10.html#2002-10-30, BBS]

volatile指定が必要なだけ?

* @koie 2011-03-18 20:34:37 [/~nminoru/diary/2002/10.html#2002-10-30, BBS]

SEGVは同期シグナルなのでメモリオーダーの問題ではないような気がします。もしそうなら
*p = a;
pause();
b = *p;
assert (a == b);
さえもあやしいということになってしまいませんか?

* シンガポール在住 2011-02-25 01:00:16 [/~nminoru/diary/2008/02.html#2008-02-06, BBS]

この情報、本当に助かりました!

はい、KENWOOD や SANYO のボイスレコーダーはかなり私の条件に近いです。
ただ soda さんもおっしゃるように登録できる mp3 ファイルやフォルダ数、プレイリストの制限が厳しいんですよね。ICレコーダーは音楽を聞くのがメインではないので仕方ない制限ですが。

あ、あと(旧機種ですが)リスト機能で選曲中は再生が止まるっていうのもちょっと不便でした。忘れてました。

条件1〜5のうち、3だけは満たしませんし、商品カテゴリもDAPじゃないんですが、ICR-PS401RM のようなICレコーダという選択肢もあるかと思います。個人的に条件5(というかエネループが使えて、電池切れになったらすぐ予備電池と交換したい)が必須なので、これの旧製品を使ってます。欠点は M3U ファイルの登録曲数の限界が99曲×5つのM3Uファイルと、少ないところでしょうか。

> uzakadeuさん
[2]のコメントでスタックと呼んだのは First-In First-Out の配列を想定していました。カーネルはスレッドスタックのサイズに制限があるので再帰関数呼び出しを使うのは難しいと思われます。

このスタックに red-black tree の各段の操作中のノードのポインタを保持しておくつもりでした。しかしよく考えると「rb_right と rb_left の両方が NULL なら free して親ノードに戻り、親側から自分を削除する」という処理を繰り返せばスタックも不要ですね。

* uzakadeu 2010-11-21 07:22:27 [/~nminoru/diary/2010/11.html#2010-11-17, BBS]

言われてみれば、巡回する方がずっとシンプルですね。失礼しました。

「スタック〜」とは再帰を使うということでしょうか?
確認してませんが、解放するだけならループでいけそうに思えます。

> uzakadeuさん
はい。struct mytype 構造体に struct list_head を入れて「red-black tree のノード間の双方向リンク」を作っておいて、一括削除はそちらを使うという方法に逃げました。これだと計算量が O(N) のオーダーですし。

ただ最終的には black-red tree を巡回してリーフノードから削除するルーチンにしようと思っています。これも O(N) オーダーに収まりますし、余分なメモリ消費が押さえられますから。ツリーの深さ分のスタックが必要になりますが。

* uzakadeu 2010-11-20 14:52:41 [/~nminoru/diary/2010/11.html#2010-11-17, BBS]

各ノードをツリー以外の方法(配列,リスト,etc)で“も”管理しておいて、そちらを使って解放するのはどうですか?

* 名無しさん 2010-06-27 21:03:29 [/~nminoru/diary/2010/01.html#2010-01-29, BBS]

超亀レスだけどたまたま見かけたので一言。
RockBox入れなよ。公式ファームとは桁違いに性能が上がるから。
たとえiHPが壊れても他の対応機種にライブラリごと移行できるし。

* ふるかわ 2010-06-12 01:14:47 [/~nminoru/diary/2010/06.html#2010-06-07, BBS]

ありがとうございます。
> なんらかの方法でパイプラインを巻き戻しているようだ。
大半のプロセッサは分岐予測と同様に、ロードも予測ミスした命令から再フェッチしているはずです。
Pentium4はリオーダバッファに細工がしてありそこから再実行すべき命令が供給されていたと思うのですが(Selective Replay)、P4とP6系ではそのへんの構造がまったく異なりますから、不採用かもしれません。
マイクロアーキテクチャ的にもP6ではP4での時ほどの効果は出ないはずですし。

> ふるかわさん
情報ありがとうございます。
Core 系はアドレスが決まったものはロードもストアも投機的に issue し、、後で memory ordering buffer が調停するようです。
実際テストプログラムを書いても 48 ロード & 32 ストアまできっちり out-of-order 実行されています。

* ふるかわ 2010-06-10 15:19:26 [/~nminoru/diary/2010/06.html#2010-06-07, BBS]

選択的再実行そのものは原理的にはメモリデータフローの予測ミスにも使えるはずですが、L1-L2の予測ミスだけであれば、固定サイクルだけバブルを挿入するというシンプルな実装もありえます。
(そうするとメモリデーターフローのような非同期的なイベントは扱えません)

* ふるかわ 2010-06-10 15:14:15 [/~nminoru/diary/2010/06.html#2010-06-07, BBS]

Pentium4にはSelective Replayという、ロードレイテンシを予測ミスした場合、依存する命令だけを再実行する機構がついていました。(常に1次キャッシュにヒットすると予測するんだったかな)
この例のようにメモリデータフロー依存がある場合についての動作はわかりません。
Core iがどうなっているのかもわかりません。

icysnowさん情報ありがとうございます。

製品版よりもフリーの方が対応状況が良いようですね。
製品版だとサポート対応OSでは全てテストが必要ですし、Microsoft の end of life が近づいているものは切り捨てられるのでしょうね。

* icysnow 2010-05-28 22:44:41 [/~nminoru/diary/2010/05.html#2010-05-22, BBS]

はじめまして。技術系の記事のファンです。
現在自分で使用しているものですが、ウイルス検出率と動作の軽さに定評があるAvira AntiVir Personal(フリー)もドキュメントを確認したところシステム要件に「Windows 2000 SP4 およびロールアップ修正プログラム 1」とありましたので利用可能なようです。今年になって日本語版も提供されるようになりました。

Avira AntiVir
http://www.free-av.com/

* AH 2010-05-24 20:04:30 [/~nminoru/diary/2010/04.html#2010-04-14, BBS]

C++のメンバ変数へのポインタのnullについては
非零の内部表現を持つコンパイラ実装が多いです

* のり 2010-03-19 13:30:26 [/~nminoru/java/class_unloading.html, BBS]

クラスローダーについて勉強になりました。

いえ iHP-120 が壊れるまでは使い続ける覚悟です。
その頃には市場に Apple と Sony しか残っていないかもしれませんが…

* 名無しの権兵衛 2010-02-02 18:58:02 [/~nminoru/diary/2010/01.html#2010-01-29, BBS]

ipod買いなよ。

* 通りすがり 2010-01-07 12:04:16 [/~nminoru/diary/2010/01.html#2010-01-04, BBS]

ご存知かも知れませんが、座席指定のとれなかった区間でも、指定席券さえあれば、車掌にその旨を告げて指定席車両の空席に座る事はできますよ。ただ、停車駅毎に退かなくちゃならないかハラハラしますが・・・

* いし 2009-12-22 21:53:12 [/~nminoru/diary/2009/12.html#2009-12-20, BBS]

横浜のヨドバシカメラにもそこそこ書籍が置いてあります。
コンピュータ、家電関係に限定されますが…。
少ないながらポイントも付きます。

> 通りすがりさん
ご存知の通り連続体仮説は証明も反証もできないことが証明された命題なので、連続体仮説を証明してしまった夢の中の説明は誤りです。

夢から覚めた後に思い直してみると、
- B列とP列が同じ濃度なのは間違いないです。
- P列がとりえる表現の集合は自然数のべき集合になっています。

問題はB列の方です。
B列は無限長の2進数なので、これである特定の無理数を表現することは可能です。
しかしB列の0/1を入れ換えて行くことで、実数全体を表現できるというのは正しくないようです。
そのためP列とB列が同じ濃度であることを証明しても意味がない。と私は理解しています。

* 通りすがり 2009-11-13 12:22:15 [/~nminoru/diary/2009/11.html#2009-11-04, BBS]

P列は2進数表現である時点で有理数でしかなく、そのP列と1:1で対応づけられると言う事は、すなわちB列とP列は同じ濃度であって、B列では実数を表現でき無いことになるが、夢の中なので夢が膨らんでたっ!という理解で合っているでしょうか?

お久しぶり。ご無沙汰しております。

最近は全然グルメじゃありませんよ。
会社と自宅の間をぐるぐる周るだけの日々が続いています。

機会があればまたお会いしましょう(^_^;

* cola 2009-10-15 22:02:21 [/~nminoru/diary/2009/10.html#2009-10-12, BBS]

お久しぶりです,colaです。

相変わらずグルメですな。

こっちに帰ったら,連絡してね^^

* soda 2009-10-01 12:40:35 [/~nminoru/diary/2009/09.html#2009-09-24, BBS]

ありゃ、Linuxはまだカーネルスタックにレッドゾーンを設けることができなかったですか。
それは辛い。
ただ、カーネルスタックに置いて良いのはせいぜい NAME_MAXぐらいまでのサイズで、
PATH_MAXくらいのサイズだと、もうスタックは避けた方が良い(たとえば、多重割り込みが
かかる場合の割り込みスタックで使うと、明らかにまずい)というのが、昔風の感覚です。
スタックサイズは昔と変わらないので、このあたりの感覚も、Linuxでも昔と変わってない気が
します。
(あと、ふつうのUNIXだとスタックはswap out時には主記憶上にないので、利用に
注意が必要ですし...)

* nminoru 2009-09-30 23:27:57 [/~nminoru/diary/2009/09.html#2009-09-24, BBS]

sodaさん、情報ありがとうございます。
Linuxカーネルのスタックサイズに制限があるのは知っていたのですが想定よりもサイズが小さかったようです。
オーバーフローしても警告なしなのはちょっと辛いです。

Powered by くっつき BBS