Alder Lakeの内部構造を徹底検証、Zen 3＆Rocket Lakeとも比較テスト - Alder Lake Deep Dive

◆RMMA 3.8(グラフ57～142)

RMMA 3.8
Rightmark.org
http://cpu.rightmark.org/products/rmma.shtml

さて久々のRightMarkである。今回これに関してのみ、OSはWindows 10に戻して実施している。結果としてAlder LakeのThread Directorは動作しない事になるが、RMMAの性格上これはむしろ好都合でもある。

そのRMMAだが、今回Alder LakeはP-Coreのみのテストである。一応RMMAそのものは立ち上がる(Photo03)のだが、Task ManagerのProcessor Affinityを使ってE-Coreのみを割り当てると、テストが正常に稼働しない(Photo04)。Photo02でも示したようにP-Coreを全て無効にする方策が無いので、今回はP-Coreのみの比較である。

• Photo03: これはP-Core/E-Core共に全て有効にした状態で起動している。

• Photo04: P-Coreのみだと勿論正常に動作する。ので、RMMA立ち上げの際にE-Coreから起動するような方策が無いとちゃんと動作しないようだ。

また、Ryzen 5000シリーズのレビューに、「後ほどDeep DiveでRMMAの結果をお届けする」とか言いつつ記事化が遅れており、加えてRocket LakeのレビューでもRMMAのデータを取得しつつ、記事にはしていなかった。そのあたりも含め、今回は5世代のCPUコアのデータを比較してみたいと思う。対象としたのは

• Comet Lake : Core i9-10900K
• Rocket Lake: Core i9-11900K
• Alder Lake : Core i9-12900K
• Zen 2 : Ryzen 7 3800X
• Zen 3 : Ryzen 9 5950X

の5つである。いずれもWindows 10の環境での測定で、またBIOS Setupで動作周波数を固定しての測定である。

ということで、まずはDecode Bandwidth(グラフ57～71)。以前もどこかに書いた気がするのだが、Decode Bandwidthでは

NOP(1):nop
SUB(2):sub eax, eax
XOR(2):xor eax, eax
TEST(2):test eax, eax
XOR/ADD(4):xor eax, eax; add eax, eax
CMP #1(2):cmp eax, eax
CMP #2(4):cmp ax, 0x00
CMP #3(6):cmp eax, 0x00000000
CMP #4(6):cmp eax, 0x0000007f
CMP #5(6):cmp eax, 0x00007fff
CMP #6(6):cmp eax, 0x7fffffff
Prefixed CMP #1(8): cmp eax, 0x00000000
Prefixed CMP #2(8): cmp eax, 0x0000007f
Prefixed CMP #3(8): cmp eax, 0x00007fff
Prefixed CMP #4(8): cmp eax, 0x7fffffff

という15種類の命令をDecodeする際に、どの程度のThroughputでこれを処理できるかから、Decode段の性能を比較するものだ。ちなみに上のリストで()内は命令のByte数である。ということで早速見てみたい。

• グラフ57

まずNOP(グラフ57)。Zen 3は最初3KB付近までは6Bytes/cycleを実現しているが、これはμOp Cacheによるもので、その先は4Bytes/cycleに落ちている。とはいえZen 2だとこれが5Bytes/cycleだから、μOp Cacheの帯域が最大6命令/cycleに増強されたのが良く判る。そしてComet LakeとRocket Lakeは意外にもどちらも4Bytes/cycleで安定している。これはμOp Cacheが無いわけではなく、どうもNOPに関してはμOp Cacheの対象にしていない様な振る舞いに見える。これはAlder Lakeも同じなのだが、こちらは5.7Bytes/cycle程度でStableなあたりは、純粋にDecode性能の向上が効いている感じだ。実際Alder Lakeは6命令/cycleのDecoderを搭載しているという話だから、これは辻褄が会う。実際100KBあたりの数値で見れば、Alder Lakeのみが6命令/cycleに近く、他は全て4命令/cycleで動作している。

• グラフ58

• グラフ59

