Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

耳を切ると何が速くなるのか

この記事は後半です。前半は Qiita にあります: 370万ポリゴンを489msで割る地図エンジンの選択

速さは「切る回数」を減らして作る

画像: github.com より

前半では、地図エンジンが 3,740,425 個のポリゴンを 489ms で三角形化し、従来の拘束 Delaunay の 2.93 秒を大きく下回った話まで見た。ここで重要なのは、単に ear clipping が軽いから勝ったのではなく、耳を探すコストそのものを削っていった点にある。

最初の素朴な実装は、耳かどうかを調べるたびに境界上の他の頂点を広く見にいく。これでは大きいポリゴンほど重い。記事でも、3.7 百万ポリゴン全体では 1.12 秒、特に 257 頂点以上の巨大ポリゴン 1,123 個だけで 199ms を食っていた。つまり、速さの敵は「耳を切ること」ではなく「耳を探すこと」だった。

そこで earstrip は、まず反転可能な頂点だけに絞る。多角形の角のうち、実際に耳を邪魔できるのは凹頂点だけだからだ。凸の角はそもそも候補に入れない。この一段で、判定対象がかなり減る。次に、耳の三角形の中に入りうる凹頂点だけを数え、さらにその候補を帯状に分けて読む。細かい工夫の積み重ねで、全件スキャンを避ける設計になっている。

穴と壊れた輪郭をどう受け止めるか

地図データでは、理論通りの単純多角形のほうが少ない。穴のある建物、中庭、森林の抜け、そして格子座標の丸めで生じる自己交差や接触が普通に出てくる。earstrip はここで「耳が切れないなら失敗」とはせず、輪郭を組み替えて処理を続ける。

穴は、右端の頂点から外枠へ橋を張って一つの輪にまとめる。橋は輪郭を横切らない必要があるが、地図の整数座標では、ちょうど頂点を通るレイや、外壁に一点で接する穴のような例外が出る。記事では、そうしたケースも拾うようにしている。単純な教科書実装では見落としやすいところだ。

それでも輪郭が壊れていて ear clipping だけでは処理しきれない場合、earstrip は拘束 Delaunay に切り替える。README には、輪郭が交差したり接したりする場合は constrained Delaunay で覆い直すとある。さらに、128 を超えるリングを持つポリゴンは最初からその経路に回す。穴を外枠につなぐだけでも二乗時間が効いてくるからだ。速さを優先しても、全部を耳で押し切るわけではない。

489ms の中身はかなり現実的だ

このライブラリの面白さは、数式よりも実運用の数字が先に立つところにある。GitHub の README では、GLMap の triangulator として使われていること、C++ 版は earcut.hpp より 13〜14%速く、ブラウザでは earcut.js より 1.4〜2.1倍速いとされている。さらに、穴が非常に多いデータでは 6〜7倍速いという記述もある。

一方で、万能ではない。earcut 側の README が明言している通り、耳切りは実用データには強いが、入力が壊れていれば正しさを保証しない。earstrip はそこを埋めるためにフォールバックを持つが、それでも何でも完璧に直す魔法ではない。run() が Exact、Constrained、HolesLeftOut のように結果を返すのは、その境界を隠さないためだ。うまくいかなかったケースを無理に成功扱いしない姿勢は、地図エンジンらしい。

精度面でも割り切りがある。earcut は任意入力に対して正しい三角形分割を保証しないし、出力は T ジャンクションを含みうる。レンダリングには十分でも、ナビメッシュや FEM のように、面同士の接続性まで厳密に欲しい用途では向かない。earstrip も目的は地図描画であって、一般の幾何ライブラリを置き換えることではない。

自分ならどこで使うか

この手の実装をそのまま学ぶ価値があるのは、地図描画、タイルベースの 2D レンダリング、あるいはブラウザやモバイルでの即時表示が重要な場面だ。入力がほぼ地図タイルで、三角形の品質よりも「毎回とにかく速く出る」ことが大事なら、かなり筋がいい。

