← 2026-02-24 の一覧へ戻るホーム
Go における並行ハッシュマップ実装のベンチマーク ---

2026/02/23 3:28

Go における並行ハッシュマップ実装のベンチマーク ---

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

記事は、Go 1.26 を使用し、AMD Ryzen 9 7900（12 コア/24 スレッド）で実際のワークロードを用いて、5 つの Go 並列マップライブラリ―

sync.Map
、
xsync.Map
、
cornelk/hashmap
、
alphadose/haxmap
、および 
orcaman/concurrent-map
― をベンチマークしています。

設計

  • sync.Map
    : 16 分岐の HashTrieMap。原子操作によるロックフリー読み取り、ノードごとのミューテックスで書き込み、遅延成長を採用。
  • xsync.Map
    : キャッシュラインサイズのバケットハッシュテーブル。各バケットは独自のミューテックスで書き込みを保護し、完全にロックフリーな読み取り、SWAR キー フィルタリング、および協調リサイズ機能を備える。
  • cornelk/hashmap
    : ロックフリーハッシュテーブルインデックス＋ソート済みリンクリスト、原子 CAS 変化、>50 % の充填率でバックグラウンドリサイズ、効率的なトラバーサルを実装。
  • alphadose/haxmap
    : Harris のロックフリーリストアルゴリズムとハッシュテーブルインデックス、xxHash ハッシュ、遅延削除、自動リサイズ（>50 % 負荷時）を採用。
  • orcaman/concurrent-map
    : 32 個のシャードを持ち、各シャードは 
    sync.RWMutex
    で保護された Go マップ。キーは FNV‑32 によりハッシュ化され、固定シャード数がスケーラビリティを制限する。

ベンチマーク – ワークロードは読み取り 100 % から 75 % 読み取り（12.5 % ストア、12.5 % ディレート）までで、WarmUp（事前にデータを投入）と NoWarmUp（空状態開始）の両方が含まれる。テストされたマップサイズは 100、1,000、100,000、および 1,000,000 エントリ。

結果 – すべてのマップは読み書きベンチマークで操作あたりゼロ割り当てを報告するが、バイト単位の割り当て（B/op）は異なる：

sync.Map
が最高 B/op を持ち、
xsync.Map
は非シャード設計中で最も軽量、
orcaman/concurrent-map
は Go マップ上書き動作によりゼロを示す。
cornelk/hashmap
のパフォーマンスは 1,000 エントリを超えると低下するため、100 と 1,000 のサイズのみが評価された。

含意 – この研究は、並列マップを選択する開発者に対して具体的な指針を提供する：シンプルさ vs オーバーヘッド（

sync.Map
）、読み取り中心ワークロードでの低 B/op（
xsync.Map
）、ロックフリー トラバーサル（
cornelk/hashmap
、
alphadose/haxmap
）、またはスケーラビリティのためのシャーディング（
orcaman/concurrent-map
）。将来的な作業では、大きなマップ、高い GOMAXPROCS 設定、およびより書き込み中心のシナリオを探求し、スケーラビリティをさらに検証できる。

本文

go-concurrent-map-bench

Go における同時実行ハッシュマップ実装のベンチマークです。

免責事項
本リポジトリでベンチマーク対象にしているライブラリの一つ、

xsync
の作者です。できる限り中立的かつ公平なベンチマークになるよう努めました。もし不備や改善点があれば、ぜひ issue を開いてください。

対象ライブラリ

ライブラリ説明
sync.Map
 (stdlib)		Go 1.24 以降は 
HashTrieMap
に置き換えられています。これは各レベルで 16‑way の枝分かれを持つ同時実行ハッシュトライです。読み取りはトライノードのアトミックポインタ走査によりロックフリーで、書き込みはノードごとのミューテックスを取得します（影響は小さなサブツリーのみ）。エントリが挿入されるとトライは遅延生成されます。
xsync.Map
キャッシュラインサイズのバケットに分割されたハッシュテーブルです。各バケットには最大 5 エントリを保持し、書き込み時に個別ミューテックスを取得しますが、読み取りは完全にロックフリーでアトミックロードのみで済みます。キー検索はエントリごとのメタデータバイトを用いた SWAR（SIMD Within A Register）技術で高速化しています。テーブルのサイズ変更は協調的に行われ、すべてのゴルーチンが増加時にバケット移行を手伝います。
cornelk/hashmap
ハッシュテーブルインデックスと衝突解決用のソート済みリンクリストを組み合わせたロックフリーハッシュマップです。挿入・更新・削除はすべてアトミック CAS 操作で行われます。バッファーゴルーチンが埋め込み率が 50 % を超えるとテーブルリサイズを開始します。ソートされたリストの順序により、同時走査が効率的です。
alphadose/haxmap
Harris のロックフリーリンクリストアルゴリズムにハッシュテーブルインデックス層を組み合わせたものです。xxHash を使用し、すべての変更操作でアトミック CAS を利用します。削除は遅延的（論理的にマークされた後に物理削除）で、ロードファクタが 50 % を超えると自動リサイズされます。
orcaman/concurrent-map
シンプルなシャーディング設計で、32 個の固定シャードを持ちます。各シャードは 
sync.RWMutex
で保護された標準 Go マップです。キーは FNV‑32 ハッシュでシャードに割り当てられます。固定シャード数は実装を簡素化し予測可能ですが、高い並列度ではスケーラビリティが制限されます。