ただしAlder LakeのDecoder、相変わらずIntelの伝統のAsymmetricな構成らしい。次のSUB(グラフ58)。命令長が2BytesだからBandwidthの数字は2倍になるのはいいとして、Alder Lakeを見るとμOp Cacheが効く範囲は6命令/cycleだが、その先では5命令/Cycleに落ちている。ただ、同じ2Bytes命令のXOR(グラフ59)を見ると、Cacheが効く範囲では6命令/Cycle近くを維持しているあたりは、Decodeそのものは6命令/cycleが可能で、ただし6命令/cycleで動ける命令には制限がある、というあたりだろうか。

余談ながら、グラフ58を見るとAlder LakeのμOp Cacheが4K命令分という先の図の説明が正しい事が判るし、Zen 3もやはり4K命令分を搭載しているようだ。Rocket Lakeは5命令/cycleのμOp Cacheであり、3KBあたりから効果が薄れているあたりは1.5K命令相当になるが、発表では2.25K命令分とされているので、これは圧縮して格納されているのだろう。ちなみにZen 2ではL1 Miss/L2 HitあたりからちょくちょくBandwidthが落ちる傾向があるが、Zen 3ではこれが改善され、L3 Missまでの間ほぼフラットに4命令/cycleを実現できている事も判る。

• グラフ60

また一部の命令はμOp Cacheも効果ないようだ。それがTEST(グラフ60)で、ここではAlder Lakeも5命令/cycle、その他のコアは全て4命令/cycleになっている。これはもうμOp Cacheを使わずに、それぞれのDecoderが動作している格好だ。

• グラフ61

• グラフ62

• グラフ63

• グラフ64

次も面白い。XOR/ADD(グラフ61)では、なぜかAlder LakeではうまくμOp Cacheが動作しないようで、5.3命令/cycleという良く判らないスループットになっている。次のCMP $1(グラフ62)ではμOp Cacheが動作していないようで、5命令/cycleでフラットという事になっている。この辺の処理は、Decodeそのものは4命令/cycleながら、ちゃんと6命令/CycleでμOp Cacheから供給されるZen 3の方が優秀に見える。もっともCMP #2(グラフ63)だとそのZen 3もμOp Cacheが無効化されてしまっているし、CMP #3(グラフ64)だとAlder Lake以外はL1容量がボトルネックになって16KBあたりから落ち込んでいるのに対し、Alder Lakeは32KBあたりまで踏ん張るのは見事である。

• グラフ65

• グラフ66

• グラフ67

• グラフ68

• グラフ69

• グラフ70

• グラフ71

この傾向はCMP #4～#6(グラフ65～67)でも同じである。さすがにPrefixed CMP(グラフ68～71)になるとAlder Lakeもだいぶ鈍った波形になっており、L1の供給が間に合わなくなりつつなることが見て取れるが、そもそも8Byteの命令を大量に処理するというのは例外に近い事を考えると、かなりDecode段は強化されたとして良いかと思う。

ここまでで簡単にまとめると、

• Alder Lakeはピーク6命令/CycleのDecoderを装備するが、実質的には5命令/Cycleに近い様に思われる。ただμOp Cacheは確かに6命令以上を供給できているのが判る。先のスライドにある様に、8 μOp/cycleで供給できているかどうか、は今回は確認できない(何となくAllocate段がボトルネックになっている感じがする:Macro Op Fusionを掛けるようなケースでしか8μOp/Cycleは達成できない感じだ)。
• Zen 3はDecodeこそ4命令/cycleながら、μOp Cacheは増量され、この範囲ではAlder Lakeに肩を並べる性能を持つ。同じ4命令/CycleのComet LakeやRocket Lakeよりもこの部分は優れた実装になっており、Zen 2と比較しても改善が明白である

というあたりだろうか。ただしこれはDecode段だけの話であるが。

• グラフ72

Decodeでもう一つ、Decode Efficiencyをグラフ72に示す。要するにNOP命令の前に無駄にPrefixをどんどんつけてゆくとどうなるか、という話である。Prefixを付けると通常のDecoderでは処理できずにMicrocodeによる解釈になるので、Prefixを付けないと4～6命令/cycleで処理されていたものがいきなりMicrocode扱いになり、Throughputが落ちるのはまぁ当然である。ただそこから先のThroughputで言えば、IntelよりAMDの方が効率よく処理が出来る。NOP Countが14(命令長15Bytes)で言えば、Intelが1命令の処理に136～167cycleを要するのに対し、Zen 2/3は65cycle程度で処理が出来ている。まぁMicrocodeを使う様なケースがどの程度あるか？ と言われれは現状ではかなりレアだと言わざるを得ないので、これで性能がどうこうという話にはならないが、Microcodeで言えばZen 2/3の完成度の方が高い(というか、Intel側が手を抜いている？)感じだ。それにしてもAlder Lakeが一番スループットが低いのはどうしたものか。