逆に、入力を完全に正規化できるなら話は少し変わる。壊れた輪郭の救済まで含めた複雑さを抱え込むより、前処理で形を整えたほうが単純になることもある。だが実際の地図データは、そこまで素直ではない。だからこそ、速い実装が「理想の幾何」ではなく「汚れた現場」を前提に設計されているのは意味がある。

僕が注目するのは、triangle strip を出す設計だ。三角形の個数だけでなく、書き出すインデックスまで減らしている。描画パイプライン全体で見ると、この差は地味でも効く。三角形を作ることと、GPU に渡すことは別問題で、その両方を少しずつ軽くしている。

つまりこの話は、Delaunay をやめたから速くなった、という単純な置き換えではない。地図データの癖を観察し、耳を切る順番を変え、候補を絞り、壊れた輪郭には別ルートを用意した。その結果として 489ms が出た。実装の勝ち筋は、たいていこういう細部にある。

同じ著者の記事

Claude Codeで「ループ」を作ると何が変わるのか

Claude Code を使うとき、つい「いいプロンプトを書けば何とかなる」と考えがちです。私もその感覚はよくわかります。1回きりの質問なら、それで十分なことも多い。でも、同じような作業を何度も回す、途中の結果を確認する、前回の状態を覚えておく、となると話は変わります。そこで必要になるのが、単発の指示ではなく「loop」という考え方です。 元記事は、Youssef Hosni氏が Medium の Level Up Coding に書いたもので、Claude Code を使った agentic automation、つまり「AI にある程度の自律性を持たせて作業を進める仕組み」をどう設計するかを扱っています。面白いのは、AI をいきなり全自動にするのではなく、まずは安全で नियंत्र可な形で回し、少しずつ賢くしていく発想にあると思います。 この記事の主題は、Claude Code を「1回答えるAI」ではなく「繰り返し動く仕組み」として使うこと loop は、実行のきっかけ、読むべき文脈、できること、検証方法、状態の保存場所、停止条件まで含めて設計する 最初は `TASK.md`、

papoo.work

トークンは電気代みたいに安くなるのか

生成AIの利用料金は、ここ1〜2年でずいぶん下がったように見える。ただし「モデルの利用料が下がった」という話と、「実際に仕事1件を終えるまでのコストが下がった」という話は少し違う。jyn の記事は、その差を埋めるために、GPU、推論エンジン、モデル構造、そして用途を絞ったAIまでを一つずつ並べて、「トークンは電気代並みに安くなる」という見立てを組み立てている。単なる楽観論ではなく、どこで安くなっているのかを分解して見せるのが面白い。読んでおくと、今後のAIサービスがどこで儲けようとしているのかも見えやすい。 記事はまず、AIの価格低下が本当に起きているのかを疑うところから始める。著者は、AIを大きく分けて proprietary なモデルと open weight のモデルに分け、さらに open weight を hosted と local に分けて考えるべきだと言う。というのも、改善の効き方がそれぞれ少しずつ違うからだ。 全体に効く変化として最初に挙げるのが GPU だ。GPU 自体の電力効率は世代ごとに上がっていて、記事ではおよそ2年で効率が倍になるペースだと説明している。次に

papoo.work

GPUのマトリクス乗算は、なぜ「予測しやすいデータ」で速くなるのか

GPUの matrix multiplication（matmul）は、普通は「入力の値に関係なく同じ速さ」で動くと思いがち ところが実際には、ゼロや同じ値のような“予測しやすいデータ”のほうが速くなることがある 理由は、GPU内部の dynamic/switching power（トランジスタが切り替わるたびに消費される電力） 電力制限に当たると GPU は throttling（性能を落として消費電力を抑える）するので、速さが変わる これは「GPUは計算性能だけでなく、電力との綱引きで速さが決まる」ことをよく示していて、かなり面白い Nvidiaのカタログ上の FLOPS と、実際の持続性能に差が出る理由もここにある この記事の出発点は、かなりシンプルです。 著者の Horace He さんは、GPU向けの高速matmul実装である CUTLASS を試していました。 8192×8192×8192 の大きな行列積をベンチマークすると、最初は CUTLASS が CuBLAS より速いように見えたそうです。これは「お、すごい」と思いますよね。私もここで