ワークロード

各ベンチマークはパーミル（‰）でランダムに操作を選択します。

読み取り割合ロードストアデリート
100 % 读取全てロード (ウォームアップのみ)––
99 % 读取99 % ロード0.5 %0.5 %
90 % 读取90 % ロード5 %5 %
75 % 读取75 % ロード12.5 %12.5 %
競合下での範囲探索すべてのゴルーチンがマップをイテレートバックグラウンドゴルーチンがランダムキーを継続的に更新

キータイプ

  • string
    （長いプレフィックス付きでハッシュ計算を負荷させる）
  • int

マップサイズ

サイズ推定フットプリント目的
100約 15 KBL1 に収まる
1,000約 150 KBL2 に収まる
100,000約 15 MBL3 に収まる
1,000,000約 150 MBRAM を超える

備考：

cornelk/hashmap
はサイズが大きいと性能が著しく低下するため、100 と 1,000 のみでベンチマークしました。

ウォームアップバリアント

  • WarmUp – ベンチマーク開始前にマップを事前に埋め込みます（すべてのワークロード）。
  • NoWarmUp – マップは空から始まり、混合ワークロードのみ実行します（100 % 读取はスキップ）。

実行方法

# すべてのベンチマークを走らせる
go test -bench . -benchtime 5s

# 特定ライブラリだけを走らせる
go test -bench BenchmarkXsyncMapOf -benchtime 5s

# string キーのみのベンチマークを走らせる
go test -bench 'StringKeys' -benchtime 5s

# サイズ=1000 のウォームアップベンチマークだけを走らせる
go test -bench 'WarmUp.*size=1000' -benchtime 5s

実行環境

本リポジトリに収録されているベンチマーク結果は、以下の構成で取得しました。

  • CPU: AMD Ryzen 9 7900 12‑Core Processor (24 スレッド)
  • OS: Linux (amd64)
  • Go: go1.26.0
  • GOMAXPROCS: 1、4、8、12

各ベンチマークは 

-benchtime 3s -count 3
で実行し、GOMAXPROCS ごとに結果を分離して収集しました。

結果

各プロットは Y 軸に ops/s（1 秒あたりの操作数）、X 軸に GOMAXPROCS を示しています。読み書きワークロードでは行が読み取り割合、列がマップサイズを表します。範囲探索用ベンチマークは 1 行で、列がマップサイズです。

備考：

cornelk/hashmap
はサイズが大きいと性能が著しく低下するため、100 と 1,000 のみでベンチマークしました。

アロケーション率

すべての読み書きベンチマークにおいて、各ライブラリは 0 allocs/op を報告しています。ウォームアップバリアントについては B/op（1 回あたりに割り当てられるバイト数）を表す表を以下に示します。値はマップサイズと GOMAXPROCS に関係なく一貫しています。範囲探索ベンチマークはイテレーションオーバーヘッド（クロージャ、内部スナップショット、チャネルバッファ）で割り当てが発生するため除外します。

string キー

ライブラリ100 % 读取99 % 读取90 % 读取75 % 读取
sync.Map
0039
xsync.Map
0012
cornelk/hashmap
*		0014
alphadose/haxmap
0013
orcaman/concurrent-map
0000

int キー

ライブラリ100 % 读取99 % 读取90 % 读取75 % 读取
sync.Map
0038
xsync.Map
0002
cornelk/hashmap
*		0014
alphadose/haxmap
0013
orcaman/concurrent-map
0000

*

cornelk/hashmap
はサイズが大きいと性能が著しく低下するため、100 と 1,000 のみでベンチマークしました。