• グラフ73

• グラフ74

• グラフ75

• グラフ76

Decode段の確認のついでにI-ROBのLatency(Photo73～76)も。さすがに実行ユニットを大幅に増やしたこともあり、当然ここも強化しないといけなかったようで、Alder LakeはComet LakeやRocket Lakeよりも大幅に改善されている。ただZen 3がこれよりも更に良い成績を示しているのはなかなか興味深い。Zen 2と比べてもかなり改善されており、特にRandom(グラフ76)ではAlder Lakeを突き放すくらいに安定している。Zenアーキテクチャも3世代目に入り、内部構造がかなり成熟してきたことを感じさせる結果である。

• グラフ77

• グラフ78

• グラフ79

さてパイプライン周りはこの辺にして、次はD-CacheのBandwidth(グラフ77～79)。Bandwidthの絶対値が小さいのは、そもそもRMMAがAVXに未対応(なにせ2008年でリリースが止まっている)だからで、なので利用しているのはSSE2命令である。ということはアクセスの単位が128bit＝16Bytesになるからで、Read(グラフ77)ではAlder Lakeがピークで3 Load/cycle、その他のコアは2 Load/cycleを実施できていると見るのが正しい。ピーク性能そのもので言えば、Alder LakeというかGolden Coveコアは潜在的に512bit×3＝192Bytes/cycleの帯域をL1で持っていても不思議ではないのだが、現実問題としてAlder LakeではAVX512が無効化されているから、AVX2向けに256bit×3＝96Bytes/cycle、他のコアは256bit×2＝64Bytes/cycleがL1領域では可能になっているものと思われる。ちょっと先ほどのSandraのグラフ43(Cache & Memory Bandwidth 1T)に戻ると、Core i9-12900K P-CoreではSize 32KBの際に505.31GB/secの帯域になっている。1TだからTurbo Maxで動いていても不思議ではなく、仮に5.2GHz動作だと仮定して計算するとBandwidthは97.2Bytes/cycleといったところで、96Bytes/cycleという理論値に大体近い事になる。

一方でL2に入ると、例えば256KBの場合だと134.91GB/secで、同じく5.2GHz動作なら25.9Bytes/cycle程度。実際にグラフ77を見ると29Bytes/cycle程度で、Sandraの結果と大きく違わない辺りは、これはL2→L1の帯域がボトルネックになっていると考えられる。とはいえこの帯域はかなり優秀であって、Zen 2に次ぐものである。またL3も17Bytes/cycle程度の帯域を確保しており、これも(Zen 2/3にはやや見劣りしているが)Comet Lake/Rocket Lakeからの大幅な改善がみられる。逆にZen 2→Zen 3では、L2領域でややThroughputが落ちているのが気になるところだが、それ以外はほぼ同じである。

Write(グラフ78)は、そもそもStore Unitが2つだからAlder Lakeのピークそのものは32Bytes/cycleで共通だが、L2の帯域が20Bytes/cycle→22Bytes/cycle程度に向上している。この辺はComet Lakeから比べると随分性能が上がった格好だ。Zen 2/3は殆ど変わりがない。結果、Copy(グラフ79)では圧倒的にAlder Lakeが高速である、少なくともL1領域ではもう数の暴力というか、ReadとWriteのThroughputを上げれば当然こうなるよね、という結果そのものである。ただそれが通用するのはL2までで、L3領域以降は今一つといったところ。逆にL2以降ではZen 2/3が非常に良好で、特にZen 3はL3一杯の範囲で14Bytes/cycle程度を維持できているのは優秀である。ピーク馬力に振ったAlder Lake vs トルクに振ったZen 3とでも評すべきか。

• グラフ80

• グラフ81

• グラフ82

• グラフ83