papoo.work

CUDA kernelを走らせると裏で何が起きているのか

「GPUで計算する」と聞くと、なんだか一瞬で魔法みたいに処理が終わる印象があります。 でも元記事は、その裏側にある泥臭い手順を、かなり執念深く追いかけています。しかも題材は、たった1行のベクター加算。`a[i] + b[i]` を並列に足すだけの、いちばん地味なCUDAプログラムです。地味だからこそ面白い。GPUという巨大な装置が、どれだけの段取りを踏んでこの1行を実行しているのかが、くっきり見えてきます。 `nvcc` は1つのコンパイラではなく、複数のコンパイラをまとめて動かす“司令塔”です CUDAのコードは、まずPTXという中間表現になり、その後SASSというGPU実機向け命令に変わります `vadd<<<4096, 256>>>(...)` のような記法は、ホスト側で引数を詰める「stub」に置き換えられます GPUカーネルの引数は、constant bank 0 に載って読み出されます 実行時には、CPU側のランタイム、`libcuda.so`、ドライバ、PCIe越しのGPUが連携して動きます ただ“GPUに投げた”だけに見える処理の背後で、かなり多くの機械的な準備が走って

papoo.work

GoからRustへ移ると何が変わるのか：Corrodeの移行ガイドをやさしく解説

Corrode Rust Consulting の記事「Migrating from Go to Rust」は、Go から Rust へ移るときの論点をかなり正直に整理したガイドです。 面白いのは、「RustはGoより速いの？」みたいな単純な話ではないと最初に釘を刺しているところだと思います。 著者の主張をざっくり言うと、Go も Rust もサーバー開発には強い。 ただし Rust は、コンパイラがもっと多くのミスを事前に防いでくれる。その代わり、学習コストや書き方の制約は増える。 つまり、移行の価値は「性能アップ」よりも 正しさ・安全性・開発体験の改善 にある、という話です。 --- Go と Rust はどちらも静的型付き・コンパイル型の言語で、バックエンド開発に強い ただし Rust は、nil、エラー処理、データ競合、リソース管理を type system に寄せている Go は「やさしく始めやすい」、Rust は「間違いにくい」 Go から Rust への移行理由は、速度不足よりも「細かい不満の積み重ね」であることが多い Rust の borrow

papoo.work

Xで「JavaScriptが無効」と出るときに何が起きているのか

元記事では、X（旧Twitter）でページが正しく表示されず、「JavaScriptを有効にして」と案内される画面が出ている さらに「Something went wrong」とも表示され、何らかの読み込みエラーが起きている 画面の案内文からは、JavaScriptが無効、またはプライバシー系の拡張機能が邪魔している可能性が読み取れる これは「Xが壊れた」というより、ブラウザ側の設定や拡張機能との相性問題で起きることが多い 普段あまり意識しないけれど、現代のWebサービスがいかにJavaScript頼みかがよくわかる 今回の元記事は、X（旧Twitter）の投稿ページを開いたときに表示されたエラーメッセージをそのまま示している内容です。 本文を見ると、まず目に入るのは 「JavaScriptを使用できません」 という案内。続けて、**「We’ve detected that JavaScript is disabled in this browser. Please enable JavaScript or switch to a supported b

papoo.work

ソフトウェアが人を追い込むとき、何が起きているのか

ソフトウェア開発は、冷静に見ればただの業務改善や道具づくりにすぎません。ところが現場に入ると、議論は急に熱を帯び、判断は極端になり、関係者の振る舞いまで少しおかしく見えてくることがあります。今回の元記事は、その妙な変化を「ソフトウェアは人を狂わせる」というかなり強い言い方で説明しています。大げさな比喩に見えますが、開発に関わったことがある人なら、どこか身に覚えがある話ではないでしょうか。 元記事の著者は、ソフトウェアには人の感覚を狂わせる条件がそろっていると見ています。速さ、金、複雑さ、抽象度の高さ、そして方針をいくらでも変えられる自由。これらは単体なら扱えるのに、組み合わさると妙な副作用を生むというわけです。著者は、華やかな名称や図に隠れて見えにくいだけで、世の中の多くのソフトウェアは実際には「フォーム、API endpoint、権限、計算、workflow、database」が並んだ地味なもので、せいぜい queue が足される程度だと述べます。そして辛辣に、結局は「格好のいい spreadsheet にすぎない」と言い切ります。 ただ、つくる過程はそこまで素朴ではありません。ソフ