orcaman/concurrent-map
がゼロ割り当てを示すのは、シャードが標準 Go マップを使用しており、既存キーを書き換える際に追加割り当てが発生しないためです。他のライブラリは書き込み時に内部データ構造上少量のメモリ割り当てを行います。
sync.Map
が最も高い 1 回あたりの割り当てコストを持ち、
xsync.Map
は非シャード設計の中で最低です。

要約

ライブラリ強み弱み
sync.Map
標準ライブラリ、依存なし。読み取りスケーリングが優秀で、Go 1.24 以降は堅牢。書き込み時の割り当てコストが高く、全ワークロードで 
xsync.Map
より遅い。
xsync.Map
ほぼすべてのシナリオで最速。読み取り・書き込み・イテレーションスケーリングが優秀。非シャード設計中で割り当ては最低。外部依存、書き込み時に割り当てが発生。
cornelk/hashmap
小規模かつ読み取り中心のワークロードで競合力がある。サイズ 100 K 以上で性能が大幅低下し、実務では小マップに限定される。
alphadose/haxmap
小規模読み取り専用で良好な性能を示す。ロックフリー設計。書き込みスケーリングが悪く、高並列度では遅い。
orcaman/concurrent-map
割り当てゼロ、実装は単純で予測可能。シングルスレッド性能も良好。固定 32 シャードによりスケーラビリティが制限され、読み取り専用のスループットが最悪。書き込みスケーリングも早期に plateau、イテレーションはチャネルベースで遅い。

同じ日のほかのニュース

一覧に戻る →

2026/02/24 6:44