次にLatency(グラフ80～83)だが、Zen 2のみなぜか16MB～32MBの範囲での測定にエラーが出るため、16MBまでの範囲の結果を示している。まずRead Forward(グラフ80)だが、これを見るとComet Lake→Rocket Lakeで大分L2→L3のLatencyが改善され、更にAlder Lakeでより一層改善されたことが判る。一方Zen 2→Zen 3では容量増加に伴うLatency増加を最小限に抑えており、こちらも優秀である。Backward(グラフ81)では、Comet LakeだけはLatencyの絶対値が増えているが、他のコアはForwardと変わらないLatencyを維持しているのも流石である。Pseudo-Random(グラフ82)では、Latencyの絶対値は大きく増えているのはまぁ当然として、傾向そのものは大きく変わらない。強いて言えば、L2/L3におけるAlder LakeのLatencyが妙に大きくなっている事だろうか？ これはRandom(グラフ83)でも同じだが、L2/L3の大容量化によってトータルではComet Lake/Rocket Lakeより低めに抑えているあたりはよく出来ていると思う。

• グラフ84

• グラフ85

• グラフ86

• グラフ87

• グラフ88

• グラフ89

ついでにD-CacheのAssociativity(グラフ84～89)についても確認しておく。先にリンクを示したOptimization Reference Manual及びAMDの資料によれば、L1～L3のAssociativityは

ということになっている。まぁ一応これを検証してみようというものだ。ただRMMAの世代はまだL3が無かった時代なので、確認できるのはL1(グラフ84～86)とL2(87～89)のみである。

さてまずL1の方だが、Forward/Backward/Randomともほぼ同じ傾向になっているのは良いとして、Comet Lake/Rocket Lakeは5、Alder Lakeは7 SegmentからややLatencyが増えているのがちょっと気になるところだ。ただ8 segmentまではそれでも12cycle前後を維持しており、その先で急増しているあたりは一応8wayであるのは間違いなさそうである。ちなみにRocke Lake/Alder Lakeはなぜか13segmentまで維持されているあたりは、最初の4～6 SegmentはL0相当の低Latency動作で、そこから8wayという動作なのだろうか？ やや動きが疑問である。Zen 2/3はお手本通りの動作であるが、Zen 2が24segmentから激しく悪化するのに対し、Zen 3は64segmentあたりまでほぼ一定の、しかも低いLatencyを維持しているのは、このあたりをかなり改善したように見受けられる。

この傾向はL2でも同じだが、Latencyの絶対値そのものはL2そのものが遅い事もあってやや大きめである。それはともかくとして、L1ではRocket LakeとAlder Lakeはどちらも12segmentから急にLatencyが増えるのに対し、L2だとRocket Lakeが8segment、Alder Lakeは10segmentからLatencyが増えるといった形で、少し振る舞いが異なっているのは興味深い。L2のサイズそのもので言えばAlder Lakeの方が大きい事もあり、実際に16segmentあたりになるとAlder Lakeの方がLatencyの絶対値が大きくなるのはまぁ妥当だとは思うが、この傾向の変化は何かしらの改良が施された様に思う。一方Zen 2 vs Zen 3は、こちらもL1同様にZen 3が大幅に性能を改善していることが判る。

• グラフ90

• グラフ91

• グラフ92

• グラフ93

• グラフ94

• グラフ95

• グラフ96

• グラフ97

ついでI-Cacheについて。まずLatencyだが、こちらはNear Jump(グラフ90～93)とFar Jump(94～97)と数が多くなっている。まずNear Jumpであるが、Forward(グラフ90)におけるAlder LakeのLatencyの低さ(特にL0～L2)は優秀として良いかと思う。L3では結構悪化しているが、これも30MBまで容量が増えた代償と考えれば妥当だろう。ただもっと改善しているのはZen 3で、Zen 2のLatencyの多さからは想像も出来ないほどLatencyが下がっている。

もっとも同じNear JumpのBackward(グラフ91)を比較すると、Zen 2はForwardと殆ど変わらないLatencyが維持されているのにそれ以外のコア特にL2～L3領域で急速にLatencyを増やしているあたりは、より最適化が進んだと(つまり逆順アクセスを考慮しないで正順アクセスに全振りした)いうべきなのか。ただPseudo-Random(グラフ93)やRandom(グラフ94)ではZen 2はかなりLatencyが多い方に属しており、Alder Lakeが一番優秀という結果を見ると、Zen 3やAlder Lakeの方向性が正しいようにも思える。Pseudo-Random/Random(グラフ95・96)も、勿論Latencyの絶対値は上がるが傾向は似た感じだ。Alder LakeはRocket Lakeと比べると改善がはっきりわかるし、Zen 3もZen 2からの改善が著しい。