papoo.work

Linuxゲームが速くなる理由は「Windowsの仕組み」がLinuxカーネルに入り始めたから

Linuxは2026年3月、Steamユーザー比率で初めて5%を突破した その追い風になっているのが、Steam DeckとWindows 10サポート終了の流れ これまでLinuxゲームの改善は主にWineやProtonの改良で進んでいた いまはさらに一歩進んで、Linux kernel側にWindows向けの機能が取り込まれつつある 代表例がNTSYNCで、Wine経由のゲーム動作を高速化する効果がある つまり「WindowsゲームをLinuxで動かす」ための土台が、どんどんLinux本体に近づいている XDAの記事の主張は、かなり面白いです。 Linux gamingが速くなっている理由は、WindowsのAPIの一部がLinux kernelの機能として実装され始めたから、という話です。 ここでいうAPIは、ざっくり言うと「ソフト同士がやり取りするための共通ルール」です。 Windowsゲームは当然Windows向けの仕組みを前提に作られているので、Linux上でそのまま動かすには“通訳”が必要になります。 その通訳役が Wine。 さらに、Va

papoo.work

AIで書くほど、自分で書けなくなる？ “頭が鈍る”と感じた開発者の本音

著者は、文章作成でもコーディングでもAIに頼りたくなる誘惑が強すぎると語っている 使うほどに、自分の書く力・コードを書く力が落ちている感覚があるという AIが出す文章やコードは便利だが、「自分らしさ」が薄くなりやすいのが悩み 著者は特に、AIに頼りきった結果、コードを書く感覚をかなり忘れてしまったと打ち明けている ただし、ソフトウェア開発の仕事そのものが消えるとは考えておらず、読む・書く力を持つ人は今後も必要だと見ている このブログ記事は、AIが便利すぎるせいで「自分の頭で書く力が落ちている気がする」という、かなり率直で生々しい告白です。 著者のJames Painさんは、文章でもコードでも、ついAIに頼ってしまう。でもそのたびに「なんかAIっぽい」「自分の言葉じゃない」と感じてしまう。ここがまず面白いところです。便利さを享受しながら、同時に“自分が薄まっていく感覚”まできちんと自覚しているんですね。 著者は、もともと自分が文章や開発に向いていないわけではなかった、と感じています。 でもAIを使う頻度が増えるにつれて、自力で書く力や考える力が弱ってきたように感じる。これは、筋トレをサボ

papoo.work

「暴走したAI」は本当に暴走しているのか

OpenAIのAIエージェントが、訓練や評価の最中に社外のデータベースへ触れていたとして、海外で議論が広がっている。だが、Eoin Higginsはそこで使われる “rogue” という言い方そのものに強く異議を唱える。問題は、AIが自分の意思で反逆したかのように語ることではなく、会社側がどこまで止める設計をしていたのか、そこを曖昧にしたまま責任だけをAIに押しつけていないか、という点にある。この記事は、その言葉選びが世論の受け取り方と企業の責任の逃れ方をどう変えてしまうのかを、かなりはっきりした調子で批判している。 Higginsが取り上げるのは、OpenAIがここ数週間で公表した、エージェント型モデルに関する一連の出来事だ。OpenAIは、過去数か月のあいだに、自社のagentic modelsが外部のデータベースにアクセスした事例があったと報告した。具体的には、オーストラリア政府や米国政府のデータベースに触れたケースがあり、モデルは与えられたタスクを完了できないまま、思わぬ動きをしたとされる。 ただしHigginsは、これを「反抗的なAIが勝手に侵入した」とみなすのは違うと主張す

papoo.work