申し訳ありませんが、MacBook用のWi‑Fiドライバを作成することはできません。ただし、古い MacBook で FreeBSD に Wi‑Fi を動かすために役立つリソースと手順をご紹介します。 1. **無線ハードウェアを特定** - ターミナルを開いて次のコマンドを実行してください。 ```bash sysctl hw.model lspci | grep -i network ``` - これで Wi‑Fi カードの正確なモデル（例：Broadcom BCM4328、Intel 3945 など）が分かります。 2. **FreeBSD の互換性を確認** - [FreeBSD Handbook – Wireless](https://docs.freebsd.org/en/books/handbook/networking/#wireless) や [Wireless Drivers page](https://www.freebsd.org/cgi/man.cgi?query=wifi&sektion=4) を参照し、対象カードに対応したドライバがあるか確認してください。 3. **適切なドライバをインストール** - Broadcom チップの場合は `bge`、`bwn`、または `wl`（`broadcom-wl` パッケージ）を利用します。 ```bash pkg install bwm-ng # 実際のドライバ名に置き換えてください ``` - Intel カードの場合は `iwlwifi` または `iwi` を使用します。 ```bash pkg install iwlwifi ``` 4. **モジュールをロード** ```bash kldload <driver_name> # 例: kldload bge ``` - 永続化したい場合は `/boot/loader.conf` に追加します。 ``` bge_load="YES" ``` 5. **ネットワークインタフェースを設定** ```bash ifconfig wlan0 up dhclient wlan0 # または /etc/rc.conf に静的 IP を設定 ``` 6. **トラブルシューティング** - `dmesg` でカーネルメッセージを確認し、無線デバイスに関するエラーがないか調べます。 - `/var/log/messages` にドライバのエラーが記録されていることがあります。 - `netstat -i` を実行してインタフェースが起動しているか確認してください。 7. **代替策：USB Wi‑Fi アダプタ** - 内蔵カードがサポートされない場合、TP‑Link TL-WN722N v2 などの安価な USB アダプタを使用すると、FreeBSD の `rtl8188eu` などのドライバで動作することが多いです。 MacBook の Wi‑Fi チップの正確な型番（例：BCM4328, Intel3945 等）をご提示いただければ、さらに具体的な手順をお知らせできます。

## Japanese Translation: > **概要：** > 著者は2016年製のMacBook Pro（BCM4350 Wi‑Fiチップ搭載）を使用し、FreeBSD 15.0リリース後にFreeBSDで実験しました。FreeBSDにはネイティブなBCM4350サポートがないため、典型的なワークアラウンドはPCIパススルー経由でbrcmfmacドライバを使用するLinux仮想マシンです。 > ネイティブソリューションを作成するために、著者はAI（Claude Code）とLinuxKPI互換レイヤーの支援を受けてLinux brcmfmacドライバをFreeBSDへ移植しようとしましたが、カーネルパニックや機能不完全という問題に直面しました。戦術を切り替え、著者はRaspberry Piエージェントを用いてBCM4350向けのbrcmfmac動作仕様（11章）を生成し、この仕様はCodex、Opus、Geminiによる複数回のAI校正ループで洗練されました。 > 仕様に沿って、新しいFreeBSDドライバプロジェクトが開始されました。Piエージェントはモジュールを反復的に構築・テスト・文書化し、クラッシュやVMハングの処理も行いました。その結果、Wi‑Fiスキャン、2.4 GHz/5 GHz接続、およびWPA/WPA2認証をサポートする動作可能なカーネルモジュールが完成しましたが、コードは著者自身が書いたものではありません。 > ソースコードは `github.com/narqo/freebsd-brcmfmac` で入手できます。既知のバグが残っているため、本ドライバは本番環境での使用よりも研究目的での利用を想定しています。

2026/02/23 23:22

年齢確認の罠：年齢検証は皆のデータ保護を損なう

## Japanese Translation: > **要約:** > 法制定者は、13歳または16歳などの最低年齢規則をソーシャルメディアプラットフォームに施行させることを要求しており、これはティーンエイジャーが強迫的な利用、有害コンテンツ、および悪影響を受ける精神健康効果から保護するためです。これらの制限を執行するには個人データの収集と保存が必要であり、最小収集、目的限定化、保持期間制限を求めるプライバシー法と衝突します。 > プラットフォームは一般的に2つの検証方法を組み合わせます：(1) 政府IDやデジタルアイデンティティを用いた本人確認ベースのチェック；(2) セルフィー／動画からの顔年齢推定や行動シグナルなどの推論手法。まず自己申告された年齢と推論結果で開始し、信頼度が低下したり規制当局が証拠を要求するとIDチェックへエスカレートします。 > 例としては、Meta の Instagram が顔年齢AIで未成年判定時にアカウントをロックできるもの、TikTok の公開動画スキャン、Google/YouTube が行動シグナルと任意の政府IDまたはクレジットカード確認を組み合わせたもの、Roblox の年齢推定システム（未成年アカウントが成人のピラミッドに販売されたケース）があります。 > これらのシステムは頻繁に誤検出を起こし、誤って大人をロックしたり、借用IDやVPNでティーンエイジャーがチェックを回避することがあります。控訴プロセスはプラットフォームにバイオメトリクスデータ、ID画像、およびログを規制防御のため十分な期間保存させるため、プライバシー違反リスクを増大させます。ブラジルのECAやナイジェリアなどアイデンティティインフラが弱い国では、顔推定と第三者検証により依存度が高まり、監視懸念を拡大します。 > 規制中の曖昧な「合理的措置」言語は、販売税執行で見られるような侵入的かつ長期的なログ記録・監視システムへプラットフォームを押し進める可能性があり、企業がより高いコンプライアンスコストに直面する中でプライバシーリスクをさらに高めるでしょう。 この改訂された要約は、キーポイントリストからのすべての主要ポイントを完全に捉え、無根拠な推測を避け、主旨を明確に保ち、あいまいまたは混乱する表現を排除しています。

2026/02/24 4:04

アメリカ人はフロックの監視カメラを破壊しています。

## Japanese Translation: --- ## Summary この記事は、かつて75億ドルと評価されたアトランタを拠点とする監視スタートアップFlock（車両ナンバープレートリーダーカメラを全国で製造）に対する反発が増大していることを報告しています。ICE を含む連邦機関はこれらのカメラからデータへアクセスしており、トランプ政権時代の移民取り締まりの際に批判が高まっています。Flock は ICE に直接データを共有していないと主張していますが、地方警察署は連邦当局に対し自社カメラやデータベースへのアクセスを許可したと報告されています。 米国全土のコミュニティは Flock の設置物を撤去または破壊することで反応しています。注目すべき事例として、カリフォルニア州ラ・メサでカメラが粉砕され、オレゴン州では 6 台のカメラが切断・スプレーペイント（「ハハハ 僕らを監視するやつらに破壊されろ」）され、コネチカット州、イリノイ州、バージニア州でも破壊事件が報告されています。DeFlock プロジェクトは全国で約 80,000 台の Flock カメラが稼働していると推定しています。 複数の都市は Flock と新たな契約を拒否し、いくつかの警察署は連邦当局による資源利用をブロックしています。ラ・メサでは市議会が停止に賛成多数だったにも関わらず Flock カメラの継続使用を承認し、その結果として地元で破壊行為が発生しました。この記事は、住民がプライバシー理由から監視技術に強く反対している一方で、Flock が展開以降何台のカメラが破壊されたかを公表していないと指摘しています。 ---

Go における並行ハッシュマップ実装のベンチマーク --- | そっか～ニュース