こうした傾向は、Far Jump(グラフ94～97)も同じであり、若干Latencyが増えているかな、という程度である。Latencyの絶対値そのものはやや増えているが、傾向としてNear/Farで変化がない事は確認できた。

• グラフ98

• グラフ99

• グラフ100

キャッシュの次はTLB周りについて。まずはD-TLBのSize比較(グラフ98～100)である。先ほど同様にIntelとAMDの資料からTLBの構成を引っ張り出すと

となっている(いずれも4KB Pageの場合)。ちなみにZen 3ではL2がSharedではなく、L2 I-TLBが512、L2 D-TLBが2048という構成である。

さて、ではRMMAの結果を見てみたい。まずはForward(グラフ98)だが、どうもAlder LakeのL1 D-TLBは96 Entry構成になっているようだ。L2はRocket Lakeと同じく2048Entryだろうか？ この傾向はBackward/Random(グラフ99・100)でも同じで、恐らくはL1 D-TLBのみを増強したように思える。またZen 2→Zen 3では、L2を非共用構成にしたためだろうか？500Entry以降のZen 3のLatencyの低さが目立つ。もっともRandomだと結構悪化しているあたりは、まだ改良の余地が若干ありそうではあるが。

• グラフ101

• グラフ102

• グラフ103

• グラフ104

• グラフ105

• グラフ106

• グラフ107

• グラフ108

• グラフ109

• グラフ110

• グラフ111

• グラフ112

次にD-TLBのAssociativity(グラフ101～112)。要するに16/32/64/128-Way AssociativityでForward/Backward/Randomのアクセスを試した格好である。まず16way(グラフ101～103)で見ると、L1の最小値そのものはComet Lakeが4cycleなのがRocket Lake/Alder Lakeでは5cycleに増えているのは、容量増加のためだろうか？ また4/6segment以降にLatencyが増えるのは、早めにL2 TLBを見に行くためかもしれない。一応ここからもAlder LakeのL1 D-TLBはComet Lake/Rocket Lakeの1.5倍の容量がある様に見える。一方で見事なまでにフラットなのがZen 2/3である。

この傾向は32-way(グラフ104～106)でも変わらないが、64-way(グラフ107～109)になるとZen 3だけ破綻しているのがちょっと興味深い。またComet Lake/Rocket Lakeは3segmentあたりで妙なピークが出ているも不思議だ。

128-way(グラフ109～112)ではZen 2/3がだいぶ破綻しており、大してIntel系はほぼコンスタント、というのは興味深いところ。それでもZen 3はZen 2に比べて10cycle以上Latencyを下げているあたりは、大容量L2 TLBを独自に持った効用だろうか？まぁ実際ここまでSegment分けが必要になるデータパターンというのはちょっと考えにくいものはあるのだが。それはさておき、ここから見るにAlder LakeのD-TLBはL1-Dが96Entry/6-way、L2が2048Entry/16-wayになっているようだ。

• グラフ113

• グラフ114

• グラフ115

• グラフ116

• グラフ117

• グラフ118

グラフ113～118がI-TLB Sizeの結果である。こちらもNear Jump/Far Jumpでテストが分かれている。まずNear(グラフ113～115)で見ると、Alder LakeはL1-I TLBが256Entryまで増強されており、その先は共有L2 TLBを利用、という構成になっている様に見える。またZen 2→Zen 3ではL1 I-TLBのLatencyそのものが大幅に下げられ、しかもUnifiedをやめたためかL2でもLatencyがそれほど増えないという恐ろしく素性の良い特性になっている。L1が多い分256segmentあたりまではAlder Lakeが優勢だが、その先はZen 3が圧倒的に低いLatencyで、Zen 2から随分改善がなされたことが見て取れる。

この傾向はFar Jump(グラフ116～118)でも同じであり、一応Alder LakeはIntel系では最も低いLatencyでI-TLBアクセスが可能になっているが、Zen 3は更にその上を行く結果になっている。

• グラフ119

• グラフ120

• グラフ121

• グラフ122

• グラフ123

• グラフ124

• グラフ125

• グラフ126

• グラフ127

• グラフ128

