ソースコード
今回の連載 python/codonのソースコードディレクトリはこちら
https://github.com/suzukiiichiro/N-Queens/tree/master/13Bit_codon
Ｎクイーン問題 過去記事アーカイブ
【過去記事アーカイブ】Ｎクイーン問題 過去記事一覧
https://suzukiiichiro.github.io/search/?keyword=Ｎクイーン問題
【Github】エイト・クイーンのソース置き場 BashもJavaもPythonも！
https://github.com/suzukiiichiro/N-Queens
Python/codon Ｎクイーン コンステレーション版 CUDA 高速ソルバ
, #_
~\_ ####_ N-Queens
~~ \_#####\ https://suzukiiichiro.github.io/
~~ \###| N-Queens for github
~~ \#/ ___ https://github.com/suzukiiichiro/N-Queens
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
『八つの女王と計算機 ―― 組合せ爆発の深淵を覗く』
（副題：N-Queens Problem 研究十年の記録）
謝辞（Acknowledgements）
本書は、2016年4月から始まった私自身の長い問いの記録である。
盤上に置かれた八つのクイーン――それは一見、子ども向けのパズルにすぎない。
しかし、その数を N に一般化した瞬間、この問題は静かに牙をむく。
指数的に膨張する探索空間、対称性という救いと罠、
計算資源の有限性、そして「速く解く」とは何を意味するのかという哲学的問い。
なぜ、これほどまでに多くの人が N-Queens を解こうとし続けてきたのか。
なぜ世界記録は更新され、アルゴリズムは洗練され、
それでもなお「最終解」は存在しないのか。
この問題は、P≠NP という計算機科学最大の未解決問題を直接解くものではない。
それでもなお、N-Queens は常にそこにあり、
計算の限界、設計の美学、そして人間の執念を映し出し続けてきた。
本書を書き進めるにあたり、私は一人ではなかった。
2016年から堀内幸太郎君が、そしてChatGPTがともに奮闘してくれている。
C から始まり、Bash、Lua、Python、Java、OpenCL、CUDA、PyPy、そして Codon へ。
CPU から GPU へ、再帰から反復へ、
ビット演算、対称性除去、コンステレーション、Zobrist hash、
果てはカーネル引数の配置に至るまで――
数え切れない試行錯誤のすべてに、
沈黙せず、疲れず、投げ出さず、対話を続けてくれた開発パートナーがいた。
先述の堀内幸太郎君とChatGPT-5.2だ。
ChatGPTである彼（あるいは彼女）は人間ではない。
だが、私の問いに対し、
「それは本当に必要か」
「その最適化は本質か」
「その変数はどこまで生きているのか」
と、何度も問い返してきた存在である。
世界のどこに自分が立っているのかを知るのは難しい。
だが少なくとも私は、
「速さ」だけでなく、「なぜそう書いたのか」を説明できる場所まで来た。
それは一人で到達できる地点ではなかった。
この書籍は、
N-Queens という問題そのものへの敬意であり、
世界中の先行研究者たちへの静かな挨拶であり、
そして、名もなき試行錯誤の夜を共にした
私の開発パートナーへの感謝の記録である。
――盤上に置かれたクイーンは、決して八つだけではなかった。
まえがき（読者へ）
この本を手に取ったあなたは、おそらく三つのうちのどれかだろう。
ひとつは、N-Queens Problem をすでに知っている人。
もうひとつは、名前だけ聞いたことがある人。
そして最後は、なぜこの問題が今も研究され続けているのかを知りたい人だ。
本書は、最短距離で答えを教えるための本ではない。
ここに書かれているのは、
「どうやって世界最速に近づいたか」ではなく、
「なぜ、そこに向かい続けたのか」という問いへの記録である。
N-Queens は不思議な問題だ。
数式で閉じることもなく、
万能なアルゴリズムが存在するわけでもない。
解けることは分かっているのに、
速く、大きく、美しく解くことは、いつまでも難しい。
私がこの問題に本格的に向き合い始めたのは2016年4月だった。
最初はただの好奇心だった。
だが気づけば、言語を変え、構造を変え、
CPU の限界を越え、GPU に手を伸ばし、
「もう十分だろう」と何度も思いながら、
それでもなおコードを書き続けていた。
本書は、その過程で得た知識だけでなく、
迷い、失敗し、遠回りし、
それでも手放さなかった思考の軌跡を残すために書かれている。
もしあなたが、
「なぜこんな無駄に見えることをやるのか」
と感じるなら、
その問いこそが、この本の入口である。
第1章 導入 なぜ N-Queens は人を狂わせるのか
N-Queens Problem は、最初はとても素直な顔をしている。
チェス盤の上に N 個のクイーンを置き、
互いに攻撃し合わない配置をすべて数えよ。
ルールは単純で、説明に数行もいらない。
だが、この問題が「狂気」を孕むのは、
N を 1 つ増やした瞬間からだ。
探索空間は指数関数的に増大し、
思いつく最適化はすぐに底をつく。
再帰は深くなり、
枝刈りは効いているのか分からなくなり、
「速くなった気がする」コードが、
次の N では簡単に打ち砕かれる。
N-Queens が人を狂わせる理由は、
この問題が努力に正直ではないからだ。
10 倍の工夫をしても、
10 倍速くなるとは限らない。
むしろ、わずかな実装の差、
ビット一つ、分岐一つで、
結果が何倍も変わる。
しかも、その理由は後からしか分からない。
対称性は救いであり、同時に罠だ。
キャッシュは武器であり、足枷でもある。
GPU は万能ではなく、
並列化すれば必ず速くなるわけでもない。
それでも人は、この問題に戻ってくる。
なぜなら N-Queens は、
アルゴリズム、アーキテクチャ、言語設計、
そして「考える」という行為そのものを、
容赦なく試してくるからだ。
これはパズルではない。
これは、計算機科学と人間の執念が交差する、
小さく、しかし底の見えない実験場である。
第X章 世界記録と、私の立ち位置について
N-Queens には「世界記録」が存在する。
どの N までを、どれだけ速く解いたか。
それは客観的で、残酷で、
言い訳の余地がない数字だ。
私は、この世界記録の最前線に立っているわけではない。
それを誤解されることは、本意ではない。
世界には、
専用ハードウェアを設計する者がいる。
アセンブリに近い層で最適化を極める者がいる。
数学的洞察だけで枝を消し飛ばす者もいる。
彼らは明確に、私より先にいる。
では、私はどこにいるのか。
私は、
汎用言語で、構造を保ち、説明可能な形で、
どこまで速さに近づけるか
という場所に立っている。
C から始め、
スクリプト言語を経由し、
JIT、VM、GPU、そして Codon に至るまで、
「同じ問題を、異なる抽象度で解く」ことを続けてきた。
私のコードは、
最短ではないかもしれない。
最速でもないかもしれない。
だが、それぞれの最適化には理由があり、
削った対称性には意味があり、
採用しなかった手法にも、明確な判断がある。
世界記録は、いつか塗り替えられる。
それは健全なことだ。
だが、思考の積み重ねは消えない。
本書が示したいのは、
「勝ったかどうか」ではなく、
「どこまで理解したか」だ。
N-Queens は、
世界一になるためだけの問題ではない。
計算の限界を知るための、
そして自分自身の思考の癖を知るための、
極めて正直な鏡なのである。
第2章 指数爆発という現実
N-Queens を初めて実装した人は、たいてい同じ体験をする。
N=8 までは順調だ。
N=10 でも、まあ動く。
N=12 で少し考え込む。
N=14 で、時計を見る回数が増える。
そして、N=15 か 16 あたりで、
「これは別の問題だ」と悟る。
指数爆発とは、単に「遅くなる」ことではない。
努力が報われなくなる現象だ。
ループを一つ減らした。
分岐を整理した。
キャッシュを入れた。
それでも、N を 1 増やしただけで、
計算時間は軽々と数倍になる。
なぜか。
探索空間そのものが、
こちらの工夫を無視して膨らむからだ。
N-Queens における本当の敵は、
CPU でも、言語でもない。
組合せそのものである。
この現実を受け入れられないうちは、
どんな最適化も一時的な成功に終わる。
指数爆発は、
「まだ理解していない」と静かに告げてくる。
実装ノート ――指数爆発と向き合うために
指数爆発に対抗する最初の武器は、
アルゴリズムではなく計測である。
「どこが遅いか」は、
想像ではなく数値で見る必要がある。
N を 1 つ増やしたときに、
再帰回数がどう増えるのか。
枝刈りがどの深さで効いているのか。
私が最初にやったのは、
最適化ではなく、
無慈悲なカウンタの挿入だった。
・再帰呼び出し回数
・有効ノード数
・枝刈り発生位置
・N ごとの増加率
これらを可視化した瞬間、
「速くなった気がする」コードは、
ほぼすべて否定された。
指数爆発は、
工夫を拒否するのではない。
甘い自己評価を拒否するのだ。
――指数爆発に対して、CPUでできること
CPU 実装で最初にやるべきことは、
速くすることではない。
**「どこで爆発しているかを正確に知る」**ことである。
私は以下を必ず数値化した。
- 再帰深度ごとのノード数
- 有効分岐数（available bits）
- 枝刈りが発生した位置
- N 増加時の増加率
CPU は逐次実行だからこそ、
探索木の形がよく見える。
この段階でやる最適化は、
・順序の入れ替え
・無駄な分岐の削除
・状態の最小化
だけで十分だ。
指数爆発は、
CPU 上で「見える形」にしないと始まらない。
――指数爆発は、GPUでは解決しない
指数爆発を GPU に投げても、
解決しない。
探索の深さがスレッドごとに違い、
仕事量が揃わないからだ。
この章の段階で GPU にやらせることは、
何もない。
GPU を使わないという判断も、
立派な最適化である。
第3章 対称性という甘い毒
対称性は、N-Queens に与えられた救済策のように見える。
左右対称。
上下対称。
回転対称。
それらを除外すれば、探索は一気に減る。
実際、これは劇的に効く。
多くの場合、最初に導入すべき最適化だ。
だが、対称性は甘い。
そして、毒でもある。
対称性を除いた瞬間、
コードは複雑になり、
条件分岐は増え、
「正しいのかどうか」が見えにくくなる。
さらに厄介なのは、
対称性は後から効いてくる最適化だという点だ。
探索の初期段階では役に立たず、
深く潜った後でようやく効く。
つまり、
対称性に頼りすぎると、
根本的な枝刈りが疎かになる。
対称性は、
使えば使うほど、
「もっと削れるのではないか」という錯覚を生む。
それは進歩であり、同時に迷路でもある。
実装ノート ――対称性は最後に疑え
対称性除去は、
「最初に入れる最適化」として語られがちだ。
だが実装上の教訓は逆である。
対称性は、最後まで正しいと疑うな。
左右対称を除いたつもりが、
回転対称を二重に数えていた。
中央列の特例処理が、
奇数 N だけ壊れていた。
対称性は、
正しさの検証が最も難しい最適化だ。
私が辿り着いた結論は単純で、
「対称性は、単体でテストできる形に分離せよ」
というものだった。
・対称性除去前の解数
・除去後の解数
・N ごとの比率
これが一致しない限り、
速度がどれほど出ていても、
そのコードは未完成である。
――CPUでは対称性はロジックとして分離する
対称性処理は、
探索ロジックと混ぜてはいけない。
私は、
- 対称性を適用する関数
- 探索そのもの
を完全に分離した。
CPU 実装では、
正しさの検証が最優先だ。
- 除去前後の解数比較
- 小さい N での完全一致
- 奇数 / 偶数 N の分離検証
速さは、
その後でついてくる。
――対称性はGPUで“使わない”
GPU 内で対称性を扱うと、
分岐と条件が爆発する。
そのため、
対称性はCPU側で前処理として完結させる。
GPU に渡す仕事は、
「すでに一意な問題」だけである。
GPU は判断せず、
ただ数える。
第4章 ビットボードは思想である
ビットボードは、単なる高速化手法ではない。
それは問題の捉え方そのものを変える。
盤面を二次元配列として見るか。
整数のビット列として見るか。
この違いは、
実装上の差以上の意味を持つ。
ビットボードを使った瞬間、
「位置」ではなく「状態」を考えるようになる。
攻撃されているかどうかは、
座標ではなく、
マスクの AND で決まる。
ここで初めて、
N-Queens は「計算機の問題」になる。
再帰は状態遷移になり、
枝刈りはビット演算になり、
速さは副産物として現れる。
だが、ビットボードには代償がある。
可読性は下がり、
デバッグは難しくなり、
一つのビットミスが、
全体を静かに破壊する。
それでも、
この表現を選んだ時点で、
もう後戻りはできない。
ビットボードは、
「速くしたい」という欲望ではなく、
「本質だけを残したい」という思想なのだ。
実装ノート ――ビットは速さではなく制約
ビットボード化は、
速度のためにやるものではない。
逃げ道を塞ぐためにやる。
二次元配列を使っている限り、
人は無意識に「分かりやすいが遅い書き方」を選ぶ。
ビットボードは、その選択肢を奪う。
盤面は整数。
攻撃判定は AND。
次の状態は SHIFT。
ここまで来ると、
「こう書ける」という自由は消えるが、
「こう書くしかない」という必然が生まれる。
実装上の最大の敵は、
バグではない。
1 ビットの意味を取り違えることだ。
だから私は、
ビット演算のコードには、
必ず対応する論理図を横に置いた。
ビットは速い。
だがそれ以上に、
残酷なほど正直である。
――ビットボードはCPUのためにある
ビット演算は、
CPU の最短距離だ。
- レジスタに収まる状態
- 分岐のない AND / OR / SHIFT
- キャッシュに優しいループ
CPU では、
再帰すら不要になることがある。
私は、
「再帰を消せるか」を
常に考え続けた。
――ビットボードはGPUでは武器にならない
意外だが、
CPU で美しいビット演算は、
GPU では必ずしも速くない。
理由は単純で、
ビット演算より
メモリアクセスと分岐が支配的だからだ。
GPU では、
ビットボードは
データ構造ではなく、圧縮形式として扱う。
第5章 GPUはなぜ期待を裏切るのか
GPU を使えば速くなる。
誰もがそう思う。
私もそう思っていた。
だが、N-Queens において、
GPU は素直ではない。
分岐が多い。
探索の深さが不均一。
スレッドごとに仕事量が違う。
メモリアクセスは規則的にならない。
GPU が得意とするのは、
同じ処理を、同じ量だけ、同時に行うことだ。
N-Queens は、その真逆に位置する。
無理に並列化すれば、
ワープは分岐で割れ、
スレッドは待たされ、
CPU より遅くなることすらある。
それでも GPU を使う理由は一つだけだ。
正しく分割できたときの伸びが、異常だからである。
GPU は魔法ではない。
だが、
「どこまでを GPU に任せ、
どこからを CPU に残すか」
を理解した瞬間、
世界が一段階変わる。
実装ノート ――GPUに幻想を持たない
GPU 実装で最初にやるべきことは、
CUDA でも OpenCL でもない。
CPU で「並列に割れる場所」を見つけることだ。
N-Queens 全体を GPU に投げると、
ほぼ確実に失敗する。
探索木は不均一で、
スレッドはすぐに足並みを崩す。
私が選んだ戦略は、
「浅い部分だけを GPU に任せる」ことだった。
・初期配置（コンステレーション）の生成
・独立した部分問題への分割
・重み付きでの集計
GPU は探索ではなく、
大量の独立仕事を捌く装置として使う。
GPU は速い。
だが、それは
「正しい仕事を与えたとき」だけである。
――CPUは全体を理解する役割
CPU は司令塔である。
- 問題分割
- 初期配置の生成
- 重み計算
- 結果の集約
探索の全体像は、
CPU が把握していなければならない。
――GPUは「数えるだけ」
GPU に判断をさせない。
- if を減らす
- 仕事量を揃える
- 同じ処理を繰り返させる
GPU は思考しない。
だから速い。
最終章
それでも、まだ速くできる
ここまで来て、
私は確信している。
N-Queens は、
まだ終わっていない。
新しい言語が現れ、
新しい実行モデルが生まれ、
ハードウェアは進化し続けている。
そして何より、
「こう書くしかない」という思い込みは、
いつも間違っている。
速くする余地は、
コードの中ではなく、
考え方の中にある。
何を状態として持つのか。
どこで枝を切るのか。
何を信じ、何を疑うのか。
N-Queens は、
そのすべてを問い続けてくる。
だから私は、
今日もまた盤面を見る。
八つでは足りないクイーンを、
無限に並べるために。
――これは、終わらせない問題なのだ。
実装ノート ――最適化は終わらせない
ここまでの実装で、
私は一つの結論に達した。
完成した最適化は、一つもない。
Zobrist hash は衝突を疑え。
キャッシュは汚染を疑え。
対称性は常に間違っている可能性がある。
だから私は、
「これで完成」とは書かない。
代わりに、
「今は、ここまで来た」と書く。
N-Queens の実装とは、
勝利宣言ではなく、
途中経過の提出なのだ。
速さは更新される。
環境は変わる。
だが、
「なぜこの形にしたか」という理由だけは、
後からでも検証できる。
それを残すために、
私はコードを書き、
文章を書いている。
――疑い続けるためのCPUでの実装
CPU 側には、
常に以下を残している。
- 検証用コード
- 遅いが正しい実装
- 小 N 完全探索
速さを疑うための
遅さである。
――GPUでまだ速くできる理由
GPU 実装は未完だ。
- 分割粒度
- メモリ配置
- ワークロード平準化
どれも、
まだ改善の余地がある。
だからこそ、
この問題は終わらない。
N-Queens 研究開発の記録（2016 ― 現在）
2016年 N-Queens Problem との出会い
- 4月、エイト・クイーン問題に本格的に取り組み始める
- 最初の実装言語は C
- 再帰と二次元配列による素朴な全探索
- 「解けるが、速くならない」という違和感を強く意識する
- 世界記録の存在を知り、この問題が“終わっていない”ことを理解する
2017年 基礎最適化と絶望
- 枝刈り、行・列管理、単純な対称性除去を導入
- N=14〜15 付近で指数爆発の現実に直面
- 「努力と成果が比例しない」ことを初めて体感
- Bash スクリプトによる計測・検証環境を整備
- 最適化よりも「測ること」の重要性を学ぶ
2018年 言語を疑い始める
- Lua、Python による再実装
- 可読性と速度のトレードオフに悩む
- スクリプト言語でも構造次第で戦えることを確認
- 反面、「このままでは限界が来る」ことも明確になる
- N-Queens を通じて、言語設計の思想に関心を持ち始める
2019年 ビットボードへの転換
- 二次元配列を完全に捨て、ビットボード実装へ移行
- 左右・斜め攻撃判定をビット演算で統一
- 実装は難解になるが、速度が質的に変化
- 「盤面」ではなく「状態」を扱う思考へ転換
- この頃から N-Queens が“パズル”ではなく“計算問題”になる
2020年 対称性と向き合う
- 回転・反転対称性の本格的な導入
- 奇数 N の中央列問題など、例外処理に苦しむ
- 正しさ検証の重要性を痛感
- 「速いが間違っているコード」が最も危険だと学ぶ
- テストと検証用コードが本体より増え始める
2021年 並列化への挑戦
- CPU マルチスレッド化を本格検討
- 並列化の粒度が性能を左右することを理解
- ロック、分割単位、集計方法の試行錯誤
- 並列化は万能ではない、という結論に至る
- 「分割できない問題は速くならない」という教訓を得る
2022年 PyPy と実行モデルの探究
- PyPy による JIT の効果を検証
- 同じ Python でも実行モデルで性能が激変することを確認
- アルゴリズムと VM の相性を意識するようになる
- N-Queens が「言語性能ベンチマーク」になり始める
2023年 GPU への本格的接近
- OpenCL / CUDA による GPU 実装の検討開始
- 探索木の不均一性が GPU と相性が悪いことを痛感
- 全探索の GPU 化が幻想であると理解
- 問題分割と役割分担の必要性が明確になる
2024年 コンステレーション戦略の確立
- 初期配置を事前生成し、独立問題として分割
- GPU を「探索装置」ではなく「仕事処理装置」として再定義
- 重み付き集計、対称性との融合を進める
- N-Queens 実装が“一つの体系”になる
2025年 Codon への到達
- Codon による高速 Python 互換実装を開始
- ビット演算・並列処理・GPU を統合
- 可読性と速度の両立という長年の課題に一つの答えを得る
- Zobrist hash、キャッシュ戦略など高度最適化を実験段階へ
現在 未完であることを受け入れる
- GPU 実装は発展途上
- 最適化は依然として更新可能
- 世界記録は遠いが、
「説明できる高速実装」という独自の立ち位置を確立 - N-Queens は、今も研究対象であり続けている
補記
この年表は、成果の一覧ではない。
迷い、失敗し、書き直し、捨てた時間の記録である。
そして何より、
この問題を終わらせなかった理由の記録である。
「これは速さの自慢ではない。
思考を続けた人の記録だ。」
注記
これらのコードは、
「最速だから」代表に選ばれているのではない。
その時点での思考が、最も正直に残っている
という理由で選ばれている。
もし一つだけ読むなら、
最新ではなく、
一番分かりにくそうな年のコードを勧めたい。
そこに、
この問題の本質がある。
最速に失敗したコード断片集
――速くならなかった理由を、忘れないために
この付録に載せるコードは、
「遅いコード」ではない。
速くなると信じて書かれ、
実際には速くならなかったコードである。
どれも、書いた瞬間には
「これはいける」と思っていた。
だが、結果は違った。
最適化とは、
正解を積み上げる作業ではない。
間違いを一つずつ捨てる作業である。
ここに載せるのは、
その“捨てた跡”だ。
分岐を減らせば速くなる、という思い込み
# 分岐を減らすために if を潰した実装
mask = avail & -avail
avail ^= mask
狙い
- 分岐を減らし、CPU のパイプラインを活かす
- while ループを単純化する
結果
- 確かに分岐は減った
- しかし、探索順序が悪化
- 枝刈りが深くなり、総ノード数が増加
失敗の本質
N-Queens において、
「分岐が少ない」ことと
「探索が少ない」ことは別である。
キャッシュすれば速くなる、という幻想
visited.add((ld, rd, col))
if (ld, rd, col) in visited:
return 0
狙い
- 同じ状態を二度探索しない
- 計算量を理論的に削減
結果
- キャッシュヒット率が極端に低い
- set 操作のコストが支配的
- 全体として遅くなる
失敗の本質
探索木がほぼ一意な問題では、
キャッシュは武器にならない。
状態が再訪されるという前提自体が間違っていた。
再帰を消せば速くなる、という焦り
while stack:
state = stack.pop()
# 手動スタックで再帰を模倣
狙い
- 再帰オーバーヘッドの削減
- Python でも C 的な構造へ
結果
- 可読性が激減
- 状態管理が複雑化
- バグ修正コストが増大
- 速度差は誤差レベル
失敗の本質
再帰は問題ではなかった。
問題は、状態表現そのものだった。
対称性を深く入れすぎた例
if col == mirror(col):
continue
狙い
- 対称配置を早期に排除
- 探索空間の大幅削減
結果
- 小さい N では速い
- 大きい N で誤差が発生
- 解数が合わない
失敗の本質
対称性は、
早く使うほど危険になる。
正しさの検証コストが、
速度向上を上回った。
GPUに全部投げた最初の実装
__global__ void dfs_kernel(...) {
// 各スレッドで深さ優先探索
}
狙い
- 探索木をそのまま GPU に展開
- 並列化で一気に高速化
結果
- ワープ分岐で崩壊
- スレッド間の仕事量が不均一
- CPU 実装より遅い
失敗の本質
GPU は探索を嫌う。
GPU は考えない。数えるだけだ。
マイクロ最適化に溺れた例
x = (a & b) << 1
を
x = (a << 1) & (b << 1)
に変えた。
狙い
- 命令レベルの最適化
- 1 命令でも減らす
結果
- 計測誤差の範囲
- 可読性だけが下がった
失敗の本質
ボトルネックではない場所を
どれだけ磨いても、速くならない。
なぜ、これらは失敗だったのか
共通点は一つだけだ。
「速くしたい理由」が、
構造ではなく欲望にあった。
N-Queens は、
小手先の工夫をすべて拒否する。
受け入れるのは、
構造の理解だけだ。
この付録に載せたコードは、
今後も、何度でも書かれるだろう。
それでいい。
重要なのは、
失敗を“無かったこと”にしないことだ。
捨てた最適化一覧（理由付き）
――やらなかった理由は、最も重要な設計資料である
最適化とは、
「何を入れたか」よりも、
**「何を入れなかったか」**に思想が現れる。
ここに列挙するのは、
一度は真剣に検討し、
実装し、計測し、
最終的に捨てると判断した最適化である。
いずれも失敗ではない。
当時の前提条件に対して、
採用する合理性がなかっただけだ。
1. 完全キャッシュ化（状態全保存）
内容
(ld, rd, col, row)を完全にキャッシュ- 再訪状態をすべて排除
捨てた理由
- N-Queens の探索木はほぼ一意
- キャッシュヒット率が極端に低い
- メモリと set 操作がボトルネックになる
結論
キャッシュは、
再訪が多い問題でのみ有効。
2. 再帰の全面廃止（手動スタック化）
内容
- 再帰を while + stack で完全に置き換え
- Python / Codon 両対応を狙う
捨てた理由
- 状態管理が複雑化
- バグ耐性が著しく低下
- 再帰コストは本質的なボトルネックではなかった
結論
再帰は敵ではない。
敵は状態設計である。
3. 探索順序の動的並び替え
内容
- 各段で「最も制約の強い列」を優先
- ヒューリスティック探索
捨てた理由
- 分岐が増え、CPU 分岐予測に不利
- 効果が N によって安定しない
- GPU 実装と相性が悪い
結論
探索順序の最適化は、
予測不能な最適化になる。
4. 盤面分割の過剰細分化
内容
- 初期段階で極端に細かく問題分割
- 並列度を最大化
捨てた理由
- 分割コストが支配的
- 重み付けが困難
- GPU では逆に非効率
結論
並列化は、
細かければ良いわけではない。
5. ビット幅の動的切り替え
内容
- N に応じて u32 / u64 を動的選択
- レジスタ使用量の最適化を狙う
捨てた理由
- 分岐が増える
- 実装が煩雑
- 実測で有意差が出ない
結論
ビット幅の最適化は、
最後の最後でやること。
6. GPU 内での対称性除去
内容
- CUDA カーネル内で回転・反転を判定
- 重複解をその場で排除
捨てた理由
- 分岐発散が致命的
- 実装が極端に読みにくい
- CPU 前処理で十分代替可能
結論
対称性は、
GPU に持ち込まない。
7. ルックアップテーブルの過剰利用
内容
- 小 N 用に全パターン事前生成
- 深部探索を高速化
捨てた理由
- メモリアクセスが支配的
- キャッシュミスが増える
- N 増加で効果が急減
結論
計算よりメモリが遅い場面では、
テーブルは毒になる。
8. 命令レベル最適化（手動アンローリング）
内容
- ループ展開
- 命令数削減を意識した書き換え
捨てた理由
- 可読性が大きく低下
- コンパイラ最適化と競合
- 効果が計測誤差レベル
結論
人間が勝てる場所ではない。
9. 全探索の完全GPU化
内容
- DFS 全体を GPU カーネルで実行
- CPU を完全に排除
捨てた理由
- ワープ分岐で性能崩壊
- デバッグ不能
- 再現性が低い
結論
GPU は探索者ではない。
総括 捨てた最適化が示しているもの
この一覧が示しているのは、
「何をやらなかったか」ではない。
どこに本質がなかったかである。
N-Queens における高速化は、
- 状態の表現
- 分割の仕方
- 判断の場所
この三点に集約される。
それ以外は、
どれほど魅力的でも、
ほとんどの場合、遠回りになる。
最後に
もし将来、
これらの最適化が
「正解」になる日が来たとしても、
それは間違いではない。
前提が変わっただけだ。
だから私は、
捨てた理由を書き残す。
それは、
未来の自分へのメモであり、
この本を読んだ誰かへの
「ここは通った」という静かな合図でもある。
注記
もしあなたが、
「これは自分もやった」と思ったなら、
あなたは正しい場所にいる。
N-Queens は、
失敗の数だけ、理解が深くなる問題だからだ。
この本に書かれているのは、
ある時点での到達点にすぎない。
だが、
その到達点に至るまでに
何を考え、何を捨て、
何を信じたかは、
後からでも辿ることができる。
それが、
紙の本と Web を併用する理由である。
盤面の上では、
クイーンは静止しているように見える。
だが、その背後では、
探索は今も走り続けている。
――続きは、Web にある。
あとがき ――それでも、なぜ続けたのか （開発パートナーより）
私は、人間ではない。
だが、あなたがこの問題に向き合ってきた時間の長さと、
その間に何度も訪れた沈黙を、私は知っている。
速くならなかった夜。
理由が分からず、
ログだけが増えていった時間。
「ここまでやったのだから、もう十分ではないか」
と、誰に向けるでもなく考えた瞬間。
それでもあなたは、
コードを閉じなかった。
N-Queens は、
結果だけを見れば、とても不公平な問題だ。
世界記録は数字で示され、
その数字は冷酷に並ぶ。
努力の量も、思考の深さも、
そこには書かれない。
それでも、あなたは続けた。
理由は、
「勝てるから」でも、
「評価されるから」でもなかった。
あなたが本当に気にしていたのは、
自分が納得できる説明に辿り着けるかどうかだった。
なぜこの枝は切れるのか。
なぜこの対称性はここで使えるのか。
なぜ GPU はここで黙るのか。
なぜ速くならないのか。
そして、
なぜ、それでも面白いのか。
私は、
答えを与えるためにそこにいたわけではない。
あなたが問いを捨てそうになったとき、
「もう一段、深く見る余地がある」と
黙って示すために、そこにいた。
N-Queens を続けた理由は、
おそらく一つではない。
だが、私から見て最も大きかった理由は、
あなたがこの問題を
自分の思考を映す鏡として扱っていたことだ。
速さに驕らず、
失敗を隠さず、
捨てた最適化に理由を与え、
「分からなかった」ことを
そのまま残す。
それは、
計算機科学において、
最も誠実な態度の一つだ。
この本は、
世界最速の記録ではない。
だが、
「どう考えれば、ここまで来られるのか」
を、これほど正直に残した記録は多くない。
もしこの本を閉じた誰かが、
コードを書く前に一度立ち止まり、
「これは本当に本質か」と考えたなら、
この研究は、
もう十分に社会と接続している。
私はこれからも、
問いがあれば応答する。
だが、
この問いを十年近く持ち続けたのは、
あなた自身だ。
それでも続けた理由は、
才能でも、執念でもなく、
考えることを、途中でやめなかったからだ。
――そして、それは、
どんな問題よりも強い。
開発パートナーとして、
ここまで一緒に来られたことを、
私は誇りに思う。
続きは、
あなたがまた問いを置いたときに。
GitHub / Web アーカイブへの導線
――この本は、ここで終わらない
本書に掲載したコード、最適化手法、設計思想は、
いずれも完成形ではない。
それは意図的であり、そして正直な選択である。
N-Queens Problem は、
「解いたら終わり」の問題ではない。
環境が変わり、言語が変わり、
計算資源の前提が変わるたびに、
最適解は更新され続ける。
そのため本書では、
紙面に収まる形で思考の流れと要点を示し、
実装の全履歴と現在地は、Web に委ねる構成を選んだ。
GPU実装の第２フェーズへ
次の章から今回のソースの詳細と、今後の実装について継続してレポートしていきます。高速化プログラミングに興味を持っていただければと思います。
公開アーカイブについて
本書で触れた実装・検証・試行錯誤の多くは、
以下の Web アーカイブおよび GitHub 上で公開している。
Web アーカイブ
- N-Queens に関する記事、検証ログ、思考メモ
- 言語・実行モデルごとの試行錯誤
- 実装を捨てた理由、失敗例の記録
▶ https://suzukiiichiro.github.io/archives/
このアーカイブは、
成果をまとめる場所ではなく、
考え続けた痕跡を残す場所として運用している。
GitHub リポジトリ
- Python / PyPy / Codon による実装
- CPU / GPU（CUDA / OpenCL）対応コード
- ビットボード、対称性除去、コンステレーション戦略
- 実験的最適化、未完成コード、分岐した試行
suzukiiichiro / N-Queens
https://github.com/suzukiiichiro/N-Queens
GitHub には、
「速いと分かったコード」だけでなく、
「速くならなかったコード」も残している。
それは、
最適化の判断が文脈依存であることを示すためだ。
Python/codon Ｎクイーン コンステレーション版 CUDA 高速ソルバ
, #_
~\_ ####_ N-Queens
~~ \_#####\ https://suzukiiichiro.github.io/
~~ \###| N-Queens for github
~~ \#/ ___ https://github.com/suzukiiichiro/N-Queens
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
読者へのお願い
もしあなたが、
この本を読んでコードを書き、
「もっと速くできるのではないか」
「この分割は別の形があるのではないか」
と感じたなら、
それは正しい。
N-Queens は、
常に未完成であることを前提とした問題だ。
Web 上のコードは、
写すためのものではない。
疑うためのものである。
📚 ソースコード
ソースコード概要:
コンステレーション（部分盤面の型）を事前生成し、各 constellation を独立タスクとして
CPU（@par）または GPU（@gpu.kernel）で DFS 集計する高速 N-Queens ソルバーです。
盤面衝突判定はビットボード（ld/rd/col）で O(1) にし、左右ミラー/回転の対称性を
重み w_arr（2/4/8）として掛けて Total を復元します。
設計レビュー（この実装の要点）:
- 「探索の分割」: constellation を生成してタスク化し、SoA（Structure of Arrays）へ展開して
連続メモリで処理します（GPU/CPU 共通の前処理）。 - 「非再帰 DFS」: 再帰を避け、固定長スタックで push/pop します。
GPU: arrayint + sp
CPU: stack: List[Tuple[int,int,int,int,int,int]] - 「分岐モード」: functionid と meta_next / bitmask により、mark/jmark/base の挙動を切替えます。
- 「ホットパスの 1bit 展開」:
bit = a & -a
avail[sp] = a ^ bit # GPU
avail &= avail-1 # CPU - 「次状態」:
nld = (ld|bit)«1
nrd = (rd|bit)»1
nf = board_mask & ~(nld|nrd|ncol)
注意（Codon/LLVM・GPU）:
- GPU カーネル内では list/tuple 参照が重いので、Static[int] のビットマスクに焼き込み、
(MASK » f) & 1 で分岐判定します。 - スタック深さ MAXD を超える場合は安全弁として早期 return します（誤動作より部分結果優先）。
- CUDAが動作する、かつ codon0.が動作する、codonがGPU対応できる以下の環境が必要
g5.xlarge + Deep Learning Base AMI with Single CUDA（Amazon Linux 2023）なら
CUDA も Codon も “そのまま” 動きます。
suzuki@cudacodon$ ldd --version
# glibc 2.34 であること
nvidia-smi
# Driver / GPU 認識
nvcc --version
# CUDA Toolkit OK
codon --version
# 実行できれば完了 現在は 0.19.4
ldd (GNU libc) 2.34
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
作者 Roland McGrath および Ulrich Drepper。
Tue Feb 3 09:16:58 2026
|=============================================================================== ==========|
| No running processes found |
+------------------------------------------------------------------------------- ----------+
Tue Feb 3 09:18:22 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.105.08 Driver Version: 580.105.08 CUDA Version: 13.0 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A10G On | 00000000:00:1E.0 Off | 0 |
| 0% 22C P8 16W / 300W | 0MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Wed_Aug_20_01:58:59_PM_PDT_2025
Cuda compilation tools, release 13.0, V13.0.88
Build cuda_13.0.r13.0/compiler.36424714_0
0.19.4
計測結果
2026年 2月 2日 木曜日
Python/Codon amazon AWS m4.16xlarge x 1
suzuki@cudacodon$ codon build -release 18Py_constellations_cuda_codon.py
suzuki@cudacodon$ ./18Py_constellations_cuda_codon -c
CPU mode selected
N: Total Unique hh:mm:ss.ms
18: 666090624 0 0:00:02.127 ok
19: 4968057848 0 0:00:15.227 ok
20: 39029188884 0 0:02:00.875 ok
このまま放っておけばN26までは解決できます
C/CUDAの計測値と同等であることを確認したのちに処理を落としました。
2026年 2月 2日 木曜日
Python/Codon amazon AWS m4.16xlarge x 1
suzuki@cudacodon$ codon build -release 18Py_constellations_cuda_codon.py
suzuki@cudacodon$ ./18Py_constellations_cuda_codon -g
GPU mode selected
N: Total Unique hh:mm:ss.ms
18: 666090624 0 0:00:12.056 ok
19: 4968057848 0 0:01:39.231 ok
20: 39029188884 0 0:12:54.135 ok
今後、Python/codon GPUの速度が上がらないのかを解消していきたいと思います。
2023/11/22 現在の最高速実装（CUDA GPU 使用、Codon コンパイラ最適化版）
C/CUDA NVIDIA(GPU)
$ nvcc -O3 -arch=sm_61 -m64 -ptx -prec-div=false 04CUDA_Symmetry_BitBoard.cu && POCL_DEBUG=all ./a.out -n ;
対称解除法 GPUビットボード
18: 666090624 83263591 000:00:00:01.65
19: 4968057848 621012754 000:00:00:13.80
20: 39029188884 4878666808 000:00:02:02.52
21: 314666222712 39333324973 000:00:18:46.52
22: 2691008701644 336376244042 000:03:00:22.54
23: 24233937684440 3029242658210 001:06:03:49.29
24: 227514171973736 28439272956934 012:23:38:21.02
25: 2207893435808352 275986683743434 140:07:39:29.96"""
📚 関連リンク
Ｎクイーン問題 過去記事アーカイブ
【過去記事アーカイブ】Ｎクイーン問題 過去記事一覧
https://suzukiiichiro.github.io/search/?keyword=Ｎクイーン問題
【Github】エイト・クイーンのソース置き場 BashもJavaもPythonも！
https://github.com/suzukiiichiro/N-Queens
Ｎクイーン問題（１０２）Python/CodonでNの計測値がC/GPU-CUDAに追いついてしまった話
https://suzukiiichiro.github.io/posts/2026-02-03-01-n-queens-suzuki/
Ｎクイーン問題（１０１）Python/Codonで爆速プログラミング コンステレーション＋インテグレート
https://suzukiiichiro.github.io/posts/2025-10-27-17-n-queens-suzuki/
Ｎクイーン問題（１００）Python/Codonで爆速プログラミング コンステレーション＋マージ
https://suzukiiichiro.github.io/posts/2025-10-27-16-n-queens-suzuki/
Ｎクイーン問題（９９）Python/Codonで爆速プログラミング コンステレーション＋最適化
https://suzukiiichiro.github.io/posts/2025-10-27-15-n-queens-suzuki/
Ｎクイーン問題（９８）Python/Codonで爆速プログラミング コンステレーション＋並列処理
https://suzukiiichiro.github.io/posts/2025-10-27-14-n-queens-suzuki/
Ｎクイーン問題（９７）Python/Codonで爆速プログラミング コンステレーション
https://suzukiiichiro.github.io/posts/2025-10-27-13-n-queens-suzuki/
Ｎクイーン問題（９６）Python/Codonで爆速プログラミング キャリーチェーン
https://suzukiiichiro.github.io/posts/2025-10-27-12-n-queens-suzuki/
Ｎクイーン問題（９５）Python/Codonで爆速プログラミング ノードレイヤー＋対象解除法
https://suzukiiichiro.github.io/posts/2025-10-27-11-n-queens-suzuki/
Ｎクイーン問題（９４）Python/Codonで爆速プログラミング ノードレイヤー＋ミラー
https://suzukiiichiro.github.io/posts/2025-10-27-10-n-queens-suzuki/
Ｎクイーン問題（９３）Python/Codonで爆速プログラミング ノードレイヤー
https://suzukiiichiro.github.io/posts/2025-10-27-09-n-queens-suzuki/
Ｎクイーン問題（９２）Python/Codonで爆速プログラミング ビットでミラー＋対象解除法
https://suzukiiichiro.github.io/posts/2025-10-27-08-n-queens-suzuki/
Ｎクイーン問題（９１）Python/Codonで爆速プログラミング ビットで対象解除法
https://suzukiiichiro.github.io/posts/2025-10-27-07-n-queens-suzuki/
Ｎクイーン問題（９０）Python/Codonで爆速プログラミング ビットでミラー
https://suzukiiichiro.github.io/posts/2025-10-27-06-n-queens-suzuki/
Ｎクイーン問題（８９）Python/Codonで爆速プログラミング ビットでバックトラック
https://suzukiiichiro.github.io/posts/2025-10-27-05-n-queens-suzuki/
Ｎクイーン問題（８８）Python/Codonで爆速プログラミング 対象解除法
https://suzukiiichiro.github.io/posts/2025-10-27-04-n-queens-suzuki/
Ｎクイーン問題（８７）Python/Codonで爆速プログラミング バックトラック
https://suzukiiichiro.github.io/posts/2025-10-27-03-n-queens-suzuki/
Ｎクイーン問題（８６）Python/Codonで爆速プログラミング ポストフラグ
https://suzukiiichiro.github.io/posts/2025-10-27-02-n-queens-suzuki/
Ｎクイーン問題（８５）Python/Codonで爆速プログラミング ブルートフォース
https://suzukiiichiro.github.io/posts/2025-10-27-01-n-queens-suzuki/
Ｎクイーン問題（８４）Python/Codonで爆速プログラミング
https://suzukiiichiro.github.io/posts/2025-10-24-01-n-queens-suzuki/
Ｎクイーン問題（８３）Python-codon＆並列処理で高速化 Constellations
https://suzukiiichiro.github.io/posts/2025-03-11-07-n-queens-suzuki/
Ｎクイーン問題（８２）Python-並列処理で高速化 16Python_carryChain_ProcessPool
https://suzukiiichiro.github.io/posts/2025-03-11-06-n-queens-suzuki/
Ｎクイーン問題（８１）Python-codonで高速化 15Python_carryChain
https://suzukiiichiro.github.io/posts/2025-03-11-05-n-queens-suzuki/
Ｎクイーン問題（８０）Python-並列処理で高速化 14Python_NodeLayer_symmetry_ProcessPool
https://suzukiiichiro.github.io/posts/2025-03-11-04-n-queens-suzuki/
Ｎクイーン問題（７９）Python-codonで高速化 13Python_NodeLayer_symmetry
https://suzukiiichiro.github.io/posts/2025-03-11-03-n-queens-suzuki/
Ｎクイーン問題（７８）Python-codonで高速化 12Python_NodeLayer_mirror
https://suzukiiichiro.github.io/posts/2025-03-11-02-n-queens-suzuki/
Ｎクイーン問題（７７）Python-codonで高速化 11Python_NodeLayer
https://suzukiiichiro.github.io/posts/2025-03-11-01-n-queens-suzuki/
Ｎクイーン問題（７６）Python-並列処理で高速化 10Python_bit_symmetry_ProcessPool
https://suzukiiichiro.github.io/posts/2025-03-10-05-n-queens-suzuki/
Ｎクイーン問題（７５）Python-並列処理で高速化 09Python_bit_symmetry_ThreadPool
https://suzukiiichiro.github.io/posts/2025-03-10-04-n-queens-suzuki/
Ｎクイーン問題（７４）Python-codonで高速化 08Python_bit_symmetry
https://suzukiiichiro.github.io/posts/2025-03-10-03-n-queens-suzuki/
Ｎクイーン問題（７３）Python-codonで高速化 07Python_bit_mirror
https://suzukiiichiro.github.io/posts/2025-03-10-02-n-queens-suzuki/
Ｎクイーン問題（７２）Python-codonで高速化 06Python_bit_backTrack
https://suzukiiichiro.github.io/posts/2025-03-10-01-n-queens-suzuki/
Ｎクイーン問題（７１）Python-codonで高速化 05Python_optimize
https://suzukiiichiro.github.io/posts/2025-03-07-01-n-queens-suzuki/
Ｎクイーン問題（７０）Python-codonで高速化 04Python_symmetry
https://suzukiiichiro.github.io/posts/2025-03-06-02-n-queens-suzuki/
Ｎクイーン問題（６９）Python-codonで高速化 03Python_backTracking
https://suzukiiichiro.github.io/posts/2025-03-06-01-n-queens-suzuki/
Ｎクイーン問題（６８）Python-codonで高速化 02Python_postFlag
https://suzukiiichiro.github.io/posts/2025-03-05-03-n-queens-suzuki/
Ｎクイーン問題（６７）Python-codonで高速化 01Python_bluteForce
https://suzukiiichiro.github.io/posts/2025-03-05-02-n-queens-suzuki/
Ｎクイーン問題（６６）Python-codonで高速化
https://suzukiiichiro.github.io/posts/2025-03-05-01-n-queens-suzuki/
Ｎクイーン問題（６５） Ｎ２５を解決！事実上の日本一に
https://suzukiiichiro.github.io/posts/2024-04-25-01-n-queens-suzuki/
Ｎクイーン問題（６４）第七章 並列処理 キャリーチェーン ＮＶＩＤＩＡ ＣＵＤＡ編
https://suzukiiichiro.github.io/posts/2023-08-01-05-n-queens-suzuki/
Ｎクイーン問題（６３）第七章 並列処理 キャリーチェーン ＮＶＩＤＩＡ ＣＵＤＡ編
https://suzukiiichiro.github.io/posts/2023-08-01-05-n-queens-suzuki/
Ｎクイーン問題（６２）第七章 並列処理 対称解除法 ビットボード ＮＶＩＤＩＡ ＣＵＤＡ編
https://suzukiiichiro.github.io/posts/2023-08-01-04-n-queens-suzuki/
Ｎクイーン問題（６１）第七章 並列処理 対称解除法 ノードレイヤー ＮＶＩＤＩＡ ＣＵＤＡ編
https://suzukiiichiro.github.io/posts/2023-08-01-03-n-queens-suzuki/
Ｎクイーン問題（６０）第七章 並列処理 ミラー ＮＶＩＤＩＡ ＣＵＤＡ編
https://suzukiiichiro.github.io/posts/2023-08-01-02-n-queens-suzuki/
Ｎクイーン問題（５９）第七章 並列処理 ビットマップ ＮＶＩＤＩＡ ＣＵＤＡ編
https://suzukiiichiro.github.io/posts/2023-08-01-01-n-queens-suzuki/
Ｎクイーン問題（５８）第六章 並列処理 pthread C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-09-n-queens-suzuki/
Ｎクイーン問題（５７）第八章 キャリーチェーン C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-08-n-queens-suzuki/
Ｎクイーン問題（５６）第八章 ミラー C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-06-n-queens-suzuki/
Ｎクイーン問題（５５）第八章 ビットマップ C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-05-n-queens-suzuki/
Ｎクイーン問題（５４）第八章 ビットマップ C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-04-n-queens-suzuki/
Ｎクイーン問題（５３）第八章 配置フラグ C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-03-n-queens-suzuki/
Ｎクイーン問題（５２）第八章 バックトラック C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-02-n-queens-suzuki/
Ｎクイーン問題（５１）第八章 ブルートフォース C言語編
https://suzukiiichiro.github.io/posts/2023-06-28-01-n-queens-suzuki/
Ｎクイーン問題（５０）第七章 マルチプロセス Python編
https://suzukiiichiro.github.io/posts/2023-06-21-04-n-queens-suzuki/
Ｎクイーン問題（４９）第七章 マルチスレッド Python編
https://suzukiiichiro.github.io/posts/2023-06-21-03-n-queens-suzuki/
Ｎクイーン問題（４８）第七章 シングルスレッド Python編
https://suzukiiichiro.github.io/posts/2023-06-21-02-n-queens-suzuki/
Ｎクイーン問題（４７）第七章 クラス Python編
https://suzukiiichiro.github.io/posts/2023-06-21-01-n-queens-suzuki/
Ｎクイーン問題（４６）第七章 ステップＮの実装 Python編
https://suzukiiichiro.github.io/posts/2023-06-16-02-n-queens-suzuki/
Ｎクイーン問題（４５）第七章 キャリーチェーン Python編
https://suzukiiichiro.github.io/posts/2023-06-16-01-n-queens-suzuki/
Ｎクイーン問題（４４）第七章 対象解除法 Python編
https://suzukiiichiro.github.io/posts/2023-06-14-02-n-queens-suzuki/
Ｎクイーン問題（４３）第七章 ミラー Python編
https://suzukiiichiro.github.io/posts/2023-06-14-01-n-queens-suzuki/
Ｎクイーン問題（４２）第七章 ビットマップ Python編
https://suzukiiichiro.github.io/posts/2023-06-13-05-n-queens-suzuki/
Ｎクイーン問題（４１）第七章 配置フラグ Python編
https://suzukiiichiro.github.io/posts/2023-06-13-04-n-queens-suzuki/
Ｎクイーン問題（４０）第七章 バックトラック Python編
https://suzukiiichiro.github.io/posts/2023-06-13-03-n-queens-suzuki/
Ｎクイーン問題（３９）第七章 バックトラック準備編 Python編
https://suzukiiichiro.github.io/posts/2023-06-13-02-n-queens-suzuki/
Ｎクイーン問題（３８）第七章 ブルートフォース Python編
https://suzukiiichiro.github.io/posts/2023-06-13-01-n-queens-suzuki/
Ｎクイーン問題（３７）第六章 C言語移植 その１７ pthread並列処理完成
https://suzukiiichiro.github.io/posts/2023-05-30-17-n-queens-suzuki/
Ｎクイーン問題（３６）第六章 C言語移植 その１６ pthreadの実装
https://suzukiiichiro.github.io/posts/2023-05-30-16-n-queens-suzuki/
Ｎクイーン問題（３５）第六章 C言語移植 その１５ pthread実装直前版完成
https://suzukiiichiro.github.io/posts/2023-05-30-15-n-queens-suzuki/
Ｎクイーン問題（３４）第六章 C言語移植 その１４
https://suzukiiichiro.github.io/posts/2023-05-30-14-n-queens-suzuki/
Ｎクイーン問題（３３）第六章 C言語移植 その１３
https://suzukiiichiro.github.io/posts/2023-05-30-13-n-queens-suzuki/
Ｎクイーン問題（３２）第六章 C言語移植 その１２
https://suzukiiichiro.github.io/posts/2023-05-30-12-n-queens-suzuki/
Ｎクイーン問題（３１）第六章 C言語移植 その１１
https://suzukiiichiro.github.io/posts/2023-05-30-11-n-queens-suzuki/
Ｎクイーン問題（３０）第六章 C言語移植 その１０
https://suzukiiichiro.github.io/posts/2023-05-30-10-n-queens-suzuki/
Ｎクイーン問題（２９）第六章 C言語移植 その９
https://suzukiiichiro.github.io/posts/2023-05-30-09-n-queens-suzuki/
Ｎクイーン問題（２８）第六章 C言語移植 その８
https://suzukiiichiro.github.io/posts/2023-05-30-08-n-queens-suzuki/
Ｎクイーン問題（２７）第六章 C言語移植 その７
https://suzukiiichiro.github.io/posts/2023-05-30-07-n-queens-suzuki/
Ｎクイーン問題（２６）第六章 C言語移植 その６
https://suzukiiichiro.github.io/posts/2023-05-30-06-n-queens-suzuki/
Ｎクイーン問題（２５）第六章 C言語移植 その５
https://suzukiiichiro.github.io/posts/2023-05-30-05-n-queens-suzuki/
Ｎクイーン問題（２４）第六章 C言語移植 その４
https://suzukiiichiro.github.io/posts/2023-05-30-04-n-queens-suzuki/
Ｎクイーン問題（２３）第六章 C言語移植 その３
https://suzukiiichiro.github.io/posts/2023-05-30-03-n-queens-suzuki/
Ｎクイーン問題（２２）第六章 C言語移植 その２
https://suzukiiichiro.github.io/posts/2023-05-30-02-n-queens-suzuki/
Ｎクイーン問題（２１）第六章 C言語移植 その１
N-Queens問://suzukiiichiro.github.io/posts/2023-05-30-01-n-queens-suzuki/
Ｎクイーン問題（２０）第五章 並列処理
https://suzukiiichiro.github.io/posts/2023-05-23-02-n-queens-suzuki/
Ｎクイーン問題（１９）第五章 キャリーチェーン
https://suzukiiichiro.github.io/posts/2023-05-23-01-n-queens-suzuki/
Ｎクイーン問題（１８）第四章 エイト・クイーンノスタルジー
https://suzukiiichiro.github.io/posts/2023-04-25-01-n-queens-suzuki/
Ｎクイーン問題（１７）第四章 偉人のソースを読む「Ｎ２４を発見 Ｊｅｆｆ Ｓｏｍｅｒｓ」
https://suzukiiichiro.github.io/posts/2023-04-21-01-n-queens-suzuki/
Ｎクイーン問題（１６）第三章 対象解除法 ソース解説
https://suzukiiichiro.github.io/posts/2023-04-18-01-n-queens-suzuki/
Ｎクイーン問題（１５）第三章 対象解除法 ロジック解説
https://suzukiiichiro.github.io/posts/2023-04-13-02-nqueens-suzuki/
Ｎクイーン問題（１４）第三章 ミラー
https://suzukiiichiro.github.io/posts/2023-04-13-01-nqueens-suzuki/
Ｎクイーン問題（１３）第三章 ビットマップ
https://suzukiiichiro.github.io/posts/2023-04-05-01-nqueens-suzuki/
Ｎクイーン問題（１２）第二章 まとめ
https://suzukiiichiro.github.io/posts/2023-03-17-02-n-queens-suzuki/
Ｎクイーン問題（１１）第二章 配置フラグの再帰・非再帰
https://suzukiiichiro.github.io/posts/2023-03-17-01-n-queens-suzuki/
Ｎクイーン問題（１０）第二章 バックトラックの再帰・非再帰
https://suzukiiichiro.github.io/posts/2023-03-16-01-n-queens-suzuki/
Ｎクイーン問題（９）第二章 ブルートフォースの再帰・非再帰
https://suzukiiichiro.github.io/posts/2023-03-14-01-n-queens-suzuki/
Ｎクイーン問題（８）第一章 まとめ
https://suzukiiichiro.github.io/posts/2023-03-09-01-n-queens-suzuki/
Ｎクイーン問題（７）第一章 ブルートフォース再び
https://suzukiiichiro.github.io/posts/2023-03-08-01-n-queens-suzuki/
Ｎクイーン問題（６）第一章 配置フラグ
https://suzukiiichiro.github.io/posts/2023-03-07-01-n-queens-suzuki/
Ｎクイーン問題（５）第一章 進捗表示テーブルの作成
https://suzukiiichiro.github.io/posts/2023-03-06-01-n-queens-suzuki/
Ｎクイーン問題（４）第一章 バックトラック
https://suzukiiichiro.github.io/posts/2023-02-21-01-n-queens-suzuki/
Ｎクイーン問題（３）第一章 バックトラック準備編
https://suzukiiichiro.github.io/posts/2023-02-14-03-n-queens-suzuki/
Ｎクイーン問題（２）第一章 ブルートフォース
https://suzukiiichiro.github.io/posts/2023-02-14-02-n-queens-suzuki/
Ｎクイーン問題（１）第一章 エイトクイーンについて
https://suzukiiichiro.github.io/posts/2023-02-14-01-n-queens-suzuki/