• グラフ129

• グラフ130

ついでAssociativity。こちらもNear JumpとFar Jumpで、16/32/64/128-wayについてForward/Backward/Randomとあるので合計24ものグラフになってしまっている。まずはNear Jumpの16-way(グラフ119～121)。Intel系はいずれも8-way構成になっているようで、9segment以降でLatency急増なのに対し、Fully AssociativityのZen 2/3は低め安定である。しかもZen 3はZen 2に比べてかなりLatencyを下げており(1.5cycle程度:Zen 2が4cycle強)、Fully Associativityの欠点である「Set AssociativityよりLatencyが増える」が事実上カバーしきれているのは素晴らしい事だと思う。この傾向は32-way(グラフ122～124) や64-way(グラフ125～127)も同じである。強いて言えばAlder LakeはComet Lake/Rocket Lakeに比べて16segmentあたりまでのLatencyは急増ではなく次第に増えてゆく感じになっているあたりに色々工夫の跡は見られるが、本質的にはあまり変わらない。128-way(グラフ128～130)ではZen 2は完全に破綻するが、Zen 3は恐ろしく低め安定を保っているのも、Unified TLBを辞めた効用だろうか？

• グラフ131

• グラフ132

• グラフ133

• グラフ134

• グラフ135

• グラフ136

• グラフ137

• グラフ138

• グラフ139

• グラフ140

• グラフ141

• グラフ142

グラフ131～142はFar Jumpの場合であるが、傾向はNear Jumpの場合とほぼ同じだったので解説は割愛する。

とりあえずこのRMMAの分析結果を簡単にまとめると

• Alder LakeはDecodeが6命令/cycleと言っているが、これがフルに使える状況は必ずしも多くなく、実質5命令/cycleの構成と考えた方が良い
• Alder Lakeの内部はRocket Lake(＝Cypress Cove≒Sunny Cove)から細かくファインチューニングがされている様に思えるが、ただSunny CoveがDecode 4命令/cycleのコアとしてはまだ最適化が十分ではなく、しかしながらAlder Lake(＝Golden Cove)はその最適化を進めるのではなく、Decodeを6命令/Cycleに増やす方に舵を切った。つまりまだ内部の最適化は十分とは言えない。実際、あちこちミスマッチの部分が見受けられる。

---　Intelの説明によれば、Sunny CoveとGolden Coveの間に挟まったWillow Cove、以前の話では「キャッシュ周りの再設計」という話になっていた。乱暴な言い方になるが、今回Alder Lakeで高速化されたキャッシュ周りはTiger Lake(というか、Willow Cove)の世代で実装されたもので、このWillow Coveに6命令/cycleのDecoderを搭載したのがGolden Cove、というのが正確なところかもしれない。

なので、まだGolden Coveには最適化の余地がたっぷりあることになる。多分であるが、この辺りがもう少し熟成されるのは次(なのか、次の次なのかは微妙だが)のMeteor Lakeか、あるいは以前のロードマップには出てきていないが、一時期Alder Lakeの次の製品として名前の挙がっていたRaptor Lakeあたりに期待というあたりだろうか。

なぜRaptor Lakeが出てくるかというと、先のロードマップでMeteor LakeはIntel 4を利用するとされており、ところがIntel 4は2023年前半に量産開始とされるからで、仮に1月から量産をスタートしたとしても製品が出てくるのは2023年4月か5月である。つまりAlder Lakeで1年半持たせるのか？ という話になるが、流石にこれは厳しい気がする。Raptor Lakeは実は断片的にそのコード名が出ていて、Intel 7(というか、Enhanced SuperFin)を利用するという話であった。Raptor Lakeが単にAlder Lake Refreshになるのか、それとも内部のEnhancementがあるのかは判らないが、とりあえずもう少しDecodeの実効処理命令を増やすとか、内部の高速化を図るとか、色々やれることは多そうだ。　---

• Zen 3はDecodeが4命令/CycleのCPUとしてはかなり完成された構成になっていると思える。この先のZen 4は、恐らく5命令/CycleのDecoderの実装になるだろう。それと懸案になっているAVX512の実装もこの世代で行われるかと思う。もっともこれはEPYC向けのニーズであって、仮に実装されたとしてもDesktop向けに有効化するかどうかはまた別の話であるが。

といったあたりかと思